[libvirt] [PATCH v3 0/5] domainRename API implementation
Michal Privoznik
mprivozn at redhat.com
Wed Aug 12 13:16:07 UTC 2015
On 10.08.2015 21:59, Tomas Meszaros wrote:
> This is an effort to implement domain rename API. Presented patch series
> consists of the following: virDomainRename API implementation for qemu,
> implementation of the virsh command domrename and the additional support
> code.
>
> The idea behind this endeavor is to provide convenient and safe way to rename
> a domain.
>
> Instead of the:
>
> virsh dumpxml domain > domain.xml
> (change domain name in domain.xml)
> virsh undefine domain
> virsh define domain.xml
>
> user can simply type:
>
> virsh domrename foo bar
>
> or call virDomainRename() API and domain "foo" will be renamed to "bar".
>
> We currently support only renaming inactive domains without snapshots.
> Renaming procedure takes care of domain log, config, guest agent path and should
> be able to recover in case of failure.
>
> I've been working on this functionality in collaboration with Michal Privoznik
> who is my mentor during the GSoC 2015. If you have any questions, ideas
> or criticism feel free to join the discussion.
>
>
> v2:
> - removed guest agent path rename code
> - removed rename permission
> - added code for emitting undefined+renamed event for the old domain
>
> v3:
> - removed domain rename permission
> - fixed virDomainRename doc comment
> - added @flags parameter to the virDomainRename API
>
> Tomas Meszaros (5):
> Introduce virDomainRename API
> virsh: Implement "domrename" command
> domain_conf: Introducde virDomainObjListRenameAddNew() &
> virDomainObjListRenameRemove()
> Introduce new VIR_DOMAIN_EVENT_DEFINED_RENAMED event
> qemu: Implement virDomainRename
>
> examples/object-events/event-test.c | 4 +
> include/libvirt/libvirt-domain.h | 6 ++
> src/conf/domain_conf.c | 35 +++++++++
> src/conf/domain_conf.h | 5 ++
> src/driver-hypervisor.h | 6 ++
> src/libvirt-domain.c | 34 +++++++++
> src/libvirt_private.syms | 2 +
> src/libvirt_public.syms | 5 ++
> src/qemu/qemu_driver.c | 145 ++++++++++++++++++++++++++++++++++++
> src/remote/remote_driver.c | 1 +
> src/remote/remote_protocol.x | 18 ++++-
> src/remote_protocol-structs | 8 ++
> tools/virsh-domain.c | 63 +++++++++++++++-
> tools/virsh.pod | 7 ++
> 14 files changed, 336 insertions(+), 3 deletions(-)
>
Okay, this looks good to me. Well, consider this squashed in:
diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
index 71ea024..9065dab 100644
--- a/src/libvirt-domain.c
+++ b/src/libvirt-domain.c
@@ -8784,11 +8784,12 @@ virDomainIsPersistent(virDomainPtr dom)
* argument. Depending on each driver implementation it may be
* required that domain is in a specific state.
*
- * Returns 0 if renamed, -1 on error
+ * Returns 0 if successfully renamed, -1 on error
*/
int
-virDomainRename(virDomainPtr dom, const char *new_name,
- unsigned int flags ATTRIBUTE_UNUSED)
+virDomainRename(virDomainPtr dom,
+ const char *new_name,
+ unsigned int flags)
{
VIR_DEBUG("dom=%p, new_name=%s", dom, NULLSTR(new_name));
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index a29cd1b..3926ccd 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -19873,7 +19873,7 @@ qemuDomainSetUserPassword(virDomainPtr dom,
static int qemuDomainRename(virDomainPtr dom,
const char *new_name,
- unsigned int flags ATTRIBUTE_UNUSED)
+ unsigned int flags)
{
virQEMUDriverPtr driver = dom->conn->privateData;
virQEMUDriverConfigPtr cfg = NULL;
@@ -19889,6 +19889,8 @@ static int qemuDomainRename(virDomainPtr dom,
char *old_dom_name = NULL;
char *old_dom_cfg_file = NULL;
+ virCheckFlags(0, ret);
+
if (VIR_STRDUP(new_dom_name, new_name) < 0)
goto cleanup;
diff --git a/src/remote_protocol-structs b/src/remote_protocol-structs
index 1fdaa55..ca36dc9 100644
--- a/src/remote_protocol-structs
+++ b/src/remote_protocol-structs
@@ -2687,6 +2687,7 @@ struct remote_domain_set_user_password_args {
struct remote_domain_rename_args {
remote_nonnull_domain dom;
remote_string new_name;
+ u_int flags;
};
struct remote_domain_rename_ret {
int rename;
ACK series. Although, since this is somewhat controversial topic, I'll
let others to chime in and express their feelings before pushing.
Michal
More information about the libvir-list
mailing list