Bug 1038845

Summary:	Mapping of vNICs to networks changes when creating a VM template
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Josep 'Pep' Turro Mauri <pep>
Component:	ovirt-engine	Assignee:	Nobody <nobody>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	3.2.0	CC:	acathrow, ecohen, gcheresh, iheim, lpeer, masayag, nyechiel, pep, Rhev-m-bugs, yeylon
Target Milestone:	---	Keywords:	Triaged
Target Release:	3.4.0
Hardware:	All
OS:	Linux
Whiteboard:	network
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-02-19 13:16:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Network	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Josep 'Pep' Turro Mauri 2013-12-05 23:31:37 UTC

Description of problem:
When creating a template from an existing VM that has multiple vNICs (attached to different networks), sometimes the order of the vNICs in the resulting template is wrong. The VMs that are later generated from that template have the wrong vNIC/network mapping.

Version-Release number of selected component (if applicable):
Seen in a 3.2.z engine as well as a 3.3 beta.

How reproducible:
Unsure. When it happens for a particular VM it's consistently reproducible.

Steps to Reproduce:
1. Create a VM with 2 vNICs, e.g. 'nic1' and 'nic2'
2. Assign network 'net2' to 'nic1' and network 'net1' to 'nic2'
3. Create a template from the VM

Actual results:
The created template maps 'net1' to 'nic1' and 'net2' to 'nic2'

Expected results:
The net-vNIC mapping of the original VM is preserved

Additional info:
Note that this is not about vNIC ordering within a VM itself, e.g. when adding new vNICs. We believe BZ 737564 is a different issue.

Comment 1 Moti Asayag 2014-01-30 13:10:53 UTC

In ovirt-engine-3.3 the vNic profiles were introduced.
A vNic profile is the container which defines the association of a nic to a network. The vNic profile replaces the former direct association to a network.

I've tried to figure out how the described scenario might happen in 3.2, but couldn't find any lead to it: 
When a template is being created from a vm, the creation process clones the same vm interfaces (without mac address), so the association of "vnic name" to "network name" is preserved (AddVmTemplateCommand.addVmInterfaces()).

Could you suggest steps to reproduce this issue ?

Comment 2 Josep 'Pep' Turro Mauri 2014-01-31 17:38:51 UTC

(In reply to Moti Asayag from comment #1)
> I've tried to figure out how the described scenario might happen in 3.2, but
> couldn't find any lead to it: 
> When a template is being created from a vm, the creation process clones the
> same vm interfaces (without mac address), so the association of "vnic name"
> to "network name" is preserved (AddVmTemplateCommand.addVmInterfaces()).

I'm not too familiar with the code, but I'll give it a try: addVmInterfaces() doesn't seem to specify an order, but executeCommand() for AddVmTemplateCommand, after calling addVmInterfaces invokes VmDeviceUtils.copyVmDevices(), which iterates over the list returned by dao.getVmDeviceByVmId(), which orders by device_id.

Could it be that there's a mix up there?

Comment 4 Moti Asayag 2014-02-02 11:27:08 UTC

(In reply to Josep 'Pep' Turro Mauri from comment #2)
> (In reply to Moti Asayag from comment #1)
> > I've tried to figure out how the described scenario might happen in 3.2, but
> > couldn't find any lead to it: 
> > When a template is being created from a vm, the creation process clones the
> > same vm interfaces (without mac address), so the association of "vnic name"
> > to "network name" is preserved (AddVmTemplateCommand.addVmInterfaces()).
> 
> I'm not too familiar with the code, but I'll give it a try:
> addVmInterfaces() doesn't seem to specify an order, but executeCommand() for
> AddVmTemplateCommand, after calling addVmInterfaces invokes
> VmDeviceUtils.copyVmDevices(), which iterates over the list returned by
> dao.getVmDeviceByVmId(), which orders by device_id.
> 
> Could it be that there's a mix up there?

Doesn't seems like the source of the problem since the the network name and the vnic name are being persisted at the same time to the db. The correlation between them should be broken.

Comment 6 Nir Yechiel 2014-02-19 13:16:22 UTC

Since it looks like we can't reproduce it, I am closing this bug for now. Please re-open it if it happen again or if you are able to provide exact steps to reproduce.