[libvirt] [PATCH] examples: Add clean-traffic-gateway into nwfilters
by Ales Musil
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'>
+ <!-- An example of a traffic filter enforcing clean traffic
+ from a VM by
+ - preventing MAC spoofing -->
+ <filterref filter='no-mac-spoofing'/>
+
+ <!-- preventing IP spoofing on outgoing -->
+ <filterref filter='no-ip-spoofing'/>
+
+ <!-- preventing ARP spoofing/poisoning -->
+ <filterref filter='no-arp-spoofing'/>
+
+ <!-- accept all other incoming and outgoing ARP traffic -->
+ <rule action='accept' direction='inout' priority='-500'>
+ <mac protocolid='arp'/>
+ </rule>
+
+ <!-- accept traffic only from specified MAC address -->
+ <rule action='accept' direction='in'>
+ <mac match='yes' srcmacaddr='$GATEWAY_MAC'
+ srcmacmask='$GATEWAY_MAC_MASK'/>
+ </rule>
+
+ <!-- allow traffic only to specified MAC address -->
+ <rule action='accept' direction='out'>
+ <mac match='yes' dstmacaddr='$GATEWAY_MAC'
+ dstmacmask='$GATEWAY_MAC_MASK'/>
+ </rule>
+
+ <!-- preventing any other traffic than between specified MACs
+ and ARP -->
+ <filterref filter='no-other-l2-traffic'/>
+
+ <!-- allow qemu to send a self-announce upon migration end -->
+ <filterref filter='qemu-announce-self'/>
+</filter>
--
1.8.3.1
6 years, 4 months
[libvirt] [PATCH v1] storage: prefer using newDef to save configfile
by Shichangkuo
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!
6 years, 4 months
Re: [libvirt] opening tap devices that are created in a container
by Jason Baron
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
6 years, 4 months
[libvirt] [PATCH] Changed LPC slot from 1 to 31
by Ivan Mishonov
---
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
6 years, 4 months
[libvirt] [jenkins-ci PATCH 0/8] lcitool: Rewrite in Python
by Andrea Bolognani
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
6 years, 4 months
[libvirt] Shared memoryBacking
by Marc-André Lureau
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
6 years, 4 months
[libvirt] [PATCH v2 0/7] Enable vfio-pci 'property' for mediated device
by Erik Skultety
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
6 years, 4 months
[libvirt] [PATCH v3 0/5] Making libvirt aware of a server need
by Marcos Paulo de Souza
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
6 years, 4 months
[libvirt] [PATCH python] Implement virDomainGetStateParams API
by Bjoern Walk
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, ¶ms, &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
6 years, 4 months
[libvirt] [PATCH] storage: prefer using newDef to save configfile
by Shichangkuo
When re-defining an active storage pool, the configfile has not changed. This issue was introduced by bfcd8fc9,
storage: Use virStoragePoolObjGetDef accessor for driver. So we prefer using newDef to save configfile.
Signed-off-by: Changkuo Shi <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 b0de96d..fab3c5b 100644
--- a/src/storage/storage_driver.c
+++ b/src/storage/storage_driver.c
@@ -844,13 +844,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;
}
@@ -860,6 +861,7 @@ storagePoolDefineXML(virConnectPtr conn,
VIR_INFO("Defining storage pool '%s'", def->name);
pool = virGetStoragePool(conn, def->name, def->uuid, NULL, NULL);
+ newDef = NULL;
cleanup:
if (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!
6 years, 4 months
