- Devel - libvirt List Archives

[libvirt] [PATCH] util: storage: Fix crash of libvirtd on network backed guest block-pull
by Peter Krempa 29 May '14

29 May '14

For guests backed by gluster volumes (or other network storage) we don't fill the backing chain (see qemuDomainDetermineDiskChain). This leaves the "relPath" field of the top image NULL. This causes a crash in virStorageFileChainLookup() when looking up a backing element for such a disk. Since I'm working on adding support for network storage and one of the steps will make the "relPath" field optional let's use STREQ_NULLABLE instead of STREQ in virStorageFileChainLookup() to avoid the problem. --- src/util/virstoragefile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 2feda67..c9b6187 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -1591,7 +1591,7 @@ virStorageFileChainLookup(virStorageSourcePtr chain, if (idx == i) break; } else { - if (STREQ(name, chain->relPath)) + if (STREQ_NULLABLE(name, chain->relPath)) break; if (nameIsFile && (chain->type == VIR_STORAGE_TYPE_FILE || chain->type == VIR_STORAGE_TYPE_BLOCK)) { -- 1.9.3

2 2

[libvirt] [PATCH V2] virsh: forbid negative vcpu argument to vcpupin.
by Jincheng Miao 29 May '14

29 May '14

vcpupin will allow argument --vcpu as a signed number, and pass it to virDomainPinVcpu directlly without checking if this value is positive(valid). > virsh vcpupin r7 -1 0 error: numerical overflow: input too large: 4294967295 This message is inaccurate, and the negative vcpu is non-valuable. So forbid vcpu argument as a negative. After patching, the result likes: > virsh vcpupin r6 -1 error: vcpupin: Invalid vCPU number. > virsh vcpupin r6 --cpulist 0-1 error: vcpupin: Missing vCPU number in pin mode. > virsh vcpupin r6 --vcpu ABC error: vcpupin: Invalid vCPU number in query mode. Signed-off-by: Jincheng Miao <jmiao(a)redhat.com> --- tools/virsh-domain.c | 42 ++++++++++++++++++++++++------------------ 1 files changed, 24 insertions(+), 18 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 84a6706..e302459 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -5797,7 +5797,7 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) { virDomainInfo info; virDomainPtr dom; - int vcpu = -1; + unsigned int vcpu; const char *cpulist = NULL; bool ret = false; unsigned char *cpumap = NULL; @@ -5809,6 +5809,7 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) bool live = vshCommandOptBool(cmd, "live"); bool current = vshCommandOptBool(cmd, "current"); bool query = false; /* Query mode if no cpulist */ + int get_vcpu; unsigned int flags = VIR_DOMAIN_AFFECT_CURRENT; VSH_EXCLUSIVE_OPTIONS_VAR(current, live); @@ -5830,29 +5831,34 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) query = !cpulist; - /* In query mode, "vcpu" is optional */ - if (vshCommandOptInt(cmd, "vcpu", &vcpu) < !query) { - vshError(ctl, "%s", - _("vcpupin: Invalid or missing vCPU number.")); - virDomainFree(dom); - return false; - } - - if ((maxcpu = vshNodeGetCPUCount(ctl->conn)) < 0) { - virDomainFree(dom); - return false; + get_vcpu = vshCommandOptUInt(cmd, "vcpu", &vcpu); + if (get_vcpu <= 0) { + /* In query mode, "vcpu" is optional */ + if (query && get_vcpu < 0) { + vshError(ctl, "%s", + _("vcpupin: Invalid vCPU number in query mode.")); + goto cleanup; + } + /* In pin mode, "vcpu" is necessary */ + if (!query) { + vshError(ctl, "%s", + _("vcpupin: Missing vCPU number in pin mode.")); + goto cleanup; + } } if (virDomainGetInfo(dom, &info) != 0) { vshError(ctl, "%s", _("vcpupin: failed to get domain information.")); - virDomainFree(dom); - return false; + goto cleanup; } if (vcpu >= info.nrVirtCpu) { vshError(ctl, "%s", _("vcpupin: Invalid vCPU number.")); - virDomainFree(dom); - return false; + goto cleanup; + } + + if ((maxcpu = vshNodeGetCPUCount(ctl->conn)) < 0) { + goto cleanup; } cpumaplen = VIR_CPU_MAPLEN(maxcpu); @@ -5871,7 +5877,7 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) vshPrintExtra(ctl, "%s %s\n", _("VCPU:"), _("CPU Affinity")); vshPrintExtra(ctl, "----------------------------------\n"); for (i = 0; i < ncpus; i++) { - if (vcpu != -1 && i != vcpu) + if (get_vcpu > 0 && i != vcpu) continue; vshPrint(ctl, "%4zu: ", i); @@ -5880,8 +5886,8 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) if (!ret) break; } - } + VIR_FREE(cpumaps); goto cleanup; } -- 1.7.1

3 3

[libvirt] [PATCHv2] util: fix virTimeLocalOffsetFromUTC DST processing
by Laine Stump 29 May '14

29 May '14

