On Wed, Dec 05, 2012 at 03:51:39PM +0200, Dan Kenigsberg wrote:
> On Tue, Dec 04, 2012 at 05:25:48AM -0500, Alon Bar-Lev wrote:
> > 
> > Thanks for this verbose description.
> > 
> > I don't think using libguestfs is the solution for this.
> 
> Yeah, it seems like a hack that would be quite hard to maintain for all
> supported guest operating systems.
> 
> > 
> > Fixing qemu to accept BIOS interface name at -net parameter is preferable. 
> > I don't think we should expose the interface a PCI device as it will have 
> > some drawbacks, but attempt to use the onboard convention.
> 
> I don't see a real use case for setting the bios name explicitly. After
> all, libvirt/vdsm/Engine is going to to allocate them according to their
> relative order. I'd be content with qemu providing a sane, reproducible,
> biosdevname for each nic.
> 
> Michael, would it be difficult to have?


This is not a qemu issue. This is a biosdevname/VMware issue.
biodevname has this code:

/*
  Algorithm suggested by:
  
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009458
*/

static int
running_in_virtual_machine (void)
{
    u_int32_t eax=1U, ecx=0U;

    ecx = cpuid (eax, ecx);
    if (ecx & 0x80000000U)
       return 1;
    return 0;
}

So it just looks for a hypervisor.

It should look at the hypervisor leaf
and either blacklist vmware specifically or whitelist kvm.

Please open (preferably urgent prio) bugzilla for biosdevname component
so we can fix it in F18, cc me.
I can write you a patch but maintainer needs to apply it.


