- Devel - libvirt List Archives

[libvirt] A problem in live migration
by 姚远 21 Jul '10

21 Jul '10

In virsh, I use command "migrate --live 1 qemu+ssh://10.1.10.60/system" to do live migration,but it shows error "internal error hostname on destination resolved to localhost, but migration requires an FQDN". I don't know why, and who do live migration successfully can help me. Thank you! My source and destination system are all fedora-13-x86_64, and the version of libvirt is 0.8.2

1 0

[libvirt] How to replace the management procedure in the virsh
by 姚远 21 Jul '10

21 Jul '10

In virsh, I usr "version" and it shows 编译使用的库：libvir 0.8.2 使用的库：libvir 0.8.2 使用的 API: QEMU 0.8.2 运行管理程序: QEMU 0.9.1 I want to replace QEMU 0.9.1 to QEMU 0.12.2, because 0.12.2 adds many new functions. I download qemu-kvm-0.12.2.tar.gz and install it, but the management procedure is not replaced. I know I should modify the profile of libvirt but I don't know where it is and how to modify it.

1 0

[libvirt] Unmarshalling error with migrate command
by Doug Goldstein 20 Jul '10

20 Jul '10

Hey guys, I'm using a server running libvirt 0.8.2 and my desktop running libvirt 0.8.2. My desktop has virt-manager 0.8.4 and I've got a Linux VM running on the server. I'm looking to use the new migration support to migrate the VM to my desktop from the server. Everytime I attempt the migration I get an error dialog containing the following (I've actually snagged this out of ~/.virt-manager/virt-manager.log [Wed, 07 Jul 2010 18:13:23 virt-manager 18880] DEBUG (migrate:456) Migrating vm=CentOS-5.4-i686-PAE from qemu+ssh://root@codeine/system to qemu:///system [Wed, 07 Jul 2010 18:13:23 virt-manager 18880] DEBUG (domain:1351) Migrating: conn=<libvirt.virConnect instance at 0x2a305f0> flags=7 dname=None uri=qemu://doug-pc/system rate=0[Wed, 07 Jul 2010 18:13:23 virt-manager 18880] DEBUG (error:86) Uncaught Error: unmarshalling remote_error : Unable to migrate guest: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/migrate.py", line 457, in _async_migrate vm.migrate(dstconn, migrate_uri, rate, live, secure) File "/usr/share/virt-manager/virtManager/domain.py", line 1352, in migrate self._backend.migrate(destconn.vmm, flags, newname, interface, rate) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 479, in migrate prefer to invoke virDomainMigrateToURI, avoiding the need to libvirtError: unmarshalling remote_error If anyone has any ideas, please let me know. -- Doug Goldstein

2 2

[libvirt] [PATCH 0/2] Fix two problems with creating new storage volumes
by Laine Stump 20 Jul '10

20 Jul '10

Both of these problems can occur only if a new storage volume is created by copying it from an existing volume. The first is a problem if the new volume is longer than the old (the new volume won't be zero-filled at the end), and the second happens if the new and old volumes are the same length (fsync wouldn't be called at the end of writing the new volume) (actually, before the 1st fix is applied, that problem would exist for *all* new volumes created as copies of existing volumes).

2 6

[libvirt] [PATCH] Fix a deadlock in bi-directional p2p concurrent migration.
by Chris Lalancette 20 Jul '10

20 Jul '10

