- Devel - libvirt List Archives

[libvirt] [PATCHv2] netcf driver: use a single netcf handle for all connections
by Laine Stump 12 Sep '13

12 Sep '13

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=983026 The netcf interface driver previously had no state driver associated with it - as a connection was opened, it would create a new netcf instance just for that connection, and close it when it was finished. the problem with this is that each connection to libvirt used up a netlink socket, and there is a per process maximum of ~1000 netlink sockets. The solution is to create a state driver to go along with the netcf driver. The state driver will opens a netcf instance, then all connections share that same netcf instance, thus only a single netlink socket will be used no matter how many connections are mde to libvirtd. This was rather simple to do - a new virObjectLockable class is created for the single driverState object, which is created in netcfStateInitialize and contains the single netcf handle; instead of creating a new object for each client connection, netcfInterfaceOpen now just increments the driverState object's reference count and puts a pointer to it into the connection's privateData. Similarly, netcfInterfaceClose() just un-refs the driverState object (as does netcfStateCleanup()), and virNetcfInterfaceDriverStateDispose() handles closing the netcf instance. Since all the functions already have locking around them, the static lock functions used by all functions just needed to be changed to call virObjectLock() and virObjectUnlock() instead of directly calling the virMutex* functions. --- Changes from V1: * make driverState a static. * switch to using a virObjectLockable for driverState, at Eric's suggestion. * add a simple error message if ncf_init() fails. Again, I've tried this with a small number of simultaneous connections (including virt-manager), but I don't have a ready-made stress test. src/interface/interface_backend_netcf.c | 173 +++++++++++++++++++++++--------- 1 file changed, 125 insertions(+), 48 deletions(-) diff --git a/src/interface/interface_backend_netcf.c b/src/interface/interface_backend_netcf.c index f47669e..627c225 100644 --- a/src/interface/interface_backend_netcf.c +++ b/src/interface/interface_backend_netcf.c @@ -41,19 +41,119 @@ /* Main driver state */ typedef struct { - virMutex lock; + virObjectLockable parent; struct netcf *netcf; } virNetcfDriverState, *virNetcfDriverStatePtr; +static virClassPtr virNetcfDriverStateClass; +static void virNetcfDriverStateDispose(void *obj); -static void interfaceDriverLock(virNetcfDriverStatePtr driver) +static int +virNetcfDriverStateOnceInit(void) +{ + if (!(virNetcfDriverStateClass = virClassNew(virClassForObjectLockable(), + "virNetcfDriverState", + sizeof(virNetcfDriverState), + virNetcfDriverStateDispose))) + return -1; + return 0; +} + +VIR_ONCE_GLOBAL_INIT(virNetcfDriverState) + +static virNetcfDriverStatePtr driverState = NULL; + +static void +virNetcfDriverStateDispose(void *obj) +{ + virNetcfDriverStatePtr driver = obj; + + if (driver->netcf) + ncf_close(driver->netcf); +} + +static void +interfaceDriverLock(virNetcfDriverStatePtr driver) +{ + virObjectLock(driver); +} + +static void +interfaceDriverUnlock(virNetcfDriverStatePtr driver) +{ + virObjectUnlock(driver); +} + +static int +netcfStateInitialize(bool privileged ATTRIBUTE_UNUSED, + virStateInhibitCallback callback ATTRIBUTE_UNUSED, + void *opaque ATTRIBUTE_UNUSED) +{ + if (virNetcfDriverStateInitialize() < 0) + return -1; + + if (!(driverState = virObjectLockableNew(virNetcfDriverStateClass))) + return -1; + + /* open netcf */ + if (ncf_init(&driverState->netcf, NULL) != 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("failed to initialize netcf")); + virObjectUnref(driverState); + driverState = NULL; + return -1; + } + return 0; +} + +static int +netcfStateCleanup(void) { - virMutexLock(&driver->lock); + if (!driverState) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Attempt to close netcf state driver already closed")); + return -1; + } + + if (virObjectUnref(driverState)) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Attempt to close netcf state driver " + "with open connections")); + return -1; + } + driverState = NULL; + return 0; } -static void interfaceDriverUnlock(virNetcfDriverStatePtr driver) +static int +netcfStateReload(void) { - virMutexUnlock(&driver->lock); + int ret = -1; + + if (!driverState) + return 0; + + interfaceDriverLock(driverState); + ncf_close(driverState->netcf); + if (ncf_init(&driverState->netcf, NULL) != 0) + { + /* this isn't a good situation, because we can't shut down the + * driver as there may still be connections to it. If we set + * the netcf handle to NULL, any subsequent calls to netcf + * will just fail rather than causing a crash. Not ideal, but + * livable (since this should never happen). + */ + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("failed to re-init netcf")); + driverState->netcf = NULL; + goto cleanup; + } + + ret = 0; +cleanup: + interfaceDriverUnlock(driverState); + + return ret; } /* @@ -148,61 +248,30 @@ static struct netcf_if *interfaceDriverGetNetcfIF(struct netcf *ncf, virInterfac return iface; } -static virDrvOpenStatus netcfInterfaceOpen(virConnectPtr conn, - virConnectAuthPtr auth ATTRIBUTE_UNUSED, - unsigned int flags) +static virDrvOpenStatus +netcfInterfaceOpen(virConnectPtr conn, + virConnectAuthPtr auth ATTRIBUTE_UNUSED, + unsigned int flags) { - virNetcfDriverStatePtr driverState; - virCheckFlags(VIR_CONNECT_RO, VIR_DRV_OPEN_ERROR); - if (VIR_ALLOC(driverState) < 0) - goto alloc_error; - - /* initialize non-0 stuff in driverState */ - if (virMutexInit(&driverState->lock) < 0) - { - /* what error to report? */ - goto mutex_error; - } - - /* open netcf */ - if (ncf_init(&driverState->netcf, NULL) != 0) - { - /* what error to report? */ - goto netcf_error; - } + if (!driverState) + return VIR_DRV_OPEN_ERROR; + virObjectRef(driverState); conn->interfacePrivateData = driverState; return VIR_DRV_OPEN_SUCCESS; - -netcf_error: - if (driverState->netcf) - { - ncf_close(driverState->netcf); - } - virMutexDestroy(&driverState->lock); -mutex_error: - VIR_FREE(driverState); -alloc_error: - return VIR_DRV_OPEN_ERROR; } -static int netcfInterfaceClose(virConnectPtr conn) +static int +netcfInterfaceClose(virConnectPtr conn) { if (conn->interfacePrivateData != NULL) { - virNetcfDriverStatePtr driver = conn->interfacePrivateData; - - /* close netcf instance */ - ncf_close(driver->netcf); - /* destroy lock */ - virMutexDestroy(&driver->lock); - /* free driver state */ - VIR_FREE(driver); + virObjectUnref(conn->interfacePrivateData); + conn->interfacePrivateData = NULL; } - conn->interfacePrivateData = NULL; return 0; } @@ -1070,7 +1139,7 @@ static int netcfInterfaceChangeRollback(virConnectPtr conn, unsigned int flags) #endif /* HAVE_NETCF_TRANSACTIONS */ static virInterfaceDriver interfaceDriver = { - "netcf", + .name = INTERFACE_DRIVER_NAME, .interfaceOpen = netcfInterfaceOpen, /* 0.7.0 */ .interfaceClose = netcfInterfaceClose, /* 0.7.0 */ .connectNumOfInterfaces = netcfConnectNumOfInterfaces, /* 0.7.0 */ @@ -1093,11 +1162,19 @@ static virInterfaceDriver interfaceDriver = { #endif /* HAVE_NETCF_TRANSACTIONS */ }; +static virStateDriver interfaceStateDriver = { + .name = INTERFACE_DRIVER_NAME, + .stateInitialize = netcfStateInitialize, + .stateCleanup = netcfStateCleanup, + .stateReload = netcfStateReload, +}; + int netcfIfaceRegister(void) { if (virRegisterInterfaceDriver(&interfaceDriver) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("failed to register netcf interface driver")); return -1; } + virRegisterStateDriver(&interfaceStateDriver); return 0; } -- 1.7.11.7

