[Bug 1409057] Re: ipxe does not take into account nic boot order specified in libvirt domain

Serge Hallyn 1409057 at bugs.launchpad.net
Wed Jan 14 16:46:44 UTC 2015


** Description changed:

+ ========================================================================
+ Impact: unable to specify nic boot order
+ Test Case: use the xml below to create a VM, and check that the 'boot order' is ignored.
+ Regression potential: This cherrypicks 4 patches from upstream, with no conflict at all, so I would not expect any regression.
+ ========================================================================
+ 
  I'm using libvirt 1.2.2 on Ubuntu 14.04 and the ipxe version is
  1.0.0+git-20131111.c3d1e78-2ubuntu1
  
  I created a KVM virtual machine with 3 network interfaces and I used the
  <boot order> libvirt option to specify the boot order among different
  vNICs as specified in
  http://libvirt.org/formatdomain.html#elementsNICSBoot
  
  This is the part of my libvirt xml file that describe the 3 defined
  network interfaces:
  
-  <interface type='direct'>
-       <mac address='52:54:00:00:00:01'/>
-       <source dev='vboxnet0' mode='vepa'/>
-       <model type='virtio'/>
-       <boot order='2'/>
-       <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
-     </interface>
-     <interface type='direct'>
-       <mac address='52:54:00:00:00:02'/>
-       <source dev='vboxnet1' mode='vepa'/>
-       <model type='virtio'/>
-       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
-     </interface>
-     <interface type='direct'>
-       <mac address='52:54:00:00:00:03'/>
-       <source dev='wlan0' mode='vepa'/>
-       <model type='virtio'/>
-       <boot order='1'/>
-       <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
-     </interface>
+  <interface type='direct'>
+       <mac address='52:54:00:00:00:01'/>
+       <source dev='vboxnet0' mode='vepa'/>
+       <model type='virtio'/>
+       <boot order='2'/>
+       <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+     </interface>
+     <interface type='direct'>
+       <mac address='52:54:00:00:00:02'/>
+       <source dev='vboxnet1' mode='vepa'/>
+       <model type='virtio'/>
+       <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
+     </interface>
+     <interface type='direct'>
+       <mac address='52:54:00:00:00:03'/>
+       <source dev='wlan0' mode='vepa'/>
+       <model type='virtio'/>
+       <boot order='1'/>
+       <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+     </interface>
  
  The first one (MAC 52:54:00:00:00:01) has boot order 2, the second one
  (MAC 52:54:00:00:00:02) has no boot order defined and the third one (MAC
  52:54:00:00:00:03) has boot order 1.
  
  The expected result should have been a DHCP bootstrap request sent first
  on the 3rd defined vNIC (boot order 1), then on 1st defined vNIC (boot
  order 2) and no more request sent (since there is no boot order defined
  for 2nd vNIC).
  
  The actual result is that a DHCP bootsrtap request is sent on all
  interfaces and not in the order specified, but from the one with lower
  to higher pci slot (that is the same order in which they are defined in
  the xml file).
  
  Here are the screenshots of the boot sequence:
  
  http://imgur.com/jWVFbMo,VNguYI3#0
  http://imgur.com/jWVFbMo,VNguYI3#1
  
  The same bug seems to be solved in Red Hat Enterprise Linux 7.0
  https://bugzilla.redhat.com/show_bug.cgi?id=1031518

** Changed in: ipxe (Ubuntu Trusty)
   Importance: Undecided => High

** Changed in: ipxe (Ubuntu Trusty)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipxe in Ubuntu.
https://bugs.launchpad.net/bugs/1409057

Title:
  ipxe does not take into account nic boot order specified in libvirt
  domain

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/1409057/+subscriptions



More information about the Ubuntu-server-bugs mailing list