----- Original Message -----
> From: "Yair Zaslavsky" <yzasl...@redhat.com>
> To: "Livnat Peer" <lp...@redhat.com>
> Cc: "Genadi Chereshnya" <gcher...@redhat.com>, engine-de...@ovirt.org, 
> vdsm-de...@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" <lp...@redhat.com>
> > To: "Dan Kenigsberg" <dan...@redhat.com>
> > Cc: "Genadi Chereshnya" <gcher...@redhat.com>,
> > engine-de...@ovirt.org, vdsm-de...@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.

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. 



> However, just to elaborate - these "extra properties" are not stored
> at the two columns of vm_static (userdefined_properties,
> predefined_properties) at the DB.
> 
> > 
> > 
> > 
> > > Would anyone elaborate about it? On the face of it, it does not
> > > seem
> > > like a pleasant API. If Engine wants to tell Vdsm about the
> > > location of
> > > various devices, we should probably be using the 'devices'
> > > property, not
> > > the bag of 'custom' property made for user-defined hooks.
> > > 
> > > I hope this API pecularity can be avoided, and very much hope
> > > that
> > > no
> > > one is depending on it.
> > > 
> > > Dan.
> > > 
> > > 
> > > [1]
> > > 'custom': {
> > >     'device_e97a9759-1c1b-45ed-9ed9-7136ef538315': 'VmDevice
> > >     {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> > >     deviceId=e97a9759-1c1b-45ed-9ed9-7136ef538315, device=ide,
> > >     type=controller, bootOrder=0, specParams={},
> > >     address={bus=0x00, domain=0x0000, type=pci, slot=0x01,
> > >     function=0x1}, managed=false, plugged=true, readOnly=false,
> > >     alias=ide0}',
> > >     
> > > 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709':
> > >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> > >     deviceId=7bfffa34-2e27-4b01-b499-6ac79c997709, device=unix,
> > >     type=channel, bootOrder=0, specParams={}, address={port=1,
> > >     bus=0, controller=0, type=virtio-serial}, managed=false,
> > >     plugged=true, readOnly=false, alias=channel0}',
> > >     
> > > 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6':
> > >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> > >     deviceId=133d9bfa-c531-414e-ad20-208d67d5a5e6,
> > >     device=virtio-serial, type=controller, bootOrder=0,
> > >     specParams={}, address={bus=0x00, domain=0x0000, type=pci,
> > >     slot=0x04, function=0x0}, managed=false, plugged=true,
> > >     readOnly=false, alias=virtio-serial0}',
> > >     
> > > 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424device_48007de9-467d-46a1-aa84-cc1a6419b5fb':
> > >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> > >     deviceId=48007de9-467d-46a1-aa84-cc1a6419b5fb,
> > >     device=spicevmc, type=channel, bootOrder=0, specParams={},
> > >     address={port=3, bus=0, controller=0, type=virtio-serial},
> > >     managed=false, plugged=true, readOnly=false,
> > >     alias=channel2}',
> > >     
> > > 'device_e97a9759-1c1b-45ed-9ed9-7136ef538315device_133d9bfa-c531-414e-ad20-208d67d5a5e6device_7bfffa34-2e27-4b01-b499-6ac79c997709device_7c107c63-605f-4b21-9893-c052ec211424':
> > >     'VmDevice {vmId=068d4914-4191-400d-a220-17a7f2d8e80c,
> > >     deviceId=7c107c63-605f-4b21-9893-c052ec211424, device=unix,
> > >     type=channel, bootOrder=0, specParams={}, address={port=2,
> > >     bus=0, controller=0, type=virtio-serial}, managed=false,
> > >     plugged=true, readOnly=false, alias=channel1}'
> > > }
> > > _______________________________________________
> > > Engine-devel mailing list
> > > engine-de...@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > engine-de...@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> engine-de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to