If you try to execute two concurrent migrations p2p from A->B and B->A, the two libvirtd's will deadlock trying to perform the migrations. The reason for this is that in p2p migration, the libvirtd's are responsible for making the RPC Prepare, Migrate, and Finish calls. However, they are currently holding the driver lock while doing so, which basically guarantees deadlock in this scenario. This patch fixes the situation by adding qemuDomainObjEnterRemoteWithDriver and qemuDomainObjExitRemoteWithDriver helper methods. The Enter take an additional object reference, then drops both the domain object lock and the driver lock. The Exit takes both the driver and domain object lock, then drops the reference. Adding calls to these Enter and Exit helpers around remote calls in the various migration methods seems to fix the problem for me in testing. This should make the situation safe. The additional domain object reference ensures that the domain object won't disappear while this operation is happening. The BeginJob that is called inside of qemudDomainMigratePerform ensures that we can't execute a second migrate (or shutdown, or save, etc) job while the migration is active. Finally, the additional check on the state of the vm after we reacquire the locks ensures that we can't be surprised by an external event (domain crash, etc). Signed-off-by: Chris Lalancette <clalance(a)redhat.com> --- src/qemu/qemu_driver.c | 57 ++++++++++++++++++++++++++++++++++++++++++------ 1 files changed, 50 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 5f2607c..1eff4bc 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -531,6 +531,21 @@ static void qemuDomainObjExitMonitorWithDriver(struct qemud_driver *driver, virD } } +static void qemuDomainObjEnterRemoteWithDriver(struct qemud_driver *driver, + virDomainObjPtr obj) +{ + virDomainObjRef(obj); + virDomainObjUnlock(obj); + qemuDriverUnlock(driver); +} + +static void qemuDomainObjExitRemoteWithDriver(struct qemud_driver *driver, + virDomainObjPtr obj) +{ + qemuDriverLock(driver); + virDomainObjLock(obj); + virDomainObjUnref(obj); +} static int qemuCgroupControllerActive(struct qemud_driver *driver, int controller) @@ -10753,14 +10768,25 @@ static int doTunnelMigrate(virDomainPtr dom, /* virStreamNew only fails on OOM, and it reports the error itself */ goto cleanup; + qemuDomainObjEnterRemoteWithDriver(driver, vm); internalret = dconn->driver->domainMigratePrepareTunnel(dconn, st, flags, dname, resource, dom_xml); + qemuDomainObjExitRemoteWithDriver(driver, vm); if (internalret < 0) /* domainMigratePrepareTunnel sets the error for us */ goto cleanup; + /* the domain may have shutdown or crashed while we had the locks dropped + * in qemuDomainObjEnterRemoteWithDriver, so check again + */ + if (!virDomainObjIsActive(vm)) { + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("guest unexpectedly quit")); + goto cleanup; + } + /* 3. start migration on source */ qemuDomainObjEnterMonitorWithDriver(driver, vm); if (flags & VIR_MIGRATE_NON_SHARED_DISK) @@ -10833,8 +10859,10 @@ cancel: finish: dname = dname ? dname : dom->name; + qemuDomainObjEnterRemoteWithDriver(driver, vm); ddomain = dconn->driver->domainMigrateFinish2 (dconn, dname, NULL, 0, uri, flags, retval); + qemuDomainObjExitRemoteWithDriver(driver, vm); cleanup: if (client_sock != -1) @@ -10873,19 +10901,32 @@ static int doNonTunnelMigrate(virDomainPtr dom, virDomainPtr ddomain = NULL; int retval = -1; char *uri_out = NULL; + int rc; + qemuDomainObjEnterRemoteWithDriver(driver, vm); /* NB we don't pass 'uri' into this, since that's the libvirtd * URI in this context - so we let dest pick it */ - if (dconn->driver->domainMigratePrepare2(dconn, - NULL, /* cookie */ - 0, /* cookielen */ - NULL, /* uri */ - &uri_out, - flags, dname, - resource, dom_xml) < 0) + rc = dconn->driver->domainMigratePrepare2(dconn, + NULL, /* cookie */ + 0, /* cookielen */ + NULL, /* uri */ + &uri_out, + flags, dname, + resource, dom_xml); + qemuDomainObjExitRemoteWithDriver(driver, vm); + if (rc < 0) /* domainMigratePrepare2 sets the error for us */ goto cleanup; + /* the domain may have shutdown or crashed while we had the locks dropped + * in qemuDomainObjEnterRemoteWithDriver, so check again + */ + if (!virDomainObjIsActive(vm)) { + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("guest unexpectedly quit")); + goto cleanup; + } + if (uri_out == NULL) { qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("domainMigratePrepare2 did not set uri")); @@ -10899,8 +10940,10 @@ static int doNonTunnelMigrate(virDomainPtr dom, finish: dname = dname ? dname : dom->name; + qemuDomainObjEnterRemoteWithDriver(driver, vm); ddomain = dconn->driver->domainMigrateFinish2 (dconn, dname, NULL, 0, uri_out, flags, retval); + qemuDomainObjExitRemoteWithDriver(driver, vm); if (ddomain) virUnrefDomain(ddomain); -- 1.7.1.1