The original version of virTimeLocalOffsetFromUTC() would fail for certain times of the day if daylight savings time was active. This could most easily be seen by uncommenting the TEST_LOCALOFFSET() cases that include a DST setting. After a lot of experimenting, I found that the way to solve it in almost all test cases is to set tm_isdst = -1 in the stuct tm prior to calling mktime(). Once this is done, the correct offset is returned for all test cases at all times except the two hours just after 00:00:00 Jan 1 UTC - during that time, any timezone that is *behind* UTC, and that is supposed to always be in DST will not have DST accounted for in its offset. I believe that the code of virTimeLocalOffsetFromUTC() is actually correct for all cases, but the problem still encountered is due to our inability to come up with a TZ string that properly forces DST to *always* be active. Since a modfication of the (currently fixed) expected result data to account for this would necessarily use the same functions that we're trying to test, I've instead just made the test program conditionally bypass the problematic cases if the current date is either December 31 or January 1. This way we get maximum testing during 363 days of the year, but don't get false failures on Dec 31 and Jan 1. --- Change from V1: correct typo in commit message pointed out by Eric, and also followed his suggestion to enable the sometimes-failing tests unless the current localtime is Jan 1 or Dec 31. src/util/virtime.c | 3 +++ tests/virtimetest.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++------- 2 files changed, 56 insertions(+), 8 deletions(-) diff --git a/src/util/virtime.c b/src/util/virtime.c index 3a56400..c69dff1 100644 --- a/src/util/virtime.c +++ b/src/util/virtime.c @@ -377,6 +377,9 @@ virTimeLocalOffsetFromUTC(long *offset) return -1; } + /* tell mktime to figure out itself whether or not DST is in effect */ + gmtimeinfo.tm_isdst = -1; + /* mktime() also obeys current timezone rules */ if ((utc = mktime(&gmtimeinfo)) == (time_t)-1) { virReportSystemError(errno, "%s", diff --git a/tests/virtimetest.c b/tests/virtimetest.c index bf27682..f378076 100644 --- a/tests/virtimetest.c +++ b/tests/virtimetest.c @@ -101,6 +101,28 @@ testTimeLocalOffset(const void *args) return 0; } + +/* return true if the date is Jan 1 or Dec 31 (localtime) */ +static bool +IsJan1OrDec31(void) +{ + time_t current = time(NULL); + struct tm timeinfo; + + if (current == (time_t)-1) { + VIR_DEBUG("time() failed"); + return false; + } + if (!localtime_r(&current, &timeinfo)) { + VIR_DEBUG("localtime_r() failed"); + return false; + } + + return (timeinfo.tm_mon == 0 && timeinfo.tm_mday == 1) || + (timeinfo.tm_mon == 11 && timeinfo.tm_mday == 31); +} + + static int mymain(void) { @@ -161,21 +183,44 @@ mymain(void) TEST_LOCALOFFSET("VIR00:30", -30 * 60); TEST_LOCALOFFSET("VIR01:30", -90 * 60); + TEST_LOCALOFFSET("VIR05:00", (-5 * 60) * 60); TEST_LOCALOFFSET("UTC", 0); TEST_LOCALOFFSET("VIR-00:30", 30 * 60); TEST_LOCALOFFSET("VIR-01:30", 90 * 60); -#if __TEST_DST + /* test DST processing with timezones that always * have DST in effect; what's more, cover a zone with * with an unusual DST different than a usual one hour */ - /* NB: These tests fail at certain times of the day, so - * must be disabled until we figure out why - */ - TEST_LOCALOFFSET("VIR-00:30VID,0,365", 90 * 60); - TEST_LOCALOFFSET("VIR-02:30VID,0,365", 210 * 60); - TEST_LOCALOFFSET("VIR-02:30VID-04:30,0,365", 270 * 60); -#endif + TEST_LOCALOFFSET("VIR-00:30VID,0/00:00:00,366/23:59:59", + ((1 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-02:30VID,0/00:00:00,366/23:59:59", + ((3 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-02:30VID-04:30,0/00:00:00,366/23:59:59", + ((4 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-12:00VID-13:00,0/00:00:00,366/23:59:59", + ((13 * 60) + 0) * 60); + + if (!IsJan1OrDec31()) { + /* experiments have shown that the following tests will fail + * during certain hours of Dec 31 or Jan 1 (depending on the + * TZ setting in the shell running the test, but in general + * for a period that apparently starts at 00:00:00 UTC Jan 1 + * and continues for 1 - 2 hours). We've determined this is + * due to our inability to specify a timezone with DST on/off + * settings that make it truly *always* on DST - i.e. it is a + * failing of the test data, *not* of the function we are + * testing. So to test as much as possible, we still run these + * tests, except on Dec 31 and Jan 1. + */ + + TEST_LOCALOFFSET("VIR02:45VID00:45,0/00:00:00,366/23:59:59", + -45 * 60); + TEST_LOCALOFFSET("VIR05:00VID04:00,0/00:00:00,366/23:59:59", + ((-4 * 60) + 0) * 60); + TEST_LOCALOFFSET("VIR11:00VID10:00,0/00:00:00,366/23:59:59", + ((-10 * 60) + 0) * 60); + } return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; } -- 1.9.3

2 2

[libvirt] [PATCH] Add capability to example AppArmor profile
by Steven Leung 29 May '14

29 May '14

I encountered an AppArmor denial in Ubuntu 14.04. I had filed a bug here https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1324251 I just wanted to see this applied upstream from Ubuntu. This update to the profile is necessary to write to 9pfs mounts. Let me know what you think about the following patch: diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index 83814ec..c80294c 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -9,6 +9,10 @@ capability dac_read_search, capability chown, + # to create and modify with 9p shares + capability fowner, + capability fsetid, + # needed to drop privileges capability setgid, capability setuid, I’m running on libvirt: 1.2.2 My host machine is: x86_64 The hypervisor is: KVM -- Steven

2 1

[libvirt] [patch v3 0/2] add support for migrateURI configuration
by Chen Fan 29 May '14

29 May '14

For now, we set the migration URI via command line '--migrate_uri' or construct the URI by looking up the dest host's hostname which could be solved by DNS automatically. But in cases the dest host have two or more NICs to reach, we may need to send the migration data over a specific NIC which is different from the automatically resloved one for some reason like performance, security, etc. thus we must explicitly specify the migrateuri in command line everytime, but it is too troublesome if there are many such hosts(and don't forget virt-manager). This patches add a configuration file option on dest host to save the default migrate uri which explicitly specify which of this host's addresses is used for transferring data, thus user doesn't boring to specify it in command line everytime. Any comments are welcome. Thank you very much. Chen Fan (2): Add support for migration URI configuration add inotify handler to qemu driver src/qemu/qemu.conf | 5 ++- src/qemu/qemu_conf.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_conf.h | 11 +++++- src/qemu/qemu_driver.c | 25 ++++++++++++- src/qemu/qemu_migration.c | 5 +++ 5 files changed, 132 insertions(+), 3 deletions(-) -- 1.8.1.4

4 10

[libvirt] [PATCH] virsh: fix typos in virsh man page
by Eric Blake 29 May '14

29 May '14

* tools/virsh.pod (attach-disk): Drop duplicate --config, fix typo in --sourcetype. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Puhsing under the trivial rule. tools/virsh.pod | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virsh.pod b/tools/virsh.pod index de9a4f7..02671b4 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -2046,7 +2046,7 @@ expected. =item B<attach-disk> I<domain> I<source> I<target> [[[I<--live>] [I<--config>] | [I<--current>]] | [I<--persistent>]] [I<--driver driver>] [I<--subdriver subdriver>] [I<--cache cache>] -[I<--type type>] [I<--mode mode>] [I<--config>] [I<--sourcetype soucetype>] +[I<--type type>] [I<--mode mode>] [I<--sourcetype sourcetype>] [I<--serial serial>] [I<--wwn wwn>] [I<--rawio>] [I<--address address>] [I<--multifunction>] [I<--print-xml>] -- 1.9.3

1 0

[libvirt] [PATCH] maint: cleanup detection of const'ness of selinux ctx
by Jim Fehlig 29 May '14

29 May '14

