February 2012 - Devel - libvirt List Archives

[libvirt] [PATCH v2] virsh: Do not check the input XML at virsh layer for cmdDetachDevice
by Osier Yang 08 Feb '12

08 Feb '12

Any device XML doesn't use the same order as libvirt generates, or uses decimal for attributes like "slot" of "<address>" will cause device detaching to fail, as virsh compares the XML simply earlier in strict manner before internal parsing. This is regression introduced by ea7182c. v1 is here: https://www.redhat.com/archives/libvir-list/2012-January/msg00395.html v1 - v2: * The two useful functions is left unchanged, marked as unused. --- tools/virsh.c | 23 +++++------------------ 1 files changed, 5 insertions(+), 18 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index 72ca93a..7997cbb 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -13153,6 +13153,7 @@ cmdAttachDevice(vshControl *ctl, const vshCmd *cmd) * @n2 second node * returns true in case n1 covers n2, false otherwise. */ +__attribute__((unused)) static bool vshNodeIsSuperset(xmlNodePtr n1, xmlNodePtr n2) { @@ -13278,6 +13279,7 @@ cleanup: * (is too ambiguous), 0 in case of success. Otherwise returns -1. @newXML * is touched only in case of success. */ +__attribute__((unused)) static int vshCompleteXMLFromDomain(vshControl *ctl, virDomainPtr dom, char *oldXML, char **newXML) @@ -13412,7 +13414,7 @@ cmdDetachDevice(vshControl *ctl, const vshCmd *cmd) { virDomainPtr dom = NULL; const char *from = NULL; - char *buffer = NULL, *new_buffer = NULL; + char *buffer = NULL; int ret; bool funcRet = false; unsigned int flags; @@ -13431,27 +13433,13 @@ cmdDetachDevice(vshControl *ctl, const vshCmd *cmd) goto cleanup; } - ret = vshCompleteXMLFromDomain(ctl, dom, buffer, &new_buffer); - if (ret < 0) { - if (ret == -2) { - vshError(ctl, _("no such device in %s"), virDomainGetName(dom)); - } else if (ret == -3) { - vshError(ctl, "%s", _("given XML selects too many devices. " - "Please, be more specific")); - } else { - /* vshCompleteXMLFromDomain() already printed error message, - * so nothing to do here. */ - } - goto cleanup; - } - if (vshCommandOptBool(cmd, "persistent")) { flags = VIR_DOMAIN_AFFECT_CONFIG; if (virDomainIsActive(dom) == 1) flags |= VIR_DOMAIN_AFFECT_LIVE; - ret = virDomainDetachDeviceFlags(dom, new_buffer, flags); + ret = virDomainDetachDeviceFlags(dom, buffer, flags); } else { - ret = virDomainDetachDevice(dom, new_buffer); + ret = virDomainDetachDevice(dom, buffer); } if (ret < 0) { @@ -13463,7 +13451,6 @@ cmdDetachDevice(vshControl *ctl, const vshCmd *cmd) funcRet = true; cleanup: - VIR_FREE(new_buffer); VIR_FREE(buffer); virDomainFree(dom); return funcRet; -- 1.7.7.3

3 4

[libvirt] [PATCH] build: avoid gcc 4.7 warning about inlines
by Eric Blake 08 Feb '12

08 Feb '12

gcc 4.7 complains: util/virhashcode.c:49:17: error: always_inline function might not be inlinable [-Werror=attributes] util/virhashcode.c:35:17: error: always_inline function might not be inlinable [-Werror=attributes] Normal 'inline' is a hint that the compiler may ignore; the fact that the function is static is good enough. We don't care if the compiler decided not to inline after all. * src/util/virhashcode.c (getblock, fmix): Relax attribute. --- Pushing under the build-breaker rule; this lets the build get further on rawhide (it later fails with: GEN remote/remote_protocol.h /usr/bin/rpcgen: C preprocessor failed with exit code 1 cannot shutdown /usr/bin/rpcgen: at ./rpc/genprotocol.pl line 122. that I still have to investigate). src/util/virhashcode.c | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/src/util/virhashcode.c b/src/util/virhashcode.c index 6d91793..d16d544 100644 --- a/src/util/virhashcode.c +++ b/src/util/virhashcode.c @@ -31,8 +31,7 @@ #include "bitrotate.h" /* slower than original but handles platforms that do only aligned reads */ -__attribute__((always_inline)) -static uint32_t getblock(const uint8_t *p, int i) +static inline uint32_t getblock(const uint8_t *p, int i) { uint32_t r; size_t size = sizeof(r); @@ -45,8 +44,7 @@ static uint32_t getblock(const uint8_t *p, int i) /* * Finalization mix - force all bits of a hash block to avalanche */ -__attribute__((always_inline)) -static uint32_t fmix(uint32_t h) +static inline uint32_t fmix(uint32_t h) { h ^= h >> 16; h *= 0x85ebca6b; -- 1.7.7.6

