Bug 886705

Summary:	live cd should include qemu-guest-agent package
Product:	[Fedora] Fedora	Reporter:	Eric Blake <eblake>
Component:	spin-kickstarts	Assignee:	Jeroen van Meeuwen <vanmeeuwen+fedora>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	admiller, awilliam, bruno, eblake, jreznik, kevin, robatino, vanmeeuwen+fedora
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	AcceptedNTH RejectedBlocker
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-16 19:41:26 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	752665

Description Eric Blake 2012-12-12 22:58:20 UTC

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):
2:qemu-guest-agent-1.2.0-24.fc18.x86_64

How reproducible:
100%

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'
  
Actual results:
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

Expected results:
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

Additional info:
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.

Comment 1 Eric Blake 2012-12-12 23:07:32 UTC

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.

Comment 2 Adam Williamson 2012-12-12 23:19:09 UTC

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'...

Comment 3 Jaroslav Reznik 2012-12-13 13:43:50 UTC

I would be ok with NTH but -1 blocker.

Comment 4 Eric Blake 2012-12-15 13:09:22 UTC

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.

Comment 5 Eric Blake 2012-12-15 13:09:53 UTC

Ignore comment 4; I pasted it into the wrong tab.

Comment 6 Adam Williamson 2012-12-17 18:27:45 UTC

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).

Comment 7 Eric Blake 2013-01-16 18:53:04 UTC

Solving this issue (making VMs have guest-agent available out-of-the-box) will make bug 744077 less important to worry about.

Comment 8 Kevin Fenzi 2013-01-16 19:41:26 UTC

Committed to spin kickstarts for f19.

Comment 9 Adam Williamson 2013-05-08 23:45:14 UTC

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)?