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