- Devel - libvirt List Archives

[libvirt] [PATCH] Don't ship generated python/libvirt.? files.
by Philipp Hahn 20 Apr '10

20 Apr '10

libvirt.c and libvirt.h are auto-generated files. Mentioning their names in *_SOURCES includes them in the distribution. During an out-of-tree build these shipped files are included instead of the auto-generated version, potentially breaking the build (as it happend in 0.8.0, because the shipped libvirt.h was missing the declaration for 'libvirt_virDomainUpdateDeviceFlags') Use the nodist_*_SOURCES automake variable instead. Signed-off-by: Philipp Hahn <hahn(a)univention.de> --- python/Makefile.am | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)

3 2

[libvirt] [PATCH] Support for faking emulator in qemuxml2argv tests
by Jiri Denemark 20 Apr '10

20 Apr '10

Hi, I thought I'd need it but turned out I didn't. In case someone else finds a good use for that, here's the patch. The idea was to provide a way to fake qemu responses on -M ?, -cpu ?, and the like. Jirka >From d1fa129d1018cd66d2bbdadc68a5f72e91bc6b0c Mon Sep 17 00:00:00 2001 Message-Id: <d1fa129d1018cd66d2bbdadc68a5f72e91bc6b0c.1271681198.git.jdenemar(a)redhat.com> From: Jiri Denemark <jdenemar(a)redhat.com> Date: Fri, 16 Apr 2010 08:20:33 +0200 Subject: [PATCH] Support for faking emulator in qemuxml2argv tests Mail-Followup-To: libvir-list(a)redhat.com This patch allows for using custom scripts instead of /usr/bin/qemu emulator in domain XML. To do so, one can specify relative path to the custom script in <emulator/>. The path needs to be relative to qemuxml2argvdata directory and it will be transparently made absolute in runtime. The expected command line needs to contain the exact relative path as was used in domain XML. --- tests/qemuxml2argvtest.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index beb5dcd..da28c93 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -38,6 +38,7 @@ static int testCompareXMLToArgvFiles(const char *xml, virDomainDefPtr vmdef = NULL; virDomainChrDef monitor_chr; virConnectPtr conn; + char *emulator = NULL; if (!(conn = virGetConnect())) goto fail; @@ -49,6 +50,17 @@ static int testCompareXMLToArgvFiles(const char *xml, VIR_DOMAIN_XML_INACTIVE))) goto fail; + if (vmdef->emulator && *vmdef->emulator != '/') { + emulator = vmdef->emulator; + vmdef->emulator = NULL; + if (virAsprintf(&vmdef->emulator, "%s/qemuxml2argvdata/%s", + abs_srcdir, emulator) < 0) { + vmdef->emulator = emulator; + emulator = NULL; + goto fail; + } + } + if (extraFlags & QEMUD_CMD_FLAG_DOMID) vmdef->id = 6; else @@ -86,6 +98,12 @@ static int testCompareXMLToArgvFiles(const char *xml, NULL, NULL, migrateFrom, NULL) < 0) goto fail; + if (emulator && *argv) { + free(*(char**) argv); + *argv = emulator; + emulator = NULL; + } + len = 1; /* for trailing newline */ tmp = qenv; while (*tmp) { @@ -125,6 +143,7 @@ static int testCompareXMLToArgvFiles(const char *xml, ret = 0; fail: + free(emulator); free(actualargv); if (argv) { tmp = argv; -- 1.7.0.4

1 1

[libvirt] [PATCH 0/6] CPU selection fixes and tests
by Jiri Denemark 20 Apr '10

20 Apr '10

