- Devel - libvirt List Archives

[libvirt] [PATCH] Don't always skip virportallocatortest
by Ján Tomko 04 Mar '14

04 Mar '14

Include dlfcn.h before checking if RTLD_NEXT is defined --- tests/virportallocatortest.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/tests/virportallocatortest.c b/tests/virportallocatortest.c index 5a93dad..fd48c11 100644 --- a/tests/virportallocatortest.c +++ b/tests/virportallocatortest.c @@ -23,8 +23,11 @@ #include "virfile.h" #include "testutils.h" -#if HAVE_DLFCN_H && defined(RTLD_NEXT) +#if HAVE_DLFCN_H +# include <dlfcn.h> +#endif +#if defined(RTLD_NEXT) # ifdef MOCK_HELPER # include "internal.h" # include <sys/socket.h> @@ -32,7 +35,6 @@ # include <arpa/inet.h> # include <netinet/in.h> # include <stdio.h> -# include <dlfcn.h> static bool host_has_ipv6 = false; static int (*realsocket)(int domain, int type, int protocol); @@ -265,7 +267,7 @@ mymain(void) VIRT_TEST_MAIN_PRELOAD(mymain, abs_builddir "/.libs/libvirportallocatormock.so") # endif -#else /* ! HAVE_DLFCN_H */ +#else /* ! defined(RTLD_NEXT) */ int main(void) { -- 1.8.3.2

2 2

[libvirt] [PCTCH v2 0/2] fix query-command-line-options
by Amos Kong 04 Mar '14

04 Mar '14

This patchset fixed some issues of query-command-line-options: * some new options haven't arguments can't be queried. (eg: -enable-fips) * some legcy options have arguments can't be queried. (eg: -vnc display) More discussion: http://marc.info/?l=qemu-devel&m=139081830416684&w=2 V2: remove duplicate option tables, update schema Amos Kong (2): qmp: rename query_option_descs() to get_param_infolist() query-command-line-options: query all the options in qemu-options.hx qapi-schema.json | 8 ++++++-- util/qemu-config.c | 58 +++++++++++++++++++++++++++++++++++++++++++++--------- 2 files changed, 55 insertions(+), 11 deletions(-) -- 1.8.5.3

2 5

[libvirt] Libvirt Java Bindings - adding domain event support - pull request
by Chris Ellis 03 Mar '14

03 Mar '14

Hi all I'm new to this list, I've been making use of the Libvirt Java bindings recently. I wanted to make use of domain events yesterday so my application can be alerted when the state of a domain changes etc. However I quickly discovered that domain events are completely broken in the current Java bindings. Whilst some of the Libvirt functions required to support domain events are exposed, the critical underpinnings are not. Specifically there is no support for setting up the event loop. So I have implemented support for domain events in the Java bindings. Currently I've only implemented the following domain event IDs: * VIR_DOMAIN_EVENT_ID_LIFECYCLE * VIR_DOMAIN_EVENT_ID_REBOOT * VIR_DOMAIN_EVENT_ID_RTC_CHANGE Implementing these is enough to test that my implementation is sane, I'm hoping to implement the majority of the other events soon. Events can be listened to by, registering via the Connect object, as follows: con.domainEventRegisterAny(DomainEventID.VIR_DOMAIN_EVENT_ID_LIFECYCLE, new DomainLifecycleEventHandler() { @Override public void onStarted(Connect connection, Domain domain, DomainEventType event, DomainEventStartedDetailType detail) throws LibvirtException { System.out.println("Got start event: " + event + "::" + detail + " for domain " + domain.getName()); } }); I've put my clone of the libvirt-java git repository on Github, my modifications to the Java binding are in a separate branch and should be simple to merge. The changes can be viewed at: https://github.com/intrbiz/libvirt-java/compare/master...ce-domain-events I'm keen to get these enhancements / fixes merged into libvirt-java. I would also like to submit further fixes to race conditions in the free() handling. Any advice / thoughts / comments welcome. Regards, Chris Ellis

4 4

[libvirt] Build failed in Jenkins: libvirt-syntax-check #2035
by Jenkins CI 03 Mar '14

03 Mar '14

