Bug 499547

Summary: virt-manager should restart guests after they have finished installing
Product: [Fedora] Fedora Reporter: Paniraj <paniraja_km>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 13CC: berrange, clalance, crobinso, hbrock, lili, markmc, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: virt-manager-0.8.4-1.fc13 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-16 17:52:00 UTC Type: ---
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: 498969    

Description Paniraj 2009-05-07 06:17:35 UTC
Description of problem:
After a Fedoara 11 guest install, if reboot is pressed, the guest vm is getting shutdown instead of reboot.

Steps to Reproduce:
1. Install Fedora11 (rwahide) with virtualization support
2. Install a Fedoar11 guest
3  Post installation stages, press "Reboot"

Comment 1 Mark McLoughlin 2009-05-07 06:46:58 UTC
Confirmed, I've noticed this too

Moving to qemu, as it's more likely a problem there than virt-manager

Comment 2 Mark McLoughlin 2009-06-03 13:21:05 UTC
Wait, no - virtinst uses qemu-kvm -no-reboot and manually re-starts the guest post-install

So, this is a virtinst problem, if anything

Comment 3 Chris Lalancette 2009-06-03 13:32:49 UTC
I think you actually meant virt-manager problem, but yes.  This is a difficult problem, and one that we unfortunately solved differently in virt-install and virt-manager.

The fundamental problem is that we need to change boot devices in between the install and the first boot of the guest OS.  That is, during the "install" stage, we want the boot device to (typically) be the CD, while during the "boot" stage after the install, we want the boot device to be the hard drive.  The way that this is accomplished in virt-install is to start up the guest with -no-reboot (as Mark mentions), and then when the install completes, the "reboot" kills the guest.  At this point, virt-install re-generates the libvirt XML with the hd as the boot device, and starts the guest again.

In virt-manager, however, it doesn't do this.  It just creates the guest with the "cd" as the boot XML, boots the guest with -no-reboot, and when the install is finished, that is that.

It's hard to say which one is more "right".  While the way virt-install does it seems more correct for installing Linux guests, it can run into problems with other guests (such as Windows) that need to reboot multiple times during installation (although there are hacks in virt-install to make this work right too).  On the other hand, the way virt-manager does it gives you a lot more control over the process, at the expense of it being more manual and not actually "rebooting" at the end.

Chris Lalancette

Comment 4 Mark McLoughlin 2009-06-03 15:26:02 UTC
Thanks for the explanation Cole - didn't realize virt-install and virt-manager handled this differently.

(In reply to comment #3)

> It's hard to say which one is more "right".  While the way virt-install does it
> seems more correct for installing Linux guests, it can run into problems with
> other guests (such as Windows) that need to reboot multiple times during
> installation (although there are hacks in virt-install to make this work right
> too).  On the other hand, the way virt-manager does it gives you a lot more
> control over the process, at the expense of it being more manual and not
> actually "rebooting" at the end.

The button you click at the end of an anaconda install says "Reboot" - that's enough to persuade me we should re-start the guest :-)

We could make it OS specific using OS_TYPES, if we're concerned about Windows

Comment 5 Cole Robinson 2009-06-03 16:05:42 UTC
clalance actually provided the explanation, but it was spot on. :)

virt-manager needs to act more like virt-install in this respect: we can just store some flags in the 'domain' object that should allow us to do the right thing.

Comment 6 Mark McLoughlin 2009-06-03 16:29:52 UTC
I typed "Chris", honest - it's bugzilla's fault

Okay, moving to F12 and re-titling

Comment 7 Mark McLoughlin 2009-06-05 09:12:42 UTC
I just tried an XP install here and it needs a reboot too - after the first stage it reboots itself, but virt-manager doesn't restart it

Comment 8 Mark McLoughlin 2009-06-05 09:14:44 UTC
*** Bug 502767 has been marked as a duplicate of this bug. ***

Comment 9 Cole Robinson 2010-03-01 02:02:29 UTC
Fixed upstream now:

http://hg.fedorahosted.org/hg/virt-manager/rev/976f202f5dbd

Moving to post. This likely won't be backported (since it requires a few virtinst changes/cleanups) unless we rebase, which is possible. Moving to POST for now.

Comment 10 Bug Zapper 2010-03-15 12:35:50 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Fedora Update System 2010-05-27 20:59:42 UTC
virt-manager-0.8.4-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/virt-manager-0.8.4-1.fc13

Comment 12 Fedora Update System 2010-05-28 18:08:52 UTC
virt-manager-0.8.4-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update virt-manager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/virt-manager-0.8.4-1.fc13

Comment 13 Fedora Update System 2010-06-16 17:51:12 UTC
virt-manager-0.8.4-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.