April 2016 - Devel - libvirt List Archives

[libvirt] [libvirt-sandbox PATCH] virt-sandbox: document how to pass arguments to commands
by Guido Günther 17 Apr '16

17 Apr '16

The example was already correct but the synopsis didn't mention '--' is required. --- bin/virt-sandbox.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bin/virt-sandbox.c b/bin/virt-sandbox.c index 9495e85..d6a441c 100644 --- a/bin/virt-sandbox.c +++ b/bin/virt-sandbox.c @@ -345,7 +345,9 @@ virt-sandbox - Run cmd under a virtual machine sandbox =head1 SYNOPSIS -virt-sandbox [OPTIONS...] COMMAND [CMDARG1 [CMDARG2 [...]]] +virt-sandbox [OPTIONS...] COMMAND + +virt-sandbox [OPTIONS...] -- COMMAND [CMDARG1 [CMDARG2 [...]]] =head1 DESCRIPTION -- 2.8.0.rc3

2 2

Re: [libvirt] [PATCH] storage_scsi: Handle physical HBA when deleting vHBA vport.
by John Ferlan 15 Apr '16

15 Apr '16

On 04/15/2016 02:26 PM, Nitesh Konkar wrote: > On Fri, Apr 15, 2016 at 8:08 PM, John Ferlan <jferlan(a)redhat.com> wrote: > Please do not remove libvir-list from a response. I've replaced it. Someone may have a different idea. >> >> >> On 04/15/2016 10:11 AM, Nitesh Konkar wrote: >>> Thanks John for the reply. >>> >>> On Fri, Apr 15, 2016 at 5:08 PM, John Ferlan <jferlan(a)redhat.com> wrote: >>> >>>> >>>> >>>> On 04/07/2016 05:09 AM, Nitesh Konkar wrote: >>>>> HBA will get treated as vHBA if not returned >>>>> after detecting vhba_parent format. >>>>> >>>>> Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com> >>>>> --- >>>>> Before Patch: >>>>> # virsh pool-destroy poolhba_name >>>>> error: Failed to destroy pool poolhba_name >>>>> error: internal error: Invalid adapter name 'pci_000x_0x_00_x' for SCSI >>>> pool >>>>> >>>>> # virsh nodedev-dumpxml scsi_host2 >>>>> <device> >>>>> <name>scsi_host2</name> >>>>> <path>xxxx</path> >>>>> <parent>pci_000x_0x_00_x</parent> >>>>> <capability type='scsi_host'> >>>>> <host>2</host> >>>>> ... >>>>> ... >>>>> <capability type='vport_ops'> >>>>> <max_vports>255</max_vports> >>>>> <vports>0</vports> >>>>> </capability> >>>>> </capability> >>>>> </device> >>>>> >>>>> After Patch: >>>>> # virsh pool-destroy poolhba_name >>>>> Pool poolhba_name destroyed >>>>> >>>>> src/storage/storage_backend_scsi.c | 5 +++++ >>>>> 1 file changed, 5 insertions(+) >>>>> >>>> >>>> Can you provide the pool-dumpxml for poolhba_name? Can you provide the >>>> nodedev-dumpxml of the 'scsi_host#' that was created for the vHBA pool? >>>> >>>> >>> This patch is to destroy a pool created out from a Physical HBA. >> Apologies, >>> if the >>> commit message was misleading. >>> >>> # virsh pool-dumpxml poolhba_name >>> <pool type='scsi'> >>> <name>poolhba_name</name> >>> <uuid>60d74134-0c18-4d4f-9305-24d96ce1a1b6</uuid> >>> <capacity unit='bytes'>268435456000</capacity> >>> <allocation unit='bytes'>268435456000</allocation> >>> <available unit='bytes'>0</available> >>> <source> >>> <adapter type='fc_host' managed='yes' wwnn='20000120fa8f1271' >>> wwpn='10000090fa8f1271'/> >>> </source> >>> <target> >>> <path>/dev/disk/by-id</path> >>> <permissions> >>> <mode>0700</mode> >>> <owner>0</owner> >>> <group>0</group> >>> </permissions> >>> </target> >>> </pool> >>> >> >> OK, maybe I wasn't clear enough... Which 'scsi_host#' is *this* pool >> associated with. Prior to creating it, do a virsh nodedev-list >> scsi_host. Then create it. Then generate the list again. >> >> The pool poolhba_name is associated with scsi_host2. > > #virsh list --all > Id Name State > ---------------------------------------------------- > > # virsh nodedev-list scsi_host > scsi_host0 > scsi_host1 > scsi_host2 > scsi_host3 > scsi_host4 > > #virsh pool-list --all > Name State Autostart > ------------------------------------------- > poolhba_name active yes > > # virsh nodedev-dumpxml scsi_host2 > <device> > <name>scsi_host2</name> > > <path>/sys/devices/pci0001:00/0001:00:00.0/0001:01:00.0/0001:02:09.0/0001:09:00.1/host2</path> > <parent>pci_0001_09_00_1</parent> > <capability type='scsi_host'> > <host>2</host> > <unique_id>1</unique_id> > <capability type='fc_host'> > <wwnn>20000120fa8f1271</wwnn> > <wwpn>10000090fa8f1271</wwpn> > <fabric_wwn>100050eb1a99d430</fabric_wwn> > </capability> > <capability type='vport_ops'> > <max_vports>255</max_vports> > <vports>1</vports> > </capability> > </capability> > </device> > > Or of course since you cannot delete the poolvhba_name, go through the >> various scsi_host#'s on your host looking for the one with the match >> wwwn/wwpn - then do the nodedev-dumpxml of that. For you example you >> are looking for the scsi_host# with the matching wwnn='20000120fa8f1271' >> and wwpn='10000090fa8f1271'. >> >> That one is supposed to list 'scsi_host2' in the <parent> field as my >> 'scsi_host19' does below. >> >> # virsh pool-list --all > Name State Autostart > ------------------------------------------- > poolhba_name active yes > > # virsh nodedev-dumpxml scsi_host2 > <device> > <name>scsi_host2</name> > > <path>/sys/devices/pci0001:00/0001:00:00.0/0001:01:00.0/0001:02:09.0/0001:09:00.1/host2</path> > <parent>pci_0001_09_00_1</parent> > <capability type='scsi_host'> > <host>2</host> > <unique_id>1</unique_id> > <capability type='fc_host'> > <wwnn>20000120fa8f1271</wwnn> > <wwpn>10000090fa8f1271</wwpn> > <fabric_wwn>100050eb1a99d430</fabric_wwn> > </capability> > <capability type='vport_ops'> > <max_vports>255</max_vports> > <vports>1</vports> > </capability> > </capability> > </device> > > Here the parent field has "pci_0001_09_00_1" and not 'scsi_host2' . This is > why it errors out. > > # virsh pool-destroy poolhba_name > 2016-04-15 18:21:07.054+0000: 113209: error : virGetSCSIHostNumber:1922 : > internal error: Invalid adapter name 'pci_0001_09_00_1' for SCSI pool > error: Failed to destroy pool poolhba_name > error: internal error: Invalid adapter name 'pci_0001_09_00_1' for SCSI pool > > Am I missing something? > Perhaps - I think I explained how the vHBA is created before... Look at the code for createVport() - see the 'parent_hoststr' description. When you did a pool-{create|define} for the "poolhba_name", you provided some XML which would search the existing 'scsi_host#' for one that's capable of supporting a vHBA. What that create is supposed to do (at least it does it on the systems I used) is create another 'scsi_host#'. That scsi_host# is then the vHBA - it's *parent* is supposed to be 'scsi_host2' - see my example. On your host perhaps scsi_host3 or scsi_host4. Do either one of those two have the wwnn/wwpn that's in your poolhba_name: <adapter type='fc_host' managed='yes' wwnn='20000120fa8f1271' wwpn='10000090fa8f1271'/> I'm really not quite sure what's happening on your host/environment. Perhaps you could follow how createVport generates things and report back. You can always 'create' another vHBA using a different wwnn/wwpn John

