[libvirt] virsh edit error
In an attempt to rename a kvm vm (which was powered off) I performed the following: $ virsh edit old-name Then changed <name>old-name</name> to <name>new-name</name> and saved and quit from the editor. $ virsh list --all Id Name State ---------------------------------- - old-name shut off - new-name shut off Performing an edit on each of these shows they're completely identical. Even the <name> section shows the old-name on both of them. I've performed restarts of libvirtd as well. If the action I did is truly invalid, we should catch that an error out on it. However I think VM renaming can be a valid use case and we have the UUID to match off of for the rename. Basically, I'm contacting the list to see if my use case was invalid and I should write my patch to spit an error, or if I should write my patch to correct the improper handling. Patch to follow based on responses. Thanks all. -- Doug Goldstein
Doug Goldstein wrote:
In an attempt to rename a kvm vm (which was powered off) I performed the following:
$ virsh edit old-name
Then changed <name>old-name</name> to <name>new-name</name> and saved and quit from the editor.
$ virsh list --all
Id Name State ---------------------------------- - old-name shut off - new-name shut off
Performing an edit on each of these shows they're completely identical. Even the <name> section shows the old-name on both of them. I've performed restarts of libvirtd as well.
If the action I did is truly invalid, we should catch that an error out on it. However I think VM renaming can be a valid use case and we have the UUID to match off of for the rename. Basically, I'm contacting the list to see if my use case was invalid and I should write my patch to spit an error, or if I should write my patch to correct the improper handling. Patch to follow based on responses.
I actually noticed this the other day too, I just forgot to file a bug about it. Since the "uniqueness" of a domain is ultimately decided by the UUID, I think that editing the name should be an allowed operation, and we should just handle it. This, of course, brings up the question of what do you do if you want to change the UUID. Following the principle of least surprise, though, I would think that editing the UUID would also be allowed. If you did so, I guess it would be considered a new domain, but we should be able to handle that as well. -- Chris Lalancette
On Fri, Jun 05, 2009 at 09:17:48AM +0200, Chris Lalancette wrote:
Doug Goldstein wrote:
In an attempt to rename a kvm vm (which was powered off) I performed the following:
$ virsh edit old-name
Then changed <name>old-name</name> to <name>new-name</name> and saved and quit from the editor.
$ virsh list --all
Id Name State ---------------------------------- - old-name shut off - new-name shut off
Performing an edit on each of these shows they're completely identical. Even the <name> section shows the old-name on both of them. I've performed restarts of libvirtd as well.
If the action I did is truly invalid, we should catch that an error out on it. However I think VM renaming can be a valid use case and we have the UUID to match off of for the rename. Basically, I'm contacting the list to see if my use case was invalid and I should write my patch to spit an error, or if I should write my patch to correct the improper handling. Patch to follow based on responses.
I actually noticed this the other day too, I just forgot to file a bug about it. Since the "uniqueness" of a domain is ultimately decided by the UUID, I think that editing the name should be an allowed operation, and we should just handle it. This, of course, brings up the question of what do you do if you want to change the UUID. Following the principle of least surprise, though, I would think that editing the UUID would also be allowed. If you did so, I guess it would be considered a new domain, but we should be able to handle that as well.
I considered the problem of renaming, but it is non-trivial to do it atomically, especially if the guest is currently running (NB you can run 'define' while it is running). Hence we now reject this explicitly We could perhaps add an explicit virDomainRename() API though, which explicitly required that the VM not be running. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Thu, Jun 04, 2009 at 05:03:14PM -0500, Doug Goldstein wrote:
In an attempt to rename a kvm vm (which was powered off) I performed the following:
$ virsh edit old-name
Then changed <name>old-name</name> to <name>new-name</name> and saved and quit from the editor.
$ virsh list --all
Id Name State ---------------------------------- - old-name shut off - new-name shut off
Performing an edit on each of these shows they're completely identical. Even the <name> section shows the old-name on both of them.
If the action I did is truly invalid, we should catch that an error out on it. However I think VM renaming can be a valid use case and we have the UUID to match off of for the rename. Basically, I'm contacting the list to see if my use case was invalid and I should write my patch to spit an error, or if I should write my patch to correct the improper handling. Patch to follow based on responses.
What libvirt version have you got ? We recently added a patch to explicitly refuse this scenario of sanme UUID, but different names /* See if a VM with matching UUID already exists */ vm = virDomainFindByUUID(&driver->domains, def->uuid); if (vm) { /* UUID matches, but if names don't match, refuse it */ if (STRNEQ(vm->def->name, def->name)) { char uuidstr[VIR_UUID_STRING_BUFLEN]; virUUIDFormat(vm->def->uuid, uuidstr); qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED, _("domain '%s' is already defined with uuid %s"), vm->def->name, uuidstr); goto cleanup; } ... It also refuses case of different UUIDs, but same names. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (3)
-
Chris Lalancette -
Daniel P. Berrange -
Doug Goldstein