> > 
> > Alon
> > 
> > ----- Original Message -----
> > > From: "Antoni Segura Puimedon" <asegu...@redhat.com>
> > > To: vdsm-devel@lists.fedorahosted.org
> > > Sent: Tuesday, December 4, 2012 11:08:31 AM
> > > Subject: [vdsm] Fedora, udev and nic renaming
> > > 
> > > Hi,
> > > 
> > > We are currently working on stabilizing the networking part of vdsm
> > > in Fedora
> > > 18 and, to achieve that purpose, we decided to test in in both
> > > physical hosts
> > > and, for extra convenience and better support, also in VMs.
> > > 
> > > Due to the move of Fedora 17 and 18 to systemd and newer udev
> > > versions, we
> > > encountered some issues that should be noted and worked on to provide
> > > our users
> > > with a hassle-free experience.
> > > 
> > > First of all, let me state what happens (in renaming) in RHEL-6.x
> > > when a new
> > > ethernet device is handled by udev:
> > > a) One or more udev rules match the characteristics of the interface:
> > > The last
> > > matching rule is applied.
> > > b) No rule is matching: /lib/udev/write-net-rules writes a permanent
> > > rule using the MAC address of the interface in a udev rules file, so
> > > the
> > > interface name will be permanent and in the ethX namespace.
> > > 
> > > In Fedora 17 (but even more so in F18), with the move to a newer
> > > version of
> > > udev and, specially, with the change from sysV init to systemd, the
> > > mechanism
> > > changed. Since systemd is making the boot happen in a parallelized
> > > way, some
> > > changes had to be enforced in udev to keep the renaming working:
> > > 
> > > - To avoid naming collisions, it was decided to use Dell's
> > > biosdevname software
> > >   to retrieve a device name for the network interfaces. Typically emX
> > >   for
> > >   onboard nics and pXpY for pci connected nics.
> > > - For devices which biosdevname could not provide any information, it
> > > was
> > >   agreed to assign them a name in the ethX space in a first-come,
> > >   first-served
> > >   fashion.
> > > - Optionally, one could define the interace MAC addr in an ifcfg file
> > >   and /lib/udev/rename-device would look into the ifcfg file and
> > >   assign
> > >   the device name there set (I have not yet succeeded in that part, I
> > >   have to
> > >   investigate more, I guess).
> > > 
> > > As you can see, biosdevname, never reports names in the eth space to
> > > avoid
> > > collision with a potential parallel discovery of an interface not
> > > recognizable
> > > by it, to which the kernel could have assigned already a bios
> > > reported name.
> > > 
> > > For physical machines this approach works fine. However, for Virtual
> > > machines
> > > with more than one nic, the automatic process described above
> > > presents some
> > > issues. Biosdevname, due to the different ways the virtualization
> > > hypervisors
> > > report the vnics, dropped support for VMs in 0.3.7 (F18 uses 0.4.1-2)
> > > and
> > > decided that on VMs, it would just return "4" to indicate to udev to
> > > use
> > > kernel first-come, first-served for those interfaces (ethX
> > > namespace).
> 
> Is this the case for all nic models (e100, rtl) or only to virtio?
> 
> > > 
> > > The issue with using first-come first-served, is that due to the
> > > highly
> > > parallelized boot there is now, it is very common to encounter that
> > > the names
> > > of your devices (as identified by MAC address) suffer a permutation
> > > upon each
> > > reboot. Here you can see an example:
> > > 
> > > NOTE: The libvirt dump of the VM reports the same PCI address for
> > > each
> > > interface across reboots.
> > > 
> > > Boot 0 (Nov 13th 14:59)
> > >     eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:54:85:57  txqueuelen 1000  (Ethernet)
> > >     eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:77:45:6b  txqueuelen 1000  (Ethernet)
> > >     eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:ca:41:c7  txqueuelen 1000  (Ethernet)
> > >     eth3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:f5:3d:c8  txqueuelen 1000  (Ethernet)
> > >     eth4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:5e:10:76  txqueuelen 1000  (Ethernet)
> > >     eth5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:95:00:93  txqueuelen 1000  (Ethernet)
> > > 
> > > Boot 1 (Nov 13th 15:01)
> > >     eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:ca:41:c7  txqueuelen 1000  (Ethernet)
> > >     eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:54:85:57  txqueuelen 1000  (Ethernet)
> > >     eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:77:45:6b  txqueuelen 1000  (Ethernet)
> > >     eth3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:f5:3d:c8  txqueuelen 1000  (Ethernet)
> > >     eth4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:5e:10:76  txqueuelen 1000  (Ethernet)
> > >     eth5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> > >         ether 52:54:00:95:00:93  txqueuelen 1000  (Ethernet)
> > > 
> > > As you can see, after rebooting:
> > > eth0 -> eth1
> > > eth1 -> eth2
> > > eth2 -> eth0
> > > 
> > > This is an issue if different vnics are connected to different
> > > networks or for
> > > whichever reason require distinct configuration. To solve this issue,
> > > on the
> > > guest there are three options:
> > > 
> > > - Assign somebody with BIOS knowledge to add KVM guest support to
> > > biosdevname
> > >   so we can use the emX/pXpY namespace and maintain a native like
> > >   experience in
> > >   the VMs. My intuition is that it could just report pXpY where X is
> > >   bus and Y
> > >   is slot. This is the preferred option.
> > > - Use libguestfs for setting udev rules using the MAC addresses we
> > > know from
> > >   the VM definition in the netX namespace (I have been told that it
> > >   is not
> > >   entirely safe to use emX namespace for this, but hopefully for VMs
> > >   this could
> > >   be done safely or, at least, pXpY).
> > > - Use libguestfs to provide ifcfg files that specify the vnics' MAC
> > > addresses
> > >   so they are picked up by udev's rename process (Have to find out
> > >   how to make
> > >   that work, as I have not managed to do it yet).
> > > 
> > > Best,
> > >  
> > > Toni
> > > 
> > > 
> > > PS: For physical machines, beware that some usb network devices don't
> > > have very
> > > original MAC addresses or don't have a mac address burned in
> > > (randomized at
> > > each boot) and, for this reason, they can create quite a lot of
> > > issues and more
> > > complicated (as in using bus and device and/or ID) udev rules should
> > > be used.
> > > _______________________________________________
> > > vdsm-devel mailing list
> > > vdsm-devel@lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > > 
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel@lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to