[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