Empty cdrom drive.

[Simon Grinberg]

----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: arch at ovirt.org, "Igor Lvovsky" <ilvovsky at redhat.com>
> Sent: Wednesday, February 15, 2012 1:43:59 PM
> Subject: Re: Empty cdrom drive.
> 
> 
> ----- Original Message -----
> > On Tue, Feb 14, 2012 at 10:59:22AM -0500, Igor Lvovsky wrote:
> > > 
> > >   Hi,
> > > I want to discuss $subject on the email just to be sure that we
> > > all
> > > on the
> > > same page.
> > > 
> > > So, today in 3.0 vdsm has two ways to create VM with cdrom :
> > >  1. If RHEV-M ask to create VM with cdrom, vdsm just create it
> > >  2. RHEV-M doesn't ask to create VM with cdrom, vdsm still
> > >  creates
> > >  VM with
> > >     empty cdrom. Vdsm creates this device as 'hdc' (IDE device,
> > >     index 2),
> > >     because of libvirt restrictions.
> > >     In this case RHEV-M will be able to "insert" cdrom on the fly
> > >     with
> > >     changeCD request.
> > > 
> > > In the new style API we want to get rid from stupid scenario #2,
> > > because
> > > we want to be able to create VM without cdrom at all.
> > 
> > > It means, that now we need to change a little our scenarios:
> > >  1. If RHEV-M ask to create VM with cdrom, vdsm just create it
> > >  2. RHEV-M doesn't want to create VM with cdrom, but it want to
> > >  be
> > >  able to
> > >     "insert" cdrom on the fly after this. Here we have two
> > >     options:
> > >     a. RHEV-M should to pass empty cdrom device on VM creation
> > >     and
> > >     use
> > >        regular changeCD after that
> > >     b. RHEV-M can create VM without cdrom and add cdrom later
> > >     through
> > >        hotplugDisk command.
> > 
> > Let's leave hotpluggin for a later discussion. Currently I am
> > worried
> > about backward and forward compatibility.
> > 
> > 1. Currently, all VMs created by ovirt-Engine has an IDE cdrom
> > device. This
> > behavior should be maintained when Engine is upgraded, to minimize
> > surprises to guests.
> > 
> > 2. In the new "devices" API introduced by Igor, Engine is
> > responsible
> > to
> > know about all guest devices and their addresses.
> > 
> > 1+2=3. Engine has to be aware of the fact that even if it did not
> > explicitly request for a cdrom, such a device exist.
> > 
> > 4. Vdsm would very much prefer that Engine explictly request that
> > an
> > empty cdrom device is included. This would allow us to start VMs
> > with
> > no
> > cdrom device at all in the future.
> > 
> > I understand that this may be a complex feat for Engine, as it
> > requires
> > a complex upgrade path to the VM data base. To be done correctly,
> > it
> > requires a compatible change to the ovirt API, too.

Why? VM DB will probably change anyhow with more fields added between versions so upgrade scripts should handle that. 

In any case if VDSM will report all devices it implies that DB change is a must (at least for the running config tables).

P.S.
Not sure that change CD should only apply to the running config. 
ATM the engine does not 'remember' the inserted CDs, thus a user that wants to change CD from the menu has no idea which CD is currently inserted. Having VDSM report devices and placing it in the running conf will solve that issue but what about sustaining after power on/off.

For physical machines the last inserted CD is the CD available after power on. In the current implementation it's the one configured in the VM properties.

What happens if it's a highly available VM that a user has changed the CD and now has crashed and restarted? The user will either loose his inserted CD or worse the CD will change. 



> > 
> > 5. I suggest a hackish API that would let us solve the problem in
> > stages: Engine would not have to explicitly list an empty CD.
> > However,
> > it would send a hack flag: hackAutoCD=True for all VM starting up.
> 
> Why? changing the API is much more difficult than changing a few bits
> of code.
> All that is required from engine is to always add a cdrom if one does
> not exist.
> Same amount of work that would be required of vdsm to implement the
> hack, but would be much more flexible.
> Backward compatibility is not an issue as the API is new.
> Using the old API would keep the old behaviour.

+1

> 
> > 
> > If this flag is True, Vdsm would add an IDE CDROM to the devices
> > list.
> > 
> > In the future, Engine would drop this flag and specify the CDROM
> > only
> > when needed.
> > 
> > Please note that (3) is still correct - Engine would see the CDROM
> > device and its address even if it was empty when the VM started
> > running.
> > 
> > 
> > Comments?
> > 
> > Dan.
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>