[libvirt] Save & Restore Synchronization
by Erkan Unal
Hi,
I am using libvirt for qemu/kvm. I have following questions in terms of
save and restore (Version 0.6.2):
1) As I checked the libvirt code, restore command is asynchronous. There
is a macro called VIR_EXEC_NONBLOCK but there is no macro called
VIR_EXEC_BLOCK. Is it possible to execute the restore in blocking mode
so that I can measure the whole restore time?
2) I tried to measure the time spent to save the VM. I am executing save
command and getting a timing. However when I execute the following
operations in order I got an error right after script issues the
restore operation (No delay between them):
"save->restore->save"
... the error is:
20:19:02.478: error : internal error Unable to open monitor path /dev/pts/3
libvir: QEMU error : internal error Unable to open monitor path /dev/pts/3
20:19:02.478: error : internal error unable to start guest: char device
redirected to /dev/pts/3
inet_listen: bind(ipv4,127.0.0.1,5912): Address already in use
inet_listen: FAILED
libvir: QEMU error : internal error unable to start guest: char device
redirected to /dev/pts/3
inet_listen: bind(ipv4,127.0.0.1,5912): Address already in use
inet_listen: FAILED
20:19:02.482: error : operation failed: failed to start VM
libvir: QEMU error : operation failed: failed to start VM
error: Failed to restore domain from /path/to/the/save/file
error: operation failed: failed to start VM
(You can find the detailed error report in the attachement when
LIBVIRT_DEBUG flag is 1)
I think that some of the cleanup is non-blocking which are cleanup of
pty device and vncserver. However, I am not sure if destroying the qemu
process is asynchronous??
P.S.: If I put one second delay between first save and restore, there is
no error. Save and restore work fine.
Thanks,
Erkan Unal
20:26:07.506: debug : virInitialize:287 : register drivers
20:26:07.506: debug : virRegisterDriver:660 : registering Test as driver 0
20:26:07.506: debug : virRegisterNetworkDriver:560 : registering Test as network driver 0
20:26:07.506: debug : virRegisterStorageDriver:591 : registering Test as storage driver 0
20:26:07.506: debug : virRegisterDeviceMonitor:622 : registering Test as device driver 0
20:26:07.506: debug : virRegisterDriver:660 : registering Xen as driver 1
20:26:07.506: debug : virRegisterDriver:660 : registering OPENVZ as driver 2
20:26:07.506: debug : virRegisterDriver:660 : registering remote as driver 3
20:26:07.506: debug : virRegisterNetworkDriver:560 : registering remote as network driver 1
20:26:07.506: debug : virRegisterStorageDriver:591 : registering remote as storage driver 1
20:26:07.506: debug : virRegisterDeviceMonitor:622 : registering remote as device driver 1
20:26:07.506: debug : virConnectOpenAuth:1089 : name=qemu:///session, auth=0x7fa21cbae660, flags=0
20:26:07.506: debug : do_open:909 : name "qemu:///session" to URI components:
scheme qemu
opaque (null)
authority (null)
server (null)
user (null)
port 0
path /session
20:26:07.506: debug : do_open:919 : trying driver 0 (Test) ...
20:26:07.506: debug : do_open:925 : driver 0 Test returned DECLINED
20:26:07.506: debug : do_open:919 : trying driver 1 (Xen) ...
20:26:07.506: debug : do_open:925 : driver 1 Xen returned DECLINED
20:26:07.506: debug : do_open:919 : trying driver 2 (OPENVZ) ...
20:26:07.506: debug : do_open:925 : driver 2 OPENVZ returned DECLINED
20:26:07.506: debug : do_open:919 : trying driver 3 (remote) ...
20:26:07.506: debug : remoteOpen:974 : Auto-remote UNIX socket
20:26:07.506: debug : remoteOpen:992 : Auto-spawn user daemon instance
20:26:07.506: debug : doRemoteOpen:511 : proceeding with name = qemu:///session
20:26:07.507: debug : call:6473 : Doing call 66 (nil)
20:26:07.507: debug : call:6543 : We have the buck 66 0x7fa21bdb5010 0x7fa21bdb5010
20:26:07.507: debug : processCallRecvLen:6131 : Got length, now need 36 total (32 more)
20:26:07.507: debug : processCalls:6399 : Giving up the buck 66 0x7fa21bdb5010 (nil)
20:26:07.507: debug : call:6574 : All done with our call 66 (nil) 0x7fa21bdb5010
20:26:07.507: debug : call:6473 : Doing call 1 (nil)
20:26:07.507: debug : call:6543 : We have the buck 1 0xf86d80 0xf86d80
20:26:07.509: debug : processCallRecvLen:6131 : Got length, now need 28 total (24 more)
20:26:07.509: debug : processCalls:6399 : Giving up the buck 1 0xf86d80 (nil)
20:26:07.509: debug : call:6574 : All done with our call 1 (nil) 0xf86d80
20:26:07.509: debug : doRemoteOpen:822 : Adding Handler for remote events
20:26:07.509: debug : doRemoteOpen:829 : virEventAddHandle failed: No addHandleImpl defined. continuing without events.
20:26:07.509: debug : do_open:925 : driver 3 remote returned SUCCESS
20:26:07.509: debug : do_open:945 : network driver 0 Test returned DECLINED
20:26:07.509: debug : do_open:945 : network driver 1 remote returned SUCCESS
20:26:07.509: debug : do_open:967 : storage driver 0 Test returned DECLINED
20:26:07.509: debug : do_open:967 : storage driver 1 remote returned SUCCESS
20:26:07.510: debug : do_open:988 : node driver 0 Test returned DECLINED
20:26:07.510: debug : do_open:988 : node driver 1 remote returned SUCCESS
20:26:07.510: debug : virDomainRestore:2012 : conn=0xf82430, from=/path/to/save/file
20:26:07.510: debug : call:6473 : Doing call 54 (nil)
20:26:07.510: debug : call:6543 : We have the buck 54 0xf86d80 0xf86d80
20:26:07.625: error : internal error Unable to open monitor path /dev/pts/3
libvir: QEMU error : internal error Unable to open monitor path /dev/pts/3
20:26:07.625: error : internal error unable to start guest: char device redirected to /dev/pts/3
inet_listen: bind(ipv4,127.0.0.1,5912): Address already in use
inet_listen: FAILED
libvir: QEMU error : internal error unable to start guest: char device redirected to /dev/pts/3
inet_listen: bind(ipv4,127.0.0.1,5912): Address already in use
inet_listen: FAILED
20:26:07.629: error : operation failed: failed to start VM
libvir: QEMU error : operation failed: failed to start VM
20:26:07.629: debug : processCallRecvLen:6131 : Got length, now need 160 total (156 more)
20:26:07.629: debug : processCalls:6399 : Giving up the buck 54 0xf86d80 (nil)
20:26:07.629: debug : call:6574 : All done with our call 54 (nil) 0xf86d80
error: Failed to restore domain from /path/to/save/file
error: operation failed: failed to start VM
20:26:07.629: debug : virConnectClose:1107 : conn=0xf82430
20:26:07.629: debug : call:6473 : Doing call 2 (nil)
20:26:07.629: debug : call:6543 : We have the buck 2 0xf86d80 0xf86d80
20:26:07.629: debug : processCallRecvLen:6131 : Got length, now need 28 total (24 more)
20:26:07.629: debug : processCalls:6399 : Giving up the buck 2 0xf86d80 (nil)
20:26:07.629: debug : call:6574 : All done with our call 2 (nil) 0xf86d80
20:26:07.629: debug : virUnrefConnect:210 : unref connection 0xf82430 1
20:26:07.629: debug : virReleaseConnect:171 : release connection 0xf82430
14 years, 8 months
[libvirt] libvirt socket closed unexpectedly / libvirt broken pipe
by Dave
Hello,
I'm trying to get eucalyptus v1.5.2 working with debian lenny, the relevant versions of libvirt software installed are from the apt-get repos, which are:
# dpkg -l|grep libvirt
ii libvirt-bin 0.4.6-10 the programs for the libvirt library
ii libvirt0 0.4.6-10 library for interfacing with different virtualization systems
The the conf file looks like so:
# cat libvirtd.conf|grep -v '#'
unix_sock_group = "libvirt"
unix_sock_rw_perms = "0770"
auth_unix_ro = "none"
auth_unix_rw = "none"
-----
my eucalyptus nc.log has the following error, which i believe is the issue, basically any instance i start, terminates about a minute later by itself, any guidance or help is much appreciated
[Sat Aug 15 03:20:41 2009][004602][EUCAERROR ] libvirt: socket closed unexpectedly (code=39)
[Sat Aug 15 03:20:43 2009][004602][EUCAERROR ] libvirt: Broken pipe (code=38)
thoughts? ideas?
14 years, 8 months
[libvirt] [PATCH] Allow libvirtd to RPC to external libvirtd.
by Chris Lalancette
Allow the daemon itself to make RPCs to an external libvirtd, but only if
the URI is fully specified. While this isn't used at the moment, it will
be for the tunnelled migration support in the future.
Signed-off-by: Chris Lalancette <clalance(a)redhat.com>
---
src/remote_internal.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/remote_internal.c b/src/remote_internal.c
index bc69c70..a416cf3 100644
--- a/src/remote_internal.c
+++ b/src/remote_internal.c
@@ -1001,7 +1001,7 @@ remoteOpen (virConnectPtr conn,
int ret, rflags = 0;
const char *autostart = getenv("LIBVIRT_AUTOSTART");
- if (inside_daemon)
+ if (inside_daemon && (!conn->uri || (conn->uri && !conn->uri->server)))
return VIR_DRV_OPEN_DECLINED;
if (!(priv = remoteAllocPrivateData(conn)))
--
1.6.0.6
14 years, 8 months
[libvirt] [PATCH 0/3] QEMU directory/monitor socket fixes/cleanup
by Daniel P. Berrange
This patch series does three things
- Moves QEMU monitor sockets in /var/lib/libvirt/qemu, since this is
created file and thus should be separate from libvirtd created data
to avoid risk from QEMU compromise.
- Sets QEMU directory ownership to match configured qemu user/group
- Fixes a minor memory leak / socket unlink
14 years, 8 months
[libvirt] [PATCH 2/2]: VirtualBox: Updated vboxNetworkUndefine() and vboxNetworkDestroy()
by Pritesh Kothari
Hi All,
I have made some changes to the functions vboxNetworkCreateXML(),
vboxNetworkDefineXML(), vboxNetworkUndefine() and vboxNetworkDestroy() to handle
multiple host only interfaces as multiple host only interfaces are supported
by VirtualBox 3.0 and greater.
The patch's are as below:
PATCH 1/2: Merged vboxNetworkCreateXML() and vboxNetworkDefineXML() and added
code to handle multiple hostonly interfaces.
PATCH 2/2: Merged vboxNetworkUndefine() and vboxNetworkDestroy() and added code
to handle multiple hostonly interfaces.
Regards,
Pritesh
14 years, 8 months
[libvirt] [PATCH 0/1] Support huge pages in guests
by Daniel P. Berrange
This patch is an update of John Cooper's original work from
last month
http://www.redhat.com/archives/libvir-list/2009-July/msg00753.html
Changes since that patch
- We create a directory $MOUNTPOINT/libvirt/qemu inside the hugetlbfs
mount point. This is neccessary because QEMU now runs as 'qemu:qemu'
in Fedora and thus cannot create files in the root. libvirtd will
automatically chown() this subdir to allow QEMU guests access
- Don't automatically probe for hugetlbfs mount if runing as an
unprivileged libvirtd, since user won't have access to the mount
unless administrator has manually created them a subdir.
- Change the XML to look like
<memoryBacking>
<hugepages/>
</memoryBacking>
This is because I fear we may have more config options for memory
backing store in the future, such as whether KVM can use KSM for
sharing on the guest.
- Add a test case for it in the XML -> ARGV convetor
- Document the new XML options
- Add the new XML options to the RNG schema
- Fix setup & auto-detection of hugetlbfs mount if no qemu.conf file
exists at all
- Add config parameter to the augeas schema
- Move the code which finds a mount point into util.c since its not
specific to QEMU
14 years, 8 months
[libvirt] [PATCH] Fix bugs in virDomainMigrate v2 code.
by Chris Lalancette
Paolo Bonzini points out that in my refactoring of the code for
virDomainMigrate(), I added a check for the return value from
virDomainMigratePerform(). The problem is that we don't want to
exit if we fail, we actually want to go on and do
virDomainMigrateFinish2() with a non-0 return code to clean things
up. Remove the check.
While reproducing this issue, I also noticed that we wouldn't
always properly propagate an error message. In particular, I
found that if you blocked off the migration ports (with iptables)
and then tried the migration, it would actually fail but we would
get no failure output from Qemu. Therefore, we would think we
succeeded, and leave a huge mess behind us. Execute the monitor
command "info migrate", and look for a failure string in there
as well.
Signed-off-by: Chris Lalancette <clalance(a)redhat.com>
---
src/libvirt.c | 2 --
src/qemu_driver.c | 15 +++++++++++++++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index ca8e003..5c1efb6 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -2962,8 +2962,6 @@ virDomainMigrateVersion2 (virDomainPtr domain,
*/
ret = domain->conn->driver->domainMigratePerform
(domain, cookie, cookielen, uri, flags, dname, bandwidth);
- if (ret == -1)
- goto done;
/* In version 2 of the migration protocol, we pass the
* status code from the sender to the destination host,
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index eb22940..772f2f9 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -6956,6 +6956,21 @@ qemudDomainMigratePerform (virDomainPtr dom,
goto cleanup;
}
+ /* it is also possible that the migrate didn't fail initially, but
+ * rather failed later on. Check the output of "info migrate"
+ */
+ VIR_FREE(info);
+ if (qemudMonitorCommand(vm, "info migrate", &info) < 0) {
+ qemudReportError (dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ "%s", _("could not get info about migration"));
+ goto cleanup;
+ }
+ if (strstr(info, "fail") != NULL) {
+ qemudReportError (dom->conn, dom, NULL, VIR_ERR_OPERATION_FAILED,
+ _("migrate failed: %s"), info);
+ goto cleanup;
+ }
+
/* Clean up the source domain. */
qemudShutdownVMDaemon (dom->conn, driver, vm);
paused = 0;
--
1.6.0.6
14 years, 8 months
