Red Hat Bugzilla – Bug 493414
Windows installs require manual reboot in the middle
Last modified: 2010-06-28 07:38:30 EDT
Description of problem:
When installing, say, Win 2008 server via virt-manager/virtinst/etc, while the CD ROM stays attached, in the middle of the process the machine must reboot. What happens, at least in rawhide is that the machine powers down, it does not reboot. This means that fully automated installs of Windows guests can't be automated without a higher level application polling to start the VM once it reboots the first time.
Basically what I'd like to see in python-virtinst is the capability to say "reboot the next time automatically" (for Windows).
I realize some of this is available in the libvirt XML but for applications it really needs to be made available in python-virtinst so they can be isolated from the internals/complexity.
Are you sure the issue here isn't just that Win 2008 reboot doesn't work under KVM? e.g. does reboot work one you have the guest installed?
Not sure. I'll try a regular reboot in a bit and let you know.
Sorry, been busy. The instructions are very easy to replicate from my initial report; currently away from the machine that has that installation, I'll click reboot for you tomorrow.
This could be win2008 specific, that's why it's helpful if you can try reproducing
Hmm, is the problem here virt-install does this using the Guest.get_continue_inst() and Guest.continue_install() but koan doesn't know to do it?
We don't typically block on guests for completion (though we /can/ if prompted). I had assumed that once kicked, they would DRT.
This seems to imply windows installs need to block.
Is the continue install logic available in all versions of Python virtinst, (i.e. EL-4, etc)
(Windows has been on the back-burner recently, another thing that came up is how to pass the answer file on a virtual floppy image to a Windows install. It seems (not sure) that that is only doable via using qemu-kvm directly since it takes not only the path to that image but also the path to a file on that floppy image.)
Okay, moving to koan, then
(In reply to comment #7)
> Is the continue install logic available in all versions of Python virtinst,
> (i.e. EL-4, etc)
Not sure about that, sorry - virt-install has been doing this for a long time, but the APIs could have evolved
(In reply to comment #7)
> (Windows has been on the back-burner recently, another thing that came up is
> how to pass the answer file on a virtual floppy image to a Windows install. It
> seems (not sure) that that is only doable via using qemu-kvm directly since it
> takes not only the path to that image but also the path to a file on that
> floppy image.)
FWIW, another way this can be done (completely through libvirt APIs) is by embedding the answer file in the ISO. I have some python snippets I can send you, but essentially you generate the answer file, put it on the CD in the i386/winnt.sif or amd64/winnt.sif file, and then regenerate the ISO with mkisofs. Then when you boot from the CD, it will automatically find the answer file and do the installation unattended. That way you don't need to play with qemu-kvm directly, you just generate libvirt XML that points to your modified CD.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.