Bug 1375379

VM rename takes place on host only when the VM is restarted. Engine should be aware of that, and not allow re-using of a currently-running VM.

The VM name should be added to the list of fields which require a VM restart. That way there would be a pending change indication

(In reply to Michal Skrivanek from comment #9)
Right, but that will be a bit more complicated than just changing the setting of the 'name' field. Consider the following case:
1. You run a VM called 'A'
2. You rename this VM to 'B'
3. You create another VM called 'B'

After #2 the name 'B' is contained only in the next-run snapshot so in order to prevent #3 from happening, not only that we need to check engine-locks and entries in vm_static but also the configuration of next-run snapshots (xml format in the 'snapshot' table) when checking name validity.

(In reply to Arik from comment #10)
> (In reply to Michal Skrivanek from comment #9)
> Right, but that will be a bit more complicated than just changing the
> setting of the 'name' field. Consider the following case:
> 1. You run a VM called 'A'
> 2. You rename this VM to 'B'
> 3. You create another VM called 'B'
> 
> After #2 the name 'B' is contained only in the next-run snapshot so in order
> to prevent #3 from happening, not only that we need to check engine-locks
> and entries in vm_static but also the configuration of next-run snapshots
> (xml format in the 'snapshot' table) when checking name validity.

Yet another reason why my suggestion in comment 8 makes sense.

(In reply to Yaniv Kaul from comment #11)
> Yet another reason why my suggestion in comment 8 makes sense.

I agree, but why both name and UUID and not only UUID?
It seems that we currently have a bug in getting the pid of the VM in the engine, but assuming we can present its pid to ease the identification of the qemu-process I see no reason not to use just the UUID

(In reply to Arik from comment #12)
> (In reply to Yaniv Kaul from comment #11)
> > Yet another reason why my suggestion in comment 8 makes sense.
> 
> I agree, but why both name and UUID and not only UUID?
> It seems that we currently have a bug in getting the pid of the VM in the
> engine, but assuming we can present its pid to ease the identification of
> the qemu-process I see no reason not to use just the UUID

Names are user friendly, makes debugging easier.
It'll be also easier for monitoring purposes (otherwise, VDSM has no idea what the VM name is and need a query to engine from somewhere).

(In reply to Yaniv Kaul from comment #13)
> (In reply to Arik from comment #12)
> > (In reply to Yaniv Kaul from comment #11)
> > > Yet another reason why my suggestion in comment 8 makes sense.
> > 
> > I agree, but why both name and UUID and not only UUID?
> > It seems that we currently have a bug in getting the pid of the VM in the
> > engine, but assuming we can present its pid to ease the identification of
> > the qemu-process I see no reason not to use just the UUID
> 
> Names are user friendly, makes debugging easier.
> It'll be also easier for monitoring purposes (otherwise, VDSM has no idea
> what the VM name is and need a query to engine from somewhere).

I don't like the option of ugly name.
And this will not solve the issue for metrics. 
Why not change it on the host?

I do like the idea,  I don't think it is ugly and it gives a good solution to the metrics,  soI don't see what the issue is. 
Changing it on the host is another verb,  probably not very difficult I reckon,  but we'll need to see how libvirt handles it (even their log files are based on domain names).

(In reply to Arik from comment #10)
> (In reply to Michal Skrivanek from comment #9)
> Right, but that will be a bit more complicated than just changing the
> setting of the 'name' field. Consider the following case:
> 1. You run a VM called 'A'
> 2. You rename this VM to 'B'
> 3. You create another VM called 'B'
> 
> After #2 the name 'B' is contained only in the next-run snapshot so in order
> to prevent #3 from happening, not only that we need to check engine-locks
> and entries in vm_static but also the configuration of next-run snapshots
> (xml format in the 'snapshot' table) when checking name validity.

Yes, until the stop of 'A' the 'B' wouldn't  be able to start (on the same host). Sure, but why would we mind?
I do not believe pure UUID is a better solution as you can change it the same way as a name - it's a configurable field.
IF we use UUID+name - then you end up with different "rows" fro metrics each time you change either of those fields...it may make sense, but it can also be annoying.
That's why I'm much more in favor to not change anything and keep it as is with comment #9 to make it a bit more obvious.

(In reply to Michal Skrivanek from comment #16)
> I do not believe pure UUID is a better solution as you can change it the
> same way as a name - it's a configurable field.

You can set the initial value of this field while creating a VM or ask to generate one by cloning a VM, but once the VM is created - the UUID cannot be changed.

so, what's the outcome?

verified on version: 4.1.0.3-0.1.el7

1. run a VM called 'A'
2. rename this VM to 'B' -> Icon appears on the VM, which require a VM restart. That way there would be a pending change indication 
3. create another VM called 'B' -> Warning appears - 'Name is already used the environment, create new unique name'