4 5

[libvirt] Doc: How to use NPIV in libvirt
by Osier Yang 12 Sep '13

12 Sep '13

Before posting it to WIKI or somewhere, I want to see if there is any suggestions on it, or if I missed something. ============================================ How to use NPIV in libvirt I planned to wrote a document about how to use NPIV in libvirt after more features are supported, but it looks like I can't wait till then, got lots lots of questions from both the bugs and mails. So here we go. The document tries to summary up the things about NPIV that libvirt supports till now, and the TODO list. Feedback or suggestion is welcomed. 1) How to find out which HBA(s) support vHBA For libvirt newer than "1.0.4", you can find it out simply by: # virsh nodedev-list --cap vports "--cap vports" is to tell "nodedev-list" only outputs the devices which support "vports" capability, i.e. support vHBA. And also since version "1.0.4", you should be able to know the maximum vports the HBA supports and the current vports number from the HBA's XML, e.g. # virsh nodedev-dumpxml scsi_host5 <device> <name>scsi_host5</name> <parent>pci_0000_04_00_1</parent> <capability type='scsi_host'> <host>5</host> <capability type='fc_host'> <wwnn>2001001b32a9da4e</wwnn> <wwpn>2101001b32a9da4e</wwpn> <fabric_wwn>2001000dec9877c1</fabric_wwn> </capability> <capability type='vport_ops'> <max_vports>164</max_vports> <vports>5</vports> </capability> </capability> </device> For libvirt older than "1.0.4", it's a bit complicated than above: First you need to find out all the HBAs, e.g. # virsh nodedev-list --cap scsi_host scsi_host0 scsi_host1 scsi_host2 scsi_host3 scsi_host4 scsi_host5 And then, to see if the HBA supports vHBA, check if the dumped XML contains "vport_ops" capability. E.g. # virsh nodedev-dumpxml scsi_host3 <device> <name>scsi_host3</name> <parent>pci_0000_00_08_0</parent> <capability type='scsi_host'> <host>3</host> </capability> </device> That says "scsi_host3" doesn't support vHBA # virsh nodedev-dumpxml scsi_host5 <device> <name>scsi_host5</name> <parent>pci_0000_04_00_1</parent> <capability type='scsi_host'> <host>5</host> <capability type='fc_host'> <wwnn>2001001b32a9da4e</wwnn> <wwpn>2101001b32a9da4e</wwpn> <fabric_wwn>2001000dec9877c1</fabric_wwn> </capability> <capability type='vport_ops' /> </capability> </device> But "scsi_host5" supports it. One might be confused with the node device naming style (e.g. scsi_host5) in this document and RHEL6 Virtualization Guide [1] (pci_10df_fe00_scsi_host_0). It's because of libvirt has two backends for node device driver: udev and HAL. We prefer the udev backend more than HAL backend in internal implementation, I think there is good enough reason to do so (HAL is maintenance mode now). I believe udev backend is used more than HAL backend, but if your destribution packager build libvirt without udev backend, don't be surprised with the node device names like the ones in [1]. 2) How to create a vHBA Pick up one HBA which supports vHBA, use it's "node device name" as the "parent" of vHBA, and specify the "wwnn" and "wwpn" in the vHBA's XML. E.g. <device> <name>scsi_host6</name> <parent>scsi_host5</parent> <capability type='scsi_host'> <capability type='fc_host'> <wwnn>2001001b32a9da5e</wwnn> <wwpn>2101001b32a9da5e</wwpn> </capability> </capability> </device> Then create the vHBA with virsh command "nodedev-create" (assuming above XML file is named "vhba.xml"): # virsh nodedev-create vhba.xml Node device scsi_host6 created from vhba.xml Since "0.9.10", libvirt will generate "wwnn" and "wwpn" automatically if they are not specified. It means one can create the vHBA by a more simple XML like: <device> <parent>scsi_host5</parent> <capability type='scsi_host'> <capability type='fc_host'> </capability> </capability> </device> 3) How to destroy a vHBA As usual, destroying something is always simpler than creating it: # virsh nodedev-destroy scsi_host6 Destroyed node device 'scsi_host6' You might already realize that the vHBA is removed permanently, don't be surprised, it's the life, node device driver doesn't support persistent config. I won't say it's nightmare for users who screams when realizing the vHBA disappeared after a system rebooting, but it's relatively not good, (assuming that you got the wwnn:wwpn pair from the storage admin, but didn't record it). Fortunately, we support the persistent vHBA now, see next section for details. 4) How to create a persistent vHBA Let's go back to the history a bit firstly. Prior to libvirt "1.0.5", one can define a "scsi" type pool based on a (v)HBA by it's scsi host name (e.g. "host5" in XML below). E.g. <pool type='scsi'> <name>poolhba0</name> <uuid>e9392370-2917-565e-692b-d057f46512d6</uuid> <capacity unit='bytes'>0</capacity> <allocation unit='bytes'>0</allocation> <available unit='bytes'>0</available> <source> <adapter name='host0'/> </source> <target> <path>/dev/disk/by-path</path> <permissions> <mode>0700</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool> Quite nice? yeah, at least it looks so, but the problem is the scsi host number is *unstable* (it can be changed after system rebooting, or kernel module reloading, or a vHBA recreating etc), and thus the "scsi" type pool based on a (v)HBA becomes unstable too. Obviously it doesn't help on the "persistent vHBA" problem. To solve the problems, since libvirt "1.0.5", we introduced new XML schema to indicate the (v)HBA. An example of the XML: <pool type='scsi'> <name>poolvhba0</name> <uuid>e9392370-2917-565e-692b-d057f46512d6</uuid> <source> <adapter type='fc_host' parent='scsi_host5' wwnn='20000000c9831b4b' wwpn='10000000c9831b4b'/> </source> <target> <path>/dev/disk/by-path</path> <permissions> <mode>0700</mode> <owner>0</owner> <group>0</group> </permissions> </target> </pool> It allows to define a "scsi" type pool based on either a HBA or a vHBA. For HBA, "parent" attribute can be omitted. For vHBA, if "parent" is not specified, libvirt will pick up the first HBA which supports vHBA, and doesn't exceed the maximum vports it supports, automatically. For the pool based on a vHBA, When the pool is starting, libvirt will check if the specified vHBA (wwnn:wwpn) is existing on host or not, if it doesn't exist yet, libvirt will create it automatically. When the pool is being stopped, the vHBA is destroyed. But since storage driver supports the persistent config, one can easily gets the vHBA with same "wwnn:wwpn" in next starting (Don't scream if your pool is transient). It's not the end if you want to get the vHBA created automatically after system rebooting, you will need to set the pool as "autostart": # virsh pool-autostart poolvhba0 One might be curious about why not to support persistent config for node device driver, and support to create persistent vHBA there. One of the reason is that it will be duplicate with what storage pool does. And another reason (the important one) is we want to assiciate the libvirt storage pool/volume with domain (see section "Use LUN for guest" below). 5) How to find out the LUN's path If you have defined the "scsi" type pool based on the (v)HBA, it's simple to lookup what LUNs attached to the (v)HBA by virsh command "vol-list", e.g. # virsh vol-list poolvhba0 --details Name Path Type Capacity Allocation -------------------------------------------------------------------------------------------------------- unit:0:2:0 /dev/disk/by-path/pci-0000:04:00.1-fc-0x203500a0b85ad1d7-lun-0 block 20.01 GiB 20.01 GiB If you have not defined a "scsi" type pool based on the (v)HBA, you can find it out (v)HBA by either virsh command "nodedev-list --tree", or iterating sysfs manually. To find out the LUNs by virsh command "nodedev-list" (irrelevant ouputs are omitted): # virsh nodedev-list --tree +- pci_0000_00_0d_0 | | | +- pci_0000_04_00_0 | | | | | +- scsi_host4 | | | +- pci_0000_04_00_1 | | | +- scsi_host5 | | | +- scsi_host7 | +- scsi_target5_0_0 | | | | | +- scsi_5_0_0_0 | | | +- scsi_target5_0_1 | | | | | +- scsi_5_0_1_0 | | | +- scsi_target5_0_2 | | | | | +- scsi_5_0_2_0 | | | | | +- block_sdb_3600a0b80005adb0b0000ab2d4cae9254 | | | +- scsi_target5_0_3 | | | +- scsi_5_0_3_0 "scsi_host5" is an HBA on my host, it has a LUN named "block_sdb_3600a0b80005adb0b0000ab2d4cae9254", don't be confused with the naming, it's the naming style libvirt uses, meaningful only for libvirt. It indicates the LUN has a short device path "/dev/sdb", and a ID "3600a0b80005adb0b0000ab2d4cae9254": # ls /dev/disk/by-id/ | grep 3600a0b80005adb0b0000ab2d4cae9254 scsi-3600a0b80005adb0b0000ab2d4cae9254 To manually find the LUNs of a (v)HBA: First, you need to iterate over all the directores begins with the SCSI scsi host number of the v(HBA) under "/sys/bus/scsi/devices". E.g. I will look up the LUNs of the HBA with SCSI host number 5 on my host: # ls /sys/bus/scsi/devices/5:* -d /sys/bus/scsi/devices/5:0:0:0 /sys/bus/scsi/devices/5:0:1:0 /sys/bus/scsi/devices/5:0:2:0 /sys/bus/scsi/devices/5:0:3:0 # ls /sys/bus/scsi/devices/5\:0\:3\:0/block/sdc It means scsi_host5 has a LUN attached with device name "sdc" on address "5:0:3:0". # ls /sys/bus/scsi/devices/5\:0\:1\:0/ | grep block device_blocked scsi_host5 doesn't have a LUN attached on address "5:0:2:0" The device name like "sdc" is not stable, to find out the stable path, find out the symbol link which points to the device name. E.g. # ls -l /dev/disk/by-path/ lrwxrwxrwx. 1 root root 9 Sep 10 22:28 pci-0000:00:07.0-scsi-0:0:0:0 -> ../../sda lrwxrwxrwx. 1 root root 10 Sep 10 22:28 pci-0000:00:07.0-scsi-0:0:0:0-part1 -> ../../sda1 lrwxrwxrwx. 1 root root 9 Sep 10 22:28 pci-0000:04:00.1-fc-0x203400a0b85ad1d7-lun-0 -> ../../sdc Then "/dev/disk/by-path/pci-0000:04:00.1-fc-0x203400a0b85ad1d7-lun-0" is the stable path of the LUN attached to address "5:0:3:0". Of course, you can use the similiar method to get the "by-id | by-uuid | by-label" stable path. 6) Use the LUN to guest Since libvirt "1.0.5", we supported to use the storage volume as disk source by two new attributes ("pool" and "volume") for disk "<source"> element. E.g. <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='poolvhba0' volume='unit:0:2:0 '/> <target dev='hda' bus='ide'/> </disk> There are lots of advantage to do so. Since the mainly purpose of the document is about "how to use", I will only mention two here to persuade you using the it. First, you don't need to look up the LUN's path youself. Second, assuming that you want to migrate a domain which uses a LUN attached to a vHBA, do you want to create the vHBA manually on target host? With the pool, you can simply define/start a pool with same config on target host. So, if your libvirt is newer than "1.0.5", we recommend you to define the "scsi" type pool based on the (v)HBA, and use "pool/volume" names to use the LUN as disk source. You can either use the LUN as qemu emulated disk, or passthrough it to guest. To use it as qemu emulated disk, specifying the "device" attribute as "device='disk|cdrom|floppy'". E.g. <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='blk-pool0' volume='blk-pool0-vol0'/> <target dev='hda' bus='ide'/> </disk> Or (using the LUN's path directly) <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/disk/by-path/pci-0000\:04\:00.1-fc-0x203400a0b85ad1d7-lun-0'/> <target dev='sda' bus='scsi'/> </disk> To passthrough the LUN, specifying the "device" attribute as "device='lun'", e.g. <disk type='volume' device='lun'> <driver name='qemu' type='raw'/> <source dev='/dev/disk/by-path/pci-0000\:04\:00.1-fc-0x203400a0b85ad1d7-lun-0'/> <target dev='sda' bus='scsi'/> </disk> 6) Future work * NPIV based SCSI host passthrough That's what the users ask: How to passthrough a (v)HBA to guest? * Expose vendor information, LUN's path, state of (v)HBA in its XML * May be a virsh command to simplify vHBA creation with options [1] http://www.linuxtopia.org/online_books/rhel6/rhel_6_virtualization/rhel_6_v… Regards, Osier

