[libvirt] [PATCH] libvirt: xen: do not use ioemu type for any emulated NIC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 When using the xm/xend stack to manage instances there is a bug that causes the emulated interfaces to be unusable when the vif config contains type=ioemu. The current code already has a special quirk to not use this keyword if no specific model is given for the emulated NIC (defaulting to rtl8139). Essentially it works because regardless of the type argument, the Xen stack always creates emulated and paravirt interfaces and lets the guest decide which one to use. So neither xl nor xm stack actually require the type keyword for emulated NICs. - --- /* * apparently type ioemu breaks paravirt drivers on HVM so skip this * from XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU */ if (xendConfigVersion <= XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU) virBufferAddLit(&buf, ",type=ioemu"); - --- This is still broken when a different emulated NIC (eg. e1000 is enforced), but the same fix solves that problem. Which is what the attached patch does. I have been testing with this change applied and was able to change between various emulated NIC models successfully. I believe it would be applicable to libvirt upstream, too. - -Stefan PS: Please cc: me directly on replies as I am not subscribed to this list. Thanks. diff -Nurp libvirt.old/src/xenxs/xen_sxpr.c libvirt-0.9.8/src/xenxs/xen_sxpr.c - --- libvirt.old/src/xenxs/xen_sxpr.c 2012-03-16 11:17:02.685042296 +0100 +++ libvirt-0.9.8/src/xenxs/xen_sxpr.c 2012-03-15 18:43:32.000000000 +0100 @@ -1873,7 +1873,9 @@ xenFormatSxprNet(virConnectPtr conn, } else { virBufferEscapeSexpr(buf, "(model '%s')", def->model); - - virBufferAddLit(buf, "(type ioemu)"); + /* See above. Also needed when model is specified. */ + if (xendConfigVersion <= XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU) + virBufferAddLit(buf, "(type ioemu)"); } if (!isAttach) diff -Nurp libvirt.old/src/xenxs/xen_xm.c libvirt-0.9.8/src/xenxs/xen_xm.c - --- libvirt.old/src/xenxs/xen_xm.c 2012-03-16 11:17:02.645042103 +0100 +++ libvirt-0.9.8/src/xenxs/xen_xm.c 2012-03-15 18:43:32.000000000 +0100 @@ -1335,7 +1335,9 @@ static int xenFormatXMNet(virConnectPtr } else { virBufferAsprintf(&buf, ",model=%s", net->model); - - virBufferAddLit(&buf, ",type=ioemu"); + /* See above. Also needed if model is specified. */ + if (xendConfigVersion <= XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU) + virBufferAddLit(&buf, ",type=ioemu"); } if (net->ifname) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPYxc9AAoJEOhnXe7L7s6j3f8P/3nyZUh5dY8vVcGsRX9mkoX5 DwioJfLit8wjNUX3iJciPnTCUprJeiOpev/dKuuIaUfSEOP+xzHKcAbSVdyXhlME R5n+EbBI6WBDbVT/rbV+Mp52bVoe3vb8LgT2dc1KzYYpcMjlzAzUd56IdJ64YQaS r9o6ps279jY6AeDEEnz0TTajKdNbMBt578kwmsES/1rHMVLT2wLrnQp6Kc9ECQ5o YjpOAU55Bl8OP+1DK0SFSyRl1gesrUXCN1g6QsWiiaeq0OpO8TDxfpxoBKwV19cO kFHoZ8UR4XyaDosVg0S2+WaOn7o8B7r1k+biD23L4QaADcsN+l4uuDHaHYX4nd/L PpbUpZY8+KjTny6H/khqYYJR/G9Wl7L6GMlGLJLihlue3/iIfrHJZdF1+dFgo9uZ vaYgjZWe1ak9vQIUfxa4enxdadBYS7Xy1JP9egA87DACnpzOEWgZ6Qadhcj0cewm MHfEmFWnaHHLI+TqaLSwN3XeTsbZ2GP8ixlW+ewNyAPd76g3uYFVTxDOd9a+r301 C+jtgwDcG1aciXR/diR/Dnr7JZ3Y9Fgu/gt/n0Pr4tIgiYF8+T4WG0osXssiiqbc 3p92VzkEl3P/g5QRdeB/+XxGz9IfAikALyNO4ztFSxk4JIh1ix/OIoaucNSc7XFl boPeTDnZLrdIVncDmJ5c =RhMW -----END PGP SIGNATURE-----
Hello, On Friday 16 March 2012 11:34:37 Stefan Bader wrote:
When using the xm/xend stack to manage instances there is a bug that causes the emulated interfaces to be unusable when the vif config contains type=ioemu.
I had a look at a similar problem some time ago, so some gereral comments: Xens point of view: If you specify model=XXX in Xen, you get that emulated NIC and also a second Xen-PV netfront interface as well. When you specify type=ioemu, you only get the emulated NIC, netfront is skipped. libvirts point of view: If you explicitly specify a model for the interface, you get exactly that model without the Xen-PV-companion interface, that is type=ioemu is added. Without an explicit model, you get the default rtl8139 and netfront. The problem with modern Linux kernels is, that unless you specify "xen_emul_unplug=never" on the Kernel command line, the kernel detects that you're running on Xen and disabled the emulated NIC leaving you without any network. So currently with libvirt you can't specify the type of the emulated NIC (for example to get a more modern e1000) and also get the Xen-PV-interface as well. If I remeber corrently that forces you to change the NIC model when installing the Windows GPLPV drivers, I hope that little bit is helpful to others, since it cost my some time to find that out myself the hard way. Corrections are appreciated. 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 PGP SIGNED MESSAGE----- Hash: SHA512 On 21.03.2012 08:58, Philipp Hahn wrote:
Hello,
On Friday 16 March 2012 11:34:37 Stefan Bader wrote:
When using the xm/xend stack to manage instances there is a bug that causes the emulated interfaces to be unusable when the vif config contains type=ioemu.
I had a look at a similar problem some time ago, so some gereral comments:
Xens point of view: If you specify model=XXX in Xen, you get that emulated NIC and also a second Xen-PV netfront interface as well. When you specify type=ioemu, you only get the emulated NIC, netfront is skipped.
Unfortunately not true. You always get the enulated NIC, whatever you do with type=ioemu.
libvirts point of view: If you explicitly specify a model for the interface, you get exactly that model without the Xen-PV-companion interface, that is type=ioemu is added. Without an explicit model, you get the default rtl8139 and netfront.
The problem with modern Linux kernels is, that unless you specify "xen_emul_unplug=never" on the Kernel command line, the kernel detects that you're running on Xen and disabled the emulated NIC leaving you without any network.
The problem is that the decision about unplugging is made based on the pci-platform device and pv device drivers present. This can lead to hard times when the modules are not loaded (or even not present on an initramfs). But this is a different problem.
So currently with libvirt you can't specify the type of the emulated NIC (for example to get a more modern e1000) and also get the Xen-PV-interface as well. If I remeber corrently that forces you to change the NIC model when installing the Windows GPLPV drivers,
- 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 od 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. Even with the newer xl stack that upstream Xen is pushing, there will always be both interfaces present. Whether type=ioemu is present or not, it has no effect at all. The only difference is that with xl, the paravirt interface is usable in all cases. And since xm/xend is deprecated, there is not much desire to fix this in xm/xend. - -Stefan
I hope that little bit is helpful to others, since it cost my some time to find that out myself the hard way. Corrections are appreciated.
Sincerely Philipp
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPaZAcAAoJEOhnXe7L7s6jsy8P/AoyI8MLQq/oESJwsHcTGJ5X +aVQPAE/aIh7i8Bu7BNciIR69yWorbt0ftxOLXSOCnTa701ml/PDy8NlAbBJEOec B9ZKlwQyVuT2H1XNOCJo4Kq7d6t2rJbVgc9ZRlgCiS/kp9VZ7MyEIreM6jXbl8C3 rC/0vLbClvqcKeHlUjlyXjvVg83HQgrDXo4OACvC+UjcV47dheegJekKq93Vwqb2 Wpd5jV30RhlL99+AV4ruzNG6bYzA+mr30Ravl+BkXbR1251n1FgWbk/iOJEbIycm a+XfDYCmQ/gQj7ve2EEe5Oq8By4SxQAoKowbevbiNRhPfqxLG9nxGniQpsVtLqPk 8kxma5cHHVV7VrGJZeOv+c4KN9gV0xP/rDBUx5Ej0ne4f2AkTCCirjAsBItws9yY nsmLcoAzpYVEk3fJxE4NyVROLmQlfBPiq8Qd9qABKjlsLV5S82imN78nKRWOwaD8 vPumqR/f7XqNwc4FHMRIv9E0K+fJvNuFilvHbS94WHyswT1/iTaYppVuqjpasn2Q sI0OJsdKUXHCxai9yAdPdLasszeHVHwJJeWTbS8wTQBbRLalThIkjFf3p4R9AWei L0SpSPnsYH8OVUkYogfW5Jk2WA+7WOmtO86kzxaPQwHXeawL4QgBysVoBPHZNbV9 VWDA+rFRUyY982zsjdTC =cMcl -----END PGP SIGNATURE-----
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/
participants (2)
-
Philipp Hahn -
Stefan Bader