[Users] Setting UUID

Simon Grinberg simon at redhat.com
Sun Feb 19 09:08:23 UTC 2012



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: users at ovirt.org
> Sent: Sunday, February 19, 2012 9:43:30 AM
> Subject: Re: [Users] Setting UUID
> 
> On 02/18/2012 11:15 PM, Livnat Peer wrote:
> > On 18/02/12 22:33, Nathan Stratton wrote:
> >> On Sat, 18 Feb 2012, Livnat Peer wrote:
> >>
> >>> How about setting the VM name instead of UUID? It won't update
> >>> permissions automatically though.
> >>
> >> Not sure I follow, VM name is good, but there are all sorts of
> >> things
> >> that care about UUID changing.
> >
> > off the top my head I can think of
> > - permissions
> > - events
> > - tags
> > - quota
> >
> > Permission and Quota can be handled manually the other two won't
> > point
> > to 'new' VM.
> >
> >> That is why we are looking for the
> >> ability to set it. Today it looks like all UUIDs are random, and I
> >> assume that a UUID needs to be unique, but how hard would it be to
> >> be
> >> able to specify a UUID? Libvirt allows this to be done and we do
> >> it all
> >> the time in our XML kvm files.
> >
> > Changing VM id does not sound like a complicated feature, when
> > designing
> > such a feature need to think of what are the impact on the history
> > DB
> > and events in the audit log (if such id was in use before).
> 
> Nathan - it would be good to start by explaining if you care about
> the
> UUID as the engine sees it, or as devices and applications see it in
> the
> guest.
> I'm guessing you care about the guest.
> to do what you want, would rquire decoupling the uuid as used by
> engine
> to identify the guest, from the one vdsm exposes to the guest.
> today the entire chain (including libvirt) uses the same uuid.

That was my first reaction when reading that:
"Not sure that you want to break that, it will require more mapping later.
Assume an external monitoring tool the collects stats, if the VM has the same hardware UUID as the engine uses it will be easier to correlate the data separately from a guest agent and from the history DB."

But then I've started to think that in some DR scenarios where both VMs (backup and source) are on the same engine but different clusters/sites. I think that an option to manually set the UUID of a VM is a must. So a better option would be to have HW UUID field in the VM properties where like for MACs you'll have the option to generate automatically or set manually. This mapping must be managed by the engine for use cases as I've mentioned above.




> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 



More information about the Users mailing list