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... > > Dan. > _______________________________________________ > vdsm-devel mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
