-----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----- -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list