[libvirt] [PATCH v2 3/3] conf: Allow users to define UUID for devices
Jim Fehlig
jfehlig at suse.com
Mon Oct 30 22:12:23 UTC 2017
On 10/30/2017 03:31 PM, Jim Fehlig wrote:
> On 10/03/2017 07:53 AM, Daniel P. Berrange wrote:
>> On Tue, Oct 03, 2017 at 02:11:44PM +0200, Martin Kletzander wrote:
>>> On Tue, Oct 03, 2017 at 12:58:59PM +0200, Michal Privoznik wrote:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1434451
>>>>
>>>> It comes handy for management application to be able to have a
>>>> per-device label so that it can uniquely identify devices it
>>>> cares about. The advantage of this approach is that we don't have
>>>> to generate aliases at define time (non trivial amount of work
>>>> and problems). The only thing we do is parse the user supplied
>>>> UUID and format it back. For instance:
>>>>
>>>> <disk type='block' device='disk'>
>>>> <driver name='qemu' type='raw'/>
>>>> <source dev='/dev/HostVG/QEMUGuest1'/>
>>>> <target dev='hda' bus='ide'/>
>>>> <uuid>1efaf08b-9317-4b0f-b227-912e4bd9f483</uuid>
>>>> <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>>>> </disk>
>>>>
>>>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>>>> ---
>>>>
>>>> This is just a very basic implementation. If I get a green light on this, I can
>>>> implement the feature further, i.e. allow device lookup on the UUID. For
>>>> instance:
>>>>
>>>> virsh domiftune fedora $UUID $bandwidth
>>
>> <snip>
>>
>> I'm thinking that part of the problem we're having with agreeing how to
>> deal with this RFE is that we're over-analysing semantics, by wondering
>> whether its a unique name or UUID, its relation to alias, whether it has
>> bearing on APIs.
>>
>> How about we change tack, and do what we did when we needed application
>> specific information at the top level - just declare a general purpose
>> <metadata> element and say it is a completely opaque blob. Libvirt will
>> *never* do anything with it, other than to preserve it exactly as is.
>> No API will ever use the metadata in any way. Libvirt will never try to
>> guarantee uniqueness of metadata for each device. It can be JSON or a
>> gziped microsoft word document for all we care. Entirely upto the app
>> developer to decide what metadata is saved and guarantee uniqueness if
>> they so desired.
>
> I vote for the opaque blob since it would be helpful for my use case described here
>
> https://www.redhat.com/archives/libvir-list/2017-October/msg01329.html
I should have read further ahead in my mail backlog, where I would have
discovered this has already be solved using <alias>. That's fine, but I'm
curious why the domain of permissible characters is restricted? Could it include
():;/ ?
Regards,
Jim
>
> The <metadata> element could contain the 'some-dev-config' from my example and
> alleviate the need to modify XML. <metadata> at the device level is a bit
> cleaner for hot (un)plug IMO. E.g.
>
> virsh attach-device foo << 'EOF'
> <disk type='block' device='disk'>
> <metadata>some-dev-config</metadata>
> <driver name='qemu' type='raw'/>
> <source dev='/dev/vg1/lv1'/>
> <target dev='vdb' bus='virtio'/>
> </disk>
> EOF
>
> Regards,
> Jim
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
More information about the libvir-list
mailing list