2 3

[libvirt] [PATCH] Make virsh setmaxmem balloon only when successful.
by Chris Lalancette 20 Jul '10

20 Jul '10

After playing around with virsh setmaxmem for a bit, I ran into some surprising behavior; if a hypervisor does not support the virDomainSetMaxMemory() API, but the value specified for setmaxmem is less than the current amount of memory in the domain, the domain would be ballooned down *before* an error was reported. To make this more consistent, run virDomainSetMaxMemory() before trying to shrink; that way, if an error is thrown, no changes to the running domain are made. Signed-off-by: Chris Lalancette <clalance(a)redhat.com> --- tools/virsh.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index 0631590..97bfa20 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -2529,19 +2529,19 @@ cmdSetmaxmem(vshControl *ctl, const vshCmd *cmd) return FALSE; } + if (virDomainSetMaxMemory(dom, kilobytes) != 0) { + vshError(ctl, "%s", _("Unable to change MaxMemorySize")); + virDomainFree(dom); + return FALSE; + } + if (kilobytes < info.memory) { if (virDomainSetMemory(dom, kilobytes) != 0) { - virDomainFree(dom); vshError(ctl, "%s", _("Unable to shrink current MemorySize")); - return FALSE; + ret = FALSE; } } - if (virDomainSetMaxMemory(dom, kilobytes) != 0) { - vshError(ctl, "%s", _("Unable to change MaxMemorySize")); - ret = FALSE; - } - virDomainFree(dom); return ret; } -- 1.6.6.1

2 3

[libvirt] [PATCH] Use unsigned long in cmdSetmem.
by Chris Lalancette 20 Jul '10

20 Jul '10