See <http://honk.sigxcpu.org:8001/job/libvirt-syntax-check/2035/> ------------------------------------------ Started by upstream project "libvirt-build" build number 2286 Building on master in workspace <http://honk.sigxcpu.org:8001/job/libvirt-syntax-check/ws/> [workspace] $ /bin/sh -xe /tmp/hudson2145980330175113322.sh + make syntax-check GEN bracket-spacing-check GFDL_version 0.53 GFDL_version TAB_in_indentation 0.37 TAB_in_indentation Wundef_boolean 0.21 Wundef_boolean avoid_attribute_unused_in_header 0.25 avoid_attribute_unused_in_header avoid_ctype_macros 0.62 avoid_ctype_macros avoid_if_before_free 4.83 avoid_if_before_free avoid_strcase 0.63 avoid_strcase avoid_write 0.31 avoid_write bindtextdomain 0.30 bindtextdomain cast_of_argument_to_free 0.54 cast_of_argument_to_free cast_of_x_alloc_return_value 0.55 cast_of_x_alloc_return_value changelog 0.31 changelog const_long_option 0.58 const_long_option copyright_check 0.81 copyright_check copyright_format 1.60 copyright_format copyright_usage 1.65 copyright_usage correct_id_types 0.67 correct_id_types error_message_period 0.53 error_message_period error_message_warn_fatal 0.52 error_message_warn_fatal flags_debug 1.11 flags_debug flags_usage 1.04 flags_usage forbid_const_pointer_typedef 1.12 forbid_const_pointer_typedef libvirt_unmarked_diagnostics 1.59 libvirt_unmarked_diagnostics m4_quote_check 0.25 m4_quote_check makefile_TAB_only_indentation 0.22 makefile_TAB_only_indentation makefile_at_at_check 0.20 makefile_at_at_check makefile_conditionals 0.21 makefile_conditionals po_check 15.16 po_check preprocessor_indentation cppi: src/nwfilter/nwfilter_dhcpsnoop.c: line 272: not properly indented maint.mk: incorrect preprocessor indentation make: *** [sc_preprocessor_indentation] Error 1 Build step 'Execute shell' marked build as failure

2 2

Re: [libvirt] Compiling libvirt RPC client library for QNX
by Panday Ritesh Sharma (rpanday) 03 Mar '14

03 Mar '14

On 25/02/14 9:18 PM, "Panday Ritesh Sharma (rpanday)" <rpanday(a)cisco.com> wrote: >Hi Roman, >Sorry !!! I did not understand "Once again, please don't top-post on >technical lists." > >I should not include 'libvirt-list(a)redhat.com' in my mail thread ? > >I have already used the option '--without-libvirtd' and hence the result. > >We are using a wrapper of make for compilation for QNX. So I need to know, >when I am compiling this client library on linux with '--without-libvirtd' >option, what all .c files and libraries are being used. Then I will take >those .c files to my build environment and link that to the libraries >needed. I will have to see whether those libraries are present in my QNX >build environment. Please helpŠ > > >Regards >Ritesh Sharma > > >On 25/02/14 8:57 PM, "Eric Blake" <eblake(a)redhat.com> wrote: > >>On 02/25/2014 08:10 AM, Panday Ritesh Sharma (rpanday) wrote: >> >>Once again, please don't top-post on technical lists. >> >>> Hi Eric, >>> I used the option '--without-macvtap' and I was able to compile on my >>> linux box. When I compiled, I see many libraries are getting built. But >>>as >>> I have explained my requirement earlier, I just need a RPC client >>>library, >>> essentially the option '--with-remote'. >> >>To build just the client library, use ./configure --without-libvirtd. >> >>> >>> If I check .c files I see only './src/libvirt.c' and './tools/virsh.c' >>>are >>> the two files where '# ifdef WITH_REMOTE' is present. >>> >>> Does it mean that as per my requirement I only need to compile these >>>files? >> >>No. You must unpack the ENTIRE tarball, and then use the configure >>options to control which files are built. Some of the logic on what to >>build is in the makefiles, and another consideration is that there are a >>LOT of library files that are used in both libvirt.so (your client >>library) and in libvirtd (the daemon executable that you are not >>building). >> >>> >>> My intent is to have a library with minimal files which suffice to my >>> requirement. Because that way it will be easier for me to compile them >>>on >>> QNX. >> >>Using configure options to compile fewer files is reasonable. Omitting >>files from the tarball is not. >> >>> >>> You have mentioned on another thread that in a weeks time some new >>>version >>> of libvirt will come which we can compile for non-linux machines ? What >>> change is coming in that version ? The latest version of libvirt can >>>not >>> be compiled for QNX ? >> >>The latest version is currently 1.2.1, but 1.2.2-rc0 was just announced >>and 1.2.2 is expected next week if all goes well. If you could test >>1.2.2-rc0 on QNX, we can still fix issues that you turn up before 1.2.2 >>goes stable. >> >> >>-- >>Eric Blake eblake redhat com +1-919-301-3266 >>Libvirt virtualization library http://libvirt.org Adding [libvirt-list] Hi Eric, This time I am writing a the bottom of this thread, is this correct ? Write way of mailing ? Could you please reply my query ? Regards Ritesh Sharma >> >

