July 2018 - Devel - libvirt List Archives

[libvirt] [PATCH] completer: Doesn't alloc enough space for null terminated array of strings
by Simon Kobyda 12 Jul '18

12 Jul '18

Functions virshSecretEventNameCompleter, virshPoolEventNameCompleter, virshNodedevEventNameCompleter allocates only enough space for array of N strings. However these are null terminated strings, so program needs to alloc space for array of N+1 strings. How to replicate error: valgrind virsh, use completer for '-nodedev-event --event' or '-pool-event --event' or '-secret-event --event'. --- tools/virsh-completer.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/virsh-completer.c b/tools/virsh-completer.c index 2327e08340..be59ea2e82 100644 --- a/tools/virsh-completer.c +++ b/tools/virsh-completer.c @@ -709,7 +709,7 @@ virshSecretEventNameCompleter(vshControl *ctl ATTRIBUTE_UNUSED, virCheckFlags(0, NULL); - if (VIR_ALLOC_N(ret, VIR_SECRET_EVENT_ID_LAST) < 0) + if (VIR_ALLOC_N(ret, VIR_SECRET_EVENT_ID_LAST + 1) < 0) goto error; for (i = 0; i < VIR_SECRET_EVENT_ID_LAST; i++) { @@ -761,7 +761,7 @@ virshPoolEventNameCompleter(vshControl *ctl ATTRIBUTE_UNUSED, virCheckFlags(0, NULL); - if (VIR_ALLOC_N(ret, VIR_STORAGE_POOL_EVENT_ID_LAST) < 0) + if (VIR_ALLOC_N(ret, VIR_STORAGE_POOL_EVENT_ID_LAST + 1) < 0) goto error; for (i = 0; i < VIR_STORAGE_POOL_EVENT_ID_LAST; i++) { @@ -787,7 +787,7 @@ virshNodedevEventNameCompleter(vshControl *ctl ATTRIBUTE_UNUSED, virCheckFlags(0, NULL); - if (VIR_ALLOC_N(ret, VIR_NODE_DEVICE_EVENT_ID_LAST) < 0) + if (VIR_ALLOC_N(ret, VIR_NODE_DEVICE_EVENT_ID_LAST + 1) < 0) goto error; for (i = 0; i < VIR_NODE_DEVICE_EVENT_ID_LAST; i++) { -- 2.17.1

2 1

[libvirt] [PATCH] examples: Add clean-traffic-gateway into nwfilters
by Ales Musil 12 Jul '18

12 Jul '18

This filter should be used to limit traffic between VMs based on their MAC adddresses. The MAC address can be set with GATEWAY_MAC and mask with GATEWAY_MAC_MASK variable. Signed-off-by: Ales Musil <amusil(a)redhat.com> --- examples/xml/nwfilter/clean-traffic-gateway.xml | 36 +++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 examples/xml/nwfilter/clean-traffic-gateway.xml diff --git a/examples/xml/nwfilter/clean-traffic-gateway.xml b/examples/xml/nwfilter/clean-traffic-gateway.xml new file mode 100644 index 0000000..d1e7c81 --- /dev/null +++ b/examples/xml/nwfilter/clean-traffic-gateway.xml @@ -0,0 +1,36 @@ +<filter name='clean-traffic-gateway'> +  + <filterref filter='no-mac-spoofing'/> + +  + <filterref filter='no-ip-spoofing'/> + +  + <filterref filter='no-arp-spoofing'/> + +  + <rule action='accept' direction='inout' priority='-500'> + <mac protocolid='arp'/> + </rule> + +  + <rule action='accept' direction='in'> + <mac match='yes' srcmacaddr='$GATEWAY_MAC' + srcmacmask='$GATEWAY_MAC_MASK'/> + </rule> + +  + <rule action='accept' direction='out'> + <mac match='yes' dstmacaddr='$GATEWAY_MAC' + dstmacmask='$GATEWAY_MAC_MASK'/> + </rule> + +  + <filterref filter='no-other-l2-traffic'/> + +  + <filterref filter='qemu-announce-self'/> +</filter> -- 1.8.3.1

1 0

[libvirt] [PATCH v1] storage: prefer using newDef to save configfile
by Shichangkuo 12 Jul '18

12 Jul '18

When re-defining an active storage pool, the configfile has not changed. This issue was introduced by bfcd8fc, storage: Use virStoragePoolObjGetDef accessor for driver. So we prefer using newDef to save configfile. Signed-off-by: shichangkuo <shi.changkuo(a)h3c.com> --- src/storage/storage_driver.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 254818e..8070d15 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -810,13 +810,14 @@ storagePoolDefineXML(virConnectPtr conn, if (!(obj = virStoragePoolObjAssignDef(driver->pools, newDef))) goto cleanup; - newDef = NULL; + newDef = virStoragePoolObjGetNewDef(obj); def = virStoragePoolObjGetDef(obj); - if (virStoragePoolObjSaveDef(driver, obj, def) < 0) { + if (virStoragePoolObjSaveDef(driver, obj, newDef ? newDef : def) < 0) { virStoragePoolObjRemove(driver->pools, obj); virObjectUnref(obj); obj = NULL; + newDef = NULL; goto cleanup; } @@ -826,6 +827,7 @@ storagePoolDefineXML(virConnectPtr conn, VIR_INFO("Defining storage pool '%s'", def->name); pool = virGetStoragePool(conn, def->name, def->uuid, NULL, NULL); + newDef = NULL; cleanup: virObjectEventStateQueue(driver->storageEventState, event); -- 1.7.9.5 ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

1 0

Re: [libvirt] opening tap devices that are created in a container
by Jason Baron 11 Jul '18

11 Jul '18

On 07/11/2018 06:10 AM, nert@wheatley wrote: > On Mon, Jul 09, 2018 at 05:00:49PM -0400, Jason Baron wrote: >> >> >> On 07/08/2018 02:01 AM, Martin Kletzander wrote: >>> On Thu, Jul 05, 2018 at 06:24:20PM +0200, Roman Mohr wrote: >>>> On Thu, Jul 5, 2018 at 4:20 PM Jason Baron <jbaron(a)akamai.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> Opening tap devices, such as macvtap, that are created in >>>>> containers is >>>>> problematic because the interface for opening tap devices is via >>>>> /dev/tapNN and devtmpfs is not typically mounted inside a container as >>>>> its not namespace aware. It is possible to do a mknod() in the >>>>> container, once the tap devices are created, however, since the tap >>>>> devices are created dynamically its not possible to apriori allow >>>>> access >>>>> to certain major/minor numbers, since we don't know what these are >>>>> going >>>>> to be. In addition, its desirable to not allow the mknod capability in >>>>> containers. This behavior, I think is somewhat inconsistent with the >>>>> tuntap driver where one can create tuntap devices inside a >>>>> container by >>>>> first opening /dev/net/tun and then using them by supplying the tuntap >>>>> device name via the ioctl(TUNSETIFF). And since TUNSETIFF validates >>>>> the >>>>> network namespace, one is limited to opening network devices that >>>>> belong >>>>> to your current network namespace. >>>>> >>>>> Here are some options to this issue, that I wanted to get feedback >>>>> about, and just wondering if anybody else has run into this. >>>>> >>>>> 1) >>>>> >>>>> Don't create the tap device, such as macvtap in the container. >>>>> Instead, >>>>> create the tap device outside of the container and then move it >>>>> into the >>>>> desired container network namespace. In addition, do a mknod() for the >>>>> corresponding /dev/tapNN device from outside the container before >>>>> doing >>>>> chroot(). >>>>> >>>>> This solution still doesn't allow tap devices to be created inside the >>>>> container. Thus, in the case of kubevirt, which runs libvirtd >>>>> inside of >>>>> a container, it would mean changing libvirtd to open existing tap >>>>> devices (as opposed to the current behavior of creating new ones). >>>>> This >>>>> would not require any kernel changes, but as mentioned seems >>>>> inconsistent with the tuntap interface. >>>>> >>>> >>>> For KubeVirt, apart from how exactly the device ends up in the >>>> container, I >>>> would want to pursue a way where all network preparations which require >>>> privileges happens from a privileged process *outside* of the >>>> container. >>>> Like CNI solutions do it. They run outside, have privileges and then >>>> create >>>> devices in the right network/mount namespace or move them there. The >>>> final >>>> goal for KubeVirt is that our pod with the qemu process is completely >>>> unprivileged and privileged setup happens from outside. >>>> >>>> As a consequence, and depending on which route Dan pursues with the >>>> restructured libvirt, I would assume that either a privileged >>>> libvirtd-part >>>> outside of containers creates the devices by entering the right >>>> namespaces, >>>> or that libvirt in the container can consume pre-created tun/tap >>>> devices, >>>> like qemu. >>>> >>> >>> That would be nice, but as far as I understand there will always be a >>> need for >>> some privileges if you want to use a tap device. It's nice that CNI >>> does that >>> and all the containers can run unprivileged, but that's because they do >>> not open >>> the tap device and they do not do any privileged operations on it. But >>> QEMU >>> needs to. So the only way would be passing an opened fd to the >>> container or >>> opening the tap device there and making the fd usable for one process in >>> the >>> container. Is this already supported for some type of containers in >>> some way? >>> >>> Martin >> >> Hi, >> >> So another option here call it #3 is to pass open fds via unix sockets. >> If there are privileged operations that QEMU is trying to do with the fd >> though, how will opening it first and then passing it to an unprivileged >> QEMU address that? Is the opener doing those operations first? >> > > Sorry for the confusion, but QEMU is not doing any privileged > operations. I got > confused by the fact that anyone can open and do a R/W on a tap device. > But it > looks like that's on purpose. No capabilities are needed for opening > /dev/net/tun and calling ioctl(TUNSETIFF) with existing name and then > doing R/W > operations on it. It just works. > > Correct me if I'm wrong, but to sum it all up, the only things that we > need to > figure out (which might possibly be solved by ideas in the other thread) > are: > > tap: > - Existence of /dev/net/tun > - Having permissions to open it (0666 by default, shouldn't be a nig deal) > - Knowing the device name > > macvtap: > - Existence of /dev/tapXX > - Having permissions to open /dev/tapXX > - One of the following: > - Knowing the device name (and being able to translate it using a > netlink socket) > - Knowing the the device index > Right - from the device name one can grab the device index using SIOCGIFINDEX and then use that to access /dev/tap{device index}. Since devtmpfs is not mounted in containers (since its not namespaced) and mknod() is I think often not allowed, the mknod() has to happen by a privileged process when the the container is being created. In addition, libvirtd would need to be changed to open this existing device (currently it only opens macvtap devices that it creates). This is option #1. > The rest should be an implementation detail. > > Am I right? Did I miss anything? I don't think so, I'm interested if option #1 is workable or if there is interest in option #2 which is to do something like /dev/net/tun in the kernel for macvtap devices. Since as Daniel pointed out something like option #1 is going to be needed anyways to work on older kernels it seems like the best option? Thanks, -Jason

1 0

[libvirt] [PATCH] Changed LPC slot from 1 to 31
by Ivan Mishonov 11 Jul '18

11 Jul '18

--- src/bhyve/bhyve_command.c | 2 +- src/bhyve/bhyve_device.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c index 802997bd2d..e595b3d6c1 100644 --- a/src/bhyve/bhyve_command.c +++ b/src/bhyve/bhyve_command.c @@ -329,7 +329,7 @@ static int bhyveBuildLPCArgStr(const virDomainDef *def ATTRIBUTE_UNUSED, virCommandPtr cmd) { - virCommandAddArgList(cmd, "-s", "1,lpc", NULL); + virCommandAddArgList(cmd, "-s", "31,lpc", NULL); return 0; } diff --git a/src/bhyve/bhyve_device.c b/src/bhyve/bhyve_device.c index 03aa6c93bd..2ed3013552 100644 --- a/src/bhyve/bhyve_device.c +++ b/src/bhyve/bhyve_device.c @@ -48,9 +48,9 @@ bhyveCollectPCIAddress(virDomainDefPtr def ATTRIBUTE_UNUSED, if (addr->domain == 0 && addr->bus == 0) { if (addr->slot == 0) { return 0; - } else if (addr->slot == 1) { + } else if (addr->slot == 31) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("PCI bus 0 slot 1 is reserved for the implicit " + _("PCI bus 0 slot 31 is reserved for the implicit " "LPC PCI-ISA bridge")); return -1; } -- 2.18.0

3 3

[libvirt] [jenkins-ci PATCH 0/8] lcitool: Rewrite in Python
by Andrea Bolognani 11 Jul '18

11 Jul '18

While the previous implementation has served us well, it was very quickly cobbled together using a language that's not really suitable for the purpose; the fact that we had to embed a Perl (previously Python) script in there is a clear indication that we had outgrown the language pretty much from the get go, and while I'm weirdly proud of the hackish way I implemented inventory handling I'll take a proper YAML parser instead any day :) The new implementation is not quite a drop-in replacement, but getting used to it should take very little time; most importantly, the new command line syntax lends itself to being extended in ways that had simply been impossible previously, and we're going to take advantage of the fact very soon when we integrate the Dockerfile generator (see [1]) and [secret feature redacted]. We also get some minor but neat improvements like much better host list handling and XDG_CONFIG_HOME support. The script is compatible with both Python 2.7 and Python 3, and doesn't rely on any downstream patch being applied to the former. I'm absolutely not great at Python, so any input on style and such will be greatly appreciated. [1] https://www.redhat.com/archives/libvir-list/2018-June/msg01238.html Andrea Bolognani (8): lcitool: Drop shell implementation lcitool: Stub out Python implementation lcitool: Add tool configuration handling lcitool: Add inventory handling lcitool: Implement the 'list' action lcitool: Implement the 'install' action lcitool: Implement the 'update' action guests: Update documentation guests/README.markdown | 8 +- guests/lcitool | 585 +++++++++++++++++++++++++---------------- 2 files changed, 366 insertions(+), 227 deletions(-) -- 2.17.1

1 8

[libvirt] Shared memoryBacking
by Marc-André Lureau 11 Jul '18

11 Jul '18

Hi, While trying to add vhost-user-gpu support to libvirt, I am wondering how the guest should be configured to enable domain memory sharing. Naively, I thought this alone should work: <memoryBacking> <access mode='shared'/> </memoryBacking> But it doesn't seem to produce memory-backend-file share=on or memory-backend-memfd (the later would be better for my case) Any opinion on how to change that? thanks -- Marc-André Lureau

1 0

[libvirt] [PATCH v2 0/7] Enable vfio-pci 'property' for mediated device
by Erik Skultety 11 Jul '18

11 Jul '18

RFC here: https://www.redhat.com/archives/libvir-list/2018-May/msg02218.html Since v1 [1]: - remodeled egl-headless to be a standalone graphics element instead of a result of some automagic with graphic's <gl> element - pushed the first 5 simple fixes that were RB'd - fixed some nits raised during review [1] https://www.redhat.com/archives/libvir-list/2018-June/msg01740.html Erik Skultety (7): qemu: caps: Introduce a capability for egl-headless conf: Introduce a new graphics display type 'headless' qemu: caps: Add vfio-pci.display capability conf: Introduce virDomainGraphicsDefHasOpenGL helper conf: Introduce new <hostdev> attribute 'display' qemu: command: Enable formatting vfio-pci.display option onto cmdline docs: Update news about the VNC console enablement for mdevs docs/formatdomain.html.in | 52 ++++++++- docs/news.xml | 10 ++ docs/schemas/domaincommon.rng | 8 ++ src/conf/domain_conf.c | 67 ++++++++++- src/conf/domain_conf.h | 5 + src/libvirt_private.syms | 1 + src/libxl/libxl_conf.c | 1 + src/qemu/qemu_capabilities.c | 8 ++ src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 59 +++++++++- src/qemu/qemu_domain.c | 122 ++++++++++++++++++++- src/qemu/qemu_driver.c | 2 + src/qemu/qemu_hotplug.c | 1 + src/qemu/qemu_process.c | 4 + src/vmx/vmx.c | 1 + tests/domaincapsschemadata/full.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 2 + tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 2 + tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 2 + tests/qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 2 + tests/qemuxml2argvdata/graphics-egl-headless.args | 26 +++++ tests/qemuxml2argvdata/graphics-egl-headless.xml | 31 ++++++ .../qemuxml2argvdata/graphics-sdl-egl-headless.xml | 35 ++++++ .../graphics-spice-egl-headless.args | 31 ++++++ .../graphics-spice-egl-headless.xml | 36 ++++++ .../graphics-spice-invalid-egl-headless.xml | 37 +++++++ .../graphics-vnc-egl-headless.args | 28 +++++ .../qemuxml2argvdata/graphics-vnc-egl-headless.xml | 37 +++++++ .../hostdev-mdev-display-missing-graphics.xml | 35 ++++++ .../hostdev-mdev-display-spice-egl-headless.args | 32 ++++++ .../hostdev-mdev-display-spice-egl-headless.xml | 40 +++++++ .../hostdev-mdev-display-spice-opengl.args | 31 ++++++ .../hostdev-mdev-display-spice-opengl.xml | 41 +++++++ .../hostdev-mdev-display-vnc-egl-headless.args | 32 ++++++ .../hostdev-mdev-display-vnc-egl-headless.xml | 40 +++++++ .../qemuxml2argvdata/hostdev-mdev-display-vnc.args | 31 ++++++ .../qemuxml2argvdata/hostdev-mdev-display-vnc.xml | 39 +++++++ tests/qemuxml2argvdata/hostdev-mdev-display.xml | 39 +++++++ tests/qemuxml2argvtest.c | 48 ++++++++ .../graphics-spice-egl-headless.xml | 44 ++++++++ .../graphics-vnc-egl-headless.xml | 42 +++++++ .../hostdev-mdev-display-active.xml | 47 ++++++++ .../hostdev-mdev-display-inactive.xml | 47 ++++++++ tests/qemuxml2xmltest.c | 4 + 50 files changed, 1202 insertions(+), 10 deletions(-) create mode 100644 tests/qemuxml2argvdata/graphics-egl-headless.args create mode 100644 tests/qemuxml2argvdata/graphics-egl-headless.xml create mode 100644 tests/qemuxml2argvdata/graphics-sdl-egl-headless.xml create mode 100644 tests/qemuxml2argvdata/graphics-spice-egl-headless.args create mode 100644 tests/qemuxml2argvdata/graphics-spice-egl-headless.xml create mode 100644 tests/qemuxml2argvdata/graphics-spice-invalid-egl-headless.xml create mode 100644 tests/qemuxml2argvdata/graphics-vnc-egl-headless.args create mode 100644 tests/qemuxml2argvdata/graphics-vnc-egl-headless.xml create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-missing-graphics.xml create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-egl-headless.args create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-egl-headless.xml create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-opengl.args create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-spice-opengl.xml create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-vnc-egl-headless.args create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-vnc-egl-headless.xml create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-vnc.args create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display-vnc.xml create mode 100644 tests/qemuxml2argvdata/hostdev-mdev-display.xml create mode 100644 tests/qemuxml2xmloutdata/graphics-spice-egl-headless.xml create mode 100644 tests/qemuxml2xmloutdata/graphics-vnc-egl-headless.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-mdev-display-active.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-mdev-display-inactive.xml -- 2.14.4

2 18

[libvirt] [PATCH v3 0/5] Making libvirt aware of a server need
by Marcos Paulo de Souza 11 Jul '18

11 Jul '18

Hi guys, this is the third version of the patchset to add a new member to virConnectDriver in order to simplfy the check for a server. Now, libvirt does the work inside virConnectOpenInternal after getting the correct driver from the URI. v2: https://www.redhat.com/archives/libvir-list/2018-July/msg00501.html v1: https://www.redhat.com/archives/libvir-list/2018-July/msg00393.html Changes from v2: * patch 2: Move check for remoteOnly member just before calling connectOpen * (only patch 2 changed in v2) Changes from v1: * Adapted the code following ideas from Matthias Bolte Marcos Paulo de Souza (5): driver.h: Add remoteOnly member to virConnectDriver struct libvirt.c: Return error when remoteOnly is set but server is empty esx_driver: Set remoteOnly member of virConnectDriver hyperv_driver: Set remoteOnly member of virConnectDriver phyp_driver: Set remoteOnly member of virConnectDriver src/driver.h | 2 ++ src/esx/esx_driver.c | 8 +------- src/hyperv/hyperv_driver.c | 8 +------- src/libvirt.c | 7 +++++++ src/phyp/phyp_driver.c | 7 +------ 5 files changed, 12 insertions(+), 20 deletions(-) -- 2.17.1

2 7

[libvirt] [PATCH python] Implement virDomainGetStateParams API
by Bjoern Walk 11 Jul '18

11 Jul '18

From: Marc Hartmayer <mhartmay(a)linux.ibm.com> This patch adds the Python binding for the virDomainGetStateParams API. The Python side can be generated automatically, the C side not. Reviewed-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com> Signed-off-by: Marc Hartmayer <mhartmay(a)linux.ibm.com> --- generator.py | 1 + libvirt-override-api.xml | 6 ++++++ libvirt-override.c | 38 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 45 insertions(+) diff --git a/generator.py b/generator.py index bd7ff112..1f6ffb9a 100755 --- a/generator.py +++ b/generator.py @@ -495,6 +495,7 @@ skip_impl = ( 'virConnectBaselineHypervisorCPU', 'virDomainGetLaunchSecurityInfo', 'virNodeGetSEVInfo', + 'virDomainGetStateParams', ) lxc_skip_impl = ( diff --git a/libvirt-override-api.xml b/libvirt-override-api.xml index 4e8d6c03..c49e244c 100644 --- a/libvirt-override-api.xml +++ b/libvirt-override-api.xml @@ -746,5 +746,11 @@ <arg name='conn' type='virConnectPtr' info='pointer to hypervisor connection'/> <arg name='flags' type='int' info='unused, always pass 0'/> </function> + <function name='virDomainGetStateParams' file='python'> + <info>Extract domain state. Each state is accompanied by a reason (if known) and optional detailed information.</info> + <arg name='dom' type='virDomainPtr' info='pointer to the domain'/> + <arg name='flags' type='unsigned int' info='extra flags; not used yet, so callers should always pass 0'/> + <return type='char *' info="dictionary of state data"/> + </function> </symbols> </api> diff --git a/libvirt-override.c b/libvirt-override.c index e74c7dda..355b9fd5 100644 --- a/libvirt-override.c +++ b/libvirt-override.c @@ -9881,6 +9881,41 @@ libvirt_virNodeGetSEVInfo(PyObject *self ATTRIBUTE_UNUSED, #endif /* LIBVIR_CHECK_VERSION(4, 5, 0) */ +#if LIBVIR_CHECK_VERSION(4, 6, 0) +static PyObject * +libvirt_virDomainGetStateParams(PyObject *self ATTRIBUTE_UNUSED, + PyObject *args) +{ + PyObject *pyobj_domain; + virDomainPtr domain; + virTypedParameterPtr params = NULL; + int nparams = 0; + unsigned int flags; + int i_retval; + PyObject *ret = NULL; + + if (!PyArg_ParseTuple(args, (char *)"OI:virDomainGetStateParams", + &pyobj_domain, &flags)) + return NULL; + domain = (virDomainPtr) PyvirDomain_Get(pyobj_domain); + + LIBVIRT_BEGIN_ALLOW_THREADS; + i_retval = virDomainGetStateParams(domain, &params, &nparams, flags); + LIBVIRT_END_ALLOW_THREADS; + + if (i_retval < 0) { + ret = VIR_PY_NONE; + goto cleanup; + } + + ret = getPyVirTypedParameter(params, nparams); +cleanup: + virTypedParamsFree(params, nparams); + return ret; +} +#endif /* LIBVIR_CHECK_VERSION(4, 6, 0) */ + + /************************************************************************ * * * The registration stuff * @@ -10124,6 +10159,9 @@ static PyMethodDef libvirtMethods[] = { {(char *) "virDomainGetLaunchSecurityInfo", libvirt_virDomainGetLaunchSecurityInfo, METH_VARARGS, NULL}, {(char *) "virNodeGetSEVInfo", libvirt_virNodeGetSEVInfo, METH_VARARGS, NULL}, #endif /* LIBVIR_CHECK_VERSION(4, 5, 0) */ +#if LIBVIR_CHECK_VERSION(4, 6, 0) + {(char *) "virDomainGetStateParams", libvirt_virDomainGetStateParams, METH_VARARGS, NULL}, +#endif /* LIBVIR_CHECK_VERSION(4, 6, 0) */ {NULL, NULL, 0, NULL} }; -- 2.17.0

1 0