1 2

[libvirt] [PATCH] storage: Don't unsparsify images when cloning
by Cole Robinson 07 Feb '12

07 Feb '12

Input to the volume cloning code is a source volume and an XML descriptor for the new volume. It is possible for the new volume to have a greater size than source volume, at which point libvirt will just stick 0s on the end of the new image (for raw format anyways). Unfortunately a logic error messed up our tracking of the of the excess amount that needed to be written: end result is that sparse clones were made very much non-sparse, and cloning regular disk images could end up excessively sized (though data unaltered). Drop the 'remain' variable entriely here since it's redundant, and track actual allocation directly against the desired 'total'. --- src/storage/storage_backend.c | 11 +++-------- 1 files changed, 3 insertions(+), 8 deletions(-) diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index 1c22112..caac2f8 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -127,7 +127,6 @@ virStorageBackendCopyToFD(virStorageVolDefPtr vol, int inputfd = -1; int amtread = -1; int ret = 0; - unsigned long long remain; size_t rbytes = READ_BLOCK_SIZE_DEFAULT; size_t wbytes = 0; int interval; @@ -165,13 +164,11 @@ virStorageBackendCopyToFD(virStorageVolDefPtr vol, goto cleanup; } - remain = *total; - while (amtread != 0) { int amtleft; - if (remain < rbytes) - rbytes = remain; + if (*total < rbytes) + rbytes = *total; if ((amtread = saferead(inputfd, buf, rbytes)) < 0) { ret = -errno; @@ -180,7 +177,7 @@ virStorageBackendCopyToFD(virStorageVolDefPtr vol, inputvol->target.path); goto cleanup; } - remain -= amtread; + *total -= amtread; /* Loop over amt read in 512 byte increments, looking for sparse * blocks */ @@ -225,8 +222,6 @@ virStorageBackendCopyToFD(virStorageVolDefPtr vol, } inputfd = -1; - *total -= remain; - cleanup: VIR_FORCE_CLOSE(inputfd); -- 1.7.7.5

2 4

[libvirt] [PATCH] Bug fix: Allow sysinfo to display processor information
by Prerna Saxena 07 Feb '12

07 Feb '12

From: Prerna Saxena <prerna(a)linux.vnet.ibm.com> Date: Mon, 6 Feb 2012 13:46:10 +0530 Subject: [PATCH] Bugfix: Allow sysinfo to display 'processor' information Calls to virSysinfoParseBIOS(), virSysinfoParseSystem() would update the buffer pointer 'base', so the processor information would be lost before virSysinfoParseProcessor() was called. Sysinfo would therefore not be able to display processor details -- It only described <bios>, <system> and <memory_device> details. Before the fix: --------------- virsh # sysinfo <sysinfo type='smbios'> <bios> .... </bios> <system> .... </system> <memory_device> .... </memory_device> After the fix: ------------- virsh # sysinfo <sysinfo type='smbios'> <bios> .... </bios> <system> .... </system> <processor> .... </processor> <memory_device> .... </memory_device> --- src/util/sysinfo.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/util/sysinfo.c b/src/util/sysinfo.c index de3108a..d92d655 100644 --- a/src/util/sysinfo.c +++ b/src/util/sysinfo.c @@ -483,16 +483,17 @@ virSysinfoRead(void) { base = outbuf; + ret->nprocessor = 0; + ret->processor = NULL; + if ((base = virSysinfoParseProcessor(base, ret)) == NULL) + goto no_memory; + if ((base = virSysinfoParseBIOS(base, ret)) == NULL) goto no_memory; if ((base = virSysinfoParseSystem(base, ret)) == NULL) goto no_memory; - ret->nprocessor = 0; - ret->processor = NULL; - if ((base = virSysinfoParseProcessor(base, ret)) == NULL) - goto no_memory; ret->nmemory = 0; ret->memory = NULL; -- 1.7.3.1 -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India

2 4

[libvirt] [PATCH 0/2] qemu: Fix stalls during live core dump
by Jiri Denemark 07 Feb '12

07 Feb '12

