Re: [libvirt] [PATCH v4 0/8]: Add arbitrary qemu command-line and monitor commands
On 07/07/2010 04:33 PM, Chris Lalancette wrote:
There is one bug left that I have not yet been able to fix. Because of the
complicated way that virsh parses command-line arguments, it is not possible
to pass through spaces and quotes when using the qemu-monitor-command.
Unfortunately, the qemu monitor commands (and in particular when using QMP)
depend heavily on quoting and spacing, so using virsh to send through
command-lines is difficult. I'll have to think about how to better resolve
this issue, but it should not hold up the rest of the series.
Would URI-style quoting (' ' - %20) make sense here?
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v4] dots should be valid characters in interface names
On 05/20/2010 09:12 AM, Chris Lalancette wrote:
On 05/20/2010 01:06 AM, Charles Duffy wrote:
On 05/19/2010 11:54 PM, Charles Duffy wrote:
A revised patch is attached. This lifts its logic from its kernel
counterpart, and is updated only to permit forward slashes (which, while
disallowed for interface names with the kernel, are required for
*device* names -- for which the ESX driver happens to overload this
field. Ugh).
Hm. You know, I'm wondering if we should have isValidIfname at all in
domain_conf.c. The thing is that if you think about different platforms
that this could be running on (Windows, Linux, Solaris, etc), and the
number of different drivers that go through here (Qemu, Xen, ESX, Virtualbox,
Phyp, openvz, ONE, UML), it seems like we have to allow everything to
cover all bases. Indeed, there is very little else in domain_conf.c that
does validity checking, probably for just this reason.
Charles, Laine, what do you think about just removing this check completely?
WORKSFORME as well.
I'm presuming that it's still appropriate to check against an empty
string. Does the attached look right? If so, I'll update the associated
RHEL6 ticket [https://bugzilla.redhat.com/show_bug.cgi?id=593907]
appropriately.
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 20c9c51..d4c2148 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -26,6 +26,7 @@
#include sys/types.h
#include sys/stat.h
#include unistd.h
+#include c-ctype.h
#include fcntl.h
#include dirent.h
#include sys/time.h
@@ -1801,12 +1802,6 @@ cleanup:
}
-static bool
-isValidIfname(const char *ifname) {
-return ifname[strspn(ifname, VALID_IFNAME_CHARS)] == 0;
-}
-
-
/* Parse the XML definition for a network interface
* @param node XML nodeset to parse for net definition
* @return 0 on success, -1 on failure
@@ -1891,7 +1886,7 @@ virDomainNetDefParseXML(virCapsPtr caps,
if ((ifname != NULL)
(((flags VIR_DOMAIN_XML_INACTIVE)
(STRPREFIX((const char*)ifname, vnet))) ||
- (!isValidIfname(ifname {
+ (*ifname == 0))) {
/* An auto-generated target name, blank it out */
/* blank out invalid interface names */
VIR_FREE(ifname);
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index fadc8bd..c3bd4e8 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -298,9 +298,6 @@ struct _virDomainNetDef {
virNWFilterHashTablePtr filterparams;
};
-# define VALID_IFNAME_CHARS \
- abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_/
-
enum virDomainChrTargetType {
VIR_DOMAIN_CHR_TARGET_TYPE_NULL = 0,
VIR_DOMAIN_CHR_TARGET_TYPE_MONITOR,
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v5] dots should be valid characters in interface names
On 05/20/2010 04:45 PM, Eric Blake wrote:
On 05/20/2010 03:06 PM, Charles Duffy wrote:
Charles, Laine, what do you think about just removing this check
completely?
WORKSFORME as well.
I'm presuming that it's still appropriate to check against an empty
string. Does the attached look right? If so, I'll update the associated
RHEL6 ticket [https://bugzilla.redhat.com/show_bug.cgi?id=593907]
appropriately.
Looks like Chris posted a similar patch, but I like yours better. But
why the additional inclusion of c-ctype.h?
Accidental -- updated patch attached -- though I'm perfectly happy with
Chris's version too (though it probably ought to clean up the now-unused
VALID_IFNAME_CHARS).
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 20c9c51..7a2bccc 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -1801,12 +1801,6 @@ cleanup:
}
-static bool
-isValidIfname(const char *ifname) {
-return ifname[strspn(ifname, VALID_IFNAME_CHARS)] == 0;
-}
-
-
/* Parse the XML definition for a network interface
* @param node XML nodeset to parse for net definition
* @return 0 on success, -1 on failure
@@ -1891,7 +1885,7 @@ virDomainNetDefParseXML(virCapsPtr caps,
if ((ifname != NULL)
(((flags VIR_DOMAIN_XML_INACTIVE)
(STRPREFIX((const char*)ifname, vnet))) ||
- (!isValidIfname(ifname {
+ (*ifname == 0))) {
/* An auto-generated target name, blank it out */
/* blank out invalid interface names */
VIR_FREE(ifname);
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index fadc8bd..c3bd4e8 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -298,9 +298,6 @@ struct _virDomainNetDef {
virNWFilterHashTablePtr filterparams;
};
-# define VALID_IFNAME_CHARS \
- abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_/
-
enum virDomainChrTargetType {
VIR_DOMAIN_CHR_TARGET_TYPE_NULL = 0,
VIR_DOMAIN_CHR_TARGET_TYPE_MONITOR,
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] dots should be valid characters in interface names
Howdy!
I spent some time scratching my head this evening, as libvirt was
stripping the target/@dev entry from my interfa...@type='ethernet'].
Turns out that this was caused by the interface name containing a
period, which is rejected by isValidIfname(). As the kernel allows the
creation of such interfaces, it is improper for libvirt to reject them.
The attached one-liner (built against RHEL6b1's libvirt but still
applicable against current master as of 10c681622) fixes this issue.
--- libvirt-0.8.1/src/conf/domain_conf.h.orig 2010-05-19 21:30:45.938288123 -0500
+++ libvirt-0.8.1/src/conf/domain_conf.h 2010-05-19 21:31:54.823074637 -0500
@@ -299,7 +299,7 @@
};
# define VALID_IFNAME_CHARS \
- abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_/
+ abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_/.
enum virDomainChrTargetType {
VIR_DOMAIN_CHR_TARGET_TYPE_NULL = 0,
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2] dots should be valid characters in interface names
On 05/19/2010 10:05 PM, Laine Stump wrote:
On 05/19/2010 10:41 PM, Charles Duffy wrote:
The attached one-liner (built against RHEL6b1's libvirt but still
applicable against current master as of 10c681622) fixes this issue.
I think we need to add : there as well (at least - maybe there are
others), don't we?
In dev_valid_name() in net/core/dev.c, the following restrictions are
enforced as of 2.6.27:
- Empty strings are disallowed
- Length must not meet or exceed 16 (IFNAMSIZ)
- '.' and '..' are each invalid as freestanding names (but accepted as
part of a longer string)
- whitespace and '/' characters are prohibited at any point in the string
...and those are the only limitations in play.
Frankly, I'm a bit surprised colons are allowed -- my intuition was that
they would be permitted only for named IPs rather than devices -- but
such is the logic given here, and a bit of experimentation shows that
the kernel accepts them (though they trigger bugs in iproute2, which
appears in at least one place to make the same assumption I did; fun!)
A revised patch is attached. This lifts its logic from its kernel
counterpart, and is updated only to permit forward slashes (which, while
disallowed for interface names with the kernel, are required for
*device* names -- for which the ESX driver happens to overload this
field. Ugh).
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 20c9c51..142a37b 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -26,6 +26,7 @@
#include sys/types.h
#include sys/stat.h
#include unistd.h
+#include ctype.h
#include fcntl.h
#include dirent.h
#include sys/time.h
@@ -1802,8 +1803,29 @@ cleanup:
static bool
-isValidIfname(const char *ifname) {
-return ifname[strspn(ifname, VALID_IFNAME_CHARS)] == 0;
+isValidIfname(const char *ifname)
+{
+if (*ifname == 0)
+return false;
+if (strlen(ifname) = IFNAME_MAX_LENGTH)
+return false;
+if (!strcmp(ifname, .) || !strcmp(ifname, ..))
+return false;
+while (*ifname) {
+/* in the kernel, forward slashes aren't allowed; however, the vmxnet
+ * driver depends on them, so we're slightly more permissive and
+ * disallow only spaces -- however, this will break for drivers other
+ * than VMware.
+ *
+ * Enforcing IFNAME_MAX_LENGTH is probably not appropriate for VMware
+ * either. Perhaps it should be using a different attribute name?
+ */
+if (isspace(*ifname)) {
+return false;
+}
+ifname++;
+}
+return true;
}
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index fadc8bd..b68818e 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -298,8 +298,8 @@ struct _virDomainNetDef {
virNWFilterHashTablePtr filterparams;
};
-# define VALID_IFNAME_CHARS \
- abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_/
+/* corresponds with kernel constant IFNAMSIZ from linux/if.h */
+# define IFNAME_MAX_LENGTH 16
enum virDomainChrTargetType {
VIR_DOMAIN_CHR_TARGET_TYPE_NULL = 0,
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3] dots should be valid characters in interface names
On 05/19/2010 11:54 PM, Charles Duffy wrote:
A revised patch is attached. This lifts its logic from its kernel
counterpart, and is updated only to permit forward slashes (which, while
disallowed for interface names with the kernel, are required for
*device* names -- for which the ESX driver happens to overload this
field. Ugh).
Failed to run make syntax-check on the last rev. Oops.
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 20c9c51..af9684d 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -26,6 +26,7 @@
#include sys/types.h
#include sys/stat.h
#include unistd.h
+#include c-ctype.h
#include fcntl.h
#include dirent.h
#include sys/time.h
@@ -1802,8 +1803,29 @@ cleanup:
static bool
-isValidIfname(const char *ifname) {
-return ifname[strspn(ifname, VALID_IFNAME_CHARS)] == 0;
+isValidIfname(const char *ifname)
+{
+if (*ifname == 0)
+return false;
+if (strlen(ifname) = IFNAME_MAX_LENGTH)
+return false;
+if (STREQ(ifname, .) || STREQ(ifname, ..))
+return false;
+while (*ifname) {
+/* in the kernel, forward slashes aren't allowed; however, the vmxnet
+ * driver depends on them, so we're slightly more permissive and
+ * disallow only spaces -- however, this will break for drivers other
+ * than VMware.
+ *
+ * Enforcing IFNAME_MAX_LENGTH is probably not appropriate for VMware
+ * either. Perhaps it should be using a different attribute name?
+ */
+if (c_isspace(*ifname)) {
+return false;
+}
+ifname++;
+}
+return true;
}
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index fadc8bd..b68818e 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -298,8 +298,8 @@ struct _virDomainNetDef {
virNWFilterHashTablePtr filterparams;
};
-# define VALID_IFNAME_CHARS \
- abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_/
+/* corresponds with kernel constant IFNAMSIZ from linux/if.h */
+# define IFNAME_MAX_LENGTH 16
enum virDomainChrTargetType {
VIR_DOMAIN_CHR_TARGET_TYPE_NULL = 0,
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] qemu-kvm spending time in do_info_migrate () during virDomainSave(); 50ms polling too fa st?
...or more particularly, in ram_bytes_remaining() called by do_info_migrate(); oddly, this is much more pronounced when running with emulator pointing at a shim prepending -no-kvm-irqchip to the invoked command line. This VM was intended to be paused for the save event (if my software was doing its job correctly), so we shouldn't be spending time running the guest CPU and writing updates for already-once-written blocks. I'm seeing much more CPU time spent inside qemu-kvm than in the exec'd lzop process compressing and writing the data stream; on attaching gdb and taking some stack traces to sample where execution time was spent, it appeared that we were spending our time responding to requests from the monitor. The question then -- is the 50ms poll in qemuDomainWaitForMigrationComplete (called from qemudDomainSave) perhaps too frequent? Thanks! --- Below is an exchange from IRC: nDuff How often should libvirt be calling info migrate during a virDomainSave (of a qemu domain)? * nDuff is seeing his qemu-kvm spending the bulk of its time inside ram_bytes_remaining() under do_info_migrate(). DV nDuff: I doubt libvirt is doing this on his own, something else is asking for the information I would assume nDuff DV, I'm not running virt-manager or such; the only management layer on top is locally developed, and it only has a single thread that's blocked waiting for the dom.save() call [this is using the Python bindings] to complete. DV interesting DV nDuff - send this to the list, someone need to look at it, at least raise the problem, maybe we didn't expected that to be so costly DV nDuff: maybe open a bugzilla nDuff it might be that it's not _usually_ so costly except that I'm hitting a qemu/kvm bug; it only started expressing itself when I added -no-kvm-irqchip to the commandline via a shim DV nDuff: I could see how trying to extract this too often could stall the migration process nDuff ...but yes, I'll post to the list. DV nDuff: maybe it's related to the capability to force migration end when the full flush will be shorter than a user defined limit -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] qemu-kvm spending time in do_info_migrate() during virDomainSave(); 50ms polling too fast?
On Mon, May 3, 2010 at 1:48 PM, Matthias Bolte matthias.bo...@googlemail.com wrote: 2010/5/3 Charles Duffy char...@dyfis.net: The question then -- is the 50ms poll in qemuDomainWaitForMigrationComplete (called from qemudDomainSave) perhaps too frequent? What's the libvirt version? Maybe the Poll for migration end every 50ms instead of 50us [1] commit (part of 0.8.1) fixes your problem, if you're currently using libvirt 0.8.1. Ahh; this predates 0.8, so that sounds to be precisely on-point. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] define tap-only networking
richard lucassen wrote: Hello list, I'm pretty new to libvirt and I'd like to try to set up simple networking as described here: http://www.xaq.nl/kvm-tap-howto.txt Is it possible to set up networking through simple tap devices using the xml format? And if yes, can someone give me a hint how to set this up? I'd argue that that's considerably less simple than letting libvirt do the work for you -- but see http://libvirt.org/formatdomain.html#elementsNICSEthernet to have libvirt avoid doing anything more complex than setting up a tap device and then running a script of your choosing to do the remaining work. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[RFC] [PATCH] Re: [libvirt] race between qemu monitor startup and blocking migrate -incoming
[ This is also filed in Red Hat's bugzilla at
https://bugzilla.redhat.com/show_bug.cgi?id=537938 ]
In cases where compression is in use, putting the waitpid() for the
decompression tool before the qemudWaitForMonitor() call appears to
eliminate the race in question.
As much of a cheap hack as it is, it seems like it would resolve the
race condition in question to always spawn and block on an intermediate
process, even if this means having *two* cat processes between
libvirtd and the qemu or kvm it is starting.
Comments?
--- libvirt-0.7.2/src/qemu/qemu_driver.c.orig 2009-11-18 17:30:52.502986557 -0600
+++ libvirt-0.7.2/src/qemu/qemu_driver.c 2009-11-18 17:37:30.414042960 -0600
@@ -100,7 +100,9 @@
struct qemud_driver *driver,
virDomainObjPtr vm,
const char *migrateFrom,
- int stdin_fd);
+ int stdin_fd,
+ int intermediate_pid,
+ int intermediate_fd);
static void qemudShutdownVMDaemon(virConnectPtr conn,
struct qemud_driver *driver,
@@ -223,7 +225,7 @@
int ret;
virResetLastError();
-ret = qemudStartVMDaemon(conn, driver, vm, NULL, -1);
+ret = qemudStartVMDaemon(conn, driver, vm, NULL, -1, -1, -1);
if (ret 0) {
virErrorPtr err = virGetLastError();
VIR_ERROR(_(Failed to autostart VM '%s': %s\n),
@@ -1941,7 +1943,9 @@
struct qemud_driver *driver,
virDomainObjPtr vm,
const char *migrateFrom,
- int stdin_fd) {
+ int stdin_fd,
+ int intermediate_pid,
+ int intermediate_fd) {
const char **argv = NULL, **tmp;
const char **progenv = NULL;
int i, ret;
@@ -1956,6 +1960,7 @@
char ebuf[1024];
char *pidfile = NULL;
int logfile;
+int childstat;
struct qemudHookData hookData;
hookData.conn = conn;
@@ -2131,6 +2136,14 @@
if (ret == -1)
goto cleanup;
+if (intermediate_pid != -1) {
+/* Wait for intermediate process to exit */
+while (waitpid(intermediate_pid, childstat, 0) == -1
+ errno == EINTR);
+}
+if (intermediate_fd != -1)
+close(intermediate_fd);
+
if ((qemudWaitForMonitor(conn, driver, vm, pos) 0) ||
(qemuDetectVcpuPIDs(conn, vm) 0) ||
(qemudInitCpus(conn, vm, migrateFrom) 0) ||
@@ -2723,7 +2736,7 @@
def = NULL;
-if (qemudStartVMDaemon(conn, driver, vm, NULL, -1) 0) {
+if (qemudStartVMDaemon(conn, driver, vm, NULL, -1, -1, -1) 0) {
virDomainRemoveInactive(driver-domains,
vm);
vm = NULL;
@@ -3837,14 +3850,8 @@
}
}
/* Set the migration source and start it up. */
-ret = qemudStartVMDaemon(conn, driver, vm, stdio, fd);
-if (intermediate_pid != -1) {
-/* Wait for intermediate process to exit */
-while (waitpid(intermediate_pid, childstat, 0) == -1
- errno == EINTR);
-}
-if (intermediatefd != -1)
-close(intermediatefd);
+ret = qemudStartVMDaemon(conn, driver, vm, stdio, fd,
+intermediate_pid, intermediatefd);
close(fd);
fd = -1;
if (ret 0) {
@@ -4144,7 +4151,7 @@
goto cleanup;
}
-ret = qemudStartVMDaemon(dom-conn, driver, vm, NULL, -1);
+ret = qemudStartVMDaemon(dom-conn, driver, vm, NULL, -1, -1, -1);
if (ret != -1)
event = virDomainEventNewFromObj(vm,
VIR_DOMAIN_EVENT_STARTED,
@@ -6209,7 +6216,7 @@
/* Start the QEMU daemon, with the same command-line arguments plus
* -incoming unix:/path/to/file or exec:nc -U /path/to/file
*/
-internalret = qemudStartVMDaemon(dconn, driver, vm, migrateFrom, -1);
+internalret = qemudStartVMDaemon(dconn, driver, vm, migrateFrom, -1, -1, -1);
VIR_FREE(migrateFrom);
if (internalret 0) {
/* Note that we don't set an error here because qemudStartVMDaemon
@@ -6404,7 +6411,7 @@
* -incoming tcp:0.0.0.0:port
*/
snprintf (migrateFrom, sizeof (migrateFrom), tcp:0.0.0.0:%d, this_port);
-if (qemudStartVMDaemon (dconn, driver, vm, migrateFrom, -1) 0) {
+if (qemudStartVMDaemon (dconn, driver, vm, migrateFrom, -1, -1, -1) 0) {
/* Note that we don't set an error here because qemudStartVMDaemon
* should have already done that.
*/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Using libvirt to obtain mac address of virtual domain
Daniel Berteaud wrote: If you need to get the mac address from bash, you can use this: virsh dumpxml myguest | grep 'mac address' | cut -d\' -f2 You'll get one mac address per line (one line per NIC on the guest) An alternate approach which doesn't depend on the specific manner in which the XML is pretty-printed follows: virsh dumpxml myguest \ | xmlstarlet sel -t \ -m /domain/devices/interfa...@type='network']/mac \ -v '@address' \ -n This does add an external dependency (see http://xmlstar.sf.net/), but I find XMLStarlet useful in conjunction with libvirt in other cases -- for instance, for programatically adding or modifying devices within the domain XML. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[PATCH] Re: [libvirt] Silently ignored virDomainRestore failures
Charles Duffy wrote:
For existing QEMU, it might be sufficient to just put an arbitrary
'sleep(5)' before issuing 'cont', which would at least give it a
reasonable chance of avoiding the race condition.
Well -- I wasn't going to submit the patch I'm now using internally
(using and waiting for a sigil on stderr when migrate_url is stdin),
but I suppose that with an else clause doing a sleep it might actually
be the closest available option to a Right Thing for preexisting qemu.
I'll wait to hear back today from the contractors testing with it (they
were hitting this race condition frequently) and post an amended copy
here if it gets their thumbs-up.
Attached is what I'm presently using as a workaround until I have a
proper (info incoming) approach implemented. It is perhaps excessively
paranoid (the extra .5sec of delay on the stdin case may not be needed),
but we haven't been able to reproduce the issue with it applied.
From ba5a3722fe699b7c4cf56b04dc90679089cd26a6 Mon Sep 17 00:00:00 2001
From: Charles Duffy charles_du...@dell.com
Date: Wed, 30 Sep 2009 23:23:42 -0500
Subject: [PATCH] Wait for a sigil before considering a migration from stdin complete
---
src/qemu_conf.c |2 +-
src/qemu_driver.c | 68 +++-
2 files changed, 62 insertions(+), 8 deletions(-)
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index 6b0b404..5a31c07 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -1401,7 +1401,7 @@ int qemudBuildCommandLine(virConnectPtr conn,
}
} else if (STREQ(migrateFrom, stdio)) {
if (qemuCmdFlags QEMUD_CMD_FLAG_MIGRATE_QEMU_EXEC) {
-migrateFrom = exec:cat;
+migrateFrom = exec:cat { echo 'MIGRATION' 'DONE'; } 2;
} else if (!(qemuCmdFlags QEMUD_CMD_FLAG_MIGRATE_KVM_STDIO)) {
qemudReportError(conn, NULL, NULL, VIR_ERR_NO_SUPPORT,
%s, _(STDIO migration is not supported with this QEMU binary));
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 412b68d..67b959f 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -101,7 +101,8 @@ static int qemudStartVMDaemon(virConnectPtr conn,
struct qemud_driver *driver,
virDomainObjPtr vm,
const char *migrateFrom,
- int stdin_fd);
+ int stdin_fd,
+ int *pos_p);
static void qemudShutdownVMDaemon(virConnectPtr conn,
struct qemud_driver *driver,
@@ -128,6 +129,11 @@ static int qemudDomainSetMemoryBalloon(virConnectPtr conn,
static int qemudDetectVcpuPIDs(virConnectPtr conn,
virDomainObjPtr vm);
+static int qemudWaitForMigrateDone(virConnectPtr conn,
+ struct qemud_driver* driver,
+ virDomainObjPtr vm,
+ off_t pos);
+
static struct qemud_driver *qemu_driver = NULL;
static int qemuCgroupControllerActive(struct qemud_driver *driver,
@@ -234,7 +240,7 @@ qemudAutostartConfigs(struct qemud_driver *driver) {
virDomainObjLock(vm);
if (vm-autostart
!virDomainIsActive(vm)) {
-int ret = qemudStartVMDaemon(conn, driver, vm, NULL, -1);
+int ret = qemudStartVMDaemon(conn, driver, vm, NULL, -1, NULL);
if (ret 0) {
virErrorPtr err = virGetLastError();
VIR_ERROR(_(Failed to autostart VM '%s': %s\n),
@@ -1840,7 +1846,8 @@ static int qemudStartVMDaemon(virConnectPtr conn,
struct qemud_driver *driver,
virDomainObjPtr vm,
const char *migrateFrom,
- int stdin_fd) {
+ int stdin_fd,
+ int *pos_p) {
const char **argv = NULL, **tmp;
const char **progenv = NULL;
int i, ret;
@@ -1980,6 +1987,8 @@ static int qemudStartVMDaemon(virConnectPtr conn,
if ((pos = lseek(logfile, 0, SEEK_END)) 0)
VIR_WARN(_(Unable to seek to end of logfile: %s\n),
virStrerror(errno, ebuf, sizeof ebuf));
+if (pos_p)
+*pos_p = pos;
for (i = 0 ; i ntapfds ; i++)
FD_SET(tapfds[i], keepfd);
@@ -2803,7 +2812,7 @@ static virDomainPtr qemudDomainCreate(virConnectPtr conn, const char *xml,
def = NULL;
-if (qemudStartVMDaemon(conn, driver, vm, NULL, -1) 0) {
+if (qemudStartVMDaemon(conn, driver, vm, NULL, -1, NULL) 0) {
virDomainRemoveInactive(driver-domains,
vm);
vm = NULL;
@@ -3615,6 +3624,48 @@ cleanup:
return ret;
}
+/* signature matches qemudHandlerMonitorOutput */
+static int
+qemudCheckMigrateOK(virConnectPtr conn
Re: [libvirt] Silently ignored virDomainRestore failures
On Tue, Sep 29, 2009 at 4:16 AM, Daniel P. Berrange berra...@redhat.comwrote: Yeah, I've been thinking much the same this morning. I think we should consider what the optimal setup is for our needs long term and try and do whatever we can for that in QEMU now. I think it'd definitely be worthwhile to have an 'info migrate' impl for incoming migration, and even to make '-incoming' optional, and add a 'migrate-incoming' command to the monitor, which like 'migrate' could be run in either blocking or non-blocking mode. 'migrate-incoming' is heavier surgery than I'm comfortable doing myself, but I'll try my hand at the info command. The only thing that bugs me about this is that if the output is being added to the existing 'info migrate', an explicit negative output (Incoming: none) will be necessary to distinguish from the case where reporting incoming migration is simply unsupported; as such, the current behavior of reporting no output at all if no migration is ongoing would need to change. For existing QEMU, it might be sufficient to just put an arbitrary 'sleep(5)' before issuing 'cont', which would at least give it a reasonable chance of avoiding the race condition. Well -- I wasn't going to submit the patch I'm now using internally (using and waiting for a sigil on stderr when migrate_url is stdin), but I suppose that with an else clause doing a sleep it might actually be the closest available option to a Right Thing for preexisting qemu. I'll wait to hear back today from the contractors testing with it (they were hitting this race condition frequently) and post an amended copy here if it gets their thumbs-up. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Silently ignored virDomainRestore failures
On Mon, Sep 28, 2009 at 6:43 AM, Daniel P. Berrange berra...@redhat.comwrote:
The flaw in QEMU is depressingly obvious
static int stdio_pclose(void *opaque)
{
QEMUFileStdio *s = opaque;
pclose(s-stdio_file);
qemu_free(s);
return 0;
}
Notice how it completely discards the exit status returned by
pclone() and just pretends everything always worked :-(
If this was handling errors correctly, you'd at least see QEMU
exiting rather than hanging around broken.
Ugh, indeed. I'll submit a patch for that later today, if nobody beats me to
it.
Hmm, this does look problematic - we need the monitor to be responsive
in order to do things like CPU pinning. We need the monitor to be
non-responsive to ensure 'cont' doesn't run until migration has finished.
We can't have it both ways, and the former wins since we need that to be
done before ever letting QEMU start allocating guest RAM pages. So relying
on 'cont' to block is not good. Is the 'cont' even neccessary - I remember
seeing somewhere that QEMU unconditionally started its CPUs after an
incoming migraiton finished ?
I've seen patches to change that behavior, so IMHO it's probably not to safe
to depend on it being one way or the other throughout the versions of qemu
libvirt supports.
What I'm tempted to do is add a command which sends a sigil to stderr to the
end of the exec: migration lines specified by libvirt, and wait for either
that sigil or an error to show up in the log for that domain before issuing
the cont; if my memory is at all correct, libvirt should have some helper
functions useful for that purpose already available.
Does this sound like a reasonable approach?
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Silently ignored virDomainRestore failures
Charles Duffy wrote: What I'm tempted to do is add a command which sends a sigil to stderr to the end of the exec: migration lines specified by libvirt, and wait for either that sigil or an error to show up in the log for that domain before issuing the cont; if my memory is at all correct, libvirt should have some helper functions useful for that purpose already available. Ugh, bad idea -- I was thinking only of the migrate-from-file case, and not of migration from any alternate source; any non-exec source doesn't allow for this hack. Anthony suggested dropping -S from the command line on incoming migrations, and using info status to poll for when the guest resumes itself; however, this doesn't work for cases when the VM was saved or migrated in a paused state and the end-user expectation is for it to remain paused. I'm tempted to add additional output to info migrate indicating whether an inbound migration is ongoing; however, this wouldn't help versions of qemu without the patch applied. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Race between monitor startup and incoming migration impacting libvirt
There appears to be a race condition wherein a 'cont' command sent immediately on qemu startup can prevent a inbound migration specified via -incoming from occurring. libvirt's process for starting up qemu domains with an incoming migration includes with a 'cont' command at the end of qemudInitCpus, shortly after a successful connection with the monitor is made. While the libvirt monitor is generally unresponsive while an inbound migration is ongoing, forcing the 'cont' to occur only after the migration has completed, this isn't always true (as will be demonstrated below). I suspect strongly that this is responsible for an occasional failure I'm seeing when loading libvirt domains from file. This is highly reproducible using qemu-kvm-0.11.0-rc2, and straightforward to demonstrate by the following means: [ONE-TIME SETUP] - Build an appropriate ramsave file via migrating a stopped guest to disk. - Mark any backing store used by this guest read-only. [COMMON STEPS] - Create an empty qcow2 file backed by the read-only store, if your guest has any disks. - Invoke qemu with arguments appropriate to the VM being resumed, and also the following: -S -monitor stdio -incoming 'exec:echo START_DELAY 2 sleep 5 echo END_DELAY 2 cat ramsave.raw echo LOAD_DONE 2'. [VALIDATING CORRECT OPERATION] - Wait until 'LOAD_DONE' is displayed, and run 'cont' - The VM will correctly resume. [REPRODUCING THE BUG] - Run 'cont' after START_DELAY is displayed, but before END_DELAY. - 'cat: write error: Broken pipe' will be displayed. - The guest VM will reboot, enter a catatonic state, or otherwise fail to load correctly. [REPRODUCING WITHOUT ARTIFICIAL DELAY] As the 'sleep 5' used in the above may be considered cheating, this issue may also be reproduced without any delay by removing the 'sleep', and terminating the shell command used to invoke qemu with $'cont\n' [REPRODUCING OVER A UNIX SOCKET] Included for completeness, as libvirt 0.7.x uses UNIX sockets here. Use -monitor unix:tmp/test.monitor during qemu invocation, and - Invoke the following in a separate window: socat - UNIX-LISTEN:/tmp/test.monitor $'cont\n' - Invoke qemu as above, but with -monitor unix:/tmp/test.monitor I have a work-in-progress patch which modifies libvirt to use -daemonize for startup; waiting for the guest to detach before attempting to interact with the monitor may avoid this issue. However, as this patch is against libvirt master, and the master branch has other issues which expose themselves on virDomainRestore, I am unable to test it here. Thoughts (and workarounds) welcome. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Miscellaneous fixes to build with -Werror
HACKING suggests compiling with --enable-compile-warnings=error before
submitting any patches; however, current master fails for me on this
account (CentOS 5.3; gcc 4.1.2).
Please see attached. I suspect most of these should be uncontroversial
-- but wonder if perhaps virStrcpy uses would be better converted to
virStrcpyStatic rather than adding virStrcpy to the symbol list as done
here, and am curious about whether the need for explicit initialization
to silence a warning regarding qemudSetLogging's log_level indicates a
bug in the macro later used to assign that value.
diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index 2bae782..ec2eab1 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -2492,7 +2492,7 @@ remoteReadSaslAllowedUsernameList (virConfPtr conf ATTRIBUTE_UNUSED,
*/
static int
qemudSetLogging(virConfPtr conf, const char *filename) {
-int log_level;
+int log_level = 0;
char *log_filters = NULL;
char *log_outputs = NULL;
int ret = -1;
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index a6668f3..c6a9df3 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -413,6 +413,7 @@ virStrToLong_ll;
virStrToLong_ull;
virStrToLong_ui;
virStrToDouble;
+virStrcpy;
virFileLinkPointsTo;
virFileResolveLink;
saferead;
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index af215ca..25d983e 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -6132,7 +6132,7 @@ static int qemudDomainDetachHostPciDevice(virConnectPtr conn,
virDomainObjPtr vm,
virDomainDeviceDefPtr dev)
{
-virDomainHostdevDefPtr detach;
+virDomainHostdevDefPtr detach = NULL;
char *cmd, *reply;
int i, ret;
pciDevice *pci;
diff --git a/src/secret/secret_driver.c b/src/secret/secret_driver.c
index 20a3fa8..9c4102e 100644
--- a/src/secret/secret_driver.c
+++ b/src/secret/secret_driver.c
@@ -432,7 +432,7 @@ static virSecretEntryPtr
secretLoad(virConnectPtr conn, virSecretDriverStatePtr driver,
const char *xml_basename)
{
-virSecretDefPtr def;
+virSecretDefPtr def = NULL;
virSecretEntryPtr secret = NULL, ret = NULL;
char *xml_filename;
diff --git a/src/storage/parthelper.c b/src/storage/parthelper.c
index 5df46e8..ab04842 100644
--- a/src/storage/parthelper.c
+++ b/src/storage/parthelper.c
@@ -34,6 +34,7 @@
#include parted/parted.h
#include stdio.h
+#include string.h
/* we don't need to include the full internal.h just for this */
#define STREQ(a,b) (strcmp((a),(b)) == 0)
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Unable to read QEMU help output: Interrupted system call doing virDomainRestore() on current master
Howdy. I've had this issue since yesterday, but avoided reporting it until determining today that it occurs on an unmodified upstream tree as well as my own local branch: $ virsh restore ramsave error: Failed to restore domain from ramsave error: Unable to read QEMU help output: Interrupted system call This happens immediately (no delay) and only on restore; virsh start behaves as usual. When running libvirtd under gdb, the failure mode is different: $ virsh restore ramsave error: Failed to restore domain from ramsave error: internal error Timed out while reading monitor startup output When running libvirtd under strace, this shows the binary being run ([/usr/bin/qemu-kvm, -help]) failing with a SIGPIPE while attempting to write to stdout. strace also shows a SIGSEGV being delivered to a libvirtd thread (a few clone()s removed from the parent) after that thread attempts to close all its open file descriptors above 0-2, but without being able to run gdb I'm at a bit of a loss as to what that thread is doing. Any suggestions? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Unable to read QEMU help output: Interrupted system call doing virDomainRestore() on current master
Charles Duffy wrote: $ virsh restore ramsave error: Failed to restore domain from ramsave error: Unable to read QEMU help output: Interrupted system call This happens immediately (no delay) and only on restore; virsh start behaves as usual. To be explicit (as I wasn't earlier) -- this is b167672c748bd7d16cd5f450096232266583b851 built on RHEL5 with a great many things disabled: $ ./configure \ --host=x86_64-redhat-linux-gnu \ --build=x86_64-redhat-linux-gnu \ --target=x86_64-redhat-linux \ --program-prefix= \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --datadir=/usr/share \ --includedir=/usr/include \ --libdir=/usr/lib64 \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --sharedstatedir=/usr/com \ --mandir=/usr/share/man \ --infodir=/usr/share/info \ --without-xen \ --without-openvz \ --without-lxc \ --without-vbox \ --without-polkit \ --without-uml \ --without-one \ --without-phyp \ --without-esx \ --with-rhel5-api \ --without-storage-fs \ --without-storage-lvm \ --without-storage-iscsi \ --without-storage-disk \ --without-capng \ --without-netcf \ --with-qemu-user=root \ --with-qemu-group=root \ --with-init-script=redhat \ --with-remote-pid-file=/var/run/libvirtd.pid -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Some problem with the save function
On Fri, Sep 18, 2009 at 1:53 AM, Chris Lalancette clala...@redhat.comwrote: diff --git a/src/qemu_driver.c b/src/qemu_driver.c index a65334f..ff30421 100644 --- a/src/qemu_driver.c +++ b/src/qemu_driver.c @@ -3912,10 +3912,15 @@ static int qemudDomainSave(virDomainPtr dom, goto cleanup; } -if (STREQ (prog, raw)) +const char *args; I think you'll get a warning about mixing code and data here. At least, it's not at the top of a block, so we should move it to the top of a block. I would have done that, but as I recall we're already declaring const char *prog immediately before its first use rather than at the top of a block, so I presumed we're using compile-time options which suppress that warning already. I'll double-check what's going on when I get back to the office. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Some problem with the save function
Chris Lalancette wrote:
No, you are right. This was part of the refactoring, and I just didn't re-read
the code. I would prefer to move prog to the top of the block myself, and add
args there; it just seems tidier.
I agree that it's tidier -- but looking at things in context, I'm not
very comfortable putting the declarations at the very top of the
function. Part of the reason is that everything else there is
initialized, even if only to NULL; I hate to break such a convention,
but at the same time, I find it dangerous to suppress any warnings the
compiler might otherwise be able to generate should a codepath allow a
variable be used uninitialized.
Does the below (creating a new code block and declaring both variables
there) work for everyone?
From c106334d8b41926ce5b6ef0917277091f3e1378e Mon Sep 17 00:00:00 2001
From: Charles Duffy charles_du...@dell.com
Date: Thu, 17 Sep 2009 18:24:15 -0500
Subject: [PATCH] prevent attempt to call cat -c during virDomainSave to raw
---
src/qemu_driver.c | 28 ++--
1 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index a65334f..0f98a6c 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -3905,17 +3905,25 @@ static int qemudDomainSave(virDomainPtr dom,
goto cleanup;
}
-const char *prog = qemudSaveCompressionTypeToString(header.compressed);
-if (prog == NULL) {
-qemudReportError(dom-conn, dom, NULL, VIR_ERR_INTERNAL_ERROR,
- _(Invalid compress format %d), header.compressed);
-goto cleanup;
-}
+{
+const char *prog = qemudSaveCompressionTypeToString(header.compressed);
+const char *args;
-if (STREQ (prog, raw))
-prog = cat;
-internalret = virAsprintf(command, migrate \exec:
- %s -c '%s' 2/dev/null\, prog, safe_path);
+if (prog == NULL) {
+qemudReportError(dom-conn, dom, NULL, VIR_ERR_INTERNAL_ERROR,
+ _(Invalid compress format %d), header.compressed);
+goto cleanup;
+}
+
+if (STREQ (prog, raw)) {
+prog = cat;
+args = ;
+} else {
+args = -c;
+}
+internalret = virAsprintf(command, migrate \exec:
+ %s %s '%s' 2/dev/null\, prog, args, safe_path);
+}
if (internalret 0) {
virReportOOMError(dom-conn);
--
1.6.4
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Some problem with the save function
Daniel Berteaud wrote:
- the second problem is present since libvirt 0.7.1. Now that the saved
file can be compressed, it seems we cannot save in a raw format any
more.
Yeeowch.
How's this for a fix?
From b0673955435ca0c441a536b05216497f68f41be0 Mon Sep 17 00:00:00 2001
From: Charles Duffy charles_du...@dell.com
Date: Thu, 17 Sep 2009 18:24:15 -0500
Subject: [PATCH] prevent attempt to call cat -c during virDomainSave to raw
---
src/qemu_driver.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index a65334f..ff30421 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -3912,10 +3912,15 @@ static int qemudDomainSave(virDomainPtr dom,
goto cleanup;
}
-if (STREQ (prog, raw))
+const char *args;
+if (STREQ (prog, raw)) {
prog = cat;
+args = ;
+} else {
+args = -c;
+}
internalret = virAsprintf(command, migrate \exec:
- %s -c '%s' 2/dev/null\, prog, safe_path);
+ %s %s '%s' 2/dev/null\, prog, args, safe_path);
if (internalret 0) {
virReportOOMError(dom-conn);
--
1.6.4
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Some problem with the save function
Daniel P. Berrange wrote: Hmm, bad error message :-( We might also need todo a chown() in the restore path to allow QEMU to read it. NB there is no compatability between QEMU version, so if you have upgraded your install of QEMU between the time you saved restored it is very likely to crash burn. How difficult would it be to set up named pipes for save and restore operations, and splice from those pipes to the actual files on the libvirtd side? Seems much preferable from a security perspective to chown'ing things around, and (unlike pipes set up ahead of time with pipe() and friends) shouldn't be disrupted by a libvirtd restart. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH] also allow use of XZ for Qemu image compression
Jim Meyering wrote: Daniel Veillard wrote: Hum, I realize that support of LZOP was added after 0.7.0, so we never made a release with it (well except for git snapshot which may have been pushed). I wonder if the best is not to just drop the lzop option altogether and stick xz as a package dependancy until we have found a way to provide at the API level which compression options are actually available. Opinions ? Dropping lzop sounds good. It seems lzop is not very popular. We don't need that many choices. lzop may not be popular, but it is distinct -- a minimum of 3x faster than every other compressor offered as an option. As the decision to use compression at all is offered as a disk space vs performance tradeoff, having an option with minimal performance impact is crucial inasmuch as it makes compression valuable to users for whom the tradeoff otherwise might not have made sense at all. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH] also allow use of XZ for Qemu image compression
Jim Meyering wrote: Good point about it being one of the fastest. I shouldn't have mentioned the subjective popular. Usefulness trumps that. I suppose Daniel, Cc'd, will decide. Per off-list discussion with DV, I'm providing some numbers. Sort order is space used on disk, lowest to highest, with a 251MB file created by virDomainSave. comptime[*] decomptime[*] space xz[default] 3m45.890s 4.960s 42MB xz[0] 0m17.450s 6.080s 54MB bzip2 0m56.290s 11.080s 58MB gzip0m13.790s 2.260s 64MB lzop0m1.970s0.800s 87MB I believe this makes the distinct niche of each of the compressors clear, with the exclusion of bzip2 (which is both slower and produces larger output compared to xz -0). [*] time is user-mode CPU time, as reported by the bash time builtin on an Intel Xeon E7330 @ 2.40GHz. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [PATCH] also allow use of XZ for Qemu image compression
[Pardon the repost -- fixed the table formatting in this version] Jim Meyering wrote: Good point about it being one of the fastest. I shouldn't have mentioned the subjective popular. Usefulness trumps that. I suppose Daniel, Cc'd, will decide. Per off-list discussion with DV, I'm providing some numbers. Sort order is space used on disk, lowest to highest, with a 251MB file created by virDomainSave. comptime[*] decomptime[*] space xz[default] 3m45.890s 4.960s 42MB xz[0] 0m17.450s 6.080s 54MB bzip2 0m56.290s 11.080s 58MB gzip0m13.790s 2.260s 64MB lzop0m1.970s0.800s 87MB I believe this makes the distinct niche of each of the compressors clear, with the exclusion of bzip2 (which is both slower and produces larger output compared to xz -0). [*] time is user-mode CPU time, as reported by the bash time builtin on an Intel Xeon E7330 @ 2.40GHz. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Reintroduce lzop compression
From 3c4f6568623ed420a9e71da33b9ce74abda289a8 Mon Sep 17 00:00:00 2001
From: Charles Duffy charles_du...@dell.com
Date: Wed, 9 Sep 2009 15:53:25 -0500
Subject: [PATCH] Reintroduce support for lzop compression
lzop was removed due to some confusion over whether it provided functional
advantages distinct from xz. This has been addressed in the mailing list post
archived at http://permalink.gmane.org/gmane.comp.emulators.libvirt/16487, and
support for lzop is re-added here.
lzop is added to the enum after xz, leaving xz at the position lzma was
originally in (which is appropriate, as it should handle decompression of
lzma-format files) and giving lzop back its prior position.
Documentation in qemu.conf is amended to remove references to lzma and add
suggestions regarding the tradeoffs made by various compressors.
Signed-off-by: Charles Duffy char...@dyfis.net
---
libvirt.spec.in |1 +
src/qemu.conf |7 ---
src/qemu_driver.c |9 ++---
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index b01f9c2..0157eee 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -117,6 +117,7 @@ Requires: /usr/bin/qemu-img
# For image compression
Requires: gzip
Requires: bzip2
+Requires: lzop
Requires: xz
%else
%if %{with_xen}
diff --git a/src/qemu.conf b/src/qemu.conf
index 342bb8a..6d6b86a 100644
--- a/src/qemu.conf
+++ b/src/qemu.conf
@@ -134,9 +134,10 @@
# memory from the domain is dumped out directly to a file. If you have
# guests with a large amount of memory, however, this can take up quite
# a bit of space. If you would like to compress the images while they
-# are being saved to disk, you can also set gzip, bzip2, lzma, xz,
-# or lzop for save_image_format. Note that this means you slow down
-# the process of saving a domain in order to save disk space.
+# are being saved to disk, you can also set lzop, gzip, bzip2, or xz
+# for save_image_format. Note that this means you slow down the process of
+# saving a domain in order to save disk space; the list above is in descending
+# order by performance and ascending order by compression ratio.
#
# save_image_format = raw
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 8f16e72..5c2a8ec 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -3624,10 +3624,10 @@ enum qemud_save_formats {
QEMUD_SAVE_FORMAT_BZIP2 = 2,
/*
* Deprecated by xz and never used as part of a release
- * QEMUD_SAVE_FORMAT_LZMA,
- * QEMUD_SAVE_FORMAT_LZOP,
+ * QEMUD_SAVE_FORMAT_LZMA
*/
QEMUD_SAVE_FORMAT_XZ = 3,
+QEMUD_SAVE_FORMAT_LZOP = 4,
/* Note: add new members only at the end.
These values are used in the on-disk format.
Do not change or re-use numbers. */
@@ -3640,7 +3640,8 @@ VIR_ENUM_IMPL(qemudSaveCompression, QEMUD_SAVE_FORMAT_LAST,
raw,
gzip,
bzip2,
- xz)
+ xz,
+ lzop)
struct qemud_save_header {
char magic[sizeof(QEMUD_SAVE_MAGIC)-1];
@@ -4384,6 +4385,8 @@ static int qemudDomainRestore(virConnectPtr conn,
intermediate_argv[0] = bzip2;
else if (header.compressed == QEMUD_SAVE_FORMAT_XZ)
intermediate_argv[0] = xz;
+else if (header.compressed == QEMUD_SAVE_FORMAT_LZOP)
+intermediate_argv[0] = lzop;
else if (header.compressed != QEMUD_SAVE_FORMAT_RAW) {
qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
_(Unknown compressed save format %d),
--
1.6.4
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Compressed save image format for Qemu.
If CPU time is one of the major disincentives towards use of compression -- any reason lzop wasn't included? $ time lzop ramsave ramsave.lzo real0m13.515s user0m7.500s sys 0m1.340s $ time gzip -c ramsave ramsave.gz real0m46.327s user0m37.690s sys 0m1.360s $ ls -lh ramsave ramsave.lzo ramsave.gz -rw-rw 1 fvte fvte 707M Aug 26 22:26 ramsave -rw-r--r-- 1 root fvte 282M Aug 27 17:48 ramsave.gz -rw-rw 1 fvte fvte 330M Aug 27 17:47 ramsave.lzo -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] race between qemu monitor startup and blocking migrate -incoming
Howdy, 'yall. I'm having issues with virDomainRestore failing, particularly under load -- even in 0.7.0, when there's no need to parse through qemu's output to find the monitor PTY. Digging through strace output of libvirtd and the qemu processes it spawns, this is happening when qemu blocks on the migrate -incoming and ceases to respond to the monitor socket -- though some versions of qemu can go into this state before the monitor socket is even opened, leading to libvirt timing out either while attempting to open the monitor socket or while trying to read therefrom, and subsequently killing the qemu instance it spawned while that instance is still attempting to migrate in its old saved state. Both of qemu-0.11.0-rc1 and qemu-kvm master have some form of blocking in -incoming exec: which can prevent libvirt from successfully carrying through a resume; I have reproduced the issue (and maintain logs from strace, available on request) irrespective of the state of Chris Lalancette's Fix detached migration with exec and Allow monitor interaction when using migrate -exec patches. The qemu binaries being used _appear_ to correctly allow monitor interaction prior to -incoming exec:... completion when interactively invoked in the trivial case shown below: $ qemu-system-x86_64 \ -monitor stdio \ -nographic \ -serial file:/dev/null \ -incoming 'exec:sleep 5; echo DONE 2; kill $PPID' \ /dev/null QEMU 0.10.91 monitor - type 'help' for more information (qemu) DONE $ ...however, whether these same binaries work as-expected when invoked from libvirt by our automated test system under load is nondeterministic. (I have yet to reproduce the issue in a low-load environment using virsh restore). Is someone else working on this? Is a known-good (or believed-good) libvirt/qemu pair available? What can I do to help in getting this issue resolved? Thanks! --- libvirt-0.7.0 + qemu-kvm-0.11.0-rc1 qemudReadMonitorOutput:728 : internal error Timed out while reading monitor startup output libvirt-0.6.5 + qemu-kvm-0.11.0-rc1 error : qemudReadMonitorOutput:705 : internal error Timed out while reading monitor startup output error : qemudWaitForMonitor:1003 : internal error unable to start guest: char device redirected to /dev/pts/9 libvir: QEMU error : internal error unable to start guest: char device redirected to /dev/pts/9 ^^ particularly interesting, as the above line should have been eaten by qemudExtractMonitorPath rather than emitted as error text --- aliguori -incoming is blocking aliguori you cannot interact with the monitor during -incoming mDuff ...shouldn't we always be opening the monitor before starting the blocking -incoming bits, though? I don't always see that happening (and have an strace handy where it certainly doesn't). aliguori no aliguori well, i think they added some patches for that aliguori but originally, that's not how it worked aliguori and i think it's silly to work that way aliguori -incoming should mean, wait patiently for an incoming migration aliguori there's no point in interfacing with the monitor in the interim mDuff I agree that interacting may not be called for, but at least connect()ing -- if it's a UNIX socket, the other side won't be able to connect at all until qemu goes first... aliguori heh, well aliguori that particular race condition is addressed by -daemonize aliguori because that's generally true aliguori you don't know how long qemu will take to open the monitor aliguori but -daemonize makes gives you notification because it doesn't daemonize the process until you've gotten to the point where all sockets are open aliguori but IIRC, libvirt doesn't use -daemonize -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/8] Various KVM PCI device assignment improvements
Mirko Raasch wrote: How can i use valgrind or some other debugging options with /etc/init.d/libvirt-bin? This won't work for valgrind, but the gdb attach command will let you connect to (and thus get a stack trace from) a running process. If your libvirtd has PID 12054, for instance: $ gdb /usr/sbin/libvirtd (gdb) attach 12054 ...let it attach, and then cause the crash... (gdb) bt ^^ and post the output. The stack trace will be most informative if your build was done with debug symbols enabled and not stripped on installation. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh migrate with libvirt-0.5.1: failed to start listening VM
Scott Baker wrote: You're supposed to have /var/lib/libvirt/images mounted via shared storage (nfs/cifs/etc) on both machines. I've heard of folks having trouble doing live migration over NFS -- something with stronger concurrency guarantees (GFS, a shared iSCSI or FC mount [possibly with cLVM to partition it up], etc) is likely to be a safer bet. (Indeed, looking at the documented preferred environment for VMware's VMotion is probably a good guideline for anything that's going to be trusted with real production usage -- a separate bonded pair of NICs on each host, connected to a dedicated network for communication with the SAN hosting the backing store). -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] turn off dnsmasq
I happen to have an outstanding ticket complaining that leaving out the dhcp/ tag disables dnsmasq _entirely_ (DNS as well as DHCP), rather than merely disabling its DHCP support, and looking at the libvirt source appears to confirm that dnsmasq should not get started if no DHCP ranges are present. The behaviors we're reporting don't appear to be compatible with each other -- does net-dumpxml really show no dhcp/ tag, or perhaps might you have edited the config file directly as opposed to using net-edit/net-define? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Save and restore with KVM!
It would be very helpful if you included your domain description -- not all hardware supported by KVM is save/restore compatible. If you're using SCSI disk drives, for instance, that would explain the breakage; virtio has similar problems for many versions of kvm (not sure about the one you're running). -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt 0.6.4: Confusing error message during virDomainRestore() if network not started
Howdy, 'yall -- I found myself scratching my head for a few minutes
trying to start a VM image via virDomainRestore().
Looking through the header definition in the XML, it read as follows:
interface type=network
mac address=00:15:3d:49:ec:0e/
source network=fvte-MIXED-DEFAULT/
target dev=vnet3/
model type=e1000/
/interface
...and on trying to do a virDomainRestore(), it exited with the following:
Traceback (most recent call last):
File /usr/bin/fvte, line 8, in module
load_entry_point('fvte==1.0', 'console_scripts', 'fvte')()
File /local/home-aux/cduffy/public_git/fvte/src/m1/fvte/cli.py,
line 1838, in main
cli.cmdloop()
File /opt/python25/lib/python2.5/cmd.py, line 142, in cmdloop
stop = self.onecmd(line)
File /local/home-aux/cduffy/public_git/fvte/src/m1/fvte/cli.py,
line 1791, in onecmd
cmd.Cmd.onecmd(self, c)
File /opt/python25/lib/python2.5/cmd.py, line 219, in onecmd
return func(arg)
File /local/home-aux/cduffy/public_git/fvte/src/m1/fvte/cli.py,
line 1538, in do_mode
self._vmm.vh_set_runmode(name, desired)
File /local/home-aux/cduffy/public_git/fvte/src/m1/fvte/vmmanip.py,
line 324, in vh_set_runmode
succp = (0 == virt['connect'].restore(ramfile))
File /opt/python25/lib/python2.5/site-packages/libvirt.py, line
1224, in restore
if ret == -1: raise libvirtError ('virDomainRestore() failed',
conn=self)
libvirt.libvirtError: internal error Failed to add tap interface
'vnet%d' to bridge 'fvtebr0' : No such device
The actual issue was that the fvte-MIXED-DEFAULT network was not
running, and an appropriate virsh net-start allowed the domain to
restore correctly; detecting this condition and providing a clearer
error message would probably be a Good Thing.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virDomainDefineXML forbidden for read only access
Kenneth Nagin wrote: I am running an application that invokes the java method virDomainDefineXML. But virDomainDefineXML is throwing the exception forbidden for read only access. I'm running as root. I can successfully define domain xml and create VMs with virsh. Any suggestion of what I am do wrong? First question -- how are you connecting? The second argument to org.libvirt.Connect.Connect(String, boolean) is the read-only flag; I'm guessing you're passing true? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] attach-disk (cdrom) requirements
Francesco Latino wrote: Is it a requirement to have the guest running to attach a CDROM ? Is there a way to attache a CDROM to a guest powered off with VIRSH If a machine is powered off, you can attach a CD-ROM by redefining the XML. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] qemu-kvm-0.10.5, kvm-kmod-2.6.30, libvirt-0.6.4 - save/restore still unreliable
Nikola Ciprich wrote: I wanted to try it using just kvm, but for some reason, I can't figure the proper way to execute it, is the -incoming exec:cat somewhere properly documented? I tried doing cat .../img.vm | qemu-kvm ... -incoming exec:cat but this doesn't seem to be the proper way. That should work fine. Your ... sets up the drives, memory amount, etc., right? Why do you say it doesn't seem to be the proper way? What fails? BTW, you might also do this: -incoming 'exec:cat .../img.vm', avoiding the need to pipe through stdin. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Avi Kivity wrote: Oh. If the command generates no output (like most), you can't tell when it completes. I suppose we could have qemu print OK after completing a command. FWIW, OpenVPN's monitor interface resolves this by prefixing all notification lines with ''. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] invalid connection pointer in virConnectClose from Python bindings
Howdy. I'm calling libvirt from a program which occasionally has cause to fork() without an immediate exec(). For the sake of simplicity, I presently call close() on all my virConnect objects [which I then delete] before forking and create new ones later. (I'm not forcing an explicit pre-fork garbage collection at present -- hopefully the close() should make one unnecessary). However, libvirt complains (and very occasionally segfaults) as I try to close the connections: libvir: error : invalid connection pointer in virConnectClose libvir: error : invalid connection pointer in virConnectClose Are there any practices I should be following to avoid this? Alternatively, if it is likely to be related to an issue in the Python bindings, is there something I could do to diagnose? Thanks! -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt 0.6.1 not playing well with RHEL5.2 lokkit
Howdy. I'm running RHEL5.2, and libvirt 0.6.1. I don't use the distro-provided firewall (system-config-securitylevel-tui-1.6.29.1-2.1.el5) and have it completely disabled, but libvirt appears to be having some trouble ascertaining as much: libvirtd: 14:05:42.807: warning : Failed to read /etc/sysconfig/system-config-firewall last message repeated 2 times kernel: fvtebr0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature. kernel: fvtebr0: starting userspace STP failed, starting kernel STP libvirtd: 14:06:34.825: error : internal error '/usr/sbin/lokkit --nostart --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/INPUT.chain' exited with non-zero status 1 and signal 0: --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/INPUT.chain: unknown option libvirtd: 14:06:34.825: warning : Failed to run '/usr/sbin/lokkit --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/INPUT.chain': Invalid argument libvirtd: 14:06:34.828: error : internal error '/usr/sbin/lokkit --nostart --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/FORWARD.chain' exited with non-zero status 1 and signal 0: --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/FORWARD.chain: unknown option libvirtd: 14:06:34.828: warning : Failed to run '/usr/sbin/lokkit --custom-rules=ipv4:filter:/var/lib/libvirt/iptables/filter/FORWARD.chain': Invalid argument libvirtd: 14:06:34.831: error : internal error '/usr/sbin/lokkit --nostart --custom-rules=ipv4:nat:/var/lib/libvirt/iptables/nat/POSTROUTING.chain' exited with non-zero status 1 and signal 0: --custom-rules=ipv4:nat:/var/lib/libvirt/iptables/nat/POSTROUTING.chain: unknown option libvirtd: 14:06:34.831: warning : Failed to run '/usr/sbin/lokkit --custom-rules=ipv4:nat:/var/lib/libvirt/iptables/nat/POSTROUTING.chain': Invalid argument -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] document static host IP assignment
Back in August 2008, DV added support for providing static IP/hostname assignments to dnsmasq via host elements in the network definition. Since this functionality isn't covered in the documentation, I wrote up a quick patch, attached. diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index ca37b05..fd68430 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -98,7 +98,9 @@ ... lt;ip address=192.168.122.1 netmask=255.255.255.0gt; lt;dhcpgt; - lt;range start=192.168.122.2 end=192.168.122.254 /gt; + lt;range start=192.168.122.100 end=192.168.122.254 /gt; + lt;host mac=00:16:3e:77:e2:ed name=foo.example.com ip=192.168.122.10 /gt; + lt;host mac=00:16:3e:3e:a9:1a name=bar.example.com ip=192.168.122.11 /gt; lt;/dhcpgt; lt;/ipgt; lt;/networkgt;/pre @@ -126,6 +128,16 @@ must lie within the scope of the network defined on the parent codeip/code element. span class=sinceSince 0.3.0/span /dd + dtcodehost/code/dt + ddWithin the codedhcp/code element there may be zero or more + codehost/code elements; these specify hosts which will be given +names and predefined IP addresses by the built-in DHCP server. Any +such element must specify the MAC address of the host to be assigned + a given name (via the codemac/code attribute), the IP to be +assigned to that host (via the codeip/code attribute), and the + name to be given that host by the DHCP server (via the +codename/code attribute). span class=sinceSince 0.4.5/span + /dd /dl h2a name=examplesExample configuration/a/h2 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] set cache=off on -disk line in qemu driver if shareable/ (but not readonly/) is set.
As cache=off is necessary for clustering filesystems such as GFS (and such is the point of shareable, yes?), I believe this is correct behavior. Comments? diff --git a/src/qemu_conf.c b/src/qemu_conf.c index 03b14f8..47c407a 100644 --- a/src/qemu_conf.c +++ b/src/qemu_conf.c @@ -960,13 +960,15 @@ int qemudBuildCommandLine(virConnectPtr conn, break; } -snprintf(opt, PATH_MAX, file=%s,if=%s,%sindex=%d%s, +snprintf(opt, PATH_MAX, file=%s,if=%s,%sindex=%d%s%s, disk-src ? disk-src : , bus, media ? media : , idx, bootable disk-device == VIR_DOMAIN_DISK_DEVICE_DISK - ? ,boot=on : ); + ? ,boot=on : , + disk-shared ! disk-readonly + ? ,cache=off : ); ADD_ARG_LIT(-drive); ADD_ARG_LIT(opt); -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] networking
James Bardin wrote: I'm not sure where to set this up, but I have a bridged device br0 that I would like to have available in virt-manager/virsh. Right now, I can edit the VM's xml interface element manually to use br0. AFAIK, you're doing the right thing (as long as you're doing a dump-xml to get the XML description out and then a define to put the updated one in; directly modifying /etc/libvirt/qemu/* is bad form). Personally, I use xmlstarlet [from shell scripts] or lxml [from python] to automate tweaking the XML host descriptions, but the details are your own call. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Minor doc tweaks
Per subject; clarifies the distinction between virDomainCreateLinux and virDomainDefineXML+virDomainCreate, and adds documentation for the autoport display attribute. diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 70b9c4a..7177965 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -584,8 +584,10 @@ ddThe codegraphics/code element has a mandatory codetype/code attribute which takes the value sdl or vnc. The former displays a window on the host desktop, while the latter activates a VNC server. - If the latter is used the codeport/code attributes specifies the - TCP port number (with -1 indicating that it should be auto-allocated). + If the latter is used the codeport/code attribute specifies the TCP + port number (with -1 as legacy syntax indicating that it should be + auto-allocated). The codeautoport/code attribute is the new + preferred syntax for indicating autoallocation of the TCP port to use. The codelisten/code attribute is an IP address for the server to listen on. The codepassword/code attribute provides a VNC password in clear text./dd diff --git a/docs/libvirt-api.xml b/docs/libvirt-api.xml index 136ba0d..7b70280 100644 --- a/docs/libvirt-api.xml +++ b/docs/libvirt-api.xml @@ -854,14 +854,14 @@ see note above'/ arg name='domain' type='virDomainPtr' info='pointer to a defined domain'/ /function function name='virDomainCreateLinux' file='libvirt' module='libvirt' - infoLaunch a new Linux guest domain, based on an XML description similar to the one returned by virDomainGetXMLDesc() This function may requires privileged access to the hypervisor./info + infoLaunch a new Linux guest domain, based on an XML description similar to the one returned by virDomainGetXMLDesc(). This function may requires privileged access to the hypervisor. The domain is not persistent, so its definition will disappear when it is destroyed, or if the host is restarted./info return type='virDomainPtr' info='a new domain object or NULL in case of failure'/ arg name='conn' type='virConnectPtr' info='pointer to the hypervisor connection'/ arg name='xmlDesc' type='const char *' info='string containing an XML description of the domain'/ arg name='flags' type='unsigned int' info='an optional set of virDomainFlags'/ /function function name='virDomainDefineXML' file='libvirt' module='libvirt' - infodefine a domain, but does not start it/info + infoDefine a domain, but does not start it. This definition is persistent, until explicitly undefined./info return type='virDomainPtr' info='NULL in case of error, a pointer to the domain otherwise'/ arg name='conn' type='virConnectPtr' info='pointer to the hypervisor connection'/ arg name='xml' type='const char *' info='the XML description for the domain, preferably in UTF-8'/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemudDomainCreate: also check uuid
Daniel Veillard wrote:
Are you disagreeing with the message (which your patch doesn't fix)
or with the semantic of the check (and then why allow to create a domain
reusing the UUID of another defined but not running domain, I can only
see confusion or security problems in doing so)
The act of creating a domain reusing the UUID of another defined but not
running domain is presumably an action taken with intent to rename that
other domain (and thus should undefine the prior domain holding that
UUID in the process... which, admittedly, the given patch didn't
explicitly do).
Anyhow, two patches attached; one revises the error messages, while the
other improves behavior with the semantics I assumed, to explicitly
undefine any duplicates found during a create; I'm happy with either.
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index b8fd11c..6ed4d8a 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2014,22 +2014,38 @@ static virDomainPtr qemudDomainCreate(virConnectPtr conn, const char *xml,
vm = virDomainFindByName(driver-domains, def-name);
if (vm) {
-qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
- _(domain '%s' is already defined and running),
- def-name);
-virDomainDefFree(def);
-return NULL;
+if(virDomainIsActive(vm)) {
+qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
+ _(domain '%s' is already defined and running),
+ def-name);
+virDomainDefFree(def);
+return NULL;
+} else {
+if(virDomainDeleteConfig(conn, vm) -1) {
+return NULL;
+} else {
+virDomainRemoveInactive(driver-domains, vm);
+}
+}
}
vm = virDomainFindByUUID(driver-domains, def-uuid);
if (vm) {
-char uuidstr[VIR_UUID_STRING_BUFLEN];
+if(virDomainIsActive(vm)) {
+char uuidstr[VIR_UUID_STRING_BUFLEN];
-virUUIDFormat(def-uuid, uuidstr);
-qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
- _(domain with uuid '%s' is already defined and running),
- uuidstr);
-virDomainDefFree(def);
-return NULL;
+virUUIDFormat(def-uuid, uuidstr);
+qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
+ _(domain with uuid '%s' is already defined and running),
+ uuidstr);
+virDomainDefFree(def);
+return NULL;
+} else {
+if(virDomainDeleteConfig(conn, vm) -1) {
+return NULL;
+} else {
+virDomainRemoveInactive(driver-domains, vm);
+}
+}
}
if (!(vm = virDomainAssignDef(conn,
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 9d661d2..3790db8 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -2015,7 +2015,7 @@ static virDomainPtr qemudDomainCreate(virConnectPtr conn, const char *xml,
vm = virDomainFindByName(driver-domains, def-name);
if (vm) {
qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
- _(domain '%s' is already defined and running),
+ _(domain '%s' is already defined),
def-name);
virDomainDefFree(def);
return NULL;
@@ -2026,7 +2026,7 @@ static virDomainPtr qemudDomainCreate(virConnectPtr conn, const char *xml,
virUUIDFormat(def-uuid, uuidstr);
qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED,
- _(domain with uuid '%s' is already defined and running),
+ _(domain with uuid '%s' is already defined),
uuidstr);
virDomainDefFree(def);
return NULL;
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemudDomainCreate: also check uuid
Blerg; the more complex patch I provided was dangerously wrong. Just applying the one that corrects the message WORKSFORME. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Support for passing arbitrary qemu/kvm admin console commands?
Richard W.M. Jones wrote: On Mon, Jun 02, 2008 at 07:47:52PM -0500, Charles Duffy wrote: I'm looking at building a framework which makes use of KVM's pseudo-migration support for snapshot management. To my knowledge, this functionality is not presently available through libvirt. Is it possible to send arbitrary qemu/kvm admin console commands to a VM started and controlled by libvirt, or does any requirement for funtionality not presently exposed through libvirt conflict with its use? We'd really like you to send commands via libvirt. Which commands in particular do you want to send? I have an outstanding patch [1] to support KVM migration which just needs much more testing. Perhaps it does what you need already? It looks to me like that patch only supports migrating to a tcp:// socket, not what I was looking to do... but looking at the qemu driver's implementation of save and restore, I should be able to use those commands as they already exist. My apologies for the noise. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Support for passing arbitrary qemu/kvm admin console commands?
I'm looking at building a framework which makes use of KVM's pseudo-migration support for snapshot management. To my knowledge, this functionality is not presently available through libvirt. Is it possible to send arbitrary qemu/kvm admin console commands to a VM started and controlled by libvirt, or does any requirement for funtionality not presently exposed through libvirt conflict with its use? Thanks! -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] iptables masquerade rule overexpansive
On my system, libvirt-0.4.0-2ubuntu6 added the following rule to allow my virtual hosts NATted access to the outside world: Chain POSTROUTING (policy ACCEPT 33904 packets, 2146K bytes) pkts bytes target prot opt in out source destination 779 102K MASQUERADE all -- * * 192.168.65.0/24 0.0.0.0/0 This resulted in *all* traffic being masqueraded, even between two different VMs -- preventing hostbased authentication between these VMs. To temporarily resolve this, I added an additional rule, as follows: Chain POSTROUTING (policy ACCEPT 34049 packets, 2160K bytes) pkts bytes target prot opt in out source destination 156 9752 ACCEPT all -- * * 192.168.65.0/24 192.168.65.0/24 865 109K MASQUERADE all -- * * 192.168.65.0/24 0.0.0.0/0 The network definition being used was as follows: network namedefault/name uuida7c5b18c-9d38-40ed-9b12-8b1a27013b85/uuid bridge name=virbr%d / forward/ ip address=192.168.65.253 netmask=255.255.255.0/ /network I'm frankly unclear on why the packets attempted to forward through .253 in any event -- the routing tables on both VMs refer to 192.168.65.0/24 as part of the local network, so my expectation is that no attempt to route through the default gateway should have occurred. In any event, having libvirt extend the MASQUERADE rule to avoid impacting traffic between hosts on the virtual network -- or adding a paired ACCEPT, as I did above -- would probably be a Good Thing. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] [PATCH] Re: iptables masquerade rule overexpansive
Daniel P. Berrange wrote: Instead of having the separate ACCEPT rule I think it would be sufficient to replace the 0.0.0.0/0 target with ! 192.168.65.0/24, eg iptables -t nat -A POSTROUTING --source 192.168.65.0/24 --destination ! 192.168.65.0/24 -j MASQUERADE so it will masquerade traffic which is leaving the ip range of the virtual network only, and leave ip traffic between the VMs VM-host alone. I considered that -- but while it will work as long as the default forward rule is ACCEPT, it could result in hosts being unable to communicate with each other if the default rule for the table is otherwise. That said, it's certainly easier... patch attached. diff -ru libvirt-0.4.0.orig/src/iptables.c libvirt-0.4.0/src/iptables.c --- libvirt-0.4.0.orig/src/iptables.c 2007-12-12 07:30:49.0 -0600 +++ libvirt-0.4.0/src/iptables.c 2008-03-27 15:31:29.0 -0500 @@ -1047,6 +1047,7 @@ return iptablesAddRemoveRule(ctx-nat_postrouting, action, --source, network, + --destination, !, network, --out-interface, physdev, --jump, MASQUERADE, NULL); @@ -1054,6 +1055,7 @@ return iptablesAddRemoveRule(ctx-nat_postrouting, action, --source, network, + --destination, !, network, --jump, MASQUERADE, NULL); } -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Re: RFC: Supporting serial parallel ports for QEMU (and improving Xen)
Daniel P. Berrange wrote: Lots of difficult bits, but I'm starting to get onto coding it. Was this ever completed and merged? I don't see it documented at http://libvirt.org/format.html -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Re: Proposal: More script hooks for interface type='ethernet'
Daniel P. Berrange wrote: Being able to specify an qemu-ifdown script is reasonable, since we already support an qemu-ifup script, but I don't want to just add that without a clearer understanding of exactly what type of network config you are trying to achieve. So rather than describing a desired implementation can you describe the deployment scenario / level of network connectivity you're trying to provide. I want similar behavior to interface type='ethernet'/ with no tap device precreated, in a scenario where CAP_NET_ADMIN (not just write access to /dev/net/tun) is necessary to create new tap devices and kvm isn't running as root. Is that an adequate description, or do I need to expand? I'm using my ifup script to select a bridge to connect to (and actually create that connection), and the ifdown script to clean up unused tap devices; these scripts use sudo where necessary. The problem, though, is that these scripts can't create the tap device themselves, so they can't use sudo for that. So -- just a bridge (or, rather, a selection of one of a few bridges), but with the tap devices dynamically created in a situation where privilege escalation is necessary for that device creation. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Proposal: More script hooks for interface type='ethernet'
I have a few issues with interface type='ethernet': - The requirement that either (1) the tap device already exists and has a constant name, or (2) the tap device can be created by the current user without privilege escalation doesn't work for places where the user wants to - dynamically generate tap devices - ...but is running kvm without privileges to do so. (this is particularly likely now that write privileges to /dev/net/tap are not enough, and the user needs CAP_NET_ADMIN to create a tap device). Allowing a target script to be specified (which is responsible for gaining any privileges necessary) which runs *before* the tap device is opened and would resolve this. - A qemu-ifup script can be specified, but not a qemu-ifdown replacement. Before looking to use libvirt, I had kvm's invocation wrapped by a script which did appropriate privilege escalation (ifname=$(sudo tunctl -b -u $USER), with sudo configured with the NOPASSWORD flag for this request -- though plenty of other approaches are certainly possible). It would be ideal if more hooks were available... for instance: interface type='ethernet' !-- script gives device name on stdout -- target script='/usr/local/bin/make-me-a-tap-device'/ !-- preexisting argument and syntax for up scripts -- script path='/etc/qemu-ifup-mynet'/ !-- option to specify a down script, passed to qemu via 'downscript=' parameter-- script-down path='/etc/qemu-ifdown-mynet'/ /interface Working around this means that I would need to preallocate the tap devices and assign them to specific VMs (boo! hiss!) or that (if I wrapped libvirt's invocation to have the tap device created just ahead of time and its name substituted into interface/@dev) 3rd-party libvirt-based management tools couldn't be used (which would defeat the point of switching to libvirt from my homegrown script collection in the first place). So -- does the proposed syntax extension look reasonable? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
