On Wed, Feb 15, 2012 at 07:16:15AM -0500, Igor Lvovsky
wrote:>
>
> > -----Original Message-----
> > From: Dan Kenigsberg [mailto:danken at redhat.com]
> > Sent: Wednesday, February 15, 2012 1:25 PM
> > To: Igor Lvovsky
> > Cc: Livnat Peer; Doron Fediuck; Ayal Baron; ovirt-devel at redhat.com
> > Subject: Re: Empty cdrom drive.
> >
> > 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.
> >
> > 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.
> >
>
> -1. I am disagree with this approach.
> If Engine can send hackAutoCD for old VMs I can't find a reason why do
not
> send device instead.
My suggestion was that Engine would send hackAutoCD for *ALL* VMs -
until Engine is capable to handle VMs without CD devices.
Vdsm would ignore this flag if a cdrom is already specified in
"devices". Thus, future Engines can drop the hackAutoCD flag and gain
cdrom-less VMs.
> As you mentioned above vdsm anyway will return this cdrom device to Engine
> and engine will
> need to put it in DB. This will cover all old VMs and there is no reason
> do not send empty cdrom device
> for new created VM.
>
> > 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.