2 1

[libvirt] [v0.9.12-maint v2 00/12] Debian's 0.9.12 patches
by Guido Günther 12 Sep '13

12 Sep '13

These are the patches Debian is currently carrying on 0.9.12. Most are straight cherry-picks. Since we're maintaining 0.9.12 for our current stable release I'm happy to push these to v0.9.12-maint. Daniel P. Berrange (2): Don't ignore return value of qemuProcessKill Fix race condition when destroying guests Eric Blake (1): build: fix virnetlink on glibc 2.11 Jiri Denemark (3): daemon: Fix crash in virTypedParameterArrayClear Revert "rpc: Discard non-blocking calls only when necessary" qemu: Add support for -no-user-config Luca Tettamanti (1): Make sure regfree is called close to it's usage Martin Kletzander (1): security: Fix libvirtd crash possibility Peter Krempa (4): qemu: Fix off-by-one error while unescaping monitor strings rpc: Fix crash on error paths of message dispatching conf: Remove callback from stream when freeing entries in console hash conf: Remove console stream callback only when freeing console helper cfg.mk | 3 +- daemon/remote.c | 16 +- src/conf/virconsole.c | 13 ++ src/qemu/qemu_capabilities.c | 7 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 11 +- src/qemu/qemu_driver.c | 21 ++- src/qemu/qemu_monitor.c | 11 +- src/rpc/virnetclient.c | 21 +-- src/rpc/virnetserverclient.c | 3 + src/rpc/virnetserverprogram.c | 11 +- src/storage/storage_backend_logical.c | 5 +- src/util/virnetlink.h | 2 + tests/qemuhelpdata/qemu-1.1 | 268 ++++++++++++++++++++++++++++++++++ tests/qemuhelpdata/qemu-1.1-device | 160 ++++++++++++++++++++ tests/qemuhelptest.c | 75 ++++++++++ 16 files changed, 586 insertions(+), 42 deletions(-) create mode 100644 tests/qemuhelpdata/qemu-1.1 create mode 100644 tests/qemuhelpdata/qemu-1.1-device -- 1.8.4.rc3

