[Engine-devel] Predictable_vNIC_Order

[Dan Kenigsberg]

On Wed, Jan 29, 2014 at 02:07:00PM +0100, Michal Skrivanek wrote:
> 
> On Jan 29, 2014, at 08:05 , Meni Yakove <myakove at redhat.com> wrote:
> 
> > Hi,
> > 
> > On oVirt 3.4 there is new feature:
> > http://liver.englab.brq.redhat.com/redirect/?url=http://wiki.ovirt.org/Feature/Predictable_vNIC_Order
> > 
> > Right now the feature make sure that the VNIC ordering for VM is the same after create VM from template/snapshot/import.
> > For example:
> > 
> > On original VM VNIC1 attached to network blue and VNIC2 attached to network red and on the VM we have two interfaces ETH0 and ETH1, after creating template from this VM and create VM from the template the order of the VNICs are the same for the new VM.
> > On the VM from template the first VNIC is attached to blue network and the second VNIC is attached to red network but on the VM we have ETH2 and ETH3
> > 
> > I think that the feature should also include Sealing_Linux_VM:
> > http://www.ovirt.org/Sealing_Linux_VM
> 
> we do have a tentative feature to seal/reset Linux VM via virt-sysprep. Not targeted to a release yet...
> 
> > Whit this on the VM from template the interface naming will be the same as the original VM. (ETH0 and ETH1)
> 
> Where do you see the connection? (I'm not opposing/arguing, just curious what you have in mind how it should work)

In certain guest OS, most notably EL6, when a VM is first run, it
creates /etc/udev/rules.d/70-persistent-net.rules which persists the
mapping between mac addresses and interface names. If the VM is booted
again, this rule makes sure that the eth0 has the same mac address as
before.

This method breaks when the mac is changed while the VM was offline, or
when a new VM is cloned out of the original one (and is allocated with a
completely new set of mac addresses). Then, in a further run of the VM,
the old "eth0" would point no where, and a new eth4 would point to a
device with the new mac address. Fedora 20, with
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/,
no longer has this issue. But other OSes do.

To avoid this, any reference to the mac address has to be stripped
before the cloned VM is run. /etc/udev/rules.d/70-persistent-net.rules
needs to be tweaked/deleted, and HWADDR lines need to be fixed/dropped
from /etc/sysconfig/network-scripts/ifcfg-*.

http://www.ovirt.org/Sealing_Linux_VM would do this (and more) before a
template is created.

A more delicate question is what needs to be done before when we clone
from a template, or import a VM. In these conditions, we usually cannot
change the original VM before cloning, and it is less clear if we really
want to remove every bit of identity from the image.

IMO it would be great to call something like

    virt-sysprep --enable=net-hwaddr /path/to/cloned/image

just after a VM is cloned. Ideally, this could be done in an HSM async
task (one we have them). Until then, an SPM task would do.


Dan.