- Devel - libvirt List Archives

[libvirt] [PATCHv2 0/2] interface driver build cleanup and udev backend addition
by Doug Goldstein 10 Sep '12

10 Sep '12

Refactored the cross use of netcf and interface for the interface driver into only interface driver references. Made netcf the primary backend provider for the interface driver. Added a udev based read-only interface driver backend to be used when netcf support is not built in. Change from v1: * rebased against master * Fixed copyright header * Added libvirt.spec.in modification * Changed virsh -V output Untested: * udev: Devices that are part of a bond. * libvirt.spec: Need some feedback from DV and the RH guys on how they want it packaged Unknown: * Should virInterfaceGetXMLDesc() be implemented for the udev backend? It will as a result contain a lot less info than the netcf based backend would for the same device (e.g. does the device start on boot). Doug Goldstein (2): build: define WITH_INTERFACE for the driver interface: add udev based backend for virInterface .gnulib | 2 +- configure.ac | 37 ++- daemon/Makefile.am | 2 +- daemon/libvirtd.c | 8 +- libvirt.spec.in | 13 +- src/Makefile.am | 34 ++- .../{netcf_driver.c => interface_backend_netcf.c} | 2 +- src/interface/interface_backend_udev.c | 395 ++++++++++++++++++++ .../{netcf_driver.h => interface_driver.h} | 0 tests/virdrivermoduletest.c | 2 +- tools/virsh.c | 8 +- 11 files changed, 480 insertions(+), 23 deletions(-) rename src/interface/{netcf_driver.c => interface_backend_netcf.c} (99%) create mode 100644 src/interface/interface_backend_udev.c rename src/interface/{netcf_driver.h => interface_driver.h} (100%) -- 1.7.8.6

3 5

[libvirt] [PATCH 0/5] Fix multiple issues related to authentication
by Daniel P. Berrange 10 Sep '12

10 Sep '12

This series fixes a load of minor bugs related to authentication of libvirt connections

2 10

[libvirt] [PATCH] docs: point out git send-email location, be more stern about make check
by Laine Stump 10 Sep '12

10 Sep '12

An email came to libvir-list wondering why the git send-email command was missing in spite of having git installed; this is due to the send-email command being in a sub-package of the main git package. While touching the hacking file, I thought it would be useful to 1) indicate the location of the source (docs/hacking.html.in) in the message at the top of HACKING, and also to make the note about running "make check" and "make syntax-check" a bit more stern. --- HACKING | 22 ++++++++++++++-------- docs/hacking.html.in | 29 ++++++++++++++++++----------- docs/hacking2.xsl | 3 ++- 3 files changed, 34 insertions(+), 20 deletions(-) diff --git a/HACKING b/HACKING index 804d54c..ab1a329 100644 --- a/HACKING +++ b/HACKING @@ -1,5 +1,6 @@ -*- buffer-read-only: t -*- vi: set ro: -DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY! +DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY +from docs/hacking.html.in! @@ -32,11 +33,14 @@ Then, when you want to post your patches: git pull --rebase (fix any conflicts) - git send-email --cover-letter --no-chain-reply-to --annotate --to=libvir-list(a)redhat.com master + git send-email --cover-letter --no-chain-reply-to --annotate \ + --to=libvir-list(a)redhat.com master -For a single patch you can omit "--cover-letter", but series of a two or more -patches needs a cover letter. If you get tired of typing -"--to=libvir-list(a)redhat.com" designation you can set it in git config: +(Note that the "git send-email" subcommand is usually not in the main git +package, but part of a sub-package called "git-email".) For a single patch you +can omit "--cover-letter", but series of a two or more patches needs a cover +letter. If you get tired of typing "--to=libvir-list(a)redhat.com" designation +you can set it in git config: git config sendemail.to libvir-list(a)redhat.com @@ -56,9 +60,11 @@ though). (3) Split large changes into a series of smaller patches, self-contained if possible, with an explanation of each patch and an explanation of how the sequence of patches fits together. Moreover, please keep in mind that it's -required to be able to compile cleanly after each patch. A feature does not -have to work until the end of a series, as long as intermediate patches don't -cause test-suite failures. +required to be able to compile cleanly (*including* "make check" and "make +syntax-check") after each patch. A feature does not have to work until the end +of a series, but intermediate patches must compile and not cause test-suite +failures (this is to preserve the usefulness of "git bisect", among other +things). diff --git a/docs/hacking.html.in b/docs/hacking.html.in index ca02669..1917b78 100644 --- a/docs/hacking.html.in +++ b/docs/hacking.html.in @@ -31,11 +31,15 @@ <pre> git pull --rebase (fix any conflicts) - git send-email --cover-letter --no-chain-reply-to --annotate --to=libvir-list(a)redhat.com master -</pre> - For a single patch you can omit <code>--cover-letter</code>, but - series of a two or more patches needs a cover letter. If you get tired - of typing <code>--to=libvir-list(a)redhat.com</code> designation you can + git send-email --cover-letter --no-chain-reply-to --annotate \ + --to=libvir-list(a)redhat.com master +</pre> + (Note that the "git send-email" subcommand is usually not + in the main git package, but part of a sub-package called + "git-email".) For a single patch you can omit + <code>--cover-letter</code>, but series of a two or more + patches needs a cover letter. If you get tired of typing + <code>--to=libvir-list(a)redhat.com</code> designation you can set it in git config: <pre> git config sendemail.to libvir-list(a)redhat.com @@ -55,12 +59,15 @@ </li> <li>Split large changes into a series of smaller patches, - self-contained if possible, with an explanation of each patch and an - explanation of how the sequence of patches fits together. Moreover, - please keep in mind that it's required to be able to compile cleanly - after each patch. A feature does not have to work until the end of a - series, as long as intermediate patches don't cause test-suite - failures. + self-contained if possible, with an explanation of each patch + and an explanation of how the sequence of patches fits + together. Moreover, please keep in mind that it's required to + be able to compile cleanly (including <code>make + check</code> and <code>make syntax-check</code>) after each + patch. A feature does not have to work until the end of a + series, but intermediate patches must compile and not cause + test-suite failures (this is to preserve the usefulness + of <code>git bisect</code>, among other things). </li> <li>Make sure your patches apply against libvirt GIT. Developers diff --git a/docs/hacking2.xsl b/docs/hacking2.xsl index 89e777b..cd1712c 100644 --- a/docs/hacking2.xsl +++ b/docs/hacking2.xsl @@ -18,7 +18,8 @@ <xsl:template match="/"> <xsl:text>-*- buffer-read-only: t -*- vi: set ro: -DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY! +DO NOT EDIT THIS FILE! IT IS GENERATED AUTOMATICALLY +from docs/hacking.html.in! -- 1.7.11.4