Qemu uses non-blocking I/O which doesn't play nice with regular file descriptors. We need to pass a pipe to qemu when dumping core to avoid stalls in live mode. Jiri Denemark (2): util: Generalize virFileDirectFd qemu: Always use iohelper for dumping domain core src/qemu/qemu_driver.c | 41 +++++++++++--------- src/util/virfile.c | 98 ++++++++++++++++++++++++++--------------------- src/util/virfile.h | 18 +++++---- 3 files changed, 86 insertions(+), 71 deletions(-) -- 1.7.8.4

2 8

[libvirt] [PATCH v2 0/1] qemu-ga: add guest-sync-delimited
by Michael Roth 07 Feb '12

07 Feb '12

Sorry for the somewhat redundant cover letter, but needed to note that: This applies on top of "[PATCH v2 0/8] qemu-ga: add support for Windows", and can also be obtained from: git://github.com/mdroth/qemu.git qga-guest-sync-delimited CHANGES SINCE v1: - removed deprecation flag for guest-sync, still useful for some implementations As noted in the commit there's a wiki write-up with more details on what exactly this is for: http://wiki.qemu.org/Features/QAPI/GuestAgent#QEMU_Guest_Agent_Protocol It's not absolutely required, but it does make dealing with some communication corner cases a heck of a lot easier for stream-based (as opposed to readline-based) client implementations.

2 4

[libvirt] [PATCH] build: don't require avahi during install
by Laine Stump 07 Feb '12

07 Feb '12

See: https://bugzilla.redhat.com/show_bug.cgi?id=785269 The specfile requires avahi during install if libvirt was built with avahi support, but there are many situations where it is undesirable to install avahi due to security concerns. If we still Build-require avahi-devel during the build, but don't require it at install time, it will be used if present, and ignored if not. --- libvirt.spec.in | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index f279d6d..dab9650 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -272,9 +272,6 @@ Requires: %{name}-client = %{version}-%{release} Requires: module-init-tools # for /sbin/ip & /sbin/tc Requires: iproute -%if %{with_avahi} -Requires: avahi -%endif %endif %if %{with_network} Requires: dnsmasq >= 2.41 -- 1.7.7.6

2 4

[libvirt] [PATCH] Allow polkit auth for VNC and SSH users
by Cole Robinson 07 Feb '12

07 Feb '12

If you are sitting in front of a physical machine and logged in as a regular user, you can connect to the system libvirtd instance by providing a root password to policykit. This is how most virt-manager users talk to libvirt. However, if you are launching virt-manager over ssh -X, or over VNC started from say /etc/sysconfig/vncservers, our policykit policy rejects the user outright, providing no option to provide the root password. This is confusing to users and doesn't seem to serve much point. Change the policy to allow inactive (VNC) and non-local (SSH, VNC) to provide root credentials for accessing system libvirtd. We use auth_admin rather than auth_admin_keep so that credentials aren't cached at all, and every subsequent reconnection to libvirt requires auth. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=625115 Similar change to PackageKit policy: https://bugzilla.redhat.com/show_bug.cgi?id=528511 --- daemon/libvirtd.policy-0 | 4 ++-- daemon/libvirtd.policy-1 | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/daemon/libvirtd.policy-0 b/daemon/libvirtd.policy-0 index b6da946..5d6845c 100644 --- a/daemon/libvirtd.policy-0 +++ b/daemon/libvirtd.policy-0 @@ -34,8 +34,8 @@ file are instantly applied. <defaults>  - <allow_any>no</allow_any> - <allow_inactive>no</allow_inactive> + <allow_any>auth_admin</allow_any> + <allow_inactive>auth_admin</allow_inactive> <allow_active>auth_admin_keep_session</allow_active> </defaults> </action> diff --git a/daemon/libvirtd.policy-1 b/daemon/libvirtd.policy-1 index 6fa3a5e..c2bec1f 100644 --- a/daemon/libvirtd.policy-1 +++ b/daemon/libvirtd.policy-1 @@ -34,8 +34,8 @@ file are instantly applied. <defaults>  - <allow_any>no</allow_any> - <allow_inactive>no</allow_inactive> + <allow_any>auth_admin</allow_any> + <allow_inactive>auth_admin</allow_inactive> <allow_active>auth_admin_keep</allow_active> </defaults> </action> -- 1.7.7.5

2 2

[libvirt] [PATCH] qemu_agent: Issue guest-sync prior to every command
by Michal Privoznik 07 Feb '12

07 Feb '12

