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


I'll be frank with you, I hate the fact that this can only be UUID and
there are reasons.  Even though other will^Wmight not share my view.

I don't want to ACK this patch even though it probably works OK.  At the
same time I'm not NACKing it since I might get overruled.

OK, it's my bad I didn't reply on the previous version, but I don't like
this so much I'll reply to it even in this new version.

So let me sum it up:

1) UUIDs are more generally useful concept

   Allowing arbitrary (but sane, e.g. [a-zA-Z0-9\-_.]) also inherently
   allows UUID is mgmt apps want to use them.  This field should never
   be used by a hypervisor, only by drivers and if necessary.

2) We cannot extend current APIs to support it, it can clash with
   libvirt's alias in the future.

   I don't see why not.  Searching by IDs (or user aliases, whatever
   you call it) does not have to be supported at all.  Mgmt apps can
   use is only as a part of domain definition.  If we want to add such
   functionality, then it can be turned on by a flag or flags, e.g.:

    - VIR_BLAH_BY_ID
    - VIR_BLAH_PREFER_ID
    - VIR_BLAH_WHATEVER

   But there is no requirement for us to provide this.  It should not
   be blocking the inclusion of this feature.

3) We have to add a lot of code that handles duplicates, etc.

   No.  No, we don't.  Duplicates can not only be handled by mgmt app
   itself, it could also be beneficial.  Imagine I have bunch of
   devices that share some source or are similar in a way and I just
   name them the same.  Even if we want to provide a way of specifying
   devices for APIs by this user supplied string, we can just unplug
   the first one we'll find.

By not requiring that it's an ID, users can take benefit of ti too.  And
making sure it's an UUID seems like a waste of computing power.

Sometimes I feel like we are trying to do too much, even stuff that
nobody will effectively use and then we have to support it.  The same
with solving corner cases in which we could just error out instead of
wasting manpower on them.

My (way more than) 2 cents.

Have a nice day,
Martin

Attachment: signature.asc
Description: Digital signature

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