Commit 292d3f2d fixed the build with libselinux 2.3, but missed some suggestions by eblake https://www.redhat.com/archives/libvir-list/2014-May/msg00977.html This patch changes the macro introduced in 292d3f2d to either be empty in the case of newer libselinux, or contain 'const' in the case of older libselinux. The macro is then used directly in tests/securityselinuxhelper.c. --- m4/virt-selinux.m4 | 7 +++++-- tests/securityselinuxhelper.c | 24 ++++-------------------- 2 files changed, 9 insertions(+), 22 deletions(-) diff --git a/m4/virt-selinux.m4 b/m4/virt-selinux.m4 index 1d899d5..a6f89ba 100644 --- a/m4/virt-selinux.m4 +++ b/m4/virt-selinux.m4 @@ -39,8 +39,11 @@ int setcon(const security_context_t context); [gt_cv_setcon_param='security_context_t'], [gt_cv_setcon_param='const char*'])]) if test "$gt_cv_setcon_param" = 'const char*'; then - AC_DEFINE_UNQUOTED([SELINUX_CTX_CHAR_PTR], 1, - [SELinux uses newer char * for security context]) + AC_DEFINE([VIR_SELINUX_CTX_CONST], [const], + [SELinux uses newer const char * for security context]) + else + AC_DEFINE([VIR_SELINUX_CTX_CONST], [], + [SELinux uses newer const char * for security context]) fi AC_MSG_CHECKING([SELinux mount point]) diff --git a/tests/securityselinuxhelper.c b/tests/securityselinuxhelper.c index af4fae4..1252c15 100644 --- a/tests/securityselinuxhelper.c +++ b/tests/securityselinuxhelper.c @@ -156,11 +156,7 @@ int getpidcon(pid_t pid, security_context_t *context) return getpidcon_raw(pid, context); } -#ifdef SELINUX_CTX_CHAR_PTR -int setcon_raw(const char *context) -#else -int setcon_raw(security_context_t context) -#endif +int setcon_raw(VIR_SELINUX_CTX_CONST char *context) { if (!is_selinux_enabled()) { errno = EINVAL; @@ -169,21 +165,13 @@ int setcon_raw(security_context_t context) return setenv("FAKE_SELINUX_CONTEXT", context, 1); } -#ifdef SELINUX_CTX_CHAR_PTR -int setcon(const char *context) -#else -int setcon(security_context_t context) -#endif +int setcon(VIR_SELINUX_CTX_CONST char *context) { return setcon_raw(context); } -#ifdef SELINUX_CTX_CHAR_PTR -int setfilecon_raw(const char *path, const char *con) -#else -int setfilecon_raw(const char *path, security_context_t con) -#endif +int setfilecon_raw(const char *path, VIR_SELINUX_CTX_CONST char *con) { const char *constr = con; if (STRPREFIX(path, abs_builddir "/securityselinuxlabeldata/nfs/")) { @@ -194,11 +182,7 @@ int setfilecon_raw(const char *path, security_context_t con) constr, strlen(constr), 0); } -#ifdef SELINUX_CTX_CHAR_PTR -int setfilecon(const char *path, const char *con) -#else -int setfilecon(const char *path, security_context_t con) -#endif +int setfilecon(const char *path, VIR_SELINUX_CTX_CONST char *con) { return setfilecon_raw(path, con); } -- 1.7.9.2

2 2

[libvirt] [PATCH v3] PCI: Introduce new device binding path using pci_dev.driver_override
by Alex Williamson 29 May '14

29 May '14

The driver_override field allows us to specify the driver for a device rather than relying on the driver to provide a positive match of the device. This shortcuts the existing process of looking up the vendor and device ID, adding them to the driver new_id, binding the device, then removing the ID, but it also provides a couple advantages. First, the above existing process allows the driver to bind to any device matching the new_id for the window where it's enabled. This is often not desired, such as the case of trying to bind a single device to a meta driver like pci-stub or vfio-pci. Using driver_override we can do this deterministically using: echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers_probe Previously we could not invoke drivers_probe after adding a device to new_id for a driver as we get non-deterministic behavior whether the driver we intend or the standard driver will claim the device. Now it becomes a deterministic process, only the driver matching driver_override will probe the device. To return the device to the standard driver, we simply clear the driver_override and reprobe the device: echo > /sys/bus/pci/devices/0000:03:00.0/driver_override echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers_probe Another advantage to this approach is that we can specify a driver override to force a specific binding or prevent any binding. For instance when an IOMMU group is exposed to userspace through VFIO we require that all devices within that group are owned by VFIO. However, devices can be hot-added into an IOMMU group, in which case we want to prevent the device from binding to any driver (override driver = "none") or perhaps have it automatically bind to vfio-pci. With driver_override it's a simple matter for this field to be set internally when the device is first discovered to prevent driver matches. Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- v3: kfree() override buffer on device release, noted by Alex Graf v2: Use strchr() as suggested by Guenter Roeck and adopted by the platform driver version of this same interface. Documentation/ABI/testing/sysfs-bus-pci | 21 ++++++++++++++++ drivers/pci/pci-driver.c | 25 +++++++++++++++++-- drivers/pci/pci-sysfs.c | 40 +++++++++++++++++++++++++++++++ drivers/pci/probe.c | 1 + include/linux/pci.h | 1 + 5 files changed, 85 insertions(+), 3 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index a3c5a66..898ddc4 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -250,3 +250,24 @@ Description: valid. For example, writing a 2 to this file when sriov_numvfs is not 0 and not 2 already will return an error. Writing a 10 when the value of sriov_totalvfs is 8 will return an error. + +What: /sys/bus/pci/devices/.../driver_override +Date: April 2014 +Contact: Alex Williamson <alex.williamson(a)redhat.com> +Description: + This file allows the driver for a device to be specified which + will override standard static and dynamic ID matching. When + specified, only a driver with a name matching the value written + to driver_override will have an opportunity to bind to the + device. The override is specified by writing a string to the + driver_override file (echo pci-stub > driver_override) and + may be cleared with an empty string (echo > driver_override). + This returns the device to standard matching rules binding. + Writing to driver_override does not automatically unbind the + device from its current driver or make any attempt to + automatically load the specified driver. If no driver with a + matching name is currently loaded in the kernel, the device + will not bind to any driver. This also allows devices to + opt-out of driver binding using a driver_override name such as + "none". Only a single driver may be specified in the override, + there is no support for parsing delimiters. diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index d911e0c..4393c12 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -216,6 +216,13 @@ const struct pci_device_id *pci_match_id(const struct pci_device_id *ids, return NULL; } +static const struct pci_device_id pci_device_id_any = { + .vendor = PCI_ANY_ID, + .device = PCI_ANY_ID, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, +}; + /** * pci_match_device - Tell if a PCI device structure has a matching PCI device id structure * @drv: the PCI driver to match against @@ -229,18 +236,30 @@ static const struct pci_device_id *pci_match_device(struct pci_driver *drv, struct pci_dev *dev) { struct pci_dynid *dynid; + const struct pci_device_id *found_id = NULL; + + /* When driver_override is set, only bind to the matching driver */ + if (dev->driver_override && strcmp(dev->driver_override, drv->name)) + return NULL; /* Look at the dynamic ids first, before the static ones */ spin_lock(&drv->dynids.lock); list_for_each_entry(dynid, &drv->dynids.list, node) { if (pci_match_one_device(&dynid->id, dev)) { - spin_unlock(&drv->dynids.lock); - return &dynid->id; + found_id = &dynid->id; + break; } } spin_unlock(&drv->dynids.lock); - return pci_match_id(drv->id_table, dev); + if (!found_id) + found_id = pci_match_id(drv->id_table, dev); + + /* driver_override will always match, send a dummy id */ + if (!found_id && dev->driver_override) + found_id = &pci_device_id_any; + + return found_id; } struct drv_dev_and_id { diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index 4e0acef..faa4ab5 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -499,6 +499,45 @@ static struct device_attribute sriov_numvfs_attr = sriov_numvfs_show, sriov_numvfs_store); #endif /* CONFIG_PCI_IOV */ +static ssize_t driver_override_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + struct pci_dev *pdev = to_pci_dev(dev); + char *driver_override, *old = pdev->driver_override, *cp; + + if (count > PATH_MAX) + return -EINVAL; + + driver_override = kstrndup(buf, count, GFP_KERNEL); + if (!driver_override) + return -ENOMEM; + + cp = strchr(driver_override, '\n'); + if (cp) + *cp = '\0'; + + if (strlen(driver_override)) { + pdev->driver_override = driver_override; + } else { + kfree(driver_override); + pdev->driver_override = NULL; + } + + kfree(old); + + return count; +} + +static ssize_t driver_override_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct pci_dev *pdev = to_pci_dev(dev); + + return sprintf(buf, "%s\n", pdev->driver_override); +} +static DEVICE_ATTR_RW(driver_override); + static struct attribute *pci_dev_attrs[] = { &dev_attr_resource.attr, &dev_attr_vendor.attr, @@ -521,6 +560,7 @@ static struct attribute *pci_dev_attrs[] = { #if defined(CONFIG_PM_RUNTIME) && defined(CONFIG_ACPI) &dev_attr_d3cold_allowed.attr, #endif + &dev_attr_driver_override.attr, NULL, }; diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index ef09f5f..54268de 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1215,6 +1215,7 @@ static void pci_release_dev(struct device *dev) pci_release_of_node(pci_dev); pcibios_release_device(pci_dev); pci_bus_put(pci_dev->bus); + kfree(pci_dev->driver_override); kfree(pci_dev); } diff --git a/include/linux/pci.h b/include/linux/pci.h index aab57b4..b72af27 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -365,6 +365,7 @@ struct pci_dev { #endif phys_addr_t rom; /* Physical address of ROM if it's not from the BAR */ size_t romlen; /* Length of ROM if it's not from the BAR */ + char *driver_override; /* Driver name to force a match */ }; static inline struct pci_dev *pci_physfn(struct pci_dev *dev)