The virsh command "setmem" takes as input a number that should represent an unsigned long number of kilobytes. Fix cmdSetmem to properly parse this as an unsigned long instead of an int. Signed-off-by: Chris Lalancette <clalance(a)redhat.com> --- tools/virsh.c | 30 ++++++++++++++++++++++++++---- 1 files changed, 26 insertions(+), 4 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index 551e97b..63816dc 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -223,6 +223,8 @@ static int vshCmddefHelp(vshControl *ctl, const char *name); static vshCmdOpt *vshCommandOpt(const vshCmd *cmd, const char *name); static int vshCommandOptInt(const vshCmd *cmd, const char *name, int *found); +static unsigned long vshCommandOptUL(const vshCmd *cmd, const char *name, + int *found); static char *vshCommandOptString(const vshCmd *cmd, const char *name, int *found); static long long vshCommandOptLongLong(const vshCmd *cmd, const char *name, @@ -2534,7 +2536,7 @@ cmdSetmem(vshControl *ctl, const vshCmd *cmd) { virDomainPtr dom; virDomainInfo info; - int kilobytes; + unsigned long kilobytes; int ret = TRUE; if (!vshConnectionUsability(ctl, ctl->conn)) @@ -2543,10 +2545,10 @@ cmdSetmem(vshControl *ctl, const vshCmd *cmd) if (!(dom = vshCommandOptDomain(ctl, cmd, NULL))) return FALSE; - kilobytes = vshCommandOptInt(cmd, "kilobytes", &kilobytes); + kilobytes = vshCommandOptUL(cmd, "kilobytes", NULL); if (kilobytes <= 0) { virDomainFree(dom); - vshError(ctl, _("Invalid value of %d for memory size"), kilobytes); + vshError(ctl, _("Invalid value of %lu for memory size"), kilobytes); return FALSE; } @@ -2558,7 +2560,7 @@ cmdSetmem(vshControl *ctl, const vshCmd *cmd) if (kilobytes > info.maxMem) { virDomainFree(dom); - vshError(ctl, _("Requested memory size %d kb is larger than maximum of %lu kb"), + vshError(ctl, _("Requested memory size %lu kb is larger than maximum of %lu kb"), kilobytes, info.maxMem); return FALSE; } @@ -9628,6 +9630,26 @@ vshCommandOptInt(const vshCmd *cmd, const char *name, int *found) return res; } +static unsigned long +vshCommandOptUL(const vshCmd *cmd, const char *name, int *found) +{ + vshCmdOpt *arg = vshCommandOpt(cmd, name); + unsigned long res = 0; + int num_found = FALSE; + char *end_p = NULL; + + if ((arg != NULL) && (arg->data != NULL)) { + res = strtoul(arg->data, &end_p, 10); + if ((arg->data == end_p) || (*end_p!= 0)) + num_found = FALSE; + else + num_found = TRUE; + } + if (found) + *found = num_found; + return res; +} + /* * Returns option as STRING */ -- 1.7.1.1

2 3

[libvirt] Libvirt segmentation fault on non root user
by Vasco Silva 20 Jul '10

20 Jul '10

Dear all, Im trying to connet to libvirtd on my local machine, but i only can contact as root user. When i run virsh command as root user, all works as expected: [root@localhost libvirt]# virsh list Id Name State ---------------------------------- When i try to run virsh as user, i get the following errors: [user@localhost ~]$ virsh list error: unable to connect to '@/home/user/.libvirt/libvirt-sock', libvirtd may need to be started: Connection refused error: failed to connect to the hypervisor on /var/log/messages, i found a segmentation fault: Jul 20 02:46:00 localhost kernel: libvirtd[22177]: segfault at 28 ip 0000000000496ca7 sp 00007f72a328bdf8 error 4 in libvirtd[400000+cc000] on my /etc/libvirt/libvirtd.conf, i have uncommented these 3 entries: listen_tls = 0 listen_tcp = 1 auth_tcp = "none" my system: Linux localhost 2.6.33.5-desktop-2xcm #1 SMP Tue Jun 22 15:53:23 WEST 2010 x86_64 x86_64 x86_64 GNU/Linux - Mandriva Free 2010 libvirt-utils-0.8.0-2mdv2010.1 I don't know how to resolve this segmentation fault, and what is the cause. Any help will be appreciated. Thanks, Vasco Silva

2 2

[libvirt] A problem about live migration of kvm
by 姚远 20 Jul '10

20 Jul '10

>From qemu-kvm-0.12.1, kvm has the function about live migration with non-shared storage. But I don't know how to use it. In the qemu monitor, "migrate -d tcp:10.1.10.42:444" which is based on shared storage is going well. I don't know how to use the command of "-b or -i" or maybe I don't know the correct format of uri. the source and destination system is Fedora-13, and the version of kvm is qemu-kvm-0.12.3. When I use the "migrate -d -b tcp:10.1.10.42:4444", the qemu monitor don't show nothing. When I use "info migrate",there shows "migrate status: failed". I don't know why? I hope someone who used this command successfully would help me, thank you.

2 1

[libvirt] ChangeLog-old file: do we need it?
by Justin Clift 20 Jul '10

20 Jul '10

Hi us, We have an old ChangeLog file in the base directory that seems to just be hanging around and not really serving a useful purpose. And takes up space. Can we remove it? Regards and best wishes, Justin Clift

2 1