- Devel - libvirt List Archives

[libvirt] [PATCH] qemu: fix regression with pinning
by Martin Kletzander 27 Aug '12

27 Aug '12

Commit 4b03d59167f4a4c6ec57def315a61d977466e75b changed the pinning behavior in a way that makes some machine non-startable. The comment mentioning that we cannot control each vcpu when there is no VCPU<->PID mapping available is true, however, this isn't necessarily an error, because this can be caused by old QEMU without support for "query-cpus" command as well as a software emulated machines that don't create more than one process. --- src/qemu/qemu_cgroup.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c index 2237d11..b45bb49 100644 --- a/src/qemu/qemu_cgroup.c +++ b/src/qemu/qemu_cgroup.c @@ -567,9 +567,9 @@ int qemuSetupCgroupForVcpu(struct qemud_driver *driver, virDomainObjPtr vm) /* If we don't know VCPU<->PID mapping or all vcpu runs in the same * thread, we cannot control each vcpu. */ - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("Unable to get vcpus' pids.")); - goto cleanup; + VIR_DEBUG("%s", _("Unable to get vcpus' pids.")); + virCgroupFree(&cgroup); + return 0; } for (i = 0; i < priv->nvcpupids; i++) { -- 1.7.12

2 2

[libvirt] [PATCH] qemu: fix regression with spice tls port allocation
by Martin Kletzander 27 Aug '12

27 Aug '12

In my quest for reusing variables I failed to edit one variable when fixing details between two patch versions. That results in a failure to start qemu with autoport and spice tls, because qemu is trying to bind two sockets to the same port. --- src/qemu/qemu_process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index abe6e74..7f85aea 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -3500,7 +3500,7 @@ int qemuProcessStart(virConnectPtr conn, goto cleanup; } - vm->def->graphics[0]->data.spice.tlsPort = port; + vm->def->graphics[0]->data.spice.tlsPort = tlsPort; } } -- 1.7.12

2 2

[libvirt] [PATCH] virsh: fix missing return value
by Alex Jia 27 Aug '12

27 Aug '12

Although virsh command raises a correct error information, the command status returns 0(true), this patch is used for fixing this issue. Signed-off-by: Alex Jia <ajia(a)redhat.com> --- tools/virsh-host.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/tools/virsh-host.c b/tools/virsh-host.c index da60895..2f3b413 100644 --- a/tools/virsh-host.c +++ b/tools/virsh-host.c @@ -701,11 +701,13 @@ cmdQemuAgentCommand(vshControl *ctl, const vshCmd *cmd) judge = vshCommandOptInt(cmd, "timeout", &timeout); if (judge < 0) { vshError(ctl, "%s", _("timeout number has to be a number")); + goto cleanup; } else if (judge > 0) { judge = 1; } if (judge && timeout < 1) { vshError(ctl, "%s", _("timeout must be positive")); + goto cleanup; } if (vshCommandOptBool(cmd, "async")) { @@ -719,6 +721,7 @@ cmdQemuAgentCommand(vshControl *ctl, const vshCmd *cmd) if (judge > 1) { vshError(ctl, "%s", _("timeout, async and block options are exclusive")); + goto cleanup; } result = virDomainQemuAgentCommand(dom, guest_agent_cmd, timeout, flags); -- 1.7.1

2 2

[libvirt] [PATCH] specfile: require libnl3 for Fedora >= 18 and RHEL >= 7
by Laine Stump 27 Aug '12

27 Aug '12

Everything is ready in both netcf and libvirt to switch over to libnl3 in future releases of both Fedora and RHEL. This needs to be done more or less simultaneously in both packages, though, because you can't mix libnl1.1 and libnl3 in the same process (e.g. libvirtd using libnl-3.so and libnetcf.so, while libnetcf.so uses libnl.so) This patch does two things when fedora >= 18 || rhel >= 7): 1) requires libnl3-devel 2) requires netcf-devel-0.2.2 or greater (the idea is that a similar patch is going into netcf's specfile, so that when a build of netcf is done on F18 or later (or RHEL7 or later) netcf will be guaranteed to be built with libnl3 rather than libnl-1.1) --- libvirt.spec.in | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index 18a7fb8..4b4d1d0 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -409,8 +409,12 @@ BuildRequires: sanlock-devel >= 1.8 BuildRequires: libpcap-devel %endif %if %{with_libnl} +%if 0%{?fedora} >= 18 || 0%{?rhel} >= 7 +BuildRequires: libnl3-devel +%else BuildRequires: libnl-devel %endif +%endif %if %{with_avahi} BuildRequires: avahi-devel %endif @@ -489,13 +493,18 @@ BuildRequires: libcap-ng-devel >= 0.5.0 %if %{with_phyp} BuildRequires: libssh2-devel %endif + %if %{with_netcf} +%if 0%{?fedora} >= 18 || 0%{?rhel} >= 7 +BuildRequires: netcf-devel >= 0.2.2 +%else %if 0%{?fedora} >= 16 || 0%{?rhel} >= 6 BuildRequires: netcf-devel >= 0.1.8 %else BuildRequires: netcf-devel >= 0.1.4 %endif %endif +%endif %if %{with_esx} %if 0%{?fedora} >= 9 || 0%{?rhel} >= 6 BuildRequires: libcurl-devel -- 1.7.11.4

