4:40 p.m.
Is there anyway to set a specific UUID for a VM?
<>
Nathan Stratton CTO,
BlinkMind, Inc.
nathan at robotics.net nathan at blinkmind.com
http://www.robotics.net http://www.blinkmind.com
12:13 p.m.
On Sat, 18 Feb 2012, Itamar Heim wrote:
On 02/18/2012 12:40 AM, Nathan Stratton wrote:
>
> Is there anyway to set a specific UUID for a VM?
no.
may i ask why?
Many times when we move or copy a guest we need to keep the same UUID. As
an example we have a VM that is running Centos 4 that we need upgraded to
Centos 6.2. How we have done this in the past:
Build new VM
Install fresh Centos 6.2
Copy over the application
Shutdown the first VM
Shutdown the 2nd VM and change UUID to match first
Fire up 2nd VM if everything works kill delete 1st VM
We run into all sorts of other situations when we make copies as backups
and need to go to one of the backups. We never need to run a two VMs with
the same UUID, but often have a box where we need to change the UUID to
match what an old box was using.
<>
Nathan Stratton CTO,
BlinkMind, Inc.
nathan at robotics.net nathan at blinkmind.com
http://www.robotics.net http://www.blinkmind.com
2:22 p.m.
On 18/02/12 20:13, Nathan Stratton wrote:
On Sat, 18 Feb 2012, Itamar Heim wrote:
> On 02/18/2012 12:40 AM, Nathan Stratton wrote:
>>
>> Is there anyway to set a specific UUID for a VM?
>
> no.
> may i ask why?
Many times when we move or copy a guest we need to keep the same UUID.
As an example we have a VM that is running Centos 4 that we need
upgraded to Centos 6.2. How we have done this in the past:
Build new VM
Install fresh Centos 6.2
Copy over the application
Shutdown the first VM
Shutdown the 2nd VM and change UUID to match first
Fire up 2nd VM if everything works kill delete 1st VM
How about setting the VM name instead of UUID? It won't update
permissions automatically though.
We run into all sorts of other situations when we make copies as
backups
and need to go to one of the backups. We never need to run a two VMs
with the same UUID, but often have a box where we need to change the
UUID to match what an old box was using.
> <>
Nathan Stratton CTO, BlinkMind, Inc.
nathan at robotics.net nathan at blinkmind.com
http://www.robotics.net http://www.blinkmind.com
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
2:33 p.m.
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. 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.
<>
Nathan Stratton CTO,
BlinkMind, Inc.
nathan at robotics.net nathan at blinkmind.com
http://www.robotics.net http://www.blinkmind.com
3:15 p.m.
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 Stratton CTO, BlinkMind, Inc.
nathan at robotics.net nathan at blinkmind.com
http://www.robotics.net http://www.blinkmind.com
8:28 p.m.
On Sat, 18 Feb 2012, Livnat Peer wrote:
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).
Any idea how to create a SQL statement to do it? I don't know enough about
SQL to build a statement, but I was able to export the DB, change all of
the references from the starting UUID to the new UUID I wanted and then
rebuild the DB. I then we able to start the VM and it used the new UUID in
the db without issue. I am sure there is a simpler method, but that is
all I had.
1:43 a.m.
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.
3:08 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Livnat Peer" <lpeer(a)redhat.com>
Cc: users(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
1:25 a.m.
----- Original Message -----
On Sat, 18 Feb 2012, Itamar Heim wrote:
> On 02/18/2012 12:40 AM, Nathan Stratton wrote:
>>
>> Is there anyway to set a specific UUID for a VM?
>
> no.
> may i ask why?
Many times when we move or copy a guest we need to keep the same
UUID. As
an example we have a VM that is running Centos 4 that we need
upgraded to
Centos 6.2. How we have done this in the past:
Build new VM
Install fresh Centos 6.2
Copy over the application
Shutdown the first VM
Shutdown the 2nd VM and change UUID to match first
Fire up 2nd VM if everything works kill delete 1st VM
What you want is the ability to copy the VM configuration, not to change the UUID.
The point of a UUID is that it is a Universally Unique ID, hence there should be only 1
such in the universe.
Instead of suggesting a solution, it is better to explain the problem.
Having the ability to clone the configuration of a VM would be a lot more useful (e.g. it
can be done multiple times and wouldn't be limited to a single VM).
We run into all sorts of other situations when we make copies as
backups
and need to go to one of the backups. We never need to run a two VMs
with
the same UUID, but often have a box where we need to change the UUID
to
match what an old box was using.
><>
Nathan Stratton CTO, BlinkMind, Inc.
nathan at robotics.net nathan at
blinkmind.com
http://www.robotics.net
http://www.blinkmind.com
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4449
days inactive
4451
days old
9 comments
5 participants
participants (5)
-
Ayal Baron -
Itamar Heim -
Livnat Peer -
Nathan Stratton -
Simon Grinberg