On Tue, Oct 23, 2012 at 05:53:20AM -0400, Doron Fediuck wrote: > > > ----- Original Message ----- > > From: "Livnat Peer" <[email protected]> > > To: "Dan Kenigsberg" <[email protected]> > > Cc: [email protected], "Genadi Chereshnya" <[email protected]>, > > [email protected] > > Sent: Monday, October 22, 2012 8:29:20 AM > > Subject: Re: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom' > > feature > > > > On 21/10/12 23:49, Dan Kenigsberg wrote: > > > On Sun, Oct 21, 2012 at 11:57:10AM -0400, Eli Mesika wrote: > > >> > > >> > > >> ----- Original Message ----- > > >>> From: "Yair Zaslavsky" <[email protected]> > > >>> To: "Livnat Peer" <[email protected]> > > >>> Cc: "Genadi Chereshnya" <[email protected]>, > > >>> [email protected], [email protected] > > >>> Sent: Sunday, October 21, 2012 5:38:54 PM > > >>> Subject: Re: [Engine-devel] unmanaged devices thrown into > > >>> 'custom' feature > > >>> > > >>> > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Livnat Peer" <[email protected]> > > >>>> To: "Dan Kenigsberg" <[email protected]> > > >>>> Cc: "Genadi Chereshnya" <[email protected]>, > > >>>> [email protected], [email protected] > > >>>> Sent: Sunday, October 21, 2012 5:18:31 PM > > >>>> Subject: Re: [Engine-devel] unmanaged devices thrown into > > >>>> 'custom' > > >>>> feature > > >>>> > > >>>> On 21/10/12 16:42, Dan Kenigsberg wrote: > > >>>>> I have just noticed that when a VM is started for the second > > >>>>> time, > > >>>>> Engine > > >>>>> issues the "create" vdsm verb with some information regarding > > >>>>> "unmanaged" devices (an example is shown below[1]) in the > > >>>>> 'custom' > > >>>>> propery bag. > > >>>>> > > >>>>> I'm surprised about this, as I was not aware of this usage of > > >>>>> the > > >>>>> 'custom' dictionary, and Vdsm is not doing anything with the > > >>>>> data. > > >>>>> > > >>>> > > >>>> If I recall correctly the idea of passing the unmanaged devices > > >>>> data > > >>>> in > > >>>> the custom property was to enable managing stable device > > >>>> addresses > > >>>> in > > >>>> the hooks (to devices that were added to the VM via hooks from > > >>>> the > > >>>> first > > >>>> place), so this info is there not for VDSM use. > > >>>> For example if you add a device in a hook it will be kept in the > > >>>> engine > > >>>> as a non managed device. later when starting the VM again you > > >>>> would > > >>>> like > > >>>> to assign the same device address to your device, and you can do > > >>>> so > > >>>> because you have access to the original address in the custom > > >>>> properties > > >>>> of the VM. > > >>> > > >>> This is exactly what Eli has explained Gendai and Dan today. > > > > > > (I was asking here because I did not understand the verbal > > > explanation.) > > > > > >> > > >> This is taken from the Stable Device Address design in > > >> http://wiki.ovirt.org/wiki/Features/Design/StableDeviceAddresses > > >> > > >> Unmanaged Device > > >> ----------------- > > >> Unmanaged Device will be supported in the new format and will > > >> include all unhandled devices as sound/controller/etc and future > > >> devices. Those devices will be persistent and will have Type , > > >> SubType (device specific) and an Address. For 3.1 an unmanaged > > >> Device is not exposed to any GUI/REST API. Unmanaged devices are > > >> passed to vdsm inside a Custom property. VDSM in it turn is > > >> passing this as is for possible hook processing. > > > > > > Thanks for the elaboration. Too bad that I've missed this issue > > > before. > > > > > > Are you aware of any hook making use of this? I hope that hook > > > writers > > > are not using APIs that are not documented in vdsmd(8). > > > > > > It seems as a classic case where a generic bag interface is coerced > > > into > > > an awkward partially-documented interface. > > > > > > I think that a better approach would have been to pass all devices > > > (managed and unmanaged alike) in the 'devices' property, and let > > > vdsm > > > expose whatever is needed to the before_vm_start hook. > > > > > > Maybe we can still do this. > > > > That was the original idea but Ayal objected and I think Igor did not > > like it as well... > > > > +2. > The original design had an 'unmanaged' (or generic) device type, and all > devices should have been normalized. But as explained, this was strongly > rejected in the VDSM side, causing Eli write some special handling for this > anomaly.
Can someone (Ayal?) explain the rejection on Vdsm side? Hiding part of the API in the custom propery bag requires strong reasoning indeed. Dan. _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
