> -----Original Message----- > From: engine-devel-boun...@ovirt.org [mailto:engine-devel-boun...@ovirt.org] > On Behalf Of Livnat Peer > Sent: Sunday, February 19, 2012 1:07 PM > To: Dan Kenigsberg > Cc: engine-devel@ovirt.org; a...@ovirt.org > Subject: Re: [Engine-devel] Empty cdrom drive. > > On 15/02/12 11:29, Miki Kenneth wrote: > > > > > > ----- Original Message ----- > >> From: "Ayal Baron" <aba...@redhat.com> > >> To: "Yaniv Kaul" <yk...@redhat.com> > >> Cc: engine-devel@ovirt.org > >> Sent: Wednesday, February 15, 2012 11:23:54 AM > >> Subject: Re: [Engine-devel] Empty cdrom drive. > >> > >> > >> > >> ----- Original Message ----- > >>> On 02/15/2012 09:44 AM, 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. > >>>> > > > The preferred solution IMO would be to let the user choose if he wants a > VM with CD or not. > I think the motivation for the above is to 'save' IDE slot if a user > does not need CD. > > If the user wants to have a VM with CD the engine would create an empty > CD and pass it to VDSM as a device, but if the user does not require a > CD there is no reason to create it in VDSM nor in the OE (oVirt Engine). > > Supporting the above requires the engine upgrade to create empty CD > device to all VMs. >
+1 Indeed, this is a right thing to do > Dan - what happens in 3.0 API if the engine passes the element cdrom but > with empty path attribute. (I know that if the engine does not pass > cdrom element VDSM creates empty CD) We will still create an empty CD > > > Livnat > > > >>>> Note: The new libvirt remove previous restriction on cdrom > >>>> devices. > >>>> Now > >>>> cdrom can be created as IDE or VIRTIO device in any index. > >>>> It means we can easily hotplug it. > >>> > >>> I didn't know a CDROM can be a virtio device, but in any way it > >>> requires > >>> driver (which may not exist on Windows). > >>> I didn't know an IDE CDROM can be hot-plugged (only USB-based?), > >> > >> It can't be hotplugged. > >> usb based is not ide (the ide device is the usb port, the cdrom is a > >> usb device afaik). > >> > >> The point of this email is that since we want to support being able > >> to start VMs *without* a cdrom then the default behaviour of > >> attaching a cdrom device needs to be implemented in engine or we > >> shall have a regression. > > This is a regression that we can not live with... > >> In the new API (for stable device addresses) vdsm doesn't > >> automatically attach a cdrom. > >> > >>> perhaps > >>> I'm wrong here. > >>> Y. > >>> > >>>> > >>>> > >>>> Regards, > >>>> Igor Lvovsky > >>>> > >>>> > >>>> _______________________________________________ > >>>> Engine-devel mailing list > >>>> Engine-devel@ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> Engine-devel@ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