4 out of the 8 tests added by patch 2/6 fail with current libvirt. After 5/6 some of them pass and some of them fail in a different way. After 6/6 all of them pass. Jirka Jiri Denemark (6): Fake host CPU for qemu tests Tests for CPU selection in qemu driver Deal with CPU models in [] Move MIN macro to util.h so that others can use it Support removing features when converting data to CPU Use configured CPU model if possible src/cpu/cpu.c | 8 +- src/cpu/cpu.h | 6 +- src/cpu/cpu_x86.c | 82 +++++++++++++++----- src/qemu/qemu_conf.c | 39 ++++++++-- src/util/util.c | 4 - src/util/util.h | 4 + .../qemuxml2argvdata/qemuxml2argv-cpu-exact1.args | 1 + tests/qemuxml2argvdata/qemuxml2argv-cpu-exact1.xml | 28 +++++++ .../qemuxml2argvdata/qemuxml2argv-cpu-exact2.args | 1 + tests/qemuxml2argvdata/qemuxml2argv-cpu-exact2.xml | 35 ++++++++ .../qemuxml2argv-cpu-minimum1.args | 1 + .../qemuxml2argvdata/qemuxml2argv-cpu-minimum1.xml | 21 +++++ .../qemuxml2argv-cpu-minimum2.args | 1 + .../qemuxml2argvdata/qemuxml2argv-cpu-minimum2.xml | 25 ++++++ .../qemuxml2argvdata/qemuxml2argv-cpu-strict1.args | 1 + .../qemuxml2argvdata/qemuxml2argv-cpu-strict1.xml | 38 +++++++++ .../qemuxml2argv-cpu-topology1.args | 1 + .../qemuxml2argv-cpu-topology1.xml | 21 +++++ .../qemuxml2argv-cpu-topology2.args | 1 + .../qemuxml2argv-cpu-topology2.xml | 22 +++++ .../qemuxml2argv-cpu-topology3.args | 1 + .../qemuxml2argv-cpu-topology3.xml | 21 +++++ tests/qemuxml2argvtest.c | 9 ++ tests/testutilsqemu.c | 30 +++++++- 24 files changed, 362 insertions(+), 39 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-exact1.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-exact1.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-exact2.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-exact2.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-minimum1.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-minimum1.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-minimum2.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-minimum2.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-strict1.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-strict1.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology1.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology1.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology2.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology2.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology3.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-topology3.xml

2 16

[libvirt] [PATCH] Fixup python binding for virDomainSnapshot APIs
by Daniel P. Berrange 20 Apr '10

20 Apr '10

