6:34 p.m.
-----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-----
3:58 p.m.
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(a)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/
4:24 p.m.
-----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-----
5:47 p.m.
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(a)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/
4605
days inactive
4610
days old
3 comments
2 participants
participants (2)
-
Philipp Hahn -
Stefan Bader