If we issue guest command and GA is not running, the issuing thread will block endlessly. We can check for GA presence by issuing guest-sync with unique ID (timestamp). We don't want to issue real command as even if GA is not running, once it is started, it process all commands written to GA socket. If we receive reply, it might be from a previous sync command, so we need to compare received ID for equality with the given one. --- Some background on this: -GA socked is always writeable, even with no GA running (!) -writing something to dead socket (=without any GA listening) will thus succeed. However, when one will (after a period of time) start the GA, it will read and process all written data. This makes timeout implementation harder. -Therefore issuing a GA command without any GA running will block indefinitely. My solution to this is: Issue harmless guest-sync command which returns given identifier. To avoid blocking, do a timed wait (5 seconds). This is the only case where we do a timed wait, regular GA commands will of course wait without any timeout. If GA didn't reply within those 5 seconds, we store an ID so we can compare it later and report 'GA unavailable'; Note that guest won't get into a different state as libvirt thinks it is in. Then, if GA is ever started, it start to process our sync commands. And all we have to do is check if we have ever issued such ID. If not an error is reported. However, there is still race: 1) GA will reply to our guest-sync 2) GA gets terminated 3) we issue regular command (e.g. fs-freeze) I am not sure this is avoidable. But this patch makes current situation bearable. src/qemu/qemu_agent.c | 165 +++++++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 159 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c index 9df5546..5ecf893 100644 --- a/src/qemu/qemu_agent.c +++ b/src/qemu/qemu_agent.c @@ -39,6 +39,7 @@ #include "virterror_internal.h" #include "json.h" #include "virfile.h" +#include "virtime.h" #define VIR_FROM_THIS VIR_FROM_QEMU @@ -106,6 +107,10 @@ struct _qemuAgent { /* If anything went wrong, this will be fed back * the next monitor msg */ virError lastError; + + /* Array of IDs issued to GA via guest-sync */ + unsigned long long *ids; + size_t ids_size; }; #if DEBUG_RAW_IO @@ -147,6 +152,7 @@ static void qemuAgentFree(qemuAgentPtr mon) (mon->cb->destroy)(mon, mon->vm); ignore_value(virCondDestroy(&mon->notify)); virMutexDestroy(&mon->lock); + VIR_FREE(mon->ids); VIR_FREE(mon->buffer); VIR_FREE(mon); } @@ -316,6 +322,8 @@ qemuAgentIOProcessLine(qemuAgentPtr mon, { virJSONValuePtr obj = NULL; int ret = -1; + size_t i; + unsigned long long id; VIR_DEBUG("Line [%s]", line); @@ -340,6 +348,40 @@ qemuAgentIOProcessLine(qemuAgentPtr mon, obj = NULL; ret = 0; } else { + /* If we've received something like: + * {"return": 1234} + * it is likely that somebody started GA + * which is now processing our previous + * guest-sync command. Check this and if so, + * don't report an error however return silently + */ + if (virJSONValueObjectGetNumberUlong(obj, "return", &id) == 0) { + for (i = 0; i < mon->ids_size; i++) { + if (mon->ids[i] != id) + continue; + + VIR_DEBUG("Received delayed reply to guest-sync: %llu", + id); + + if (mon->ids_size > 1) { + memmove(&mon->ids[i], + &mon->ids[i + 1], + sizeof(*mon->ids) * (mon->ids_size - (i + 1))); + + mon->ids_size--; + if (VIR_REALLOC_N(mon->ids, mon->ids_size) < 0) { + /* Ignore, harmless */ + } + } else { + VIR_FREE(mon->ids); + mon->ids_size = 0; + } + + ret = 0; + goto cleanup; + } + } + qemuReportError(VIR_ERR_INTERNAL_ERROR, _("Unexpected JSON reply '%s'"), line); } @@ -813,11 +855,28 @@ void qemuAgentClose(qemuAgentPtr mon) qemuAgentUnlock(mon); } +#define QEMU_AGENT_WAIT_TIME (1000ull * 5) +/** + * qemuAgentSend: + * @mon: Monitor + * @msg: Message + * @timeout: use timeout? + * + * Send @msg to agent @mon. + * Wait max QEMU_AGENT_WAIT_TIME for agent + * to reply. + * + * Returns: 0 on success, + * -2 on timeout, + * -1 otherwise + */ static int qemuAgentSend(qemuAgentPtr mon, - qemuAgentMessagePtr msg) + qemuAgentMessagePtr msg, + bool timeout) { int ret = -1; + unsigned long long now, then; /* Check whether qemu quit unexpectedly */ if (mon->lastError.code != VIR_ERR_OK) { @@ -827,13 +886,26 @@ static int qemuAgentSend(qemuAgentPtr mon, return -1; } + if (timeout) { + if (virTimeMillisNow(&now) < 0) + return -1; + then = now + QEMU_AGENT_WAIT_TIME; + } + mon->msg = msg; qemuAgentUpdateWatch(mon); while (!mon->msg->finished) { - if (virCondWait(&mon->notify, &mon->lock) < 0) { - qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Unable to wait on monitor condition")); + if ((timeout && virCondWaitUntil(&mon->notify, &mon->lock, then) < 0) || + (!timeout && virCondWait(&mon->notify, &mon->lock) < 0)) { + if (errno == ETIMEDOUT) { + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Guest agent not available for now")); + ret = -2; + } else { + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Unable to wait on monitor condition")); + } goto cleanup; } } @@ -855,6 +927,83 @@ cleanup: } +/** + * qemuAgentGuestSync: + * @mon: Monitor + * + * Send guest-sync with unique ID and wait for + * reply. If we get one, check if received ID + * is equal to given. + * + * Returns: 0 on success, + * -1 otherwise + */ +static int +qemuAgentGuestSync(qemuAgentPtr mon) +{ + int ret = -1; + int send_ret; + unsigned long long id, id_ret; + qemuAgentMessage sync_msg; + + memset(&sync_msg, 0, sizeof sync_msg); + + if (virTimeMillisNow(&id) < 0) + return -1; + + if (virAsprintf(&sync_msg.txBuffer, + "{\"execute\":\"guest-sync\", " + "\"arguments\":{\"id\":%llu}}", id) < 0) { + virReportOOMError(); + return -1; + } + sync_msg.txLength = strlen(sync_msg.txBuffer); + + VIR_DEBUG("Sending guest-sync command with ID: %llu", id); + + send_ret = qemuAgentSend(mon, &sync_msg, true); + + VIR_DEBUG("Agent guest-sync returned: %d", send_ret); + + if (send_ret == -1) { + /* error reported */ + goto cleanup; + } else if (send_ret == -2) { + /* don't report errors as we don't want to + * overwrite the one from qemuAgentSend() */ + if (VIR_REALLOC_N(mon->ids, mon->ids_size) == 0) + mon->ids[mon->ids_size++] = id; + goto cleanup; + } + + if (!sync_msg.rxObject) { + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Missing monitor reply object")); + goto cleanup; + } + + if (virJSONValueObjectGetNumberUlong(sync_msg.rxObject, + "return", &id_ret) < 0) { + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Malformed return value")); + goto cleanup; + } + + VIR_DEBUG("Guest returned ID: %llu", id_ret); + if (id_ret != id) { + qemuReportError(VIR_ERR_INTERNAL_ERROR, + _("Guest agent returned ID: %llu instead of %llu"), + id_ret, id); + goto cleanup; + } + ret = 0; + +cleanup: + virJSONValueFree(sync_msg.rxObject); + VIR_FREE(sync_msg.txBuffer); + return ret; +} + static int qemuAgentCommand(qemuAgentPtr mon, virJSONValuePtr cmd, @@ -866,6 +1015,11 @@ qemuAgentCommand(qemuAgentPtr mon, *reply = NULL; + if (qemuAgentGuestSync(mon) < 0) { + /* helper reported the error */ + return -1; + } + memset(&msg, 0, sizeof msg); if (!(cmdstr = virJSONValueToString(cmd))) { @@ -880,12 +1034,11 @@ qemuAgentCommand(qemuAgentPtr mon, VIR_DEBUG("Send command '%s' for write", cmdstr); - ret = qemuAgentSend(mon, &msg); + ret = qemuAgentSend(mon, &msg, false); VIR_DEBUG("Receive command reply ret=%d rxObject=%p", ret, msg.rxObject); - if (ret == 0) { if (!msg.rxObject) { qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", -- 1.7.3.4

3 3

[libvirt] [PATCH 0/1] qemu-ga: add guest-sync-delimited
by Michael Roth 07 Feb '12

07 Feb '12

Sorry for the somewhat redundant cover letter, but needed to note that: This applies on top of "[PATCH v2 0/8] qemu-ga: add support for Windows", and can also be obtained from: git://github.com/mdroth/qemu.git qga-guest-sync-delimited As noted in the commit there's a wiki write-up with more details on what exactly this is for: http://wiki.qemu.org/Features/QAPI/GuestAgent#QEMU_Guest_Agent_Protocol It's not absolutely required, but it does make dealing with some communication corner cases a heck of a lot easier.

2 3