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

[Stefan Bader]

-----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-----