[Pkg-libvirt-maintainers] Bug#664124: Bug#664124: libvirt: should not use type=ioemu for any emulated NIC

[Stefan Bader]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 15.03.2012 19:53, Guido Günther wrote:
> Hi Stefan, On Thu, Mar 15, 2012 at 07:08:47PM +0100, Stefan Bader wrote:
>> Package: libvirt Version: 0.9.8-2 Severity: normal Tags: patch User:
>> ubuntu-devel at lists.ubuntu.com Usertags: origin-ubuntu precise
>> ubuntu-patch
>> 
>> Dear Maintainer,
>> 
>> libvirt uses xend (xm stack) to manage Xen instances. Even when using any
>> emulated NIC, there will always be a paravirt NIC in parallel if the 
>> pci-platform device is present. Newer guests will unplug the emulated NIC
>> on boot. However there is a bug in the stack that will cause the paravirt
>> NIC to have no MAC address when "type=ioemu" is used in the vif
>> definition. On the other hand, even without this keyword, the emulated
>> NIC will be provided.
>> 
>> Current libvirt already has a quirk to drop this when using no specific 
>> NIC model (defaulting to rtl8139). But the problem exists as well when 
>> using any other emulated NIC.
>> 
>> So currently, when booting a 3.0+ kernel after setting up the instance 
>> with the default NIC model, everything works. Changing the model to 
>> something like e1000, then the guest cannot use the paravirt interface 
>> after unplugging the emulated one. Ending up with no network.
>> 
>> *** /tmp/tmpay_5Gn/bug_body In Ubuntu, the attached patch was applied to
>> achieve the following:
>> 
>> The parch replicates the quirk used to prevent the usage of "type=ioemu" 
>> to be used for the case of using a NIC model name explicitely. I think it
>> should be useful/working for Debian as well. Sorry if this is not the
>> ideal justification. Since this is the first time I use submittodebian, I
>> am not sure how this exactly should be done.
>> 
>> 
>> [ Stefan Bader ] * Never use type=ioemu for NIC definitions. It is not
>> needed and actually breaks the paravirt interface which always gets 
>> created in parallel.
> 
> What's the upstream status of this issue? Please push this upstream 
> directly - this doesn't look like anything debian specific. -- Guido

I just sent it to upstream, too. Not sure about that outcome. I just thought,
the problem must exist for Debian, too. And in case this becomes an issue, you
could have the same adjustment.

- -Stefan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJPYxe8AAoJEOhnXe7L7s6j8GQP/jPTjGb86+6BCDngji39hJvb
6H2zrh++RZCbshkPvqLRM3GcKYO4zVSOTeYLvJPeLfzH94PU5JqRb1mgyUhCNlBG
iEPQ8VVEbJ9R/L2rEZvmUqzomX+xS+qfcNfWRSE8iNFvUtUFVqSl8i3Jyus6uAiP
1aqTu5bcQa5petaYaTi7C5WZU3zIEZzwo7kLeSeTer+kuTzcIQ8spy+KszxI4jox
3ri0N/64YdnJZDZqOsz2zyJPdqF9c0sTIrCgM4Vl42c33VuRjFztXCHZ/Ay8em0L
qmpWIqijRuQN2KVf2TXJBsy4dAMLB2tbKM++5/iBFnxpBL8hnjtE/7Ba8u/drJhA
F0BD1zzLAO0CNSwbh6mCFeeIk3LuOMcLlUrlCecYVvGHbj8Z0kRf8igIUIo63Btc
2j5jDRCZMmhk2iviubL0J4rGqkkbZUtGHTvdeESiUXhfSJlMqJnfPRVsc1u8WnPH
0Y2DS+2wNSBWIbwbyRH5E1ULQvytQ3AbaK0pQ5J5TNxxYRCKGwDgR2/tFeHigda3
x6yTz7li8y245SBIVZB3+5TyhnoSLAC6jQZhAygHfVNsh2rdQUMvpb6nmygxVrMr
oYj/jKv8622/yE9OW3c7P49RiP1L3Ip+WfZG5Hjw8GW8pCp56dUsJkiMCdTxo+h/
q9np3NVHywnV0X3kV5D7
=ZnSn
-----END PGP SIGNATURE-----