1 0

[libvirt] [PATCH libvirt v2 0/2] libxl: support vscsi
by Olaf Hering 15 Apr '16

15 Apr '16

Add support for upcoming vscsi= in libxl. Changes between v1 and v2: - rebase to 'master' (ad584cb) - Update API to v12 Olaf Hering (2): libxl: include a XLU_Config in _libxlDriverConfig libxl: support vscsi src/libxl/libxl_conf.c | 66 +++++++++++++++++ src/libxl/libxl_conf.h | 8 ++ src/libxl/libxl_domain.c | 2 +- src/libxl/libxl_driver.c | 187 +++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 262 insertions(+), 1 deletion(-)

2 5

[libvirt] [PATCH] libxl config file convertion: correct `type=netfront' to 'type=vif'
by Chunyan Liu 15 Apr '16

15 Apr '16

According to current xl.cfg docs and xl codes, it uses type=vif instead of type=netfront. Currently after domxml-to-native, libvirt xml model=netfront will be converted to xl type=netfront. This has no problem before, xen codes for a long time just check type=ioemu, if not, set type to _VIF. Since libxl uses parse_nic_config to avoid duplicate codes, it compares 'type=vif' and 'type=ioemu' for valid parameters, others are considered as invalid, thus we have problem with type=netfront in xl config file. #xl create sles12gm-hvm.orig Parsing config from sles12gm-hvm.orig Invalid parameter `type'. Correct the convertion in libvirt, so that it matchs libxl codes and also xl.cfg. Signed-off-by: Chunyan Liu <cyliu(a)suse.com> --- Since type=netfront config has been used for a very long time, at lease for xm/xend, it has no problem. I'm not sure if we need to split into xenParseXLVif vs xenParseXMVif, and xenFormatXLVif vs xenFormatXMVif for this change? src/xenconfig/xen_common.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c index 4dcd484..ae81635 100644 --- a/src/xenconfig/xen_common.c +++ b/src/xenconfig/xen_common.c @@ -944,7 +944,8 @@ xenParseVif(virConfPtr conf, virDomainDefPtr def) VIR_STRDUP(net->model, model) < 0) goto cleanup; - if (!model[0] && type[0] && STREQ(type, "netfront") && + if (!model[0] && type[0] && + (STREQ(type, "netfront") || STREQ(type, "vif")) && VIR_STRDUP(net->model, "netfront") < 0) goto cleanup; @@ -1201,7 +1202,7 @@ xenFormatNet(virConnectPtr conn, virBufferAsprintf(&buf, ",model=%s", net->model); } else { if (net->model != NULL && STREQ(net->model, "netfront")) { - virBufferAddLit(&buf, ",type=netfront"); + virBufferAddLit(&buf, ",type=vif"); } else { if (net->model != NULL) virBufferAsprintf(&buf, ",model=%s", net->model); -- 2.1.4

3 2

[libvirt] [PATCH V2] libxl: use LIBXL_API_VERSION 0x040200
by Jim Fehlig 15 Apr '16

15 Apr '16

To ensure the libvirt libxl driver will build with future versions of Xen where the libxl API may change in incompatible ways, explicitly use LIBXL_API_VERSION 0x040200. The libxl driver does use new libxl APIs that have been added since Xen 4.2, but currently it does not make use of any changes made to existing APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity. The version can be bumped if/when the libxl driver consumes the changed APIs. Further details can be found in the following discussion thread https://www.redhat.com/archives/libvir-list/2016-April/msg00178.html Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- configure.ac | 2 ++ src/libxl/libxl_conf.h | 12 ------------ src/libxl/libxl_domain.c | 15 --------------- 3 files changed, 2 insertions(+), 27 deletions(-) diff --git a/configure.ac b/configure.ac index b1500f6..446f2a2 100644 --- a/configure.ac +++ b/configure.ac @@ -894,6 +894,7 @@ if test "$with_libxl" != "no" ; then PKG_CHECK_MODULES([LIBXL], [xenlight], [ LIBXL_FIRMWARE_DIR=`$PKG_CONFIG --variable xenfirmwaredir xenlight` LIBXL_EXECBIN_DIR=`$PKG_CONFIG --variable libexec_bin xenlight` + LIBXL_CFLAGS="$LIBXL_CFLAGS -DLIBXL_API_VERSION=0x040200" with_libxl=yes ], [LIBXL_FOUND=no]) if test "$LIBXL_FOUND" = "no"; then @@ -906,6 +907,7 @@ if test "$with_libxl" != "no" ; then LIBS="$LIBS $LIBXL_LIBS" AC_CHECK_LIB([xenlight], [libxl_ctx_alloc], [ with_libxl=yes + LIBXL_CFLAGS="$LIBXL_CFLAGS -DLIBXL_API_VERSION=0x040200" LIBXL_LIBS="$LIBXL_LIBS -lxenlight" ],[ if test "$with_libxl" = "yes"; then diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h index 3c0eafb..24e2911 100644 --- a/src/libxl/libxl_conf.h +++ b/src/libxl/libxl_conf.h @@ -69,18 +69,6 @@ # endif -/* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new - * parameter has been added, representative of 'VCPU soft affinity'. If one - * does not care about it (and that's libvirt case), passing NULL is the - * right thing to do. To mark that change, LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY - * is defined. */ -# ifdef LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY -# define libxl_set_vcpuaffinity(ctx, domid, vcpuid, map) \ - libxl_set_vcpuaffinity((ctx), (domid), (vcpuid), (map), NULL) -# define libxl_set_vcpuaffinity_all(ctx, domid, max_vcpus, map) \ - libxl_set_vcpuaffinity_all((ctx), (domid), (max_vcpus), (map), NULL) -# endif - typedef struct _libxlDriverPrivate libxlDriverPrivate; typedef libxlDriverPrivate *libxlDriverPrivatePtr; diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c index 86fb713..14a900c 100644 --- a/src/libxl/libxl_domain.c +++ b/src/libxl/libxl_domain.c @@ -1026,9 +1026,6 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, int managed_save_fd = -1; libxlDomainObjPrivatePtr priv = vm->privateData; libxlDriverConfigPtr cfg; -#ifdef LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS - libxl_domain_restore_params params; -#endif virHostdevManagerPtr hostdev_mgr = driver->hostdevMgr; libxl_asyncprogress_how aop_console_how; @@ -1118,20 +1115,8 @@ libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm, ret = libxl_domain_create_new(cfg->ctx, &d_config, &domid, NULL, &aop_console_how); } else { -#if defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_SEND_BACK_FD) - params.checkpointed_stream = 0; - ret = libxl_domain_create_restore(cfg->ctx, &d_config, &domid, - restore_fd, -1, &params, NULL, - &aop_console_how); -#elif defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS) - params.checkpointed_stream = 0; - ret = libxl_domain_create_restore(cfg->ctx, &d_config, &domid, - restore_fd, &params, NULL, - &aop_console_how); -#else ret = libxl_domain_create_restore(cfg->ctx, &d_config, &domid, restore_fd, NULL, &aop_console_how); -#endif } virObjectLock(vm); -- 2.6.1

3 3

[libvirt] Regarding PCI/PCIe Multifunction hotplug support in libvirt
by Shivaprasad bhat 15 Apr '16

15 Apr '16

Hi All, I am exploring how to go about supporting multi-function hot-plug/unplug support from libvirt now that Qemu has enabled it. The Qemu semantics is that, qemu queues the notification to guest until function 0 is hot- plugged and on function 0 hot-plug, all the previously added devices in the slot are notified to the guest. For hot-unplug - On x86, unplug of any device in the slot would unplug all the functions of the slot. On PPC, unplug all non-zero functions first, then unplug the function zero which triggers the unplug of all the functions in the slot. On Libvirt, I had a brief chat with Laine Stump on IRC and we "think" the below semantics would be appropriate. 1) Change the virDomainAttachDeviceFlags() to recognize multiple devices in the XML and the application should make one call to attach all the functions for the slot at one time. 2) The libvirt qemu driver to translate this into multiple attach device commands to qemu with the final operation being for function 0. 3) The XML now needs to accept multiple devices and there is a need for single parent element. I am thinking if we should have all devices to be enclosed in <device></device> parent element. Note that this is only when all the devices should go to the same slot. We probably should disallow user attempting to hot-plug to different slots with this. 4) For the hot-unplug, the application to send all the devices the same way enclosed in <device></devices> and libvirt to go ahead with unplug only if all the devices are specified in the XML for the slot. Want to know if you foresee any problem with using <device></device> semantics Or you have any different approach/suggestions. Any comments greatly appreciated. Thanks and Regards, Shivaprasad