5 6

[libvirt] [PATCH v2] build: fix build with libselinux 2.3
by Cédric Bosdonnat 28 May '14

28 May '14

Several function signatures changed in libselinux 2.3, now taking a 'const char *' instead of 'security_context_t'. The latter is defined in selinux/selinux.h as typedef char *security_context_t; --- m4/virt-selinux.m4 | 18 ++++++++++++++++++ tests/securityselinuxhelper.c | 16 ++++++++++++++++ 2 files changed, 34 insertions(+) diff --git a/m4/virt-selinux.m4 b/m4/virt-selinux.m4 index 003c2a8..c299793 100644 --- a/m4/virt-selinux.m4 +++ b/m4/virt-selinux.m4 @@ -28,6 +28,24 @@ AC_DEFUN([LIBVIRT_CHECK_SELINUX],[ [with_selinux_mount=check]) if test "$with_selinux" = "yes"; then + AC_CACHE_CHECK([for selinux setcon parameter type], [gt_cv_setcon_param], + [AC_COMPILE_IFELSE( + [AC_LANG_PROGRAM( + [[ +#include <selinux/selinux.h> + +int setcon(const security_context_t context) { + return 0; +} + ]], + [[]])], + [gt_cv_setcon_param='security_context'], + [gt_cv_setcon_param='const char*'])]) + if test "$gt_cv_setcon_param" = 'const char*'; then + AC_DEFINE_UNQUOTED([SELINUX_CTX_CHAR_PTR], 1, + [SELinux uses char * for security context]) + fi + AC_MSG_CHECKING([SELinux mount point]) if test "$with_selinux_mount" = "check" || test -z "$with_selinux_mount"; then if test -d /sys/fs/selinux ; then diff --git a/tests/securityselinuxhelper.c b/tests/securityselinuxhelper.c index dbc4c29..af4fae4 100644 --- a/tests/securityselinuxhelper.c +++ b/tests/securityselinuxhelper.c @@ -156,7 +156,11 @@ int getpidcon(pid_t pid, security_context_t *context) return getpidcon_raw(pid, context); } +#ifdef SELINUX_CTX_CHAR_PTR +int setcon_raw(const char *context) +#else int setcon_raw(security_context_t context) +#endif { if (!is_selinux_enabled()) { errno = EINVAL; @@ -165,13 +169,21 @@ int setcon_raw(security_context_t context) return setenv("FAKE_SELINUX_CONTEXT", context, 1); } +#ifdef SELINUX_CTX_CHAR_PTR +int setcon(const char *context) +#else int setcon(security_context_t context) +#endif { return setcon_raw(context); } +#ifdef SELINUX_CTX_CHAR_PTR +int setfilecon_raw(const char *path, const char *con) +#else int setfilecon_raw(const char *path, security_context_t con) +#endif { const char *constr = con; if (STRPREFIX(path, abs_builddir "/securityselinuxlabeldata/nfs/")) { @@ -182,7 +194,11 @@ int setfilecon_raw(const char *path, security_context_t con) constr, strlen(constr), 0); } +#ifdef SELINUX_CTX_CHAR_PTR +int setfilecon(const char *path, const char *con) +#else int setfilecon(const char *path, security_context_t con) +#endif { return setfilecon_raw(path, con); } -- 1.8.4.5

3 4

[libvirt] [PATCH] Managed-Save: False warning on successful managed save restoration
by Jason J. Herne 28 May '14

28 May '14

From: "Jason J. Herne" <jjherne(a)us.ibm.com> qemuDomainObjStart is checking the return code from qemuDomainObjRestore for errors even after determining that the return code is 0. This causes the following error message to appear even when the restore was successful. Unable to restore from managed state [path]. Maybe the file is corrupted? A simple conditional to handle the error case takes care of the problem. Signed-off-by: Jason J. Herne <jjherne(a)us.ibm.com> --- src/qemu/qemu_driver.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2b852eb..cec2b6c 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -6081,14 +6081,15 @@ qemuDomainObjStart(virConnectPtr conn, else vm->hasManagedSave = false; } - - if (ret > 0) { - VIR_WARN("Ignoring incomplete managed state %s", managed_save); - } else { - VIR_WARN("Unable to restore from managed state %s. " - "Maybe the file is corrupted?", managed_save); - goto cleanup; + else { + if (ret > 0) { + VIR_WARN("Ignoring incomplete managed state %s", managed_save); + } else { + VIR_WARN("Unable to restore from managed state %s. " + "Maybe the file is corrupted?", managed_save); + } } + goto cleanup; } } -- 1.8.3.2

3 5

[libvirt] [PATCH] qemu: managedsave: Don't spam logs with warnings about corrupted image
by Peter Krempa 28 May '14

28 May '14

Even successful start of a VM from a managed save image would spam the logs with the following message: Unable to restore from managed state [path]. Maybe the file is corrupted? Re-arrange the logic to output the warning only when the image is corrupted. The flaw was introduced in commit cfc28c66. --- src/qemu/qemu_driver.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2b852eb..7a29b82 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -6080,14 +6080,14 @@ qemuDomainObjStart(virConnectPtr conn, VIR_WARN("Failed to remove the managed state %s", managed_save); else vm->hasManagedSave = false; - } - if (ret > 0) { - VIR_WARN("Ignoring incomplete managed state %s", managed_save); - } else { + goto cleanup; + } else if (ret < 0) { VIR_WARN("Unable to restore from managed state %s. " "Maybe the file is corrupted?", managed_save); goto cleanup; + } else { + VIR_WARN("Ignoring incomplete managed state %s", managed_save); } } } -- 1.9.3

2 2

[libvirt] [PATCH 0/3] Fix startup of gluster pools
by Peter Krempa 28 May '14

28 May '14

Currently a gluster pool fails to start due to an attempt to canonicalize a path residing on gluster storage. This series rearranges things to avoid that. Peter Krempa (3): storage: Return backing format from virStorageFileGetMetadataFromFD storage: fs: Drop-in replace use of virStorageFileGetMetadataFromBuf utils: storage: Canonicalize paths only for local filesystems src/qemu/qemu_driver.c | 2 +- src/storage/storage_backend_fs.c | 20 +++++++------------- src/util/virstoragefile.c | 27 +++++++++++++++------------ src/util/virstoragefile.h | 3 ++- 4 files changed, 25 insertions(+), 27 deletions(-) -- 1.9.3

2 7

[libvirt] [PATCH] qemu: reject rather than hang on blockcommit of active layer
by Eric Blake 28 May '14

28 May '14

qemu 2.0 added the ability to commit the active layer, but slightly differently than what libvirt had been anticipating in its implementation of the virDomainBlockCommit call. As a result, if you attempt to do a 'virsh blockcommit $dom vda', qemu gets into a state where it is waiting on libvirt to end the job, while libvirt is waiting on qemu to end the job, and the guest is effectively hung with regards to further commands for that block device. I have patches coming down the pipeline that will add full support for blockcommit of the active layer when coupled with qemu 2.0 or later; but they depend on Peter's improvements to block job handling and form enough of a new feature that they are not ready for inclusion in the 1.2.5 release. So for now, just reject the attempt, rather than letting the user get stuck. This is no worse than the behavior of qemu 1.7 rejecting the job. * src/qemu/qemu_driver.c (qemuDomainBlockCommit): Reject active commit. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- This patch should be committed before the 1.2.5 release, while I continue to polish my full series for active commit support for inclusion after the release. src/qemu/qemu_driver.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2b852eb..f008763 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -15461,6 +15461,15 @@ qemuDomainBlockCommit(virDomainPtr dom, &top_parent))) goto endjob; + /* FIXME: qemu 2.0 supports active commit, but as a two-stage + * process; qemu 2.1 is further improving active commit. We need + * to start support it in libvirt. */ + if (topSource == &disk->src) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("committing the active layer not supported yet")); + goto endjob; + } + if (!topSource->backingStore) { virReportError(VIR_ERR_INVALID_ARG, _("top '%s' in chain for '%s' has no backing file"), -- 1.9.3

2 2

[libvirt] xl and libvirt.
by Alvin Starr 28 May '14

28 May '14

I have been trying do some simulations of an openstack environment on my workstation that is running xen and libvirt. I managed to create nested HVM environments under lx but found a number of shortfalls in libxl code. I have added a nestedhvm as a domain feature and was looking at inspecting the domain configuration when I realized that the persistant data is keept in config files in /var/lib/xen/userdata..... Libvirt and lx have incompatible file names and are using different config formats. Libvirt keeps the data as XML and xl keeps them as xm config files. This means that libvirt domains cannot be manged with xl or xl domains managed by libvirt. Part of me thinks that sticking with the XL file format would be nice from the point of view of being able to use xenlight tools once the domain is configured. At the very least it may make sense to keep an XL copy of the config file in a format that xenlight can use. To achieve my original goal of managing a nested HVM environment from libvirt I need to get the CPUID flags working but I do believe that it would be nice to have the various xen and libvirt tools being able to talk to each other. Any pearls of wisdom would be greatly appreciated. -- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin(a)netvel.net ||

3 6

[libvirt] Call for agenda for weekly meeting May 29th, 2014
by Daniel P. Berrange 28 May '14

28 May '14

Hi Folks, Tomorrow (thursday) at 1400 UTC is set for our next weekly meeting on #virt-meeting of irc.oftc.net If you have any agenda items to raise please add them to: https://public.pad.fsfe.org/p/libvirt-community-meeting NB, I will likely be offline tomorrow at the Xen Community Hackathon, so if any agenda items are added, I'll trust that someone else here will chair the meeting the meeting instead.... Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 0

[libvirt] [PATCH 0/5] [RFC] Add support for per-guest-node binding
by Martin Kletzander 28 May '14

28 May '14

Currently we are only able to bind the whole domain to some host nodes using the /domain/numatune/memory element. Numerous requests were made to support host<->guest numa node bindings, so this series tries to pinch an idea on how to do that using /domain/numatune/memnode elements. So here are few ideas I'd like to know others opinions on: For some reason, qemu wants to know what host nodes it can use to for allocation of the memory. While adding support for that, qemu added various memory objects (-object memory*) with different backends. There's 'memory-file' which is used for hugepages and 'memory-ram' which is used for standard allocation. Latest version of the qemu proposal is here: http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg02706.html Caveats: - I'm not sure how cpu hotplug is done with guest numa nodes, but if there is a possibility to increase the number of numa nodes (which does not make sense to me from (a) user point of view and (b) our XMLs and APIs), we need to be able to hotplug the ram as well, - virDomainGetNumaParameters() now reflects only the /domain/numatune/memory settings, not 'memnode' ones, - virDomainSetNumaParameters() is not allowed when there is some /domain/numatune/memnode parameter as we can query memdev info, but not change it (if I understood the QEMU side correctly), - when domain is started, cpuset.mems cgroup is not modified per for each vcpu, this will be fixed, but the question is how to handle it for non-strict settings [*], - automatic numad placement can be now used together with memnode settings which IMHO doesn't make any sense, but I was hesitant to disable that in case somebody has a constructive criticism in this area. - This series alone is broken when used with /domain/memoryBacking/hugepages, because it will still use the memory-ram object, but that will be fixed with Michal's patches on top of this series. One idea how to solve some of the problems is to say that /domain/numatune/memory is set for the whole domain regardless of what anyone puts in /domain/numatune/memnode. virDomainGetNumaParameters() could be extended to tell the info for all guest numa nodes, although it seems new API would suit better for this kind of information. But is it really neede when we are not able to modify it live and the information is available in the domain XML? *) does (or should) this: ... <numatune> <memory mode='strict' placement='static' nodeset='0-7'/> <memnode nodeid='0' mode='preferred' nodeset='7'/> </numatune> ... mean what it looks like it means, that is "in guest node 0, prefer allocating from host node 7 but feel free to allocate from 0-6 as well in case you can't use 7, but never try allocating from host nodes 8-15"? Martin Kletzander (5): conf, schema: add 'id' field for cells conf, schema: add support for numatune memnode element qemu: purely a code movement qemu: numa capability probing qemu: pass numa node binding preferences to qemu docs/formatdomain.html.in | 29 +++- docs/schemas/domaincommon.rng | 22 +++ src/conf/cpu_conf.c | 39 ++++- src/conf/domain_conf.c | 181 +++++++++++++++++---- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 160 ++++++++++++++++-- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_domain.c | 23 ++- src/qemu/qemu_driver.c | 14 +- src/qemu/qemu_process.c | 3 +- src/util/virnuma.h | 14 +- tests/qemuxml2argvdata/qemuxml2argv-cpu-numa1.xml | 6 +- tests/qemuxml2argvdata/qemuxml2argv-cpu-numa2.xml | 6 +- tests/qemuxml2argvdata/qemuxml2argv-cpu-numa3.xml | 25 +++ .../qemuxml2argv-numatune-auto-prefer.args | 6 + .../qemuxml2argv-numatune-auto-prefer.xml | 29 ++++ .../qemuxml2argv-numatune-auto.args | 6 + .../qemuxml2argv-numatune-auto.xml | 26 +++ .../qemuxml2argv-numatune-memnode-nocpu.xml | 25 +++ .../qemuxml2argv-numatune-memnodes-problematic.xml | 31 ++++ .../qemuxml2argv-numatune-memnodes.args | 8 + .../qemuxml2argv-numatune-memnodes.xml | 31 ++++ .../qemuxml2argv-numatune-prefer.args | 6 + .../qemuxml2argv-numatune-prefer.xml | 29 ++++ tests/qemuxml2argvtest.c | 51 ++++-- .../qemuxml2xmlout-cpu-numa1.xml | 28 ++++ .../qemuxml2xmlout-cpu-numa2.xml | 28 ++++ tests/qemuxml2xmltest.c | 4 + tests/qemuxmlnstest.c | 2 +- 31 files changed, 747 insertions(+), 93 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-numa3.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto-prefer.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto-prefer.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-auto.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnode-nocpu.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnodes-problematic.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnodes.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-memnodes.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-prefer.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-numatune-prefer.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-numa1.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-numa2.xml -- 1.9.3

2 10

[libvirt] [PATCH] doc: fix documentation of virDomainSet(Get)Metadata
by Dan Kenigsberg 28 May '14

28 May '14

The documentation of the functions should match the argument name in the actual function signature. Signed-off-by: Dan Kenigsberg <danken(a)redhat.com> --- src/libvirt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 72a9f6d..f01b6dd 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -10109,14 +10109,14 @@ virDomainGetSecurityLabelList(virDomainPtr domain, /** * virDomainSetMetadata: * @domain: a domain object - * @type: type of description, from virDomainMetadataType + * @type: type of metadata, from virDomainMetadataType * @metadata: new metadata text * @key: XML namespace key, or NULL * @uri: XML namespace URI, or NULL * @flags: bitwise-OR of virDomainModificationImpact * * Sets the appropriate domain element given by @type to the - * value of @description. A @type of VIR_DOMAIN_METADATA_DESCRIPTION + * value of @metadata. A @type of VIR_DOMAIN_METADATA_DESCRIPTION * is free-form text; VIR_DOMAIN_METADATA_TITLE is free-form, but no * newlines are permitted, and should be short (although the length is * not enforced). For these two options @key and @uri are irrelevant and @@ -10202,7 +10202,7 @@ virDomainSetMetadata(virDomainPtr domain, /** * virDomainGetMetadata: * @domain: a domain object - * @type: type of description, from virDomainMetadataType + * @type: type of metadata, from virDomainMetadataType * @uri: XML namespace identifier * @flags: bitwise-OR of virDomainModificationImpact * -- 1.9.3

2 1

[libvirt] [PATCH] virsh: forbid negative vcpu argument to vcpupin.
by Jincheng Miao 28 May '14

28 May '14

vcpupin will allow argument --vcpu as a signed number, and pass it to virDomainPinVcpu directlly without checking if this value is positive(valid). > virsh vcpupin r7 -1 0 error: numerical overflow: input too large: 4294967295 This message is inaccurate, and the negative vcpu is non-valuable. So forbid vcpu argument as a negative. Signed-off-by: Jincheng Miao <jmiao(a)redhat.com> --- tools/virsh-domain.c | 24 ++++++++++-------------- 1 files changed, 10 insertions(+), 14 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 84a6706..d9804cc 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -5797,7 +5797,7 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) { virDomainInfo info; virDomainPtr dom; - int vcpu = -1; + unsigned int vcpu; const char *cpulist = NULL; bool ret = false; unsigned char *cpumap = NULL; @@ -5830,29 +5830,25 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd) query = !cpulist; - /* In query mode, "vcpu" is optional */ - if (vshCommandOptInt(cmd, "vcpu", &vcpu) < !query) { + /* In query mode, "vcpu" is optional*/ + if (vshCommandOptUInt(cmd, "vcpu", &vcpu) < !query) { vshError(ctl, "%s", _("vcpupin: Invalid or missing vCPU number.")); - virDomainFree(dom); - return false; - } - - if ((maxcpu = vshNodeGetCPUCount(ctl->conn)) < 0) { - virDomainFree(dom); - return false; + goto cleanup; } if (virDomainGetInfo(dom, &info) != 0) { vshError(ctl, "%s", _("vcpupin: failed to get domain information.")); - virDomainFree(dom); - return false; + goto cleanup; } if (vcpu >= info.nrVirtCpu) { vshError(ctl, "%s", _("vcpupin: Invalid vCPU number.")); - virDomainFree(dom); - return false; + goto cleanup; + } + + if ((maxcpu = vshNodeGetCPUCount(ctl->conn)) < 0) { + goto cleanup; } cpumaplen = VIR_CPU_MAPLEN(maxcpu); -- 1.7.1

2 1

[libvirt] [PATCHv2 00/33] Gluster backing chains and relative block commit/pull
by Peter Krempa 28 May '14

28 May '14

Hi, this is my second take on this topic. Some of the patches are still in a RFC status as the last six patches require qemu support which is still on review upstream. The rest should be fine as is even without the qemu bits. Peter Krempa (33): qemu: process: Refresh backing chain info when reconnecting to qemu qemu: Make qemuDomainPrepareDiskChainElement aware of remote storage storage: Store gluster volume name separately storage: Rework debugging of storage file access through storage driver conf: Fix domain disk path iterator to work with networked storage storage: Add NONE protocol type for network disks storage: Add support for access to files using provided uid/gid storage: Add storage file API to read file headers storage: backend: Add unique id retrieval API storage: Add API to check accessibility of storage volumes storage: Move virStorageFileGetMetadata to the storage driver storage: Determine the local storage type right away test: storage: Initialize storage source to correct type storage: backend: Add possibility to suppress errors from backend lookup storage: Switch metadata crawler to use storage driver to get unique path storage: Switch metadata crawler to use storage driver to read headers storage: Switch metadata crawler to use storage driver file access check storage: Add infrastructure to parse remote network backing names storage: Change to new backing store parser storage: Traverse backing chains of network disks util: string: Return element count from virStringSplit util: string: Add helper to free non-NULL terminated string arrays util: storagefile: Add helper to resolve "../", "./" and "////" in paths util: storage: Add helper to resolve relative path difference util: storagefile: Add canonicalization to virStorageFileSimplifyPath storage: gluster: Add backend to return unique storage file path qemu: json: Add format strings for optional command arguments qemu: monitor: Add argument for specifying backing name for block commit qemu: monitor: Add support for backing name specification for block-stream lib: Introduce flag VIR_DOMAIN_BLOCK_COMMIT_RELATIVE lib: Introduce flag VIR_DOMAIN_BLOCK_REBASE_RELATIVE qemu: Add support for networked disks for block commit qemu: Add support for networked disks for block pull/block rebase cfg.mk | 2 +- include/libvirt/libvirt.h.in | 6 + src/Makefile.am | 2 + src/conf/domain_conf.c | 72 ++- src/libvirt_private.syms | 7 +- src/qemu/qemu_capabilities.c | 8 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 24 +- src/qemu/qemu_domain.c | 10 +- src/qemu/qemu_driver.c | 160 +++++-- src/qemu/qemu_migration.c | 6 +- src/qemu/qemu_monitor.c | 21 +- src/qemu/qemu_monitor.h | 4 +- src/qemu/qemu_monitor_json.c | 139 ++++-- src/qemu/qemu_monitor_json.h | 2 + src/qemu/qemu_process.c | 5 + src/security/virt-aa-helper.c | 2 + src/storage/storage_backend.c | 16 +- src/storage/storage_backend.h | 22 +- src/storage/storage_backend_fs.c | 127 +++++- src/storage/storage_backend_gluster.c | 203 +++++++-- src/storage/storage_driver.c | 329 +++++++++++++- src/storage/storage_driver.h | 15 +- src/util/virstoragefile.c | 818 ++++++++++++++++++++++++---------- src/util/virstoragefile.h | 31 +- src/util/virstring.c | 44 +- src/util/virstring.h | 7 + tests/Makefile.am | 7 +- tests/qemumonitorjsontest.c | 2 +- tests/virstoragetest.c | 290 +++++++++++- tools/virsh-domain.c | 29 +- 31 files changed, 1988 insertions(+), 424 deletions(-) -- 1.9.3

2 59

[libvirt] [bug] python-libvirt vcpus mismatch
by Chris Friesen 28 May '14

28 May '14

I've got a libvirt-created instance where I've been messing with affinity, and now something is strange. I did the following in python: >>> import libvirt >>> conn=libvirt.open("qemu:///system") >>> dom = conn.lookupByName('instance-00000027') >>> dom.vcpus() ([(0, 1, 528150000000L, 2), (1, 1, 548070000000L, 3)], [(False, False, True, False), (False, False, True, False)]) I'm totally confused by that "3". It's supposed to represent the physical cpu that virtual cpu 1 is running on. But cpu 3 isn't even in the allowable affinity map for vcpu 1. If I query the data other ways, I get both cpus running on physical cpu 2: root@compute-0:~# virsh vcpupin instance-00000027 VCPU: CPU Affinity ---------------------------------- 0: 2 1: 2 root@compute-0:~# virsh emulatorpin instance-00000027 emulator: CPU Affinity ---------------------------------- *: 2 root@compute-0:~# taskset -pac 15072 pid 15072's current affinity list: 2 pid 15073's current affinity list: 1-3 pid 15075's current affinity list: 2 pid 15076's current affinity list: 0 So I'm left with the conclusion that there is something strange going on with libvirt-python. Anyone got any ideas? Chris

2 1

[libvirt] [PATCH RFC] build: fix build with libselinux 2.3
by Jim Fehlig 28 May '14

28 May '14

The attached patch is an attempt to fix recent build failures I've noticed with libselinux 2.3 CC securityselinuxhelper.lo securityselinuxhelper.c:159:5: error: conflicting types for 'setcon_raw' int setcon_raw(security_context_t context) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:41:12: note: previous declaration of 'setcon_raw' was here extern int setcon_raw(const char * con); ^ securityselinuxhelper.c:168:5: error: conflicting types for 'setcon' int setcon(security_context_t context) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:40:12: note: previous declaration of 'setcon' was here extern int setcon(const char * con); ^ securityselinuxhelper.c:174:5: error: conflicting types for 'setfilecon_raw' int setfilecon_raw(const char *path, security_context_t con) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:110:12: note: previous declaration of 'setfilecon_raw' was here extern int setfilecon_raw(const char *path, const char * con); ^ securityselinuxhelper.c:185:5: error: conflicting types for 'setfilecon' int setfilecon(const char *path, security_context_t con) ^ In file included from securityselinuxhelper.c:30:0: /usr/include/selinux/selinux.h:109:12: note: previous declaration of 'setfilecon' was here extern int setfilecon(const char *path, const char * con); ^ Noticing that security_context_t changed to 'const char *', my first thought was to use AC_CHECK_TYPE to check for security_conext_t, but alas the typedef remains in 2.3 with the comment "No longer used; here for compatibility with legacy callers". I then pursued the approach in this patch of defining a config var based on 'pkg-config --modversion', which works in a test script, but not in the context of the LIBVIRT_CHECK_SELINUX macro. Probably due to some missed quoting, but I'm reaching the m4 knowledge barrier. Before attempting to bypass that, I'd like to see what others think of this approach. Is there a simpler solution? Regards, Jim

2 2

[libvirt] [PATCH] util: fix virTimeLocalOffsetFromUTC DST processing
by Laine Stump 27 May '14

27 May '14

The original version of virTimeLocalOffsetFromUTC() (commit 1cddaea7aeca441b733c31990a3f139dd2d346f6) would fail for certain times of the day if daylight savings time was active. This could most easily be seen by uncommenting the TEST_LOCALOFFSET() cases that invlude a DST setting. After a lot of experimenting, I found that the way to solve it in almost all test cases is to set tm_isdst = -1 in the stuct tm prior to calling mktime(). Once this is done, the correct offset is returned for all test cases at all times except the two hours just after 00:00:00 Jan 1 UTC - during that time, any timezone that is *behind* UTC, and that is supposed to always be in DST will not have DST accounted for in its offset. I still do not know the source of this problem, but it appears to be either a bug in glibc, or my improper specification of a TZ setting, so I am leaving the offending tests listed in virtimetest.c, but disabling them for now. --- See https://www.redhat.com/archives/libvir-list/2014-May/msg00898.html for my earlier comments on this problem. src/util/virtime.c | 3 +++ tests/virtimetest.c | 24 +++++++++++++++++------- 2 files changed, 20 insertions(+), 7 deletions(-) diff --git a/src/util/virtime.c b/src/util/virtime.c index 3a56400..c69dff1 100644 --- a/src/util/virtime.c +++ b/src/util/virtime.c @@ -377,6 +377,9 @@ virTimeLocalOffsetFromUTC(long *offset) return -1; } + /* tell mktime to figure out itself whether or not DST is in effect */ + gmtimeinfo.tm_isdst = -1; + /* mktime() also obeys current timezone rules */ if ((utc = mktime(&gmtimeinfo)) == (time_t)-1) { virReportSystemError(errno, "%s", diff --git a/tests/virtimetest.c b/tests/virtimetest.c index bf27682..35551ea 100644 --- a/tests/virtimetest.c +++ b/tests/virtimetest.c @@ -161,20 +161,30 @@ mymain(void) TEST_LOCALOFFSET("VIR00:30", -30 * 60); TEST_LOCALOFFSET("VIR01:30", -90 * 60); + TEST_LOCALOFFSET("VIR05:00", (-5 * 60) * 60); TEST_LOCALOFFSET("UTC", 0); TEST_LOCALOFFSET("VIR-00:30", 30 * 60); TEST_LOCALOFFSET("VIR-01:30", 90 * 60); -#if __TEST_DST + /* test DST processing with timezones that always * have DST in effect; what's more, cover a zone with * with an unusual DST different than a usual one hour */ - /* NB: These tests fail at certain times of the day, so - * must be disabled until we figure out why - */ - TEST_LOCALOFFSET("VIR-00:30VID,0,365", 90 * 60); - TEST_LOCALOFFSET("VIR-02:30VID,0,365", 210 * 60); - TEST_LOCALOFFSET("VIR-02:30VID-04:30,0,365", 270 * 60); + TEST_LOCALOFFSET("VIR-00:30VID,0/00:00:00,366/23:59:59", + ((1 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-02:30VID,0/00:00:00,366/23:59:59", + ((3 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-02:30VID-04:30,0/00:00:00,366/23:59:59", + ((4 * 60) + 30) * 60); + TEST_LOCALOFFSET("VIR-12:00VID-13:00,0/00:00:00,366/23:59:59", + ((13 * 60) + 0) * 60); +#ifdef __BROKEN_DST_TESTS + TEST_LOCALOFFSET("VIR02:45VID00:45,0/00:00:00,366/23:59:59", + -45 * 60); + TEST_LOCALOFFSET("VIR05:00VID04:00,0/00:00:00,366/23:59:59", + ((-4 * 60) + 0) * 60); + TEST_LOCALOFFSET("VIR11:00VID10:00,0/00:00:00,366/23:59:59", + ((-10 * 60) + 0) * 60); #endif return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; -- 1.9.3

2 2

[libvirt] Python setBlkioParameters function broken
by Qiang Guan 27 May '14

27 May '14

I've tried to use domain.setBlkioParameters with ipython, and I'm finding it's throwing the mysterious error: ubuntu@host-192-168-0-7:~$ dpkg -l | grep libvirt ii libvirt-bin 1.2.2-0ubuntu13.1 amd64 programs for the libvirt library ii libvirt0 1.2.2-0ubuntu13.1 amd64 library for interfacing with different virtualization systems ii python-libvirt 1.2.2-0ubuntu1 amd64 libvirt Python bindings ubuntu@host-192-168-0-7:~$ sudo ipython ...... In [85]: doms[0] Out[85]: <libvirt.virDomain at 0x7fe688879250> In [86]: params Out[86]: {'weight': 250} In [87]: doms[0].setBlkioParameters(params, 0) libvirt: error : argument unsupported: parameter '' not supported --------------------------------------------------------------------------- libvirtError Traceback (most recent call last) <ipython-input-87-026c35502a5c> in <module>() ----> 1 doms[0].setBlkioParameters(params, 0) /usr/lib/python2.7/dist-packages/libvirt.pyc in setBlkioParameters(self, params, flags) 1961 """Change the blkio tunables """ 1962 ret = libvirtmod.virDomainSetBlkioParameters(self._o, params, flags) -> 1963 if ret == -1: raise libvirtError ('virDomainSetBlkioParameters() failed', dom=self) 1964 return ret 1965 libvirtError: argument unsupported: parameter '' not supported The libvirt debug log info are as following: 2014-05-27 08:37:27.752+0000: 7559: debug : remoteDispatchDomainSetBlkioParametersHelper:7328 : server=0x7fd81deec930 client=0x7fd81df05170 msg=0x7fd81df06eb0 rerr=0x7fd816059c80 args=0x7fd7e40009a0 ret=0x7fd7e4000910 2014-05-27 08:37:27.752+0000: 7559: debug : virObjectNew:199 : OBJECT_NEW: obj=0x7fd7e4000c60 classname=virDomain 2014-05-27 08:37:27.752+0000: 7559: debug : virObjectRef:293 : OBJECT_REF: obj=0x7fd7f80011f0 2014-05-27 08:37:27.752+0000: 7559: debug : virDomainSetBlkioParameters:3985 : dom=0x7fd7e4000c60, (VM: name=instance-00000050, uuid=f844cf42-07d1-4b73-8de7-7437bf32aab0), params=0x7fd7e4000930, nparams=1, flags=0 2014-05-27 08:37:27.752+0000: 7559: debug : virDomainSetBlkioParameters:3986 : params[""]=(uint)250 2014-05-27 08:37:27.752+0000: 7559: debug : virObjectRef:293 : OBJECT_REF: obj=0x7fd81deec300 2014-05-27 08:37:27.752+0000: 7559: debug : virAccessManagerCheckConnect:215 : manager=0x7fd81deec300(name=stack) driver=QEMU perm=0 2014-05-27 08:37:27.752+0000: 7559: debug : virAccessManagerCheckConnect:215 : manager=0x7fd81deec370(name=none) driver=QEMU perm=0 2014-05-27 08:37:27.752+0000: 7559: debug : virObjectUnref:256 : OBJECT_UNREF: obj=0x7fd81deec300 2014-05-27 08:37:27.752+0000: 7559: error : virTypedParamsValidate:97 : argument unsupported: parameter '' not supported -- ------------ Jackie Best Regards

1 0

[libvirt] [Patch v2 0/3] use -serial for ppce500 board and add test case
by Olivia Yin 27 May '14

27 May '14

Machine name ppce500 is used to replace ppce500v2 supported by QEMU. QEMU ppce500 board uses the legacy -serial option. Test case ppce500-serial is used to verify this change. Olivia Yin (3): change machine name ppce500v2 as ppce500 qemu: Fix specifying char devs for PPC tests: add test case for -serial option for ppce500 docs/schemas/domaincommon.rng | 2 +- src/qemu/qemu_capabilities.c | 9 +++++++- tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.xml | 2 +- .../qemuxml2argv-ppce500-serial.args | 7 ++++++ .../qemuxml2argv-ppce500-serial.xml | 26 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 1 + tests/testutilsqemu.c | 2 +- 8 files changed, 46 insertions(+), 5 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ppce500-serial.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ppce500-serial.xml -- 1.8.5

2 4

[libvirt] [PATCH 0/3] use -serial for ppce500 board and add test case
by Olivia Yin 27 May '14

27 May '14

Machine name ppce500 is used to replace ppce500v2 supported by QEMU. QEMU ppce500 board uses the old style -serial options. Test case ppce500-serial is used to verify this change. Olivia Yin (3): change machine name ppce500v2 as ppce500 qemu: Fix specifying char devs for PPC tests: add test case for -serial option for ppce500 docs/schemas/domaincommon.rng | 2 +- src/qemu/qemu_capabilities.c | 10 ++++++--- tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-ppc-dtb.xml | 2 +- .../qemuxml2argv-ppce500-serial.args | 7 ++++++ .../qemuxml2argv-ppce500-serial.xml | 26 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 1 + tests/testutilsqemu.c | 2 +- 8 files changed, 45 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ppce500-serial.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ppce500-serial.xml -- 1.8.5

5 11