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@xxxxxxxxxxxxx
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 ---
- Subject: FYI Xen-4.1.2+libvirt-0-8-7: type=ioemu and PV on HVM guests
- From: Philipp Hahn <hahn@xxxxxxxxxxxxx>
- Date: Thu, 22 Dec 2011 10:34:22 +0100
- Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
- Organization: Univention.de
- User-agent: KMail/1.9.10 (enterprise35 20100903.1171286)
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@xxxxxxxxxxxxx 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.
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list