2 1

[libvirt] [PATCH v2 0/4] Fix parsing our own XMLs
by Martin Kletzander 15 Apr '16

15 Apr '16

v2: - Just a rebase - I did *not* use virPCIDeviceAddress wording instead as discussed in the v1 thread. That's because we have lot of functions working with virDevicePCIAddress named exactly after that and renaming those would be ugly IMHO. v1: - https://www.redhat.com/archives/libvir-list/2016-April/msg00081.html Martin Kletzander (4): Change virPCIDeviceAddress to virDevicePCIAddress Move capability formatting together schemas: Update nodedev schema to match reality conf: Parse more of our nodedev XML docs/schemas/nodedev.rng | 29 +++--- src/conf/device_conf.h | 11 +-- src/conf/node_device_conf.c | 109 +++++++++++++++++++-- src/conf/node_device_conf.h | 6 +- src/libvirt_private.syms | 10 +- src/network/bridge_driver.c | 4 +- src/node_device/node_device_linux_sysfs.c | 6 +- src/util/virhostdev.c | 12 +-- src/util/virnetdev.c | 4 +- src/util/virnetdev.h | 2 +- src/util/virpci.c | 80 +++++++-------- src/util/virpci.h | 29 +++--- .../pci_0000_00_1c_0_header_type.xml | 2 +- tests/nodedevschemadata/pci_0000_02_10_7_sriov.xml | 23 +++++ .../pci_0000_02_10_7_sriov_pf_vfs_all.xml | 29 ++++++ ...i_0000_02_10_7_sriov_pf_vfs_all_header_type.xml | 30 ++++++ .../pci_0000_02_10_7_sriov_vfs.xml | 26 +++++ .../pci_0000_02_10_7_sriov_zero_vfs_max_count.xml | 21 ++++ tests/nodedevxml2xmltest.c | 7 ++ 19 files changed, 335 insertions(+), 105 deletions(-) create mode 100644 tests/nodedevschemadata/pci_0000_02_10_7_sriov.xml create mode 100644 tests/nodedevschemadata/pci_0000_02_10_7_sriov_pf_vfs_all.xml create mode 100644 tests/nodedevschemadata/pci_0000_02_10_7_sriov_pf_vfs_all_header_type.xml create mode 100644 tests/nodedevschemadata/pci_0000_02_10_7_sriov_vfs.xml create mode 100644 tests/nodedevschemadata/pci_0000_02_10_7_sriov_zero_vfs_max_count.xml -- 2.8.1

