Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 886705 - live cd should include qemu-guest-agent package
Summary: live cd should include qemu-guest-agent package
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: spin-kickstarts
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jeroen van Meeuwen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedNTH RejectedBlocker
Depends On:
Blocks: F18-accepted, F18FinalFreezeExcept
TreeView+ depends on / blocked
 
Reported: 2012-12-12 22:58 UTC by Eric Blake
Modified: 2013-05-08 23:45 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-16 19:41:26 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

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)?
Note You need to log in before you can comment on or make changes to this bug.