libvirt/virt-manager: Embeds full path to qemu-system in saved .xml files

  • Done
  • quality assurance status badge
Details
4 participants
  • 宋文武
  • Leo Famulari
  • Mike Gerwitz
  • Vagrant Cascadian
Owner
unassigned
Submitted by
Vagrant Cascadian
Severity
normal
Merged with

Debbugs page

Vagrant Cascadian wrote 7 years ago
(address . bug-guix@gnu.org)
87in83ots0.fsf@aikidev.net
When i create a new libvirt instance with virt-manager, it embeds the
full path to the qemu binary used at the time. For the machine named
"networkboot":

# grep qemu-system /etc/libvirt/qemu/networkboot.xml
<emulator>/gnu/store/0rzb7rjri2kb258j58asndw2pnp0xv9p-qemu-2.11.1/bin/qemu-system-x86_64:</emulator>

If I later run "guix gc" and it happens to remove this particular qemu
version, the system no longer runs, of course:

# virsh start networkboot
error: Failed to start domain networkboot
error: Cannot check QEMU binary
/gnu/store/0rzb7rjri2kb258j58asndw2pnp0xv9p-qemu-2.11.1/bin/qemu-system-x86_64:
No such file or directory

It also means each virtual machine may be running on an older version of
qemu, for better or worse.

Manaully replacing the emulator entry in the .xml file with
/run/current-system/profie/bin/qemu-system-x86_64 works around the
issue, and might be the easiest fix.

It wouldn't take advantage of a qemu install done in the user's
profile. I'm not sure if libvirtd can be run as a user-installed
profile, so maybe it has to use the system path anyways. I believe
libvirtd is normally run as it's own user, with it's own PATH.

live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEcDardHbDotegGFCHt4uC1IFLkbYFAlrs9D8ACgkQt4uC1IFL
kbY67g/+MtPUFd8xmOlWmxUSZpPiCe09eB9OU/tY6Nc0SDu61golpJSBgtxhFdoC
ayCoUSB1g3VO9sjiHw0+YS8TMbRwOkLUXe4jiyhaHbGzPY+B1wn5rFr4gnyDOj7S
gT+P4L2K/A8Ijyv8e/kpSsDI0wC2TqO3mXRj0hvmOrxFCo4Xa5KGwnWTMSf0M8i7
2HycWHY+U7CiF8DwZRiwvrVLlQzck5g+DEhLVKkcjhRLTMtZIpn4IOfcYRQjlNrV
SqD8SCOtFLMXX/HURzS1KiIp9fsfBSqhty6U7qSiRCwHCDajk8+S5461TNjuptOk
C8/E6x9Bao3ecthI654CVfeI+pvItJe0JsBy+0aXQvd2u0kmHjANNGfFmeruL++W
tgzVcchU1x8Qu6QcM7cNYKmQ7Esf2kqa5kM9zQL8BeZ6N9623D35xLK7M/l6Rh+o
adgWybWcuItf8xpRMoXY80pvvvvM8jFrqr7Bozgyzo2Tm03TH64VKrPEKQvCuFJH
I6OoTYNhEplAtYZBdXw4NrnamHolkUq5zVMUJOG149t+tmRtq7z+ONVPip7KHb8o
s1yR0xshvAQIcJ/SjrE05ZrDmfVIE8tt+KAlKZzOSf4T8UCzkn7L3RIDAAiv+tQY
wRPk4V5MbXSNFItnKvYK2CiuC8V7EaYRHGqDdP++Lxc9W6RIg2c=
=6D/Q
-----END PGP SIGNATURE-----

Mike Gerwitz wrote 7 years ago
(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 31365@debbugs.gnu.org)
87r2mqopw4.fsf@gnu.org
On Fri, May 04, 2018 at 17:01:03 -0700, Vagrant Cascadian wrote:
Toggle quote (16 lines)
> When i create a new libvirt instance with virt-manager, it embeds the
> full path to the qemu binary used at the time. For the machine named
> "networkboot":
>
> # grep qemu-system /etc/libvirt/qemu/networkboot.xml
> <emulator>/gnu/store/0rzb7rjri2kb258j58asndw2pnp0xv9p-qemu-2.11.1/bin/qemu-system-x86_64:</emulator>
>
> If I later run "guix gc" and it happens to remove this particular qemu
> version, the system no longer runs, of course:
>
> # virsh start networkboot
> error: Failed to start domain networkboot
> error: Cannot check QEMU binary
> /gnu/store/0rzb7rjri2kb258j58asndw2pnp0xv9p-qemu-2.11.1/bin/qemu-system-x86_64:
> No such file or directory