4 7

[libvirt] [PATCH v2] esx: Support VLAN tags in virtual network port groups
by Matthias Bolte 26 Aug '12

26 Aug '12

--- v2: Use network level VLAN config if there is no portgroup specific VLAN config given. src/esx/esx_network_driver.c | 65 ++++++++++++++++++++++++++++++++++++++--- 1 files changed, 60 insertions(+), 5 deletions(-) diff --git a/src/esx/esx_network_driver.c b/src/esx/esx_network_driver.c index 09d46d3..7b529ee 100644 --- a/src/esx/esx_network_driver.c +++ b/src/esx/esx_network_driver.c @@ -489,7 +489,40 @@ esxNetworkDefineXML(virConnectPtr conn, const char *xml) goto cleanup; } - hostPortGroupSpec->vlanId->value = 0; + if (def->portGroups[i].vlan.trunk) { + /* FIXME: Change this once tag-less trunk-mode is supported */ + if (def->portGroups[i].vlan.nTags != 1 || + *def->portGroups[i].vlan.tag != 4095) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("VLAN tag has to be 4095 in trunk mode")); + goto cleanup; + } + + hostPortGroupSpec->vlanId->value = 4095; + } else if (def->portGroups[i].vlan.nTags == 1) { + hostPortGroupSpec->vlanId->value = *def->portGroups[i].vlan.tag; + } else if (def->portGroups[i].vlan.nTags > 1) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("Can apply one VLAN tag per port group only")); + goto cleanup; + } else if (def->vlan.trunk) { + /* FIXME: Change this once tag-less trunk-mode is supported */ + if (def->vlan.nTags != 1 || *def->vlan.tag != 4095) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("VLAN tag has to be 4095 in trunk mode")); + goto cleanup; + } + + hostPortGroupSpec->vlanId->value = 4095; + } else if (def->vlan.nTags == 1) { + hostPortGroupSpec->vlanId->value = *def->vlan.tag; + } else if (def->vlan.nTags > 1) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("Can apply one VLAN tag per port group only")); + goto cleanup; + } else { + hostPortGroupSpec->vlanId->value = 0; + } if (def->portGroups[i].bandwidth != NULL) { if (esxBandwidthToShapingPolicy @@ -519,6 +552,8 @@ esxNetworkDefineXML(virConnectPtr conn, const char *xml) network = virGetNetwork(conn, hostVirtualSwitch->name, md5); cleanup: + /* FIXME: need to remove virtual switch if adding port groups failed */ + virNetworkDefFree(def); esxVI_HostVirtualSwitch_Free(&hostVirtualSwitch); esxVI_HostPortGroup_Free(&hostPortGroupList); @@ -695,6 +730,7 @@ esxNetworkGetXMLDesc(virNetworkPtr network_, unsigned int flags) esxVI_String *hostPortGroupKey = NULL; esxVI_String *networkName = NULL; virNetworkDefPtr def; + virPortGroupDefPtr portGroup; if (esxVI_EnsureSession(priv->primary) < 0) { return NULL; @@ -824,9 +860,12 @@ esxNetworkGetXMLDesc(virNetworkPtr network_, unsigned int flags) for (networkName = networkNameList; networkName != NULL; networkName = networkName->_next) { if (STREQ(networkName->value, hostPortGroup->spec->name)) { - def->portGroups[def->nPortGroups].name = strdup(networkName->value); + portGroup = &def->portGroups[def->nPortGroups]; + ++def->nPortGroups; - if (def->portGroups[def->nPortGroups].name == NULL) { + portGroup->name = strdup(networkName->value); + + if (portGroup->name == NULL) { virReportOOMError(); goto cleanup; } @@ -834,13 +873,29 @@ esxNetworkGetXMLDesc(virNetworkPtr network_, unsigned int flags) if (hostPortGroup->spec->policy != NULL) { if (esxShapingPolicyToBandwidth (hostPortGroup->spec->policy->shapingPolicy, - &def->portGroups[def->nPortGroups].bandwidth) < 0) { + &portGroup->bandwidth) < 0) { ++def->nPortGroups; goto cleanup; } } - ++def->nPortGroups; + if (hostPortGroup->spec->vlanId->value > 0) { + if (hostPortGroup->spec->vlanId->value == 4095) { + portGroup->vlan.trunk = true; + } + + /* FIXME: Remove this once tag-less trunk-mode is supported */ + portGroup->vlan.nTags = 1; + + if (VIR_ALLOC_N(portGroup->vlan.tag, 1) < 0) { + virReportOOMError(); + goto cleanup; + } + + *portGroup->vlan.tag = + hostPortGroup->spec->vlanId->value; + } + break; } } -- 1.7.4.1

2 1

[libvirt] [PATCH] esx: Support VLAN tags in virtual network port groups
by Matthias Bolte 26 Aug '12

26 Aug '12

--- src/esx/esx_network_driver.c | 38 +++++++++++++++++++++++++++++++++----- 1 files changed, 33 insertions(+), 5 deletions(-) diff --git a/src/esx/esx_network_driver.c b/src/esx/esx_network_driver.c index 09d46d3..2f5f1ab 100644 --- a/src/esx/esx_network_driver.c +++ b/src/esx/esx_network_driver.c @@ -489,7 +489,16 @@ esxNetworkDefineXML(virConnectPtr conn, const char *xml) goto cleanup; } - hostPortGroupSpec->vlanId->value = 0; + if (def->portGroups[i].vlan.trunk) { + hostPortGroupSpec->vlanId->value = 4095; + } else if (def->portGroups[i].vlan.nTags == 1) { + hostPortGroupSpec->vlanId->value = *def->portGroups[i].vlan.tag; + } else if (def->portGroups[i].vlan.nTags > 1) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("Can apply one VLAN tag per port group only")); + } else { + hostPortGroupSpec->vlanId->value = 0; + } if (def->portGroups[i].bandwidth != NULL) { if (esxBandwidthToShapingPolicy @@ -695,6 +704,7 @@ esxNetworkGetXMLDesc(virNetworkPtr network_, unsigned int flags) esxVI_String *hostPortGroupKey = NULL; esxVI_String *networkName = NULL; virNetworkDefPtr def; + virPortGroupDefPtr portGroup = NULL; if (esxVI_EnsureSession(priv->primary) < 0) { return NULL; @@ -824,9 +834,12 @@ esxNetworkGetXMLDesc(virNetworkPtr network_, unsigned int flags) for (networkName = networkNameList; networkName != NULL; networkName = networkName->_next) { if (STREQ(networkName->value, hostPortGroup->spec->name)) { - def->portGroups[def->nPortGroups].name = strdup(networkName->value); + portGroup = &def->portGroups[def->nPortGroups]; + ++def->nPortGroups; + + portGroup->name = strdup(networkName->value); - if (def->portGroups[def->nPortGroups].name == NULL) { + if (portGroup->name == NULL) { virReportOOMError(); goto cleanup; } @@ -834,13 +847,28 @@ esxNetworkGetXMLDesc(virNetworkPtr network_, unsigned int flags) if (hostPortGroup->spec->policy != NULL) { if (esxShapingPolicyToBandwidth (hostPortGroup->spec->policy->shapingPolicy, - &def->portGroups[def->nPortGroups].bandwidth) < 0) { + &portGroup->bandwidth) < 0) { ++def->nPortGroups; goto cleanup; } } - ++def->nPortGroups; + if (hostPortGroup->spec->vlanId->value > 0) { + if (hostPortGroup->spec->vlanId->value == 4095) { + portGroup->vlan.trunk = true; + } + + portGroup->vlan.nTags = 1; + + if (VIR_ALLOC_N(portGroup->vlan.tag, 1) < 0) { + virReportOOMError(); + goto cleanup; + } + + *portGroup->vlan.tag = + hostPortGroup->spec->vlanId->value; + } + break; } } -- 1.7.4.1

3 3

[libvirt] switching both libvirt and netcf packages to use libnl3 instead of libnl-1.1
by Laine Stump 24 Aug '12

24 Aug '12

Both libvirt and the netcf library it links to use libnl for doing things with netlink sockets. libnl comes in a couple of different and API-incompatible flavors, namely libnl-1.1 and libnl-3. For a long time Fedora had just libnl-1.1, and libvirt only supported libnl-1.1 Awhile back Fedora gained support for using libnl-3 instead of libnl-1.1, and did so in a way that allows both libraries (both runtime and -devel) to still exist on the system at the same time, and programs can pick which one they want to use. Even more recently libvirt and netcf got patches to support building with libnl-3 rather than libnl-1.1 (preferring libnl-3 if both are available). Since development (and even bugfixes) of libnl-1.1 is basically dead, I want to switch over the F18 and later builds of libvirt to use libnl-3, but this will take careful timing (and some restrictions in the libvirt specfile) because attempting to run a libnl3-linked libvirt with a netcf.so that was linked with libnl-1.1 (or vice versa) results in a segv. Other than the basic use of a Requires: line in the libvirt specfile to make the newly-libnl3-enabled build of libvirt require a similarly-enabled build of netcf, does anyone have any recommendations on making this transition as painless as possible (and as soon as possible - I obviously want to do this before F18 is released).

1 0

[libvirt] [PATCHv2 0/3] split snapshot conf out of domain conf
by Eric Blake 24 Aug '12

24 Aug '12

Rebased version from v1 [1], only changes are catering to other changes in domain_conf in the meantime, and (temporarily) dropping the XML changes of the original patch 4 until I have code that can actually use the XML in 0.10.1. I'm hoping these three patches still qualify for 0.10.0. [1] https://www.redhat.com/archives/libvir-list/2012-August/msg01250.html Eric Blake (3): snapshot: make virDomainSnapshotObjList opaque snapshot: split snapshot conf code into own file snapshot: rename an enum po/POTFILES.in | 1 + src/Makefile.am | 3 +- src/conf/domain_conf.c | 933 +------------------------------------------- src/conf/domain_conf.h | 143 +------ src/conf/snapshot_conf.c | 972 ++++++++++++++++++++++++++++++++++++++++++++++ src/conf/snapshot_conf.h | 157 ++++++++ src/esx/esx_driver.c | 1 + src/libvirt_private.syms | 5 +- src/qemu/qemu_command.c | 1 + src/qemu/qemu_domain.c | 7 +- src/qemu/qemu_domain.h | 3 +- src/qemu/qemu_driver.c | 69 ++-- src/qemu/qemu_migration.c | 2 +- src/vbox/vbox_tmpl.c | 1 + 14 files changed, 1209 insertions(+), 1089 deletions(-) create mode 100644 src/conf/snapshot_conf.c create mode 100644 src/conf/snapshot_conf.h -- 1.7.11.4

2 10

[libvirt] [PATCH] xen-xs: fix uuid of renamed domain
by Philipp Hahn 24 Aug '12

24 Aug '12

When the XenStore tdb lives persistently and is not cleared between host reboots, Xend (version 3.4 and 4.1) re-creates the domain information located in XenStore below /vm/$UUID. (According to the xen-3.2-commit hg265950e3df69 to fix a problem when locally migrating a domain to the host itself.) When doing so a version number is added to the UUID separated by one dash, which confuses xenStoreDomainIntroduced(): It iterates over all domains and tries to lookup all inactive domains using xenStoreDomainGetUUID(), which fails if the running domain is renamed: virUUIDParse() fails to parse the versioned UUID and the domain is flagged as missing. When this happens the function delays .2s and re-tries 20 times again, multiplied by the number of renamed VMs. 14:48:38.878: 4285: debug : xenStoreDomainIntroduced:1354 : Some domains were missing, trying again This adds a significant delay: # time virsh list >/dev/null real 0m6.529s # xenstore-list /vm 00000000-0000-0000-0000-000000000000 00000000-0000-0000-0000-000000000000-1 00000000-0000-0000-0000-000000000000-2 00000000-0000-0000-0000-000000000000-3 00000000-0000-0000-0000-000000000000-4 00000000-0000-0000-0000-000000000000-5 7c06121e-90c3-93d4-0126-50481d485cca 00000000-0000-0000-0000-000000000000-6 00000000-0000-0000-0000-000000000000-7 144ad19d-dfb4-2f80-8045-09196bb8784f 00000000-0000-0000-0000-000000000000-8 144ad19d-dfb4-2f80-8045-09196bb8784f-1 00000000-0000-0000-0000-000000000000-9 00000000-0000-0000-0000-000000000000-10 00000000-0000-0000-0000-000000000000-11 00000000-0000-0000-0000-000000000000-12 00000000-0000-0000-0000-000000000000-13 00000000-0000-0000-0000-000000000000-14 144ad19d-dfb4-2f80-8045-09196bb8784f-2 00000000-0000-0000-0000-000000000000-15 144ad19d-dfb4-2f80-8045-09196bb8784f-3 00000000-0000-0000-0000-000000000000-16 The patch adds truncation of the UUID as read from the XenStore path before passing it to virUUIDParse(). The same issue is reported at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666135> Signed-off-by: Philipp Hahn <hahn(a)univention.de> --- src/xen/xs_internal.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/src/xen/xs_internal.c b/src/xen/xs_internal.c index e56d1a4..cdaef17 100644 --- a/src/xen/xs_internal.c +++ b/src/xen/xs_internal.c @@ -1115,8 +1115,11 @@ int xenStoreDomainGetUUID(virConnectPtr conn, snprintf(prop, 199, "/local/domain/%d/vm", id); prop[199] = 0; /* This will return something like - * /vm/00000000-0000-0000-0000-000000000000 */ + * /vm/00000000-0000-0000-0000-000000000000[-*] */ uuidstr = xs_read(priv->xshandle, 0, prop, &len); + /* Strip optional version suffix when VM was renamed */ + if (len > 40) /* strlen('/vm/') + VIR_UUID_STRING_BUFLEN - sizeof('\0') */ + uuidstr[40] = '\0'; /* remove "/vm/" */ ret = virUUIDParse(uuidstr + 4, uuid); -- 1.7.1

2 1

[libvirt] [PATCH 1/2] security: Add DAC to security_drivers
by Michal Privoznik 24 Aug '12

24 Aug '12

Currently, if users set 'security_driver="dac"' in qemu.conf libvirtd fails to initialize as DAC driver is not found because it is missing in our security drivers array. --- src/security/security_driver.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/security/security_driver.c b/src/security/security_driver.c index f450a94..e6da220 100644 --- a/src/security/security_driver.c +++ b/src/security/security_driver.c @@ -35,6 +35,7 @@ # include "security_apparmor.h" #endif +#include "security_dac.h" #include "security_nop.h" #define VIR_FROM_THIS VIR_FROM_SECURITY @@ -46,6 +47,7 @@ static virSecurityDriverPtr security_drivers[] = { #ifdef WITH_SECDRIVER_APPARMOR &virAppArmorSecurityDriver, #endif + &virSecurityDriverDAC, &virSecurityDriverNop, /* Must always be last, since it will always probe */ }; -- 1.7.8.6

2 4