[Bug 1620407] Re: vm startup broken when interface definition has script tag
Chris J Arges
1620407 at bugs.launchpad.net
Thu Feb 9 03:56:13 UTC 2017
Hello Matthias, or anyone else affected,
Accepted libvirt into xenial-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/libvirt/1.3.1-1ubuntu10.8 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Your feedback will aid us getting this update
out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed. In either case, details of your testing will help
us make a better decision.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance!
** Changed in: libvirt (Ubuntu Xenial)
Status: In Progress => Fix Committed
** Tags added: verification-needed
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1620407
Title:
vm startup broken when interface definition has script tag
Status in libvirt package in Ubuntu:
Fix Released
Status in libvirt source package in Xenial:
Fix Committed
Bug description:
Regression restricted to set script which is rare as it is a massive
security drop
[Impact]
* A user using a type "ethernet" device with a custom script as working
in Trusty runs into an error on Xenial.
* Essentially Xenials libvirt "only" stumbles over a check&add on an
index for that network device. But since it might be externally created
later (up until on qemu start) it might not be available at the time it
is checking. So the fix skips the check index in those cases.
* The fix as-is is not upstream because upstream opted for a fare bigger
rework of the section in which after 9c17d665fdc5f "autocreate tap
device for ethernet network type" libvirt calls the script. That also
allows different security levels (permission of libvirt instead of
qemu) but these changes are huge and not sufficient for an SRU fix.
[Test Case]
* Create a guest your usual way (e.g. uvtool-libvirt
* Add a script based type network ethernet device (there is no need to
create a script, one can use the default of qemu). The xml snippet
looks like this:
<interface type='ethernet'>
<mac address='52:54:00:18:0d:a3'/>
<script path='/etc/qemu-ifup'/>
<target dev='newdevname'/>
<model type='virtio'/>
</interface>
* without the fix this runs into:
error: Failed to start domain <guestname>
error: Unable to get index for interface <devicename>: No such device
[Regression Potential]
* There could be a cornercase around nicindexes which due to the skip in
case net->skript is set that was not covered in our experiments now
failing. But since as of today setting the script tag in generally
fails those people should not exist.
* Another fact that limits the potential regression is that type ethernet
devices come at a huge security disadvantage - it needs to run
privileged as root and also disable certain security features (not
clearing capabilities for example).
That said the number of users still using that feature should be low
and shrinking further.
[Other Info]
* n/a
----- original report -----
Ubuntu 16.04.1 LTS (amd64)
libvirt-bin 1.3.1-1ubuntu10.1
We use external scripts to setup tap interfaces, e.g.
<interface type='ethernet'>
<mac address='52:54:00:18:0d:a3'/>
<script path='/etc/libvirt/14v/mf_testet.sh'/>
<target dev='mf_testet'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
Starting the VM throws an error message ("interface not found" or
something like that).
IIUC, the script invocation is done by qemu, so the interface
may not yet exist when libvirt is constructing the qemu cmd args.
Checking for that interface in advance therefore is a bug.
Attached patch skips the check if a <script> parameter is provided.
Regards
Matthias Ferdinand
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1620407/+subscriptions
More information about the Ubuntu-sponsors
mailing list