2 8

[libvirt] [PATCH] ploop: Fix build with gluster
by Jiri Denemark 15 Apr '16

15 Apr '16

Recent patches addiing support for ploop volumes did not properly update gluster backend. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- Pushed as a build-breaker. src/storage/storage_backend_gluster.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/storage/storage_backend_gluster.c b/src/storage/storage_backend_gluster.c index d2e79bc..0085052 100644 --- a/src/storage/storage_backend_gluster.c +++ b/src/storage/storage_backend_gluster.c @@ -435,6 +435,7 @@ virStorageBackendGlusterVolDelete(virConnectPtr conn ATTRIBUTE_UNUSED, case VIR_STORAGE_VOL_FILE: case VIR_STORAGE_VOL_DIR: case VIR_STORAGE_VOL_BLOCK: + case VIR_STORAGE_VOL_PLOOP: case VIR_STORAGE_VOL_LAST: virReportError(VIR_ERR_NO_SUPPORT, _("removing of '%s' volumes is not supported " -- 2.8.1

1 0

[libvirt] [PATCH v5] Add functions for handling exponential backoff loops.
by Richard W.M. Jones 15 Apr '16

15 Apr '16

v4b -> v5: - Move documentation to .c file. - Change the name of the while function to virTimeBackOffWait. Rich.

3 5

[libvirt] [PATCH v6 0/7] storage:dir: ploop volumes support
by Olga Krishtal 15 Apr '16

15 Apr '16

This series of patches introduces the support of ploop volumes in storage pools (dir, fs, etc). Ploop volume is a disk loopback block device consists of root.hds (it is the image file) and DiskDescriptor.xml: https://openvz.org/Ploop/format. Due to this fact it can't be treated as file or any other volume type, moreover, in order to successfully manipulate with such volume, ploop tools should be installed. All callbacks except the wipeVol are supported. First patch introduces ploop volume type. This is a directory with two files inside. The name of the directory is the name of the volume. Patch 2 deals with creating an empty volume and cloning the existing one. Clone is done via simle cp operation. If any of this operation fails - directory will be deleted. Patch 3 deletes recursively ploop directory. Patch 4 uses ploop tool to resize volume. Patch 6 adapts all refreshing functions to work with ploop. To get information the directory is checked. The volume is treated as the ploops one only if it contains ploop files. Every time the pool is refreshed DiskDescriptor.xml is restored. This is necessary, because the content of the volume may have changed. Upload and download (patch 7) can't be done if the volume contains snapshots. v6: - There is no DiskDescriptor.xml restoring during the refresh pool operation. This operation is moved to storage driver. - fixed issue with regenerating xml for ploop volume with the snapshots. v5: - added ploop volume type - there is no change in opening volume functions. Now reopening takes place is the volume is ploops one. - restore DiskDescriptor.xml every refresh pool - all information, except format is taken from header - forbidden upload and download ops for volume with snapshots - there is no separate function for deleting the volume - fixed identation and leaks v4: - fixed identation issues. - in case of .uploadVol, DiskDescriptor.xml is restored. - added check of ploops'accessibility v3: - no VIR_STORAGE_VOL_PLOOP type any more - adapted all patches according to previous change - fixed comments v2: - fixed memory leak - chenged the return value of all helper functions to 0/-1. Now check for success is smth like that: vir****Ploop() < 0 - fixed some identation issues.

2 16