Re: [Engine-devel] [vdsm] unmanaged devices thrown into 'custom' feature

----- Original Message ----- > From: "Livnat Peer" <lpeer(a)redhat.com&gt; > To: "Dan Kenigsberg" <danken(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org, "Genadi Chereshnya" <gcheresh(a)redhat.com&gt;, vdsm-devel(a)fedorahosted.org > 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" <yzaslavs(a)redhat.com&gt; > >>> To: "Livnat Peer" <lpeer(a)redhat.com&gt; > >>> Cc: "Genadi Chereshnya" <gcheresh(a)redhat.com&gt;, > >>> engine-devel(a)ovirt.org, vdsm-devel(a)fedorahosted.org > >>> Sent: Sunday, October 21, 2012 5:38:54 PM > >>> Subject: Re: [Engine-devel] unmanaged devices thrown into > >>> 'custom' feature > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Livnat Peer" <lpeer(a)redhat.com&gt; > >>>> To: "Dan Kenigsberg" <danken(a)redhat.com&gt; > >>>> Cc: "Genadi Chereshnya" <gcheresh(a)redhat.com&gt;, > >>>> engine-devel(a)ovirt.org, vdsm-devel(a)fedorahosted.org > >>>> 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.