[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] libvirt: xen: do not use ioemu type for any emulated NIC



Hello Stefan,

On Wednesday 21 March 2012 09:24:04 Stefan Bader wrote:
> Unfortunately not true. You always get the enulated NIC, whatever you do
> with type=ioemu.
...
> From what I see (and at least from Xen side expect) is that you always get
> both. Whether you use default or a specific NIC type. The only way for your
> guest not to get an emulated device is to disable the pci-platform device
> in the config.
> Otherwise the Xen approach is to always present both and let the guest
> decide whether it is capable of using the pv devices (which are faster).
> Then the guest unplugs the emulated devices so there is no confusion. The
> goal there is to have one configuration on the hosting side which allows
> the guest to switch as it is capable.
>
> So currently with the default setting for the NIC, you get the implicit
> model or rtl8139 and the paravirt NIC. Newer Linux guests will, if they
> think they can handle paravirt devices, unplug the emulated interfaces
> (NICs and disks). I would expect a similar behavior from the Windows
> drivers. So with the default, there should be no need to change the model.
>
> However with the current libvirt, when you do select something like e1000,
> then the Xen configuration gets a type=ioemu added. But that does _not_
> prevent the paravirt interface to be present, its "just" unusable because
> it does not have a MAC address.

Yes, you're correct. Now that you mention the MAC adress, I remember seeing 
the netfront device with an all-zero-MAC-adress. I started writing the 
attached email some time ago, but never sent it because the libvirt behaviour 
was understandable and consistent: "If you specify a model, you only what 
that model (and not the netfront as well)".
That this behaviour makes switching from emulated to PV more complicates, is a 
different matter. I would appreciate a change in that behaviour as well, so 
+1 for your work.

Sincerely
Philipp
-- 
Philipp Hahn           Open Source Software Engineer      hahn univention de
Univention GmbH        be open.                       fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/
--- Begin Message ---
Hello,

This is a follow-up to [PATCH] Cut out "type=ioemu" on Xen3.1
<http://www.redhat.com/archives/libvir-list/2007-June/msg00050.html> and
[PATCH 0/2] Xen: Add support for interface model='netfront' 
<http://www.redhat.com/archives/libvir-list/2009-November/msg00778.html>

While testing Xen-4.1.2 with libvirt-0.8.7 (and still 0.9.6) I noticed, that 
libvirt in some cases still adds "type=ioemu" to the network interface 
configuration. This breaks the automatic switch of Linux HVM domains to Xen PV 
(unless you explicitly disable this by passing "xen_emul_unplug=never" to the 
domU Linux kernel), because otherwise the NIC ends up with MAC address 
00:00:00:00:00:00.

I have found two related posts, what 'ioemu' is needed for:
<http://xen.1045712.n5.nabble.com/Xen-4-1-2-PVHVM-guest-with-Linux-3-1-0-network-problem-empty-MAC-address-all-zeroes-td4953451.html>
> It seems "type=ioemu" is not required for anything..
> not even for normal HVM emulated nics.

<http://mail-index.netbsd.org/port-xen/2008/09/04/msg004300.html>
> type=ioemu  explicitely specifies that ioemu has to be used.

Even worse with XenLight the meaning of "ioemu" will invert its meaning:
<http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html>
> ioemu (default) -- this device will be provided as an emulate device to the 
guest and also as a paravirtualised device ...

In libvirt-git/src/xenxs/xen_sxpr.c:1865 there is this comment
> apparently (type ioemu) breaks paravirt drivers on HVM so skip
> this from XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU

which disables adding the "(type ioemu)" if no model is explicitly defined. If 
any other model then "netfront" is specified, the "(type ioemu)" is always 
added, which makes it impossible to specify a different default emulated NIC 
other then rtl8139 and still allow a guest to switch to PV.






More background info:

# virsh domxml-to-native xen-sxpr phahn-hv189.xml  | grep --only '(device (vif 
\(([^)]*)\)*))'
(device (vif (mac '00:16:3e:d3:5f:e5')(bridge 'eth0')(script 'vif-bridge')
(model 'rtl8139')(type ioemu)
))

This currently breaks running a Linux in a HV domain, because the Kernel 
detectes the PV devices and tries to switch to them:
# dmesg
Netfront and the Xen platform PCI driver haven been compiled for this kernel: 
unplug emulated NICs.
Blkfront and the Xen platform PCI driver haven been compiled for this kernel: 
unplug emulated disks.

After that the PV NIC ends up with an MAC-address of 00:00:00:00:00:00:
# ip l show eth0

This is because the address is not passed via xenstore:
# xm list -l foo | grep -F mac
  (mac 00:16:3e:1a:25:80)
# xenstore-ls -f / | grep -F 00:16:3e:1a:25:80
/vm/2693345e-110b-f085-3347-ee379ef72687/image/dmargs = "-domain-name 
foo -videoram 4 -k de -vnc 0.0.0.0:0 -vncunused -parallel none -vcpus 
1 -vcpu_avail 0x1 -boot dc -serial none -acpi -usb -usbdevice tablet -net 
nic,vlan=1,macaddr=00:16:3e:1a:25:80,model=rtl8139 -net 
tap,vlan=1,ifname=tap-vif3.0,bridge=eth0"
/local/domain/0/backend/vif/103/0/mac = "00:16:3e:1a:25:80"

After removing the "type=ioemu", re-defining the domain and starting it again, 
I get an additional entry in XenStore:
# xm list -l foo | grep -F mac
  (mac 00:16:3e:21:31:de)
# xenstore-ls -f / | grep -F 00:16:3e:21:31:de
/vm/3c959005-5bc6-cdd1-2b5d-facf9bf1a4ba/image/dmargs = "-domain-name 
foo -videoram 4 -k de -vnc 0.0.0.0:0 -vncunused -parallel none -vcpus 
1 -vcpu_avail 0x1 -boot dc -serial none -acpi -usb -usbdevice tablet -net 
nic,vlan=1,macaddr=00:16:3e:21:31:de,model=rtl8139 -net 
tap,vlan=1,ifname=tap-vif3.0,bridge=eth0"
/local/domain/0/backend/vif/105/0/mac = "00:16:3e:21:31:de"
/local/domain/105/device/vif/0/mac = "00:16:3e:21:31:de"

The source code of Xend also suggests, that adding "ioemu" only disabled 
setting those two XenStore entries:
# grep -FnA2 ioemu xen-4.1.2/tools/python/xen/xend/server/netif.py
151:        if typ != 'ioemu':
152-            front = { 'handle' : "%i" % devid,
153-                      'mac'    : mac }

See <https://bugzilla.redhat.com/show_bug.cgi?id=632021> for the 
xen_emul_unplug=never trick.

Sincerely
Philipp
-- 
Philipp Hahn           Open Source Software Engineer      hahn univention de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/

--- End Message ---

Attachment: signature.asc
Description: This is a digitally signed message part.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]