[libvirt] [PATCH v2 3/3] conf: Allow users to define UUID for devices

Martin Kletzander mkletzan at redhat.com
Tue Oct 3 14:03:20 UTC 2017

On Tue, Oct 03, 2017 at 02:53:46PM +0100, 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
>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.

That is kind of what I was aiming for.  But in order for it to be cleaner and
easier to use from user as well (and not only mgmt apps) I thought the metadata
would just be one identifier.  If you want to store more metadata for the
device, then you can do all that in the domain metadata and just reference the
particular device using the identifier if mgmt app wants to do that.

I'm just trying to see this from both of the big pictures. a) making it usable
for mgmt apps and b) not constraining it to programs, but also allowing users to
take "advantage" of that.

So in the end metadata feels better than uuid, but I think we could still make
it *way* simpler.  Not only for mgmt apps and users, but also for us as libvirt
developers by minimizing the technical debt and possible future drawbacks.

>|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
>|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
>|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20171003/73c10f89/attachment-0001.sig>

More information about the libvir-list mailing list