The generator code was totally wrong for the virDomainSnapshot APIs, not generating the wrapper class, and giving methods the wrong names * generator.py: Set metadata for virDomainSnapshot type & APIs * libvirt-override-api.xml, libvirt-override.c: Hand-code the virDomainSnapshotListNames glue layer --- python/generator.py | 27 ++++++++++++++++++++++- python/libvirt-override-api.xml | 6 +++++ python/libvirt-override.c | 46 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 78 insertions(+), 1 deletions(-) diff --git a/python/generator.py b/python/generator.py index cb9f3d9..6f082e8 100755 --- a/python/generator.py +++ b/python/generator.py @@ -243,6 +243,9 @@ py_types = { 'const virStream *': ('O', "virStream", "virStreamPtr", "virStreamPtr"), 'virDomainSnapshotPtr': ('O', "virDomainSnapshot", "virDomainSnapshotPtr", "virDomainSnapshotPtr"), + 'const virDomainSnapshotPtr': ('O', "virDomainSnapshot", "virDomainSnapshotPtr", "virDomainSnapshotPtr"), + 'virDomainSnapshot *': ('O', "virDomainSnapshot", "virDomainSnapshotPtr", "virDomainSnapshotPtr"), + 'const virDomainSnapshot *': ('O', "virDomainSnapshot", "virDomainSnapshotPtr", "virDomainSnapshotPtr"), } py_return_types = { @@ -277,6 +280,7 @@ skip_impl = ( 'virConnectListDefinedStorageVols', 'virConnectListDefinedInterfaces', 'virConnectListNWFilters', + 'virDomainSnapshotListNames', 'virConnGetLastError', 'virGetLastError', 'virDomainGetInfo', @@ -643,6 +647,8 @@ classes_type = { "virStream *": ("._o", "virStream(self, _obj=%s)", "virStream"), "virConnectPtr": ("._o", "virConnect(_obj=%s)", "virConnect"), "virConnect *": ("._o", "virConnect(_obj=%s)", "virConnect"), + "virDomainSnapshotPtr": ("._o", "virDomainSnapshot(self,_obj=%s)", "virDomainSnapshot"), + "virDomainSnapshot *": ("._o", "virDomainSnapshot(self, _obj=%s)", "virDomainSnapshot"), } converter_type = { @@ -651,7 +657,7 @@ converter_type = { primary_classes = ["virDomain", "virNetwork", "virInterface", "virStoragePool", "virStorageVol", "virConnect", "virNodeDevice", "virSecret", - "virStream"] + "virStream", "virDomainSnapshot"] classes_ancestor = { } @@ -663,6 +669,7 @@ classes_destructors = { "virStorageVol": "virStorageVolFree", "virNodeDevice" : "virNodeDeviceFree", "virSecret": "virSecretFree", + "virDomainSnapshot": "virDomainSnapshotFree", # We hand-craft __del__ for this one #"virStream": "virStreamFree", } @@ -767,6 +774,24 @@ def nameFixup(name, classe, type, file): elif name[0:12] == "virDomainGet": func = name[12:] func = string.lower(func[0:1]) + func[1:] + elif name[0:29] == "virDomainSnapshotLookupByName": + func = name[9:] + func = string.lower(func[0:1]) + func[1:] + elif name[0:26] == "virDomainSnapshotListNames": + func = name[9:] + func = string.lower(func[0:1]) + func[1:] + elif name[0:20] == "virDomainSnapshotNum": + func = name[9:] + func = string.lower(func[0:1]) + func[1:] + elif name[0:26] == "virDomainSnapshotCreateXML": + func = name[9:] + func = string.lower(func[0:1]) + func[1:] + elif name[0:24] == "virDomainSnapshotCurrent": + func = name[9:] + func = string.lower(func[0:1]) + func[1:] + elif name[0:17] == "virDomainSnapshot": + func = name[17:] + func = string.lower(func[0:1]) + func[1:] elif name[0:9] == "virDomain": func = name[9:] func = string.lower(func[0:1]) + func[1:] diff --git a/python/libvirt-override-api.xml b/python/libvirt-override-api.xml index e95c46a..6f1bc04 100644 --- a/python/libvirt-override-api.xml +++ b/python/libvirt-override-api.xml @@ -243,5 +243,11 @@ <arg name='xmlCPUs' type='const char **' info='array of XML descriptions of host CPUs'/> <arg name='flags' type='unsigned int' info='fine-tuning flags, currently unused, pass 0.'/> </function> + <function name='virDomainSnapshotListNames' file='python'> + <info>collect the list of snapshots for the given domain</info> + <arg name='dom' type='virDomainPtr' info='pointer to the domain'/> + <arg name='flags' type='unsigned int' info='flags, curently unused'/> + <return type='str *' info='the list of Names of None in case of error'/> + </function> </symbols> </api> diff --git a/python/libvirt-override.c b/python/libvirt-override.c index 02bc313..ce21f60 100644 --- a/python/libvirt-override.c +++ b/python/libvirt-override.c @@ -943,6 +943,51 @@ libvirt_virConnectListDefinedDomains(PyObject *self ATTRIBUTE_UNUSED, } static PyObject * +libvirt_virDomainSnapshotListNames(PyObject *self ATTRIBUTE_UNUSED, + PyObject *args) { + PyObject *py_retval; + char **names = NULL; + int c_retval, i; + virDomainPtr dom; + PyObject *pyobj_dom; + int flags; + + if (!PyArg_ParseTuple(args, (char *)"Oi:virDomainSnapshotListNames", &pyobj_dom, &flags)) + return(NULL); + dom = (virDomainPtr) PyvirDomain_Get(pyobj_dom); + + LIBVIRT_BEGIN_ALLOW_THREADS; + c_retval = virDomainSnapshotNum(dom, flags); + LIBVIRT_END_ALLOW_THREADS; + if (c_retval < 0) + return VIR_PY_NONE; + + if (c_retval) { + names = malloc(sizeof(*names) * c_retval); + if (!names) + return VIR_PY_NONE; + LIBVIRT_BEGIN_ALLOW_THREADS; + c_retval = virDomainSnapshotListNames(dom, names, c_retval, flags); + LIBVIRT_END_ALLOW_THREADS; + if (c_retval < 0) { + free(names); + return VIR_PY_NONE; + } + } + py_retval = PyList_New(c_retval); + + if (names) { + for (i = 0;i < c_retval;i++) { + PyList_SetItem(py_retval, i, libvirt_constcharPtrWrap(names[i])); + free(names[i]); + } + free(names); + } + + return(py_retval); +} + +static PyObject * libvirt_virDomainGetInfo(PyObject *self ATTRIBUTE_UNUSED, PyObject *args) { PyObject *py_retval; int c_retval; @@ -3275,6 +3320,7 @@ static PyMethodDef libvirtMethods[] = { {(char *) "virConnectListDefinedInterfaces", libvirt_virConnectListDefinedInterfaces, METH_VARARGS, NULL}, {(char *) "virConnectBaselineCPU", libvirt_virConnectBaselineCPU, METH_VARARGS, NULL}, {(char *) "virDomainGetJobInfo", libvirt_virDomainGetJobInfo, METH_VARARGS, NULL}, + {(char *) "virDomainSnapshotListNames", libvirt_virDomainSnapshotListNames, METH_VARARGS, NULL}, {NULL, NULL, 0, NULL} }; -- 1.6.6.1

3 3

[libvirt] KVM Forum 2010: Call for Papers
by KVM Forum 2010 Program Committee 19 Apr '10

19 Apr '10

================================================================= CALL FOR PAPERS KVM Forum 2010 ================================================================= DESCRIPTION The KVM Forum is back! After a break last year we're proud to present this year's gathering around KVM again. The idea is to have everyone involved with KVM development come together to talk about the future and current state of KVM, teaching everyone some pieces of the puzzle they might be missing without. So if you're a KVM developer, mark the dates in your calendar! If possible, also submit a talk -- we're interested in a wide variety of KVM topics, so don't hesitate to propose a talk on your work. If you're not a KVM developer, please read on nevertheless (or jump to END USER COLLABORATION). DATES / LOCATION Conference: August 9 - 10, 2010 Location: Renaissance Boston Waterfront in Boston, MA Abstracts due: May 14th, 2010 Notification: May 28th, 2010 Yes, we're colocated with LinuxCon. Tickets for the KVM Forum also count for LinuxCon. http://events.linuxfoundation.org/component/registrationpro/?func=details&d… PROCESS At first check if it's before May 14th. If you're past that date, you're out of luck. Now try to think hard and come up with a great idea that you could talk about. Once you have that set, we need you to write up a short abstract (~150 words) on it. In your submission please note how long your talk will take. Slots vary in length up to one hour. Also include in your proposal the proposal type -- one of: technical talk, breakout session, or end-user talk. Add that information to the abstract and submit it at the following URL: http://events.linuxfoundation.org/cfp/cfp-add Now, wait until May 24th. You will receive a notification on whether your talk was accepted or not. SCOPE OF TALKS We have a list of suggested presentation topics below. These suggestions are just for guidance, please feel free to submit a proposal on any of these or related topics. In general, the more it's about backend infrastructure, the better. KVM - Scaling and performance - Nested virtualization - I/O improvements - Driver domains - Time keeping - Memory management (page sharing, swapping, huge pages, etc) - Fault tolerance - VEPA, vswitch Embedded KVM - KVM on ARM, PPC, MIPS, ...? - Real-time requirements host/guest - Device pass-through w/o iommu - Custom device/platform models QEMU - Device model improvements - New devices - Security model - Scaling and performance - Desktop virtualization - Increasing robustness - Management interfaces - QMP protocol and implementation - Live migration Virtio - Speeding up existing devices - Vhost - Alternatives - Using virtio in non-kvm environments - Virtio on non-Linux Management infrastructure - Libvirt - Kvm autotest - Easy networking - Qemud BREAKOUT SESSION We will reserve some time each day to break out for working sessions. These sessions will be less formal than a presentation and more focused on developing a solution to some real development issue. If you are interested in getting developers together to hack on some code, submit your proposal and just make it clear it's a breakout session proposal. END-USER COLLABORATION One of the big challenges as developers is to know what, where and how people actually use our software. To solve this issue at least a little, there will be a few slots reserved for end users talking about their deployments, problems and achievements. So if you have a KVM based deployment running in production or are about to roll out one, please also submit a talk (see PROCESS), and simply mark it asn an end-user collaboration proposal. We would love to have an open discussion of fields where KVM/Qemu can still improve and you would have the unique chance to steer that process! Keep in mind that most of the Forum will be focused on development though, so we suggest you also come with a good portion of technical interest :-). And of course, no product marketing please! The purpose is to engage with KVM developers. LIGHTNING TALKS In addition to submitted talks we will also have some room for lightning talks. So if you have something you think might be done until the KVM Forum, but you're not sure you could fill 15 minutes with it. Or if you don't know if you'll make it until there, just keep in mind that you will still get the chance to talk about it. Lightning talk submissions and scheduling will be handled on-site at KVM Forum. Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2010 in August! Now, start thinking about that talk you want to give. Thanks, your KVM Forum 2010 Program Commitee Alexander Graf, Novell Anthony Liguori, IBM Avi Kivity, Red Hat Chris Wright, Red Hat Dor Laor, Red Hat Jan Kiszka, Siemens Please contact us with any questions or comments. KVM-Forum-2010-PC(a)redhat.com

1 0

[libvirt] [PATCH] Fix crash in nwfilter driver check
by Daniel P. Berrange 19 Apr '10

19 Apr '10

The nwfilterDriverActive() could de-reference a NULL pointer if it hadn't be started at the point it was called. It was also not thread safe, since it lacked locking around data accesses. * src/nwfilter/nwfilter_driver.c: Fix locking & NULL checks in nwfilterDriverActive() --- src/nwfilter/nwfilter_driver.c | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/src/nwfilter/nwfilter_driver.c b/src/nwfilter/nwfilter_driver.c index 58df4e1..412c5b8 100644 --- a/src/nwfilter/nwfilter_driver.c +++ b/src/nwfilter/nwfilter_driver.c @@ -153,9 +153,16 @@ nwfilterDriverReload(void) { */ static int nwfilterDriverActive(void) { - if (!driverState->pools.count) + int ret; + + if (!driverState) return 0; - return 1; + + nwfilterDriverLock(driverState); + ret = driverState->pools.count ? 1 : 0; + nwfilterDriverUnlock(driverState); + + return ret; } /** -- 1.6.6.1

2 1

[libvirt] ESX and inaccessible storage pools
by Matthias Bolte 19 Apr '10

19 Apr '10

I'm currently implementing the storage driver for ESX and have a mapping problem. libvirt storage pools can be either running or inactive just like the domain. ESX is a bit different here. A datastore is always active. It can be inaccessible, e.g. if an NFS is mounted as datastore but the NFS server went unreachable. I discussed this with Daniel on IRC and he summarized it like this: <DV> they are defined, the system knows them, but they are not available for use The question is, what should the ESX driver do with inaccessible datastores? Option 1: They could just be represented as inactive storage pools, but libvirt's semantic for inactive storage pools includes that the user can start an inactive storage pool. That's not possible for an inaccessible datastore, so the driver would report an error if a user tries to start an inaccessible storage pool. Option 2: Just ignore inaccessible datastores and make the ESX storage driver to pretend that they don't exist. But this would hide information from the user. Option 3: Extend libvirt's API for inaccessible storage pools. There are possibly other options and I'd like to hear your comments and suggestions. Matthias

3 3

[libvirt] [RFC PATCH 0/5] Qemu Monitor Passthrough
by Chris Lalancette 19 Apr '10

19 Apr '10

Hello, As we discussed on the list, here are RFC patches that allow both qemu monitor passthrough and the ability to specify extra arguments to be passed on the qemu command-line. I've specifically not done the more complicated regex command-line editing for now, since we don't have consensus on it. There are a few outstanding issues with these patches: 1) Should we have a separate structure for the per-driver qemuMonitorCommand entry point? 2) Due to the way that virsh parses command-line arguments, it's not possible to pass it an argument that has spaces (even if you properly quote it). Therefore I have a hack in place that will convert ^ to space before passing it along, which is pretty crappy. How should we go about fixing this? Fix virsh argument parsing, or go about it a different way? Questions or comments about the patch series are welcome. Chris Lalancette

2 14

[libvirt] That the Linux bridge configuration does not work afer I upgraded the kernel to 2.6.33.2.
by Frank Peng 19 Apr '10

19 Apr '10

Hello, When I use a standard Redhat kernel, it's ok. Everything's working right. That the Linux bridge configuration does not work afer I upgraded the kernel to 2.6.33.2. Why? [root@node78 ~]# cat /etc/issue Red Hat Enterprise Linux Server release 5.5 (Tikanga) Kernel \r on an \m [root@node78 ~]# uname -a Linux node78 2.6.33.2 #1 SMP Wed Apr 14 10:10:29 CST 2010 x86_64 x86_64 x86_64 GNU/Linux [root@node78 ~]# cat /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted [root@node78 ~]# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root@node78 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 # Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) DEVICE=eth0 HWADDR=00:15:17:11:16:18 BRIDGE=br0 NM_CONTROLLED=no ONBOOT=yes [root@node78 ~]# cat /etc/sysconfig/network-scripts/ifcfg-br0 DEVICE=br0 TYPE=Bridge BOOTPROTO=static BROADCAST=192.168.0.255 IPADDR=192.168.0.78 NETMASK=255.255.255.0 NETWORK=192.168.0.0 DELAY=0 NM_CONTROLLED=no ONBOOT=yes [root@node78 ~]#cd /usr/src/ [root@node78 ~]#tar jxf linux-2.6.33.2.tar.bz2 [root@node78 ~]#ln -s linux-2.6.33.2 linux [root@node78 ~]#cd linux [root@node78 ~]#cp /boot/config-2.6.18-164.el5 /usr/src/linux-2.6.33.2/.config [root@node78 ~]#make menuconfig (add the option "enable deprecated sysfs feathures to support old userspace tools") [root@node78 ~]#make && make modules && make modules_install && make install [root@node78 ~]# ifconfig br0 Link encap:Ethernet HWaddr 00:15:17:11:16:18 inet addr:192.168.0.78 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::215:17ff:fe11:1618/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7217 errors:0 dropped:0 overruns:0 frame:0 TX packets:273 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:738606 (721.2 KiB) TX bytes:36168 (35.3 KiB) eth0 Link encap:Ethernet HWaddr 00:15:17:11:16:18 inet6 addr: fe80::215:17ff:fe11:1618/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7490 errors:0 dropped:0 overruns:0 frame:0 TX packets:304 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:866112 (845.8 KiB) TX bytes:42312 (41.3 KiB) Memory:b8820000-b8840000 eth1 Link encap:Ethernet HWaddr 00:15:17:11:16:19 inet addr:10.0.7.78 Bcast:10.255.255.255 Mask:255.0.0.0 inet6 addr: fe80::215:17ff:fe11:1619/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:59 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1056 (1.0 KiB) TX bytes:10982 (10.7 KiB) Memory:b8800000-b8820000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1831 errors:0 dropped:0 overruns:0 frame:0 TX packets:1831 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3576260 (3.4 MiB) TX bytes:3576260 (3.4 MiB) [root@node78 ~]# ifconfig vmbr0 vmbr0: error fetching interface information: Device not found Best Regards, Frank

1 0

[libvirt] [PATCH] nwfilter: Free nwfilter hash of virConnectPtr
by Matthias Bolte 18 Apr '10

18 Apr '10

And close the driver on connection close. --- src/datatypes.c | 20 ++++++++++++++++++++ 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/src/datatypes.c b/src/datatypes.c index ebcd538..25962a6 100644 --- a/src/datatypes.c +++ b/src/datatypes.c @@ -129,6 +129,20 @@ virSecretFreeName(void *secret_, const char *name ATTRIBUTE_UNUSED) } /** + * virNWFilterPoolFreeName: + * @pool: a nwfilter pool object + * + * Destroy the nwfilter pool object, this is just used by the nwfilter pool hash callback. + * + * Returns 0 in case of success and -1 in case of failure. + */ +static int +virNWFilterPoolFreeName(virNWFilterPtr pool, const char *name ATTRIBUTE_UNUSED) +{ + return (virUnrefNWFilter(pool)); +} + +/** * virDomainSnapshotFreeName: * @snapshot: a domain snapshotobject * @@ -212,6 +226,8 @@ failed: virHashFree(ret->nodeDevices, (virHashDeallocator) virNodeDeviceFree); if (ret->secrets != NULL) virHashFree(ret->secrets, virSecretFreeName); + if (ret->nwfilterPools != NULL) + virHashFree(ret->nwfilterPools, (virHashDeallocator) virNWFilterPoolFreeName); virMutexDestroy(&ret->lock); VIR_FREE(ret); @@ -245,6 +261,8 @@ virReleaseConnect(virConnectPtr conn) { virHashFree(conn->nodeDevices, (virHashDeallocator) virNodeDeviceFree); if (conn->secrets != NULL) virHashFree(conn->secrets, virSecretFreeName); + if (conn->nwfilterPools != NULL) + virHashFree(conn->nwfilterPools, (virHashDeallocator) virNWFilterPoolFreeName); virResetError(&conn->err); @@ -292,6 +310,8 @@ virUnrefConnect(virConnectPtr conn) { conn->deviceMonitor->close (conn); if (conn->secretDriver) conn->secretDriver->close (conn); + if (conn->nwfilterDriver) + conn->nwfilterDriver->close (conn); if (conn->driver) conn->driver->close (conn); -- 1.6.3.3

2 2