- Devel - libvirt List Archives

[libvirt] [PATCH] nwfilter: RHEL 5 gcc fixes
by Stefan Berger 06 Apr '10

06 Apr '10

This patch fixes some compilation issues for the RHEL5 build. I am also removing the IPV6 constant where it appears in the wrong place. Seems like a new bad thing to rely on the compiler to tell about potentially uninitialized vars... Signed-off-by; Stefan Berger <stefanb(a)us.ibm.com> --- src/conf/nwfilter_conf.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) Index: libvirt-acl/src/conf/nwfilter_conf.c =================================================================== --- libvirt-acl.orig/src/conf/nwfilter_conf.c +++ libvirt-acl/src/conf/nwfilter_conf.c @@ -392,7 +392,9 @@ struct _virXMLAttr2Struct static const struct int_map macProtoMap[] = { INTMAP_ENTRY(ETHERTYPE_ARP , "arp"), INTMAP_ENTRY(ETHERTYPE_IP , "ipv4"), +#ifdef ETHERTYPE_IPV6 INTMAP_ENTRY(ETHERTYPE_IPV6, "ipv6"), +#endif INTMAP_ENTRY_LAST }; @@ -547,7 +549,6 @@ static const struct int_map ipProtoMap[] #ifdef IPPROTO_SCTP INTMAP_ENTRY(IPPROTO_SCTP, "sctp"), #endif - INTMAP_ENTRY(IPPROTO_IPV6, "ipv6"), INTMAP_ENTRY(IPPROTO_ICMPV6, "icmpv6"), INTMAP_ENTRY_LAST }; @@ -1124,7 +1125,7 @@ virNWFilterRuleDetailsParse(xmlNodePtr n nwItemDesc *item; int int_val; unsigned int uint_val; - void *data_ptr, *storage_ptr; + void *data_ptr = NULL, *storage_ptr; valueValidator validator; char *match = virXMLPropString(node, "match"); nwIPAddress ipaddr; @@ -1550,7 +1551,7 @@ virNWFilterRuleParse(xmlNodePtr node) char *direction; char *prio; int found; - int found_i; + int found_i = 0; unsigned int priority; xmlNodePtr cur;

2 2

[libvirt] [PATCH] Fix compiler warning about unused conn parameter
by Matthias Bolte 06 Apr '10

06 Apr '10

This only affects builds without NUMA support. --- I just pushed this patch. src/nodeinfo.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/nodeinfo.c b/src/nodeinfo.c index 402a6b7..4d7fac1 100644 --- a/src/nodeinfo.c +++ b/src/nodeinfo.c @@ -450,7 +450,7 @@ int nodeCapsInitNUMA(virCapsPtr caps ATTRIBUTE_UNUSED) { return 0; } -int nodeGetCellsFreeMemory(virConnectPtr conn, +int nodeGetCellsFreeMemory(virConnectPtr conn ATTRIBUTE_UNUSED, unsigned long long *freeMems ATTRIBUTE_UNUSED, int startCell ATTRIBUTE_UNUSED, int maxCells ATTRIBUTE_UNUSED) @@ -460,7 +460,7 @@ int nodeGetCellsFreeMemory(virConnectPtr conn, return -1; } -unsigned long long nodeGetFreeMemory(virConnectPtr conn) +unsigned long long nodeGetFreeMemory(virConnectPtr conn ATTRIBUTE_UNUSED) { nodeReportError(VIR_ERR_NO_SUPPORT, "%s", _("NUMA memory information not available on this platform")); -- 1.6.3.3

1 0

[libvirt] Sys::Virt Perl bindings - calling newSVpv with unsafe length
by Richard W.M. Jones 06 Apr '10

06 Apr '10

Dan, After tracking down a very obscure bug in hivex & libguestfs Perl bindings, I started looking for places where we call newSVpv with a variable length argument that could be zero. In such cases, one should call newSVpvn instead, otherwise Perl will try to use strlen() to calculate the length of the data buffer when length is passed in as zero [I'm sure you are aware of this already]. There seems to be one such case in the Sys::Virt bindings: http://cpansearch.perl.org/src/DANBERR/Sys-Virt-0.2.3/Virt.xs CODE: if ((bytes = virSecretGetValue(sec, &len, flags)) == NULL) { _croak_error(virConnGetLastError(virSecretGetConnect(sec))); } RETVAL = newSVpv((char*)bytes, len); Maybe 'len' can never be zero here, but I think it's safer to turn this into a call to newSVpvn anyway. Also, if you look at the source to newSVpv: http://github.com/mirrors/perl/blob/blead/sv.c#L7752 You'll see there is an extra test, not present with newSVpvn. So it's better to always call newSVpvn wherever there is a constant-sized buffer, eg in code like this: if ((virDomainGetUUID(dom, rawuuid)) < 0) { _croak_error(virConnGetLastError(virDomainGetConnect(dom))); } RETVAL = newSVpv((char*)rawuuid, sizeof(rawuuid)); Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

2 1

[libvirt] [PATCH] [0/4] Managed save APIs version 2
by Daniel Veillard 06 Apr '10

06 Apr '10

Change w.r.t. version 1 is the saving path under /var/lib and not /var/run, the restore bug fix spotted by Laine and the various typo and improvement from Eric. As posted earlier, I have implemented the small set of managed save APIs, where libvirt stores the domain state itself and can then recover that state when the domain is started up. I think the code is complete, but not really tested (I still need to debug a failure which seems unrelated), with the exception of the virsh commands which probably need to be extended for convenience. Also I implemented it only for the qemu driver, I would not be surprized if an ESX backend could be implemented since there is no file path in this API. A command "virsh saveall" would be convenient, to be added later. More documentation is needed too. Thanks to Chris Lalancette who wrote a large part of this code ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

5 22

[libvirt] [PATCH] Fix compiler warning about non-literal format string
by Matthias Bolte 06 Apr '10

06 Apr '10

--- I just pushed this patch. src/security/security_apparmor.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/security/security_apparmor.c b/src/security/security_apparmor.c index db04d5c..8e1c794 100644 --- a/src/security/security_apparmor.c +++ b/src/security/security_apparmor.c @@ -483,7 +483,7 @@ AppArmorSetSecurityProcessLabel(virSecurityDriverPtr drv, virDomainObjPtr vm) } if (aa_change_profile(profile_name) < 0) { - virSecurityReportError(VIR_ERR_INTERNAL_ERROR, + virSecurityReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("error calling aa_change_profile()")); goto clean; } -- 1.6.3.3

1 0

[libvirt] Build fails on RHEL-5
by Chris Lalancette 05 Apr '10

05 Apr '10

Hey Stefan, When trying to build libvirt head on RHEL-5, I'm getting this error: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../include -I../src/util -I../include -I/usr/include/libxml2 -DLIBDIR=\"/usr/local/lib\" -DBINDIR=\"/usr/local/libexec\" -DSBINDIR=\"/usr/local/sbin\" -DSYSCONF_DIR=\"/usr/local/etc\" -DLOCALEBASEDIR=\"/usr/local/share/locale\" -DPKGDATADIR=\"/usr/local/share/libvirt\" -DLOCAL_STATE_DIR=\"/usr/local/var\" -DGETTEXT_PACKAGE=\"libvirt\" -Wall -Wformat -Wformat-security -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables -fdiagnostics-show-option -Werror -DIN_LIBVIRT -g -O2 -MT libvirt_conf_la-nwfilter_conf.lo -MD -MP -MF .deps/libvirt_conf_la-nwfilter_conf.Tpo -c conf/nwfilter_conf.c -fPIC -DPIC -o .libs/libvirt_conf_la-nwfilter_conf.o conf/nwfilter_conf.c:395: error: 'ETHERTYPE_IPV6' undeclared here (not in a function) make[3]: *** [libvirt_conf_la-nwfilter_conf.lo] Error 1 It seems that ETHERTYPE_IPV6 is not declared in /usr/include/net/ethernet.h in RHEL-5. We can probably get around this by adding (untested): #ifndef ETHERTYPE_IPV6 #define ETHERTYPE_IPV6 0x86dd #endif At the top of nwfilter_conf.c -- Chris Lalancette

2 2

[libvirt] [PATCH] Only parse 'CPU XML' in virCPUDefParseXML()
by Jim Fehlig 05 Apr '10

05 Apr '10

I received a report of user crashing libvirtd with virsh capabilities > capabilities.xml virsh cpu-compare capabilities.xml Breakpoint 1, x86ModelFind (map=0x6fb6f0, name=0x0) at cpu/cpu_x86.c:501 501 model = map->models; (gdb) bt #0 x86ModelFind (map=0x6fb6f0, name=0x0) at cpu/cpu_x86.c:501 #1 0x00007ffff70d0832 in x86ModelFromCPU (cpu=0x712070, map=0x6fb6f0, policy=1) at cpu/cpu_x86.c:541 #2 0x00007ffff70d12e9 in x86Compute (host=0x6ea610, cpu=0x712070, guest=0x0) at cpu/cpu_x86.c:822 #3 0x00007ffff70d1750 in x86Compare (host=0x6ea610, cpu=0x712070) at cpu/cpu_x86.c:927 #4 0x00007ffff70cf0c9 in cpuCompare (conn=0x6f69a0, host=0x6ea610, cpu=0x712070) at cpu/cpu.c:118 #5 0x00007ffff70ceff4 in cpuCompareXML (conn=0x6f69a0, host=0x6ea610, xml=0x6fa3e0 "<capabilities>\n\n <host>\n <cpu>\n <arch>x86_64</arch>\n <features>\n <pae/>\n </features>\n </cpu>\n <migration_features>\n <live/>\n <uri_transports>\n <uri_tra"...) at cpu/cpu.c:90 .. (gdb) n 503 if (STREQ(model->name, name)) (gdb) Program received signal SIGSEGV, Segmentation fault. 0x00007ffff4ff4960 in strcmp () from /lib64/libc.so.6 name, passed to x86ModelFind(), is NULL because virCPUDefParseXML() failed to parse anything meaningful from the "malformed" CPU XML. I waffled for quite a while on how to fix this and in the end decided to ensure the CPU XML passed to virCPUDefParseXML() does in fact contain an element named 'cpu'. AFAICT, all consumers of virCPUDefParseXML() pass an xmlNodePtr rooted at 'cpu' element. NB: I will be offline until Monday so if this patch is satisfactory please include it for 0.7.8/0.8.0 release :-). Otherwise I'll respin with suggested changes next week. Thanks! Jim

2 3

[libvirt] .so version number question
by Eric Blake 05 Apr '10

05 Apr '10

On IRC, Chris raised the question on what version number we should be using for libvirt.so. The libtool manual has an entire chapter on the matter: http://www.gnu.org/software/libtool/manual/libtool.html#Release-numbers In particular, it states that if you are using the -version-info flag to libtool (which our src/Makefile.am currently does), then you are promising to abide by the libtool versioning rules, where the .so version is treated as current:revision:age (and not major.minor.micro). In fact, libtool goes so far as to state that "Never try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions. Instead, use the -release flag (see Release numbers), but be warned that every release of your package will not be binary compatible with any other release." Should we be using -release instead of -version-info? Or should we continue using -version-info, but follow the advice of divorcing the .so version number from the release number? For example, according to the libtool rules, if the two version numbers are independent, then going from libtool 0.7.7 to 0.8.0 (that is, a minor version number bump in terms of packaging numbering), should go from libvirt.so.0:7:7 (we are at API version 0, with seven revisions of the code implementing that API, and are compatible back to -7:0:0, which is nonsense, so it effectively works out that we are compatible back to 0:0:0) to libvirt.so.1:0:1 (we added API, this is the first implementation of that new API, and we are compatible back to 0.x.x). Going by the libtool rules means that the c.r.a field will increment 'c' rather frequently (basically, every time we add an API!), but as long as 'a' increments just as frequently, then we are not making any backwards incompatible changes. But if you don't like that, the we should be going by the -release flag to libtool, where the .so numbering matches the libvirt release numbering. On the other hand, libtool states that using the -release flag means that anyone that uses libtool to link against libvirt.so is treated as being an incompatible change (basically, even though we are striving hard to maintain backwards compatibility, libtool can't exploit that). Again from the manual, "Note that this option causes a modification of the library name, so do not use it unless you want to break binary compatibility with any past library releases. In general, you should only use -release for package-internal libraries or for ones whose interfaces change very frequently." Libvirt's interface changes frequently, but libvirt.so is not a package-internal library so I don't think that -release is the way to go. Should I try to prepare a patch to start making better use of the -version-info libtool flag according to the libtool rules? And if so, is everyone okay with just punting on this issue until after 0.8.0 is out the door? -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

1 0

[libvirt] clarified syntax-check error message
by Dave Allan 05 Apr '10

05 Apr '10

I pushed the attached trivial patch after noticing that I had a tab in one of my RNG schemas and that the error message was not quite right in that case. Dave

1 0

[libvirt] [PATCH Java] Add finalize to automatically free libvirt objects
by Matthias Bolte 05 Apr '10

05 Apr '10

The Connect and Network classes already had finalize, add it to all other classes that wrap libvirt objects to unify the behavior. --- src/main/java/org/libvirt/Device.java | 5 +++++ src/main/java/org/libvirt/Domain.java | 5 +++++ src/main/java/org/libvirt/Interface.java | 5 +++++ src/main/java/org/libvirt/Network.java | 1 + src/main/java/org/libvirt/StoragePool.java | 5 +++++ src/main/java/org/libvirt/StorageVol.java | 5 +++++ 6 files changed, 26 insertions(+), 0 deletions(-) diff --git a/src/main/java/org/libvirt/Device.java b/src/main/java/org/libvirt/Device.java index b4f9a0c..5329be5 100644 --- a/src/main/java/org/libvirt/Device.java +++ b/src/main/java/org/libvirt/Device.java @@ -132,6 +132,11 @@ public class Device { return desc; } + @Override + public void finalize() throws LibvirtException { + free(); + } + /** * Frees this device object. The running instance is kept alive. The data * structure is freed and should not be used thereafter. diff --git a/src/main/java/org/libvirt/Domain.java b/src/main/java/org/libvirt/Domain.java index e7b24ef..a80800c 100644 --- a/src/main/java/org/libvirt/Domain.java +++ b/src/main/java/org/libvirt/Domain.java @@ -162,6 +162,11 @@ public class Domain { processError(); } + @Override + public void finalize() throws LibvirtException { + free(); + } + /** * Frees this domain object. The running instance is kept alive. The data * structure is freed and should not be used thereafter. diff --git a/src/main/java/org/libvirt/Interface.java b/src/main/java/org/libvirt/Interface.java index 44bcad5..8b97925 100644 --- a/src/main/java/org/libvirt/Interface.java +++ b/src/main/java/org/libvirt/Interface.java @@ -112,6 +112,11 @@ public class Interface { return returnValue; } + @Override + public void finalize() throws LibvirtException { + free(); + } + /** * Frees this interface object. The running instance is kept alive. The data * structure is freed and should not be used thereafter. diff --git a/src/main/java/org/libvirt/Network.java b/src/main/java/org/libvirt/Network.java index 3c6f313..63b1f12 100644 --- a/src/main/java/org/libvirt/Network.java +++ b/src/main/java/org/libvirt/Network.java @@ -64,6 +64,7 @@ public class Network { processError(); } + @Override public void finalize() throws LibvirtException { free(); } diff --git a/src/main/java/org/libvirt/StoragePool.java b/src/main/java/org/libvirt/StoragePool.java index 7de7d50..54468bd 100644 --- a/src/main/java/org/libvirt/StoragePool.java +++ b/src/main/java/org/libvirt/StoragePool.java @@ -115,6 +115,11 @@ public class StoragePool { processError(); } + @Override + public void finalize() throws LibvirtException { + free(); + } + /** * Free a storage pool object, releasing all memory associated with it. Does * not change the state of the pool on the host. diff --git a/src/main/java/org/libvirt/StorageVol.java b/src/main/java/org/libvirt/StorageVol.java index 5ae5f5c..c5a3717 100644 --- a/src/main/java/org/libvirt/StorageVol.java +++ b/src/main/java/org/libvirt/StorageVol.java @@ -75,6 +75,11 @@ public class StorageVol { processError(); } + @Override + public void finalize() throws LibvirtException { + free(); + } + /** * Release the storage volume handle. The underlying storage volume contains * to exist -- 1.6.3.3

3 4