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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
---

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

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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux