April 2015 - Devel - libvirt List Archives

[libvirt] request for backwards compatibility
by Kash Pande 17 Apr '15

17 Apr '15

Hi there, I've been trying to use libvirt-php to bring libvirt support to jentu which runs on mostly Debian Wheezy machines. I've had a few bugs setting network devices as active with the released (0.4.8) version: PHP Warning: libvirt_network_get_information(): Invalid XPath node for network gateway IP address in /var/www/libjentu-virt.php on line 54 PHP Warning: libvirt_network_set_active() expects exactly 2 parameters, 1 given in /var/www/libjentu-virt.php on line 55 PHP Warning: libvirt_network_set_active(): Invalid arguments in /var/www/libjentu-virt.php on line 55 Building the latest Git repository results in: gcc -g -O2 -Wall -fpic -DCOMPILE_DL_LIBVIRT=1 -I/usr/include/php5 -I/usr/include/php5/main -I/usr/include/php5/TSRM -I/usr/include/php5/Zend -I/usr/include/php5/ext -I/usr/include/php5/ext/date/lib -c -o libvirt-php.o libvirt-php.c -I/usr/include/libxml2 -DHAVE_CONFIG_H libvirt-php.c: In function ‘zm_startup_libvirt’: libvirt-php.c:1179:2: error: ‘VIR_DOMAIN_VCPU_GUEST’ undeclared (first use in this function) libvirt-php.c:1179:2: note: each undeclared identifier is reported only once for each function it appears in libvirt-php.c: In function ‘get_next_free_numeric_value’: libvirt-php.c:2719:6: warning: format ‘%x’ expects argument of type ‘unsigned int *’, but argument 3 has type ‘long int *’ [-Wformat] make[2]: *** [build] Error 1 And this is because debian wheezy has an old version of libvirt that does not have this declared. The proper solution looks like it'd be a configure-time check and enable or disable the new VCPU guest modifiers if they are not available because I'm not so sure wheezy will ever get a newer version of libvirt. Thanks, Kash Pande Jentu Technologies, Inc. http://jentu-networks.com

1 0

[libvirt] [PATCH V3 0/3] libxl: domain destroy fixes
by Jim Fehlig 16 Apr '15

16 Apr '15

V3 of a small series to fix issues wrt domain destroy V1: https://www.redhat.com/archives/libvir-list/2015-March/msg01337.html V2: https://www.redhat.com/archives/libvir-list/2015-April/msg00072.html In this version, patch 3 is changed a bit to provide a wrapper for unlocking, destroying, and locking the domain. Existing libxl_domain_destroy callers are changed to use the wrapper. Jim Fehlig (3): libxl: Move job acquisition in libxlDomainStart to callers libxl: acquire a job when destroying a domain libxl: drop virDomainObj lock when destroying a domain src/libxl/libxl_domain.c | 106 ++++++++++++++++++++++---------------------- src/libxl/libxl_domain.h | 8 ++-- src/libxl/libxl_driver.c | 81 ++++++++++++++++++++++++--------- src/libxl/libxl_migration.c | 4 +- 4 files changed, 118 insertions(+), 81 deletions(-) -- 1.8.4.5

3 7

[libvirt] [PATCH 0/5] libxl: improve xl config parsing
by Jim Fehlig 16 Apr '15

16 Apr '15

This series was inspired by Marek's and Chunyan's patches to add support for <kernel>, <initrd>, and <cmdline> in Xen HVM domain config https://www.redhat.com/archives/libvir-list/2015-March/msg00328.html https://www.redhat.com/archives/libvir-list/2014-September/msg01006.html Patches 1 and 2 are trivial prep for patch 3, which moves parsing and formatting of <os> config out of the common code and into the xl and xm specfic parsing/formatting code. For ease of review, identical copies of xen{Parse,Format}OS are made in xen_{xl,xm}.c. Changes to the xl parsing/formatting functions are made in patch 4 and 5. Changing the order in which config is parsed/formatted has the unfortunate side affect of requiring corresponding changes to the test config data files. Patch 3 shoulders that burden. Jim Fehlig (5): xenconfig: export xenConfigCopyString xenconfig: remove redunant parsing of device_model xenconfig: move <os> parsing/formating to config-specific files xenconfig: don't use "kernel" for hvmloader libxl: support HVM direct kernel boot src/libxl/libxl_conf.c | 9 ++ src/xenconfig/xen_common.c | 146 +---------------- src/xenconfig/xen_common.h | 5 + src/xenconfig/xen_xl.c | 178 +++++++++++++++++++++ src/xenconfig/xen_xm.c | 141 ++++++++++++++++ tests/testutilsxen.c | 8 +- .../test-fullvirt-direct-kernel-boot.cfg | 29 ++++ .../test-fullvirt-direct-kernel-boot.xml | 49 ++++++ tests/xlconfigdata/test-fullvirt-multiusb.cfg | 5 +- tests/xlconfigdata/test-new-disk.cfg | 5 +- tests/xlconfigdata/test-spice.cfg | 5 +- tests/xlconfigtest.c | 3 + tests/xmconfigdata/test-escape-paths.cfg | 6 +- tests/xmconfigdata/test-fullvirt-force-hpet.cfg | 6 +- tests/xmconfigdata/test-fullvirt-force-nohpet.cfg | 6 +- tests/xmconfigdata/test-fullvirt-localtime.cfg | 6 +- tests/xmconfigdata/test-fullvirt-net-ioemu.cfg | 6 +- tests/xmconfigdata/test-fullvirt-net-netfront.cfg | 6 +- tests/xmconfigdata/test-fullvirt-new-cdrom.cfg | 6 +- tests/xmconfigdata/test-fullvirt-old-cdrom.cfg | 6 +- tests/xmconfigdata/test-fullvirt-parallel-tcp.cfg | 6 +- .../test-fullvirt-serial-dev-2-ports.cfg | 6 +- .../test-fullvirt-serial-dev-2nd-port.cfg | 6 +- tests/xmconfigdata/test-fullvirt-serial-file.cfg | 6 +- tests/xmconfigdata/test-fullvirt-serial-null.cfg | 6 +- tests/xmconfigdata/test-fullvirt-serial-pipe.cfg | 6 +- tests/xmconfigdata/test-fullvirt-serial-pty.cfg | 6 +- tests/xmconfigdata/test-fullvirt-serial-stdio.cfg | 6 +- .../test-fullvirt-serial-tcp-telnet.cfg | 6 +- tests/xmconfigdata/test-fullvirt-serial-tcp.cfg | 6 +- tests/xmconfigdata/test-fullvirt-serial-udp.cfg | 6 +- tests/xmconfigdata/test-fullvirt-serial-unix.cfg | 6 +- tests/xmconfigdata/test-fullvirt-sound.cfg | 6 +- tests/xmconfigdata/test-fullvirt-usbmouse.cfg | 6 +- tests/xmconfigdata/test-fullvirt-usbtablet.cfg | 6 +- tests/xmconfigdata/test-fullvirt-utc.cfg | 6 +- tests/xmconfigdata/test-no-source-cdrom.cfg | 6 +- tests/xmconfigdata/test-paravirt-net-e1000.cfg | 2 +- tests/xmconfigdata/test-paravirt-net-vifname.cfg | 2 +- .../test-paravirt-new-pvfb-vncdisplay.cfg | 2 +- tests/xmconfigdata/test-paravirt-new-pvfb.cfg | 2 +- .../test-paravirt-old-pvfb-vncdisplay.cfg | 2 +- tests/xmconfigdata/test-paravirt-old-pvfb.cfg | 2 +- tests/xmconfigdata/test-paravirt-vcpu.cfg | 2 +- tests/xmconfigdata/test-pci-devs.cfg | 6 +- 45 files changed, 511 insertions(+), 242 deletions(-) create mode 100644 tests/xlconfigdata/test-fullvirt-direct-kernel-boot.cfg create mode 100644 tests/xlconfigdata/test-fullvirt-direct-kernel-boot.xml -- 1.8.4.5

2 7

[libvirt] [PATCH] util: set MAC address for VF via netlink message to PF + VF# when possible
by Laine Stump 16 Apr '15

16 Apr '15

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1113474 When we set the MAC address of a network device as a part of setting up macvtap "passthrough" mode (where the domain has an emulated netdev connected to a host macvtap device that has exclusive use of the physical device, and sets the device MAC address to match its own, i.e. "<interface type='direct'> <source mode='passthrough' .../>"), we use ioctl(SIOCSIFHWADDR) giving it the name of that device. This is true even if it is an SRIOV Virtual Function (VF). But, when we are setting the MAC address / vlan ID of a VF in preparation for "hostdev network" passthrough (this is where we set the MAC address and vlan id of the VF before detaching the host net driver and assigning the device to the domain with PCI passthrough, i.e. "<interface type='hostdev'>", we do the setting via a netlink RTM_SETLINK message for that VF's Physical Function (PF), telling it the VF# we want to change. This sets an "administratively changed MAC" flag for that VF in the PF's driver, and from that point on (until the PF's driver is reloaded) that VF's MAC address can't be changed. This means that if a VF is used for hostdev passthrough, it will have the admin flag set, and future attempts to use that VF for macvtap passthrough will fail. The solution to this problem is to check if a device being used for macvtap passthrough is actually a VF; if so, we use the netlink RTM_SETLINK message to the PF to set the VF's mac address instead of ioctl(SIOCSIFHWADDR); if not, behavior does not change from previously. There are three pieces to making this work: 1) virNetDevMacVLan(Create|Delete)WithVPortProfile() now call virNetDev(Replace|Restore)NetConfig() rather than virNetDev(Replace|Restore)MacAddress() (simply passing -1 for VF# and vlanid). 2) virNetDev(Replace|Restore)NetConfig() check to see if the device is a VF. If so, they find the PF's name and VF#, allowing them to call virNetDev(Replace|Restore)VfConfig(). 3) To prevent mixups when detaching a macvtap passthrough device that had been attached while running an older version of libvirt, virNetDevRestoreVfConfig() is potentially given the preserved name of the VF, and if the proper statefile for a VF can't be found in the stateDir (${stateDir}/${pfname}_vf${vfid}), virNetDevRestoreMacAddress() is called instead (which will look in the file named ${stateDir}/${vfname}). This problem has existed in every version of libvirt that has both macvtap passthrough and interface type='hostdev'. Fortunately people seem to use one or the other though. --- (I'm still doing some testing on this, but as long as this approach doesn't cause any other regressions (so far it doesn't appear to), this is the final form. So any ACK given will be contingent on the functional tests passing.) src/util/virnetdev.c | 66 ++++++++++++++++++++++++++++++++++++++++----- src/util/virnetdevmacvlan.c | 4 +-- 2 files changed, 62 insertions(+), 8 deletions(-) diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index a7903c3..a3f302f 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -2243,7 +2243,8 @@ virNetDevReplaceVfConfig(const char *pflinkdev, int vf, } static int -virNetDevRestoreVfConfig(const char *pflinkdev, int vf, +virNetDevRestoreVfConfig(const char *pflinkdev, + int vf, const char *vflinkdev, const char *stateDir) { int rc = -1; @@ -2258,6 +2259,17 @@ virNetDevRestoreVfConfig(const char *pflinkdev, int vf, stateDir, pflinkdev, vf) < 0) return rc; + if (vflinkdev && !virFileExists(path)) { + /* this VF's config may have been stored with + * virNetDevReplaceMacAddress while running an older version + * of libvirt. If so, the ${pf}_vf${id} file won't exist. In + * that case, try to restore using the older method with the + * VF's name directly. + */ + rc = virNetDevRestoreMacAddress(vflinkdev, stateDir); + goto cleanup; + } + if (virFileReadAll(path, 128, &fileData) < 0) goto cleanup; @@ -2311,11 +2323,31 @@ virNetDevReplaceNetConfig(const char *linkdev, int vf, const virMacAddr *macaddress, int vlanid, const char *stateDir) { + int ret = -1; + char *pfdevname = NULL; + + if (vf == -1 && virNetDevIsVirtualFunction(linkdev)) { + /* If this really *is* a VF and the caller just didn't know + * it, we should set the MAC address via PF+vf# instead of + * setting directly via VF, because the latter will be + * rejected any time after the former has been done. + */ + if (virNetDevGetPhysicalFunction(linkdev, &pfdevname) < 0) + goto cleanup; + if (virNetDevGetVirtualFunctionIndex(pfdevname, linkdev, &vf) < 0) + goto cleanup; + linkdev = pfdevname; + } + if (vf == -1) - return virNetDevReplaceMacAddress(linkdev, macaddress, stateDir); + ret = virNetDevReplaceMacAddress(linkdev, macaddress, stateDir); else - return virNetDevReplaceVfConfig(linkdev, vf, macaddress, vlanid, - stateDir); + ret = virNetDevReplaceVfConfig(linkdev, vf, macaddress, vlanid, + stateDir); + + cleanup: + VIR_FREE(pfdevname); + return ret; } /** @@ -2330,10 +2362,32 @@ virNetDevReplaceNetConfig(const char *linkdev, int vf, int virNetDevRestoreNetConfig(const char *linkdev, int vf, const char *stateDir) { + int ret = -1; + char *pfdevname = NULL; + const char *vfdevname = NULL; + + if (vf == -1 && virNetDevIsVirtualFunction(linkdev)) { + /* If this really *is* a VF and the caller just didn't know + * it, we should set the MAC address via PF+vf# instead of + * setting directly via VF, because the latter will be + * rejected any time after the former has been done. + */ + if (virNetDevGetPhysicalFunction(linkdev, &pfdevname) < 0) + goto cleanup; + if (virNetDevGetVirtualFunctionIndex(pfdevname, linkdev, &vf) < 0) + goto cleanup; + vfdevname = linkdev; + linkdev = pfdevname; + } + if (vf == -1) - return virNetDevRestoreMacAddress(linkdev, stateDir); + ret = virNetDevRestoreMacAddress(linkdev, stateDir); else - return virNetDevRestoreVfConfig(linkdev, vf, stateDir); + ret = virNetDevRestoreVfConfig(linkdev, vf, vfdevname, stateDir); + + cleanup: + VIR_FREE(pfdevname); + return ret; } #else /* defined(__linux__) && defined(HAVE_LIBNL) */ diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c index 5fd2097..ea628c0 100644 --- a/src/util/virnetdevmacvlan.c +++ b/src/util/virnetdevmacvlan.c @@ -779,7 +779,7 @@ int virNetDevMacVLanCreateWithVPortProfile(const char *tgifname, * emulate their switch in firmware. */ if (mode == VIR_NETDEV_MACVLAN_MODE_PASSTHRU) { - if (virNetDevReplaceMacAddress(linkdev, macaddress, stateDir) < 0) + if (virNetDevReplaceNetConfig(linkdev, -1, macaddress, -1, stateDir) < 0) return -1; } @@ -914,7 +914,7 @@ int virNetDevMacVLanDeleteWithVPortProfile(const char *ifname, int vf = -1; if (mode == VIR_NETDEV_MACVLAN_MODE_PASSTHRU) - ignore_value(virNetDevRestoreMacAddress(linkdev, stateDir)); + ignore_value(virNetDevRestoreNetConfig(linkdev, vf, stateDir)); if (ifname) { if (virNetDevVPortProfileDisassociate(ifname, -- 2.1.0

2 2

[libvirt] [PATCH] virbuffer: fix build on rhel-6
by Pavel Hrdina 16 Apr '15

16 Apr '15

On rhel-6 is broken gcc that reports this warning: util/virbuffer.c:500: error: logical '&&' with non-zero constant will always evaluate as true [-Wlogical-op] Move the pragma directive before function virBufferEscapeString because since commit aeb5262e this function uses 'strchr' too. Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- Pushed as build-breaker fix. src/util/virbuffer.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/util/virbuffer.c b/src/util/virbuffer.c index 3d13c90..5b338f8 100644 --- a/src/util/virbuffer.c +++ b/src/util/virbuffer.c @@ -421,6 +421,15 @@ virBufferVasprintf(virBufferPtr buf, const char *format, va_list argptr) buf->use += count; } +/* Work around spurious strchr() diagnostics given by -Wlogical-op + * for gcc < 4.6. Doing it via a local pragma keeps the damage + * smaller than disabling it on the package level. Unfortunately, the + * affected GCCs don't allow diagnostic push/pop which would have + * further reduced the impact. */ +#if BROKEN_GCC_WLOGICALOP +# pragma GCC diagnostic ignored "-Wlogical-op" +#endif + /** * virBufferEscapeString: * @buf: the buffer to append to @@ -535,15 +544,6 @@ virBufferEscapeSexpr(virBufferPtr buf, virBufferEscape(buf, '\\', "\\'", format, str); } -/* Work around spurious strchr() diagnostics given by -Wlogical-op - * for gcc < 4.6. Doing it via a local pragma keeps the damage - * smaller than disabling it on the package level. Unfortunately, the - * affected GCCs don't allow diagnostic push/pop which would have - * further reduced the impact. */ -#if BROKEN_GCC_WLOGICALOP -# pragma GCC diagnostic ignored "-Wlogical-op" -#endif - /** * virBufferEscape: * @buf: the buffer to append to -- 2.0.5

1 0

[libvirt] [PATCH] nwfilter: Partly initialize driver even for non-privileged users
by Michal Privoznik 16 Apr '15

16 Apr '15

https://bugzilla.redhat.com/show_bug.cgi?id=1211436 This reverts commit b7829f959b33c6e32422222a9ed745c0da7dc696. The previous fix was not correct. Like everywhere else, a driver is a global variable allocated in stateInitialize function (or something similar for stateless drivers). Later, when a driver API is called, it's possible that the global variable is accessed and dereferenced. Now, some drivers require root privileges because they undertake some actions reserved only for the system admin (e.g. manipulating host firewall). And here's the trouble, the NWFilter state initializer exited too early when finding out it's running unprivileged, leaving the global NWFilter driver variable uninitialized. Any subsequent API call that tried to lock the driver resulted in dereferencing the driver and thus crash. On the other hand, in order to not resurrect the bug the original commit was fixing, Let's forbid the nwfilter define in session mode. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> Conflicts: src/nwfilter/nwfilter_driver.c: Context. Code changed a bit since 2013. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/nwfilter/nwfilter_driver.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/nwfilter/nwfilter_driver.c b/src/nwfilter/nwfilter_driver.c index 8e3db43..1a868b6 100644 --- a/src/nwfilter/nwfilter_driver.c +++ b/src/nwfilter/nwfilter_driver.c @@ -176,9 +176,6 @@ nwfilterStateInitialize(bool privileged, char *base = NULL; DBusConnection *sysbus = NULL; - if (!privileged) - return 0; - if (virDBusHasSystemBus() && !(sysbus = virDBusGetSystemBus())) return -1; @@ -193,6 +190,9 @@ nwfilterStateInitialize(bool privileged, driver->watchingFirewallD = (sysbus != NULL); driver->privileged = privileged; + if (!privileged) + return 0; + nwfilterDriverLock(); if (virNWFilterIPAddrMapInit() < 0) @@ -535,6 +535,12 @@ nwfilterDefineXML(virConnectPtr conn, virNWFilterObjPtr nwfilter = NULL; virNWFilterPtr ret = NULL; + if (!driver->privileged) { + virReportError(VIR_ERR_OPERATION_INVALID, "%s", + _("Can't define NWFilters in session mode")); + return NULL; + } + nwfilterDriverLock(); virNWFilterWriteLockFilterUpdates(); virNWFilterCallbackDriversLock(); -- 2.0.5

2 1

[libvirt] [PATCH] virNetSocketNewConnectUNIX: Don't unlink(NULL)
by Michal Privoznik 16 Apr '15

16 Apr '15

There is a possibility that we jump onto error label with @lockpath still initialized to NULL. Here, the @lockpath should be unlink()-ed, but passing there a NULL is not a good idea. Don't do that. In fact, we should call unlink() only if we created the lock file successfully. Reported-by: John Ferlan <jferlan(a)redhat.com> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/rpc/virnetsocket.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c index b824285..a59e3e1 100644 --- a/src/rpc/virnetsocket.c +++ b/src/rpc/virnetsocket.c @@ -622,7 +622,7 @@ int virNetSocketNewConnectUNIX(const char *path, usleep(5000); } - if (lockfd) { + if (lockfd != -1) { unlink(lockpath); VIR_FORCE_CLOSE(lockfd); VIR_FREE(lockpath); @@ -640,12 +640,13 @@ int virNetSocketNewConnectUNIX(const char *path, return 0; error: - if (lockfd) + if (lockfd != -1) { unlink(lockpath); + VIR_FORCE_CLOSE(lockfd); + } VIR_FREE(lockpath); VIR_FREE(rundir); VIR_FORCE_CLOSE(fd); - VIR_FORCE_CLOSE(lockfd); return -1; } #else -- 2.0.5

2 1

[libvirt] [PATCH] lxc: move wireless PHYs to a network namespace
by Michal Privoznik 16 Apr '15

16 Apr '15

From: Lubomir Rintel <lkundrak(a)v3.sk> The 802.11 interfaces can not be moved by themselves, their Phy has to move too. If there are other interfaces, they have to move too -- hopefully it's not too confusing. This is a less-invasive alternative to defining a new hostdev type for PHYs. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/virnetdev.c | 39 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 36 insertions(+), 3 deletions(-) diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index a816e5d..21fa9d0 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -560,20 +560,53 @@ int virNetDevSetMTUFromDevice(const char *ifname, */ int virNetDevSetNamespace(const char *ifname, pid_t pidInNs) { - int rc; + int ret = -1; char *pid = NULL; + char *phy = NULL; + char *phy_path = NULL; + int len; + const char *argv[] = { "ip", "link", "set", ifname, "netns", NULL, NULL }; + const char *iwargv[] = { + "iw", "phy", NULL, "set", "netns", NULL, NULL + }; + if (virAsprintf(&pid, "%lld", (long long) pidInNs) == -1) return -1; argv[5] = pid; - rc = virRun(argv, NULL); + if (virRun(argv, NULL) < 0) + goto cleanup; + /* The 802.11 wireless devices only move together with their PHY. */ + if (virNetDevSysfsFile(&phy_path, ifname, "phy80211/name") < 0) + goto cleanup; + + if ((len = virFileReadAllQuiet(phy_path, 1024, &phy) < 0)) { + if (errno == ENOENT) { + /* Okay, this is not a wireless card. Claim success. */ + ret = 0; + } + goto cleanup; + } + + /* Remove a line break. */ + phy[len - 1] = '\0'; + + iwargv[2] = phy; + iwargv[5] = pid; + if (virRun(iwargv, NULL) < 0) + goto cleanup; + + ret = 0; + cleanup: + VIR_FREE(phy_path); + VIR_FREE(phy); VIR_FREE(pid); - return rc; + return ret; } #if defined(SIOCSIFNAME) && defined(HAVE_STRUCT_IFREQ) -- 2.0.5

2 1

[libvirt] unclear docs about scsi hostdev
by Olaf Hering 16 Apr '15

16 Apr '15

The scsi host example in https://libvirt.org/formatdomain.html does not make it clear what "<adapter name='scsi_host0'/>" refers to. It implies that any host #0 will be used. Since the index numbers for each host are dynamic an unexpected device may be used by libvirt. The reason I'm looking at this is to support vscsi in libxl. I have a change for xl(1) and want to add also libvirt support. The xend vscsi driver supported both H:C:T:L and /dev/whatever notation to describe the physical dom0 device. This was translated into H:C:T:L for the xenlinux backend driver. The new pvops backend driver understands "naa.wwn:lun" and "H:C:T:L" format. My libxl implementation will also translate /dev/whatever into "naa.wwn:lun". My change supports both xenlinux and pvops. I think its natural to refer to a /dev/disk/by-*/* name for pdev, if the SCSI device supports that. Looks like _virDomainHostdevSubsysSCSI->u.host is very limited in what it accepts as input. What should be done to accept both "/dev/whatever" and "naa.wwn:lun" as pdev? The <address/> part looks like the same format what the frontend driver understands: "host:channel:target:lun". Olaf

1 1

[libvirt] [PATCH] virCondWaitUntil: calculate timespec correctly
by Michael Chapman 16 Apr '15

16 Apr '15

ts.tv_nsec was off by a factor of 1000, making timeouts less than a second in the future often expiring immediately. Signed-off-by: Michael Chapman <mike(a)very.puzzling.org> --- src/util/virthread.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/virthread.c b/src/util/virthread.c index c2a9e7f..6c49515 100644 --- a/src/util/virthread.c +++ b/src/util/virthread.c @@ -164,7 +164,7 @@ int virCondWaitUntil(virCondPtr c, virMutexPtr m, unsigned long long whenms) struct timespec ts; ts.tv_sec = whenms / 1000; - ts.tv_nsec = (whenms % 1000) * 1000; + ts.tv_nsec = (whenms % 1000) * 1000000; if ((ret = pthread_cond_timedwait(&c->cond, &m->lock, &ts)) != 0) { errno = ret; -- 2.1.0

3 3