[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [ovirt-devel] Empty cdrom drive.



On Wed, Feb 15, 2012 at 07:16:15AM -0500, Igor Lvovsky wrote:
> 
> 
> > -----Original Message-----
> > From: Dan Kenigsberg [mailto:danken redhat com]
> > Sent: Wednesday, February 15, 2012 1:25 PM
> > To: Igor Lvovsky
> > Cc: Livnat Peer; Doron Fediuck; Ayal Baron; ovirt-devel 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]