Hide Forgot
Description of problem: i reformatted by pc from f15 to f16. i then set about to import my saved disk images. everything went well until i told my vm to poweroff. i used poweroff from the command line. to my surprise it did a reboot. in total, i did the same process with 3 centos images and 1 windows xp. all showed the same behaviour. reboot when i tell it to poweroff/shutdown. i am happy to say the 2nd boot fulfilled the command and the vm did not come up again. Version-Release number of selected component (if applicable): How reproducible: 4 times on different os = everytime Steps to Reproduce: 1. create new vm 2.import disk image (from f15?) 3. Actual results: Expected results: Additional info:
There are a couple bugs here, but it is mostly expected behavior. When the user installs a linux guest from CDROM, it is a 2 stage process: boot from media and install the OS, guest attempts to reboot, virt-manager forces it to shutdown, we reconfigure the guest definition to boot from the harddisk and not the CDROM, and then virt-manager starts the guest (first boot up). If at any point the user uses virt-manager to shut the guest off (and not let the guest initiate shut down at end of install), virt-manager will skip that second boot up, since user manually requested shutoff. Problem is, virt-manager only notices a user initiated shutdown if it is done through the UI. You did it from the command line, so virt-manager thought the guest shut down naturally and we tried to reboot it. So that's bug 1. The fix for this is to use libvirt's domain events, however that's not really a bug fix and tons of dev work that isn't worth tracking for fedora (it will happen at some point). The other bug is that an 'import' isn't really a 2 phase install, but we treat it like one. It's more like booting a livecd, where we skip the second boot attempt. So we can use this bug to track fixing that issue.
Fixed the import issue upstream: http://git.fedorahosted.org/git?p=virt-manager.git;a=commit;h=b2c95375a36e8b3b97d77f1740ad64fb521486fb
Due to the annoyance of upstream code being different from f16 code now, this would require a custom backport, so given the low impact I'm just closing this as upstream. Please let me know if this is a problem.