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

[Livnat Peer]

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 at redhat.com>
>>> To: "Livnat Peer" <lpeer at redhat.com>
>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>, engine-devel at ovirt.org, vdsm-devel at 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 at redhat.com>
>>>> To: "Dan Kenigsberg" <danken at redhat.com>
>>>> Cc: "Genadi Chereshnya" <gcheresh at redhat.com>,
>>>> engine-devel at ovirt.org, vdsm-devel at 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...


> 
> Dan.
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>