3 14

[libvirt] [PATCH] LXC: don't try to mount selinux filesystem when user namespace enabled
by Gao feng 12 Sep '13

12 Sep '13

Right now we mount selinuxfs even user namespace is enabled and ignore the error. But we shouldn't ignore these errors when user namespace is not enabled. This patch skips mounting selinuxfs when user namespace enabled. Signed-off-by: Gao feng <gaofeng(a)cn.fujitsu.com> --- src/lxc/lxc_container.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 661ac52..84b1b57 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -797,7 +797,7 @@ static int lxcContainerMountBasicFS(bool userns_enabled) #if WITH_SELINUX if (STREQ(mnts[i].src, SELINUX_MOUNT) && - !is_selinux_enabled()) + (!is_selinux_enabled() || userns_enabled)) continue; #endif @@ -814,12 +814,6 @@ static int lxcContainerMountBasicFS(bool userns_enabled) VIR_DEBUG("Mount %s on %s type=%s flags=%x, opts=%s", srcpath, mnts[i].dst, mnts[i].type, mnts[i].mflags, mnts[i].opts); if (mount(srcpath, mnts[i].dst, mnts[i].type, mnts[i].mflags, mnts[i].opts) < 0) { -#if WITH_SELINUX - if (STREQ(mnts[i].src, SELINUX_MOUNT) && - (errno == EINVAL || errno == EPERM)) - continue; -#endif - virReportSystemError(errno, _("Failed to mount %s on %s type %s flags=%x opts=%s"), srcpath, mnts[i].dst, NULLSTR(mnts[i].type), -- 1.8.3.1