2 2

[libvirt] [PATCH] Fix unwanted closing of libvirt client connection
by Christophe Fergeau 10 Sep '12

10 Sep '12

e5a1bee07 introduced a regression in Boxes: when Boxes is left idle (it's still doing some libvirt calls in the background), the libvirt connection gets closed after a few minutes. What happens is that this code in virNetClientIOHandleOutput gets triggered: if (!thecall) return -1; /* Shouldn't happen, but you never know... */ and after the changes in e5a1bee07, this causes the libvirt connection to be closed. Upon further investigation, what happens is that virNetClientIOHandleOutput is called from gvir_event_handle_dispatch in libvirt-glib, which is triggered because the client fd became writable. However, between the times gvir_event_handle_dispatch is called, and the time the client lock is grabbed and virNetClientIOHandleOutput is called, another thread runs and completes the current call. 'thecall' is then NULL when the first thread gets to run virNetClientIOHandleOutput. After describing this situation on IRC, danpb suggested this: 11:37 < danpb> In that case I think the correct thing would be to change 'return -1' above to 'return 0' since that's not actually an error - its a rare, but expected event which is what this patch is doing. I've tested it against master libvirt, and I didn't get disconnected in ~10 minutes while this happens in less than 5 minutes without this patch. --- src/rpc/virnetclient.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/rpc/virnetclient.c b/src/rpc/virnetclient.c index 43a9814..727ed67 100644 --- a/src/rpc/virnetclient.c +++ b/src/rpc/virnetclient.c @@ -1205,7 +1205,10 @@ virNetClientIOHandleOutput(virNetClientPtr client) thecall = thecall->next; if (!thecall) - return -1; /* Shouldn't happen, but you never know... */ + return 0; /* This can happen if another thread raced with us and + * completed the call between the time this thread woke + * up from poll()ing and the time we locked the client + */ while (thecall) { ssize_t ret = virNetClientIOWriteMessage(client, thecall); -- 1.7.11.4

2 2

[libvirt] [libvirt-glib 1/4] config: Allow NULL node name to gvir_config_object_set_content
by Christophe Fergeau 10 Sep '12

10 Sep '12

This is useful when you want to set the content of the current node. --- libvirt-gconfig/libvirt-gconfig-object.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/libvirt-gconfig/libvirt-gconfig-object.c b/libvirt-gconfig/libvirt-gconfig-object.c index a7352a5..ac0545c 100644 --- a/libvirt-gconfig/libvirt-gconfig-object.c +++ b/libvirt-gconfig/libvirt-gconfig-object.c @@ -534,7 +534,6 @@ gvir_config_object_set_node_content(GVirConfigObject *object, GVirConfigObject *node; g_return_if_fail(GVIR_CONFIG_IS_OBJECT(object)); - g_return_if_fail(node_name != NULL); if (value == NULL) { gvir_config_object_delete_child(object, node_name, NULL); @@ -542,8 +541,12 @@ gvir_config_object_set_node_content(GVirConfigObject *object, return; } - node = gvir_config_object_replace_child(object, node_name); - g_return_if_fail(node != NULL); + if (node_name != NULL) { + node = gvir_config_object_replace_child(object, node_name); + g_return_if_fail(node != NULL); + } else { + node = g_object_ref(G_OBJECT(object)); + } encoded_data = xmlEncodeEntitiesReentrant(node->priv->node->doc, (xmlChar *)value); xmlNodeSetContent(node->priv->node, encoded_data); @@ -559,7 +562,6 @@ gvir_config_object_set_node_content_uint64(GVirConfigObject *object, char *str; g_return_if_fail(GVIR_CONFIG_IS_OBJECT(object)); - g_return_if_fail(node_name != NULL); str = g_strdup_printf("%"G_GUINT64_FORMAT, value); gvir_config_object_set_node_content(object, node_name, str); -- 1.7.11.4

2 8

[libvirt] [PATCH] qemu: Remove limit enforcing when setting processor count
by Peter Krempa 10 Sep '12

10 Sep '12

When setting processor count for a domain using the API libvirt enforced a maximum processor count that was determined using an IOCTL on /dev/kvm. Unfortunately this value isn't representative enough and qemu happily accepts and starts with values greater than the reported value. This patch removes the check so that users are able to use full potential of their big boxes also when setting processor counts with the API not just in XML. --- src/qemu/qemu_driver.c | 16 +++------------- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 8e8e00c..6be3e5f 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -3595,7 +3595,6 @@ qemuDomainSetVcpusFlags(virDomainPtr dom, unsigned int nvcpus, virDomainObjPtr vm; virDomainDefPtr persistentDef; const char * type; - int max; int ret = -1; bool maximum; @@ -3645,20 +3644,11 @@ qemuDomainSetVcpusFlags(virDomainPtr dom, unsigned int nvcpus, goto endjob; } - if ((max = qemudGetMaxVCPUs(NULL, type)) < 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("could not determine max vcpus for the domain")); - goto endjob; - } - - if (!maximum && vm->def->maxvcpus < max) { - max = vm->def->maxvcpus; - } - - if (nvcpus > max) { + if (!maximum && nvcpus > vm->def->maxvcpus) { virReportError(VIR_ERR_INVALID_ARG, _("requested vcpus is greater than max allowable" - " vcpus for the domain: %d > %d"), nvcpus, max); + " vcpus for the domain: %d > %d"), + nvcpus, vm->def->maxvcpus); goto endjob; } -- 1.7.12

4 7

[libvirt] [libvirt-designer][PATCH 0/4] Basic disk & interface support
by Michal Privoznik 10 Sep '12

10 Sep '12

with small example called virtxml Michal Privoznik (4): Load osinfo DB on init domain: Introduce disk support examples: Create an example of usage program domain: Introduce interface support .gitignore | 1 + Makefile.am | 2 +- configure.ac | 6 +- examples/Makefile.am | 23 ++ examples/virtxml.c | 406 ++++++++++++++++++++++++++ libvirt-designer/Makefile.am | 1 + libvirt-designer/libvirt-designer-domain.c | 302 +++++++++++++++++++- libvirt-designer/libvirt-designer-domain.h | 12 +- libvirt-designer/libvirt-designer-internal.h | 30 ++ libvirt-designer/libvirt-designer-main.c | 17 +- libvirt-designer/libvirt-designer.sym | 4 + 11 files changed, 799 insertions(+), 5 deletions(-) create mode 100644 examples/Makefile.am create mode 100644 examples/virtxml.c create mode 100644 libvirt-designer/libvirt-designer-internal.h -- 1.7.8.6

3 13

Re: [libvirt] [User question] Huge buffer size on KVM host
by Avi Kivity 10 Sep '12

10 Sep '12

On 08/16/2012 05:54 PM, Martin Wawro wrote: > > On Aug 15, 2012, at 2:57 PM, Avi Kivity wrote: > >>> >>> We are using logical volumes and the cache is set to 'none'. >> >> Strange, that should work without any buffering. >> >> What the contents of >> >> /sys/block/sda/queue/hw_sector_size >> >> and >> >> /sys/block/sda/queue/logical_block_size >> >> ? >> > > Hi Avi, > > It seems that the kernel on that particular machine is too old, those entries are > not featured. We checked on a comparable setup with a newer kernel and both entries > were set to 512. > > We also did have a third more thorough look on the caching. It turns out that the > virt-manager does not seem to honor the caching adjusted in the GUI correctly. > We disabled caching on all virtual devices for this particular VM and checking > with "ps -fxal" revealed, that only one of those devices (and a rather small one too) > had this set. We corrected this in the XML file directly and the buffer size > currently resides at around 1.8 GB after rebooting the VM (the only virtio device > not having the cache=none option set is now the (non-mounted) cdrom). > cc += libvirt-list Is there a reason that cdroms don't get cache=none? -- error compiling committee.c: too many arguments to function

2 1

[libvirt] Libvir JNA report SIGSEGV
by Benjamin Wang (gendwang) 10 Sep '12

10 Sep '12

Hi, I try to verify the JNA with concurrent situation but meet some problems. The following is my example code: public static void testcase1() throws LibvirtException { Connect conn=null; Connect conn1=null; //connect to the hypervisor conn = new Connect("esx://10.74.125.68:443/?no_verify=1&transport=https", new ConnectAuthDefault(), 0); System.out.println(conn.getVersion()); //connect to the hypervisor conn1 = new Connect("esx://10.74.125.90:443/?no_verify=1&transport=https", new ConnectAuthDefault(), 0); System.out.println(conn1.getVersion()); while(true) { int[] array = new int[100000000]; Long version = conn.getVersion(); Long version1 = conn1.getVersion(); try { Thread.sleep(1000); } catch(Exception e) { } } } When I add line "int[] array = new int[100000000]", then the following error will be generated very quickly: # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000003f9b07046e, pid=30049, tid=1109510464 # # Java VM: OpenJDK 64-Bit Server VM (1.6.0-b09 mixed mode linux-amd64) # Problematic frame: # C [libc.so.6+0x7046e] # # An error report file with more information is saved as: I have tried to write the similar code as following. It works well. static void virXenBasic_TC001(void) { virConnectPtr conn = NULL; virConnectPtr conn1 = NULL; unsigned long version = 0; unsigned long version1 = 0; char *hostname = NULL; conn = virConnectOpenAuth("esx://10.74.125.21/?no_verify=1", virConnectAuthPtrDefault, 0); if (conn == NULL) { fprintf(stderr, "Failed to open connection to qemu:///system\n"); return; } conn1 = virConnectOpenAuth("esx://192.168.119.40/?no_verify=1", virConnectAuthPtrDefault, 0); if (conn1 == NULL) { fprintf(stderr, "Failed to open connection to qemu:///system\n"); return; } while(true) { hostname = malloc(sizeof(char) * 100000000); virConnectGetVersion(conn, &version); virConnectGetVersion(conn, &version1); free(hostname); sleep(1); } return; } B.R. Benjamin Wang

2 7

[libvirt] [PATCH 0/6 v4] Atomic API to list storage volumes
by Osier Yang 10 Sep '12

10 Sep '12

v3 - v4: * Just rebase on the top, and split each API from the big set. Osier Yang (6): list: Define new API virStoragePoolListAllVolumes list: Implemente RPC calls for virStoragePoolListAllVolumes list: Implement virStoragePoolListAllVolumes for storage driver list: Implement virStoragePoolListAllVolumes for test driver list: Use virStoragePoolListAllVolumes in virsh list: Expose virStoragePoolListAllVolumes to Python binding daemon/remote.c | 58 +++++++++ include/libvirt/libvirt.h.in | 3 + python/generator.py | 1 + python/libvirt-override-api.xml | 8 +- python/libvirt-override-virStoragePool.py | 11 ++ python/libvirt-override.c | 50 ++++++++ src/driver.h | 6 +- src/libvirt.c | 50 ++++++++ src/libvirt_public.syms | 1 + src/remote/remote_driver.c | 66 ++++++++++ src/remote/remote_protocol.x | 14 ++- src/remote_protocol-structs | 13 ++ src/storage/storage_driver.c | 67 ++++++++++ src/test/test_driver.c | 67 ++++++++++ tools/virsh-volume.c | 197 ++++++++++++++++++++++------- 15 files changed, 562 insertions(+), 50 deletions(-) create mode 100644 python/libvirt-override-virStoragePool.py -- 1.7.7.3

3 14