Thanks for looking into this; I hit this problem last night but hadn't
had the time to research.

I encountered this issue the same way (after a `guix gc').

Toggle quote (3 lines)
> It also means each virtual machine may be running on an older version of
> qemu, for better or worse.

Yes, I was concerned by that as well. :X VMs would not benefit from
security fixes, which is to me is the more important issue here.

--
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJa7QfrAAoJEIyRe39dxRuiJcsP/iEhPEPCOpo0nkScxTAp5fqZ
1mckHglJdB10mxzdBN0XJ7Us/hy1chsSUS3iq7Om09t77F7NUczon6/Eidh44d1N
WdaEBO4XolXQqWHsTwZgbkT98AcKzNdjw0cEnpwNXtR45CBVLv9vLy3pHBTwHmj9
QxwhgoZ4I+2a3CxivspSf4bMfyxHC5I7MALn16nzgQCW9YOj3smyW4oCfXbQ66T6
WMReTNWylGt4WFz2Gv8J98YqpW1zVL+KotdRuBl/KAe5rKZI7pDCko9MAcmTcjMF
XVBw9gQ1TvaZZz8O5Ioh4HY7n0HSx1RguJ8jF9Gy53o8kgynclOBv/mT0hyXwIgo
Z1BKr0uDntunxP7fCQDsgAxe1pQi2KVKJ4uRZm8m2d5z29BDky5pOIjiGjvT3nf8
QANmyJmsAGBWTB73X9MSmIVNrnn62HmwEZWSYZkoOYP4Ya2WibSY10mU8zb/q5d0
avrcPwmxD194SvPRnlabIHuBALC+VENT0aM47FYiAVaglK37FoExvb3SzvZdFuEb
n9vgVaROcimWgOZVLRhbVQD+PNXhOIXNrcWabXyNtnk6vuNeoJsjE7jP4Bvi9LOS
wUW7FRisrzLELolaAxqIo38uEHUUuy2+A6VfnmRxH2laStIErm3j1fUD2wNKoqOk
Z7eqFPfqXO79RTxRLNtW
=5XTE
-----END PGP SIGNATURE-----

宋文武 wrote 6 years ago
(name . Vagrant Cascadian)(address . vagrant@debian.org)(address . 31365-done@debbugs.gnu.org)
871rwnxemp.fsf@member.fsf.org
Vagrant Cascadian <vagrant@debian.org> writes:

Toggle quote (24 lines)
> When i create a new libvirt instance with virt-manager, it embeds the
> full path to the qemu binary used at the time. For the machine named
> "networkboot":
>
> # grep qemu-system /etc/libvirt/qemu/networkboot.xml
> <emulator>/gnu/store/0rzb7rjri2kb258j58asndw2pnp0xv9p-qemu-2.11.1/bin/qemu-system-x86_64:</emulator>
>
> If I later run "guix gc" and it happens to remove this particular qemu
> version, the system no longer runs, of course:
>
> # virsh start networkboot
> error: Failed to start domain networkboot
> error: Cannot check QEMU binary
> /gnu/store/0rzb7rjri2kb258j58asndw2pnp0xv9p-qemu-2.11.1/bin/qemu-system-x86_64:
> No such file or directory
>
> It also means each virtual machine may be running on an older version of
> qemu, for better or worse.
>
> Manaully replacing the emulator entry in the .xml file with
> /run/current-system/profie/bin/qemu-system-x86_64 works around the
> issue, and might be the easiest fix.
>

Hello, I believe my commit 'ef640db2f509f51ebfe3a6a66ba837ef3103bbb7'
fix this, now it use '/run/current-system/profie/bin/qemu-system-x86_64'
in the xml files. Close now.. Thank you!
Closed
Leo Famulari wrote 4 years ago
(no subject)
(address . control@debbugs.gnu.org)
YGjBgnzfCVsAw2go@jasmine.lan
unarchive 31365
reopen 31365
merge 47570 31365
?
Your comment

This issue is archived.

To comment on this conversation send an email to 31365@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 31365
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help