3 8

[libvirt] [PATCH 0/3] nwfilter: Fix some issues in DHCP Snooping code
by Stefan Berger 03 Mar '14

03 Mar '14

The following 3 patches fix some issues in the DHCP Snooping code. Stefan Berger (3): nwfilter: Cap the poll timeout in the DHCP Snooping code nwfilter: Display the pcap errror message nwfilter: Increase buffer size for libpcap src/nwfilter/nwfilter_dhcpsnoop.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) -- 1.8.1.4

2 8

[libvirt] [PATCH] dnsmasq: allowing RFC 2782 compliant srv records
by Steven Malin 03 Mar '14

03 Mar '14

Hello, I want to provide a patch which allows RFC 2782 compliant dns srv records in the network configs. If you have questions, please contact me. Kind Regards, Steven Malin --- src/conf/network_conf.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c index bac0465..9a4285b 100644 --- a/src/conf/network_conf.c +++ b/src/conf/network_conf.c @@ -961,9 +961,11 @@ virNetworkDNSSrvDefParseXML(const char *networkName, goto error; } - /* Check whether protocol value is the supported one */ + /* Check whether protocol value is supported (also RFC 2782 compliant) */ if (def->protocol && STRNEQ(def->protocol, "tcp") && - (STRNEQ(def->protocol, "udp"))) { + STRNEQ(def->protocol, "udp") && + STRNEQ(def->protocol, "_tcp") && + STRNEQ(def->protocol, "_udp")) { virReportError(VIR_ERR_XML_DETAIL, _("Invalid protocol attribute value '%s' " "in DNS SRV record of network %s"), -- 1.7.1

2 1

[libvirt] [PATCH] qemu: Implement a stub cpuArchDriver.baseline() handler for arm
by Oleg Strikov 03 Mar '14

03 Mar '14

Openstack Nova calls virConnectBaselineCPU() during initialization of the instance to get a full list of CPU features. This patch adds a stub to arm-specific code to handle this request (no actual work is done). Signed-off-by: Oleg Strikov <oleg.strikov(a)canonical.com> --- This is a port of the following aarch64-specific change: http://libvirt.org/git/?p=libvirt.git;a=commit;h=69fba97f631c26a322bf9f2949… Only function names were changed. --- src/cpu/cpu_arm.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/src/cpu/cpu_arm.c b/src/cpu/cpu_arm.c index 5baff42..ec80b35 100644 --- a/src/cpu/cpu_arm.c +++ b/src/cpu/cpu_arm.c @@ -86,6 +86,29 @@ ArmGuestData(virCPUDefPtr host ATTRIBUTE_UNUSED, return VIR_CPU_COMPARE_IDENTICAL; } +static virCPUDefPtr +ArmBaseline(virCPUDefPtr *cpus, + unsigned int ncpus ATTRIBUTE_UNUSED, + const char **models ATTRIBUTE_UNUSED, + unsigned int nmodels ATTRIBUTE_UNUSED, + unsigned int flags) +{ + virCPUDefPtr cpu = NULL; + + virCheckFlags(VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES, NULL); + + if (VIR_ALLOC(cpu) < 0 || + VIR_STRDUP(cpu->model, cpus[0]->model) < 0) { + virCPUDefFree(cpu); + return NULL; + } + + cpu->type = VIR_CPU_TYPE_GUEST; + cpu->match = VIR_CPU_MATCH_EXACT; + + return cpu; +} + struct cpuArchDriver cpuDriverArm = { .name = "arm", .arch = archs, @@ -96,7 +119,7 @@ struct cpuArchDriver cpuDriverArm = { .free = ArmDataFree, .nodeData = ArmNodeData, .guestData = ArmGuestData, - .baseline = NULL, + .baseline = ArmBaseline, .update = ArmUpdate, .hasFeature = NULL, }; -- 1.7.9.5

2 1

Re: [libvirt] [PATCH 4/4] qemu: add unit tests for the capabilities xml
by Francesco Romani 03 Mar '14

03 Mar '14

----- Original Message ----- > From: "Eric Blake" <eblake(a)redhat.com> > To: "Francesco Romani" <fromani(a)redhat.com>, libvir-list(a)redhat.com > Sent: Friday, February 28, 2014 12:49:25 AM > Subject: Re: [libvirt] [PATCH 4/4] qemu: add unit tests for the capabilities xml > > On 01/17/2014 08:31 AM, Francesco Romani wrote: > > the test is loosely inspired from qemucapabilitiestest > > and qemuxml2xmltest. > > > > Added a new test instead of extending an existing one because > > the feature being tested don't really fits nicely in any > > s/don't/doesn't/ s/fits/fit/ Will fix. > > existing place. > > --- > > .gitignore | 1 + > > tests/Makefile.am | 10 +- > > tests/qemucaps2xmldata/all_1.6.0-1.caps | 142 ++++++++++++++ > > tests/qemucaps2xmldata/all_1.6.0-1.xml | 51 +++++ > > tests/qemucaps2xmldata/nodisksnapshot_1.6.0-1.caps | 141 +++++++++++++ > > tests/qemucaps2xmldata/nodisksnapshot_1.6.0-1.xml | 51 +++++ > > tests/qemucaps2xmltest.c | 217 > > +++++++++++++++++++++ > > 7 files changed, 612 insertions(+), 1 deletion(-) > > create mode 100644 tests/qemucaps2xmldata/all_1.6.0-1.caps > > create mode 100644 tests/qemucaps2xmldata/all_1.6.0-1.xml > > create mode 100644 tests/qemucaps2xmldata/nodisksnapshot_1.6.0-1.caps > > create mode 100644 tests/qemucaps2xmldata/nodisksnapshot_1.6.0-1.xml > > create mode 100644 tests/qemucaps2xmltest.c > > Fails 'make check' for me: > > $ make -C tests check TESTS=qemucaps2xmltest \ > VERBOSE=yes VIR_TEST_DEBUG=1 > ... > > TEST: qemucaps2xmltest > 1) all_1.6.0-1 ... > Offset 393 > Expect [6</machine> > <machine>none</machine> > <machine canonical='pc-i440fx-1.6'>pc</machine> > <machine>pc-i440fx-1.5</machine> > <machine>pc-i440fx-1.4</machine> > ... > Actual [7</machine> > <machine>none</machine> > <machine canonical='pc-i440fx-1.7'>pc</machine> > <machine>pc-i440fx-1.6</machine> > <machine>pc-i440fx-1.5</machine> > > which means you wrote the test by probing the installed qemu, instead of > our testsuite helper binary, and my installed qemu 1.7 differs from your > setup of 1.6. That has to be fixed before this can be applied. Yes, I have qemu 1.6.1 in my test box, this is probably the reason why I haven't noticed this misbehaviour before. This is a point I wanted to discuss because I'm not sure how to properly achieve this. Please see below for my questions on this topic. > > > +++ b/tests/qemucaps2xmltest.c > > @@ -0,0 +1,217 @@ > > +/* > > > + > > + virQEMUCapsCacheAdd(cache, "kvm", qemuCaps); > > + virQEMUCapsCacheAdd(cache, "qemu", qemuCaps); > > + virQEMUCapsCacheAdd(cache, "qemu-system-x86_64", qemuCaps); > > + virQEMUCapsCacheAdd(cache, "qemu-system-i386", qemuCaps); > > + virQEMUCapsCacheAdd(cache, "/usr/bin/qemu-system-x86_64", qemuCaps); > > + virQEMUCapsCacheAdd(cache, "/usr/bin/qemu-system-i386", qemuCaps); > > Is this where the testsuite ended up probing the installed file system > instead of using only data from the testsuite? Yes, it is. What I want to achieve here is to pre-fill the capabilities cache, by using the function I exported in a previous patch on this series, with the test data. The intent is of course to use only the data from the testsuite and to be independent from the installed QEMU, if any, as you pointed out above. I tried a few different attempts but looks like I'm still missing the point. How can I improve this test to achieve this objective? There is an unit-test I can learn from? Any advice is welcome, I want to fix this. Thanks for the review and best regards, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani

1 0

[libvirt] [PATCH] docs: typo fix
by Roman Bogorodskiy 03 Mar '14

03 Mar '14

* drvuml.html.in: (connected) s/toa PTY/to a PTY/ --- docs/drvuml.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/drvuml.html.in b/docs/drvuml.html.in index fe7769d..03c04ef 100644 --- a/docs/drvuml.html.in +++ b/docs/drvuml.html.in @@ -65,7 +65,7 @@ uml+ssh://root@example.com/system (remote access, SSH tunnelled) </p> <p> - Once booted the primary console is connected toa PTY, and + Once booted the primary console is connected to a PTY, and thus accessible with "virsh console" or equivalent tools </p> -- 1.8.4.2

2 2