Rich, libvirt doesn't directly support renaming a domain, although we have a
longstanding bug for that. The reason is that domain name is unfortunately
used key for storing various domain related information. To rename a domain,
you need to dump its XML, undefine the domain, change the name in the XML and
use it to define the same domain with different name.

The steps you used work as desired. It's an undocumented feature of virsh edit
(coming from its use of virDomainDefine API) and can be used for cloning
domain definition.

What to do here? We shouldn't change virDomainDefine behavior obviously, but maybe we can add a 'virsh edit' specific check like

if newname != oldname:

Finishing that thought, basically if newname != oldname, print some message explaining you cannot rename a guest with edit command. can use virsh define w/ new name and uuid, but that has caveats like not moving over saved state, snapshots, etc.

Hello, 

I will  love to work on this bug. I just need some more specifics on the files;  I should look at to fix this  bug.

Thanks,
Noella

'virsh edit' handling is kind of confusing.

See tools/virsh-domain.c:cmdEdit for the 'virsh edit' entry point. But a lot of the edit support is generic infrastructure in tools/virsh-edit.c

If I was going to implement this, I'd extend tools/virsh-edit.c to take another macro like EDIT_XML_IDENTITY_CHANGED. It will need to take the original XML, and the new XML, and compare their name and UUID values. If both have changed, then prompt the user to ask if that's what they want. You can use the virXPathString function to help parsing the XML to get the name and UUID, look for other examples in virsh-domain.c

Unfortunately though the description of this bug makes it sound easier than the actual implementation would be...

I think this bug should be closed. Rich, this way of cloning domains is practically a misuse of virsh edit. I mean it's possible only because virsh uses virDomainDefine() underneath. If we ever come up with virDomainChangeXML() which would update anything but the domain name and UUID, virsh edit would have fail. The best we can do - to increase the virsh user-friendliness is to do what Cole suggested. But on the other hand, I know plenty of libvirt developers who misuse this behaviour (myself included) so I don't like to see it changed.

On the other hand, once libvirt supports object rename, virsh {net-,vol-,...}edit can adapt that. Until then, I think current behaviour should be preserved.

(In reply to Michal Privoznik from comment #6)
> I think this bug should be closed. Rich, this way of cloning domains is
> practically a misuse of virsh edit. I mean it's possible only because virsh
> uses virDomainDefine() underneath. If we ever come up with
> virDomainChangeXML() which would update anything but the domain name and
> UUID, virsh edit would have fail. The best we can do - to increase the virsh
> user-friendliness is to do what Cole suggested. But on the other hand, I
> know plenty of libvirt developers who misuse this behaviour (myself
> included) so I don't like to see it changed.
> 

I was thinking that if we detected name + UUID change, we would print an error, but with a prompt option to continue anyways. So it wouldn't be blocking users who intentionally want to create a new VM definition, but we still warn people who might not know what they are doing.

That said the edit handling code is already quite intense, and I doubt many people make this mistake in practice, so personally I don't mind if this bug is closed

Well in this case. I will prefer to work on another bug then.

Thanks for the assistance.
Noella

(In reply to Cole Robinson from comment #7)
> <snip/>
> That said the edit handling code is already quite intense, and I doubt many
> people make this mistake in practice, so personally I don't mind if this bug
> is closed

Okay, I'm closing this one then. It's worth mentioning that libvirt grew rename command as part of GSoC project:

virsh domrename $oldname $newname