Description of problem:
When running a LiveCD inside a qemu-kvm virtual machine, there are a number of tasks that can be made more efficient if the guest is running the qemu-guest-agent service. For example, the host can reliably ask the guest to shutdown via a guest-agent command
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a guest VM using the liveCD iso as its source and with the appropriate plumbing for the host to connect to the guest agent (need help with this step? ask on oftc#virt)
2. within that guest, 'systemctl status qemu-guest-agent'
3. from the host, 'virsh shutdown $guest --mode agent'
1. guest should boot
2. qemu-guest-agent is not installed
3. shutdown with --mode agent fails because the agent is undetected; shutdown via --mode acpi fails because the gnome-shell default is to go into S3 rather than shut down
1. guest should boot
2. the guest should detect that it is in a VM, so the qemu-guest-agent service should be running
3. the shutdown via the agent should work
qemu-guest-agent is only 285k installed, and didn't drag in any additional dependencies when I installed it onto the F18 beta. Hopefully that is not deemed to big to be worth the improved functionality of host control over the guest.
Proposing as an F18 final blocker under the following criteria:
Final 4: "The release live images must properly support mounting and using a persistent storage overlay for the entire system and/or one for the /home partition, if such an overlay or overlays have been correctly written to the medium from which the image is booted"
Beta 17: "The release must be able host virtual guest instances of the same release, using Fedora's current preferred virtualization technology"
Beta 23: "All release-blocking desktops' offered mechanisms (if any) for shutting down, logging out and rebooting must work"
When self-hosting a VM that uses a LiveCD and persistent storage, it is essential that the guest be shut down cleanly so as not to corrupt the contents of that persistent overlay. When shutting down the host, it is therefore necessary to have a means to put the guest into shutdown (S5) rather than just suspend (S3). However, since the ACPI shutdown option does not trigger a shutdown, the guest needs some other way to know when the host needs it to shut down cleanly. The preferred technology for this is via the guest agent.
I can see NTH for this, blocker seems a stretch. Presumably this has been the case for all recent releases and nothing has exploded. The criterion is satisfied in most cases, only in the VM case is it not satisfied, and even then only arguably - you can still shutdown cleanly by, e.g., sshing into the guest and running 'shutdown'...
I would be ok with NTH but -1 blocker.
Actually, I do see one way to reliably create a managedsave image that won't load - by upgrading qemu in the meantime that fails to accept incoming migration. But that is a bug in qemu, not libvirt, and we should be fixing the incoming migration problems rather than having to patch libvirt to issue a bandaid message telling the user that their managedsave image won't work because of a qemu bug.
Ignore comment 4; I pasted it into the wrong tab.
Discussed at 2012-12-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . Rejected as a blocker, this clearly isn't serious enough to consider a violation of the criteria. Weakly accepted as NTH as it can affect a non-updateable config (live boot), and the fix seems small and non-invasive (and may give us other useful stuff in live guests like copy/paste to host).
Solving this issue (making VMs have guest-agent available out-of-the-box) will make bug 744077 less important to worry about.
Committed to spin kickstarts for f19.
So this seems kinda inconsistent. We put spice-vdagent in @base-x in comps, so just about any install of any kind will get it, but qemu-guest-agent in fedora-live-base.ks , so only live images get it.
Was there some sort of plan behind that decision, or is it just inconsistent? Should we put qemu-guest-agent in @standard (perhaps through this new comps group we're creating for VM guest agents)?