2 1

[libvirt] [PATCH] qemu: Fix checking of guest ABI compatibility when reverting snapshots
by Peter Krempa 12 Sep '13

12 Sep '13

When reverting a live internal snapshot with a live guest the ABI compatiblity check was comparing a "migratable" definition with a normal one. This resulted in the check failing with: revert requires force: Target device address type none does not match source pci This patch generates a "migratable" definition from the actual one to check against the definition from the snapshot to avoid this problem. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1006886 --- src/qemu/qemu_driver.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index bbf2d23..ae1948f 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -13037,6 +13037,7 @@ static int qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, qemuDomainObjPrivatePtr priv; int rc; virDomainDefPtr config = NULL; + virDomainDefPtr migratableDef = NULL; virQEMUDriverConfigPtr cfg = NULL; virCapsPtr caps = NULL; @@ -13151,8 +13152,13 @@ static int qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, * to have finer control. */ if (virDomainObjIsActive(vm)) { /* Transitions 5, 6, 8, 9 */ - /* Check for ABI compatibility. */ - if (config && !virDomainDefCheckABIStability(vm->def, config)) { + /* Check for ABI compatibility. We need to do this check against + * the migratable XML or it will always fail otherwise */ + if (!(migratableDef = qemuDomainDefCopy(driver, vm->def, + VIR_DOMAIN_XML_MIGRATABLE))) + goto cleanup; + + if (config && !virDomainDefCheckABIStability(migratableDef, config)) { virErrorPtr err = virGetLastError(); if (!(flags & VIR_DOMAIN_SNAPSHOT_REVERT_FORCE)) { @@ -13357,6 +13363,7 @@ cleanup: } if (vm) virObjectUnlock(vm); + virDomainDefFree(migratableDef); virObjectUnref(caps); virObjectUnref(cfg); -- 1.8.3.2

2 2

[libvirt] USB: about the auto identify funciton for guest OS
by Gonglei (Arei) 12 Sep '13

12 Sep '13

Hi, all Qemu upstream had achieved USB Auto Connect function for the guest. the patch was: https://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02341.html However, Libvirt has not provide such an interface that identifies a USB device for pass through with physical port, rather than the device number. Do you have any ideas or plans about this problem? Thanks in advance. Best Regards, -Gonglei

1 0

[libvirt] [PATCHv6 0/5] Introduce API to query IP addresses for given domain
by Nehal J Wani 12 Sep '13

12 Sep '13

This feature has been requested for a very long time. Since qemu guest agent gives us reliable results, now the wait is over. The RFC was first proposed by Michal Privoznik: http://www.redhat.com/archives/libvir-list/2012-February/msg00437.html A patch was submitted, using structs: https://www.redhat.com/archives/libvir-list/2012-June/msg00220.html Another patch was submitted, using XML: https://www.redhat.com/archives/libvir-list/2012-June/msg00904.html Neither of the patches were accepted, probably due to lack of extensibility and usability. Hence, we thought of using virTypedParameters for reporting list of interfaces along with their MAC address and IP addresses. The RFC can be found here: https://www.redhat.com/archives/libvir-list/2013-July/msg00084.html The idea of extensibility was rejected and rendered out of scope of libvirt. Hence, we were back to structs. This API is called virDomainInterfaceAddresses which returns a dynamically allocated array of virDomainInterface struct. The great disadvantage is once this gets released, it's written in stone and we cannot change or add an item into it. The API supports two methods: * Return information (list of all associated interfaces with MAC address and IP addresses) of all of the domain interfaces by default (if no interface name is provided) * Return information for the specified interface (if an interface name is provided) v6: * Inclusion of flags, readonly check for guest agent connection * Correction of memory leaks, other small nits. v5: * s/virDomainInterfacesAddresses/virDomainInterfaceAddresses. * Case for IP aliasing handled using virHashTable. * New test cases added, involving multiple and 0 IP addresse(s) per interface. * IP prefix changed from int to unsigned int. * Changes to practice libvirt habits. * https://www.redhat.com/archives/libvir-list/2013-September/msg00003.html v4: * Various style nits, indentation errors, memory leaks fixed. * https://www.redhat.com/archives/libvir-list/2013-August/msg01265.html v3: * Upper bounds to number of interfaces and addresses per interface introduced. * Change from array of structs to array of pointers * ifaces_count moved from function argument to return value * Changes in variable names * Test cases added for qemuAgentGetInterfaces. * https://www.redhat.com/archives/libvir-list/2013-August/msg01215.html v2: * Logical errors, memory leaks and few other errors fixed. * https://www.redhat.com/archives/libvir-list/2013-August/msg00631.html v1: * http://www.redhat.com/archives/libvir-list/2013-July/msg01553.html Nehal J Wani (5): domifaddr: Implement the public APIs domifaddr: Implement the remote protocol domifaddr: Implement the API for qemu domifaddr: Add virsh support domifaddr: Expose python binding daemon/remote.c | 130 ++++++++++++++++++++++++++ examples/python/Makefile.am | 2 +- examples/python/README | 1 + examples/python/domipaddrs.py | 56 +++++++++++ include/libvirt/libvirt.h.in | 38 ++++++++ python/generator.py | 3 + python/libvirt-override-api.xml | 8 +- python/libvirt-override.c | 102 ++++++++++++++++++++ src/driver.h | 6 ++ src/libvirt.c | 135 +++++++++++++++++++++++++++ src/libvirt_public.syms | 6 ++ src/qemu/qemu_agent.c | 201 ++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_agent.h | 3 + src/qemu/qemu_driver.c | 76 +++++++++++++++ src/remote/remote_driver.c | 99 ++++++++++++++++++++ src/remote/remote_protocol.x | 40 +++++++- src/remote_protocol-structs | 24 +++++ tests/qemuagenttest.c | 188 +++++++++++++++++++++++++++++++++++++ tools/virsh-domain-monitor.c | 131 ++++++++++++++++++++++++++ tools/virsh.pod | 18 ++++ 20 files changed, 1264 insertions(+), 3 deletions(-) create mode 100755 examples/python/domipaddrs.py -- 1.7.11.7

3 11

[libvirt] [v0.9.12-maint 08/11] Make sure regree is called close to it's usage
by Luca Tettamanti 12 Sep '13

12 Sep '13

This is a backport of 71da3b66a8455faf8019effe3cf504a31f91f54a. --- src/storage/storage_backend_logical.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/storage/storage_backend_logical.c b/src/storage/storage_backend_logical.c index 9a91dd9..7abb17b 100644 --- a/src/storage/storage_backend_logical.c +++ b/src/storage/storage_backend_logical.c @@ -204,13 +204,16 @@ virStorageBackendLogicalMakeVol(virStoragePoolObjPtr pool, if (err != 0) { char error[100]; regerror(err, reg, error, sizeof(error)); + regfree(reg); virStorageReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to compile regex %s"), error); goto cleanup; } - if (regexec(reg, groups[3], nvars, vars, 0) != 0) { + err = regexec(reg, groups[3], nvars, vars, 0); + regfree(reg); + if (err != 0) { virStorageReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("malformed volume extent devices value")); goto cleanup; -- 1.8.4.rc3

2 3

[libvirt] Xen 4.1 misc issues
by Roberto Sassu 12 Sep '13

12 Sep '13

Hi everyone I'm using Ubuntu 12.04.3 LTS with the Xen hypervisor installed (package version: 4.1.2-2ubuntu2.10), and Libvirt v0.10.2.2 (that interacts with Xen through the libxl driver). I performed some adjustments to have the required features: - Switch from Xend to libxl: I created upstart jobs for xenstored and xenconsoled so that necessary daemons are started earlier enough and Libvirt can contact the hypervisor through libxl. - Add support for Open vSwitch: I added the script 'vif-openvswitch', taken from the master branch of the GIT repository, to the /etc/xen/scripts directory in order to plug network interfaces to Open vSwitch switches. I know that the support for libxl is experimental in Xen 4.1, but I'm wondering if someone has a solution to the following issues: 1) On domain destroy, the host configuration is not clean: if the flag 'force' is set to 0 some entries in the xenstored database are not removed (console, ...) if the flag 'force' is set to 1 (as it is done in Libvirt), the event 'online' associated to the network interface is not triggered and, thus, the vif is not removed from the Open vSwitch switch. To fix this issue, I temporarily added a call to vif-openvswitch into the xen-hotplug-cleanup script. 2) When a domain is started from Libvirt, the console source path does not appear in the output of the command 'virsh dumpxml instance-00000381' 3) Sometimes, a domU is not started at all. If I start a virtual machine from Libvirt through virsh or directly through xl, these tools report that the virtual machine is running but I see no messages coming from the console and the CPU time remains fixed. I'm attaching some files that may be useful to understand the problem: - libvirt.xml: domain specifications (Libvirt format) - domain.xl: domain specifications (Xen format) - libvirt_virsh_dumpxml.log: output of the command 'virsh dumpxml instance-00000381' - xl_create.log: output of the command 'xl create -d domain.xl' - xl_info.log: output of the command 'xl info' - qemu-dm-instance-00000381.log: qemu-dm log - syslog_vif6_0.log: vif attach/detach logs from /var/log/syslog - xenstore-db-not-clean.log: xenstore db entries not removed after 'xl destroy' - libvirt_libxl.log: log from /var/log/libvirt/libxl.log after the execution of the command 'virsh create libvirt.xml' Lastly, I want to add that the image I'm using for the tests is Ubuntu Precise 12.04.3 LTS, taken from the URL: http://cloud-images.ubuntu.com/precise/current/precise-server-cloudimg-amd6… and the kernel is taken from the URL: http://cloud-images.ubuntu.com/precise/current/unpacked/precise-server-clou… Thanks Roberto Sassu

2 2

[libvirt] [PATCH] Fix virsystemdtest for previous commit
by Daniel P. Berrange 12 Sep '13

12 Sep '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The change to query org.freedesktop.DBus.ListActivatableNames to detect systemd broke the test suite, since we did not have stubs to respond to this dbus call. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- tests/virsystemdmock.c | 54 +++++++++++++++++++++++++++++++++----------------- tests/virsystemdtest.c | 4 ++++ 2 files changed, 40 insertions(+), 18 deletions(-) Pushed under build break rule. diff --git a/tests/virsystemdmock.c b/tests/virsystemdmock.c index 5dbd33f..59b312d 100644 --- a/tests/virsystemdmock.c +++ b/tests/virsystemdmock.c @@ -65,29 +65,47 @@ dbus_bool_t dbus_message_set_reply_serial(DBusMessage *message ATTRIBUTE_UNUSED, } DBusMessage *dbus_connection_send_with_reply_and_block(DBusConnection *connection ATTRIBUTE_UNUSED, - DBusMessage *message ATTRIBUTE_UNUSED, + DBusMessage *message, int timeout_milliseconds ATTRIBUTE_UNUSED, - DBusError *error) + DBusError *error ATTRIBUTE_UNUSED) { DBusMessage *reply = NULL; + const char *service = dbus_message_get_destination(message); - if (getenv("FAIL_BAD_SERVICE")) { - DBusMessageIter iter; - const char *error_message = "Something went wrong creating the machine"; - if (!(reply = dbus_message_new(DBUS_MESSAGE_TYPE_ERROR))) - return NULL; - dbus_message_set_error_name(reply, "org.freedesktop.systemd.badthing"); - dbus_message_iter_init_append(reply, &iter); - if (!dbus_message_iter_append_basic(&iter, - DBUS_TYPE_STRING, - &error_message)) { - dbus_message_unref(reply); - return NULL; + if (STREQ(service, "org.freedesktop.machine1")) { + if (getenv("FAIL_BAD_SERVICE")) { + DBusMessageIter iter; + const char *error_message = "Something went wrong creating the machine"; + if (!(reply = dbus_message_new(DBUS_MESSAGE_TYPE_ERROR))) + return NULL; + dbus_message_set_error_name(reply, "org.freedesktop.systemd.badthing"); + dbus_message_iter_init_append(reply, &iter); + if (!dbus_message_iter_append_basic(&iter, + DBUS_TYPE_STRING, + &error_message)) { + dbus_message_unref(reply); + return NULL; + } + } else { + reply = dbus_message_new(DBUS_MESSAGE_TYPE_METHOD_RETURN); } - } else if (getenv("FAIL_NO_SERVICE")) { - dbus_set_error(error, - "org.freedesktop.DBus.Error.ServiceUnknown", - "%s", "The name org.freedesktop.machine1 was not provided by any .service files"); + } else if (STREQ(service, "org.freedesktop.DBus")) { + const char *svc1 = "org.foo.bar.wizz"; + const char *svc2 = "org.freedesktop.machine1"; + DBusMessageIter iter, sub; + reply = dbus_message_new(DBUS_MESSAGE_TYPE_METHOD_RETURN); + dbus_message_iter_init_append(reply, &iter); + dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY, + "s", &sub); + + dbus_message_iter_append_basic(&sub, + DBUS_TYPE_STRING, + &svc1); + if (!getenv("FAIL_NO_SERVICE")) + dbus_message_iter_append_basic(&sub, + DBUS_TYPE_STRING, + &svc2); + dbus_message_iter_close_container(&iter, &sub); } else { reply = dbus_message_new(DBUS_MESSAGE_TYPE_METHOD_RETURN); } diff --git a/tests/virsystemdtest.c b/tests/virsystemdtest.c index a9c6d32..7dc7520 100644 --- a/tests/virsystemdtest.c +++ b/tests/virsystemdtest.c @@ -94,9 +94,11 @@ static int testCreateNoSystemd(const void *opaque ATTRIBUTE_UNUSED) 123, false, NULL)) == 0) { + unsetenv("FAIL_NO_SERVICE"); fprintf(stderr, "%s", "Unexpected create machine success\n"); return -1; } + unsetenv("FAIL_NO_SERVICE"); if (rv != -2) { fprintf(stderr, "%s", "Unexpected create machine error\n"); @@ -126,9 +128,11 @@ static int testCreateBadSystemd(const void *opaque ATTRIBUTE_UNUSED) 123, false, NULL)) == 0) { + unsetenv("FAIL_BAD_SERVICE"); fprintf(stderr, "%s", "Unexpected create machine success\n"); return -1; } + unsetenv("FAIL_BAD_SERVICE"); if (rv != -1) { fprintf(stderr, "%s", "Unexpected create machine error\n"); -- 1.8.3.1

3 2