Hide Forgot
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.
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 ?
(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?
(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.
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.