[Ovirt-devel] Issue with ISO provisioning
Hugh O. Brock
hbrock at redhat.com
Wed Oct 15 13:56:10 UTC 2008
On Wed, Oct 15, 2008 at 02:27:32PM +0100, Daniel P. Berrange wrote:
> On Wed, Oct 15, 2008 at 09:21:10AM -0400, Hugh O. Brock wrote:
> > On Tue, Oct 14, 2008 at 10:11:01PM -0400, Perry Myers wrote:
> >
> > [snip]
> >
> > >
> > > So Windows installs right now work because the soft reboot in step 3 does
> > > not cause the vm to shutdown. If it did that, the restart of the vm
> > > would come up without the ISO in the drive (since that is a temporary
> > > association)
> > >
> > > We've talked in the past about changing domains so that on reboot the vm
> > > is destroyed and then restarted by taskomatic. This way the boot device
> > > can be toggled between reboots. This fixes linux PXE provisioning, which
> > > right now has a problem because after OS installation over PXE boot the
> > > domain soft reboots and tries to PXE again.
> > >
> > > So it seems the requirements for Windows and Linux provisioning are
> > > somewhat at odds. What we may have to do is make it so taskomatic is
> > > aware of the OS type and sets up the semantics of domain rebooting
> > > accordingly.
> >
> > Yes, this is exactly the same song-and-dance we went through with
> > python-virtinst when getting Windows installs to work from
> > virt-manager. What we need to do is figure out a good abstraction for
> > the various possible install modes and either a. allow the user to
> > specify what's desired, or preferably b. figure it out ourselves.
> >
> > What we want is some way to say "OK, the install is finished, now
> > change the VM to boot in the proper permanent configuration." If we
> > always set VMs to halt on reboot and we have a way for taskomatic to
> > detect that a VM has halted in mid-install, we could have the UI pop
> > up a message asking the user if the install finished? It would be
> > difficult to make that clear but it could work, I think...
>
> Two ideas
>
> - The BIOS boot device is not a single device, but actually a list
> of devices, so you can do
>
> <boot dev='cdrom'/>
> <boot dev='hd'/>
>
> and it'll try 'cdrom' first, falling back to 'hd'.
>
> - The installer will try to eject the CDROM media inside the guest,
> so if we could make sure it stays ejected we wouldn't need to
> change the XML
>
>
> Alternatively setup boot order
>
> <boot dev='hd'/>
> <boot dev='cdrom'/>
>
> and dd 512 zero bytes to the disk before booting the installer so it
> picks the cdrom first time, and on 2nd boot will find the harddisk
> bootsector.
>
> NB, we didn't do this with virt-install because we didn't want to
> make changes to their disk by accident, but maybe its more acceptable
> for oVirts use case where things are more tightly managed
>
>
The first idea probably works better for the Windows-multiple-reboot
case, since presumably Windows won't eject the install media until
it's really done with it.
QEMU should deal with "ejecting" a virtual cdrom OK, shouldn't it?
--Hugh
More information about the ovirt-devel
mailing list