Re: [libvirt] QMP stubs: how to return "not implemented" errors?

On Tue, Oct 04, 2016 at 03:57:10PM -0500, Eric Blake wrote: > On 10/04/2016 01:22 PM, Eduardo Habkost wrote: > > On Mon, Oct 03, 2016 at 03:15:39PM -0500, Eric Blake wrote: > > [...] > >>> 3.2) Removing the unimplemented command from query-commands only > >>>(by calling qmp_disable_command()),

Re: [libvirt] [PATCH 3/3] introduce pull backup

On 09/30/2016 10:38 AM, Nikolay Shirokovskiy wrote: > > > On 30.09.2016 01:02, John Ferlan wrote: >> >> >> [...] >> Because it's also dependent upon an x-blockdev-del, it cannot be pushed upstream to libvirt. I know qemu work continues w/r/t blockdev-add and backups, but I

Re: [libvirt] QMP stubs: how to return "not implemented" errors?

On 10/04/2016 01:22 PM, Eduardo Habkost wrote: > On Mon, Oct 03, 2016 at 03:15:39PM -0500, Eric Blake wrote: > [...] >>> 3.2) Removing the unimplemented command from query-commands only >>>(by calling qmp_disable_command()), but keeping it on the QAPI >>>schema. I am not sure it's OK to do

Re: [libvirt] Release of libvirt-2.3.0

On Tue, Oct 04, 2016 at 09:24:42PM +0200, Jean-Marc Liger wrote: > Le 04/10/2016 à 19:29, Daniel Veillard a écrit : > > >We are a little late but that allowed us to catch a regression before it > > impacted > > the release :) > >I have tagged the release in git, pushed signed tarball and

Re: [libvirt] Release of libvirt-2.3.0

Le 04/10/2016 à 19:29, Daniel Veillard a écrit : We are a little late but that allowed us to catch a regression before it impacted the release :) I have tagged the release in git, pushed signed tarball and rpms to the usual place: ftp://libvirt.org/libvirt/ I also pushed the

Re: [libvirt] QMP stubs: how to return "not implemented" errors?

On Mon, Oct 03, 2016 at 03:15:39PM -0500, Eric Blake wrote: [...] > > 3.2) Removing the unimplemented command from query-commands only > >(by calling qmp_disable_command()), but keeping it on the QAPI > >schema. I am not sure it's OK to do that. If it is, this > >sounds like the

[libvirt] Release of libvirt-2.3.0

We are a little late but that allowed us to catch a regression before it impacted the release :) I have tagged the release in git, pushed signed tarball and rpms to the usual place: ftp://libvirt.org/libvirt/ I also pushed the associated python bindings release available at:

Re: [libvirt] [OSSTEST PATCH 1/2] libvirt: Check migration capabilities using proper XML parser

Ian Jackson writes ("[OSSTEST PATCH 1/2] libvirt: Check migration capabilities using proper XML parser"): > Do not grep the virsh capabilities output (!) Instead, parse the XML > using perl's XML modules and look for the specific feature flag using > an XPATH pattern. ...> > +sub

[libvirt] [OSSTEST PATCH 2/2] libvirt: Do not attempt save/restore when migration not advertised

Currently, osstest wrongly thinks that ARM can do save/restore, because `virsh help' does mention the save command (on all architectures). Additionally, check the virth capabilities xpath /capabilities/host/migration_features to try to see whether this host supports migration. I am not sure

[libvirt] [OSSTEST PATCH 0/2] libvirt: Fix save/restore capability check on ARM

Currently, osstest, the Xen Project's automated test framework, erroneously thinks that save/restore is supported with libvirt on ARM. In fact, save/restore is not supported by Xen on ARM at all. The result is that osstest then actually attempts the save/restore, and abandons the test job as a

[libvirt] [OSSTEST PATCH 1/2] libvirt: Check migration capabilities using proper XML parser

Do not grep the virsh capabilities output (!) Instead, parse the XML using perl's XML modules and look for the specific feature flag using an XPATH pattern. AFAICT from looking at the XML, that's But the original code does not test for . Xen could in principle

Re: [libvirt] Entering freeze for libvirt-2.3.0

On 04.10.2016 18:03, Peter Krempa wrote: > On Fri, Sep 30, 2016 at 15:28:08 +0200, Daniel Veillard wrote: >> On Fri, Sep 30, 2016 at 11:37:08AM +0200, Guido Günther wrote: >>> On Tue, Sep 27, 2016 at 10:14:36PM +0200, Daniel Veillard wrote: Since nobody complained about my earlier message

Re: [libvirt] [PATCH] qemu_command: Count the cpus correctly when the are absent

On Tue, Oct 04, 2016 at 17:22:37 +0530, Shivaprasad wrote: > qemuBuildSmpCommandLine - is ending up generating "-smp 0," after > first/subsequent restarts of the guest and we see "error: internal error: qemu > reported thread id for inactive vcpu 'X'" > > The PostParse logic which changes the

[libvirt] [PATCH 2/2] Revert "conf: Skip post parse callbacks when creating copy"

This breaks vCPU hotplug, because when starting a domain, we create a copy of domain definition (which becomes live XML) and during the post parse callbacks we might adjust some tunings so that vCPU hotplug is possible. This reverts commit 581b7756af18dcf84b57d9947978725d2dfbfc18. Signed-off-by:

[libvirt] [PATCH 1/2] Revert "domain_conf: Introduce VIR_DOMAIN_DEF_PARSE_SKIP_POST_PARSE"

This breaks vCPU hotplug, because when starting a domain, we create a copy of domain definition (which becomes live XML) and during the post parse callbacks we might adjust some tunings so that vCPU hotplug is possible. This reverts commit c0f90799bc7fa4b690ead6a592806378a243873c. Signed-off-by:

Re: [libvirt] [PATCH 0/2] Revert two patches of mine

On Tue, Oct 04, 2016 at 18:02:36 +0200, Michal Privoznik wrote: > Basically, this broke vCPU hotplug (as discovered by Peter). > While these are fixing a bug, they have lover priority (nobody > reported the bug until I tried unusual scenario). So revert these > in favour of vCPU hotplug feature

Re: [libvirt] Entering freeze for libvirt-2.3.0

On Fri, Sep 30, 2016 at 15:28:08 +0200, Daniel Veillard wrote: > On Fri, Sep 30, 2016 at 11:37:08AM +0200, Guido Günther wrote: > > On Tue, Sep 27, 2016 at 10:14:36PM +0200, Daniel Veillard wrote: > > > Since nobody complained about my earlier message with the release plan, > > > I tagged

[libvirt] [PATCH 0/2] Revert two patches of mine

Basically, this broke vCPU hotplug (as discovered by Peter). While these are fixing a bug, they have lover priority (nobody reported the bug until I tried unusual scenario). So revert these in favour of vCPU hotplug feature available and do the right fix after the release. Michal Privoznik (2):

Re: [libvirt] [PATCH v3 09/18] qemu: set/use info->pciConnectFlags during qemuDomainAssignDevicePCISlots

On 10/04/2016 10:11 AM, Andrea Bolognani wrote: On Tue, 2016-09-20 at 15:14 -0400, Laine Stump wrote: Set pciConnectFlags in each device's DeviceInfo prior to assigning PCI addresses, and then use those flags later when actually assigning the addresses with qemuDomainPCIAddressReserveNextAddr()

Re: [libvirt] [libvirt-glib 03/20] gconfig: Introduce GVirConfigDomainGraphicsListenAddress

On Tue, Oct 04, 2016 at 05:23:41PM +0200, Christophe Fergeau wrote: > From: Visarion Alexandru > > This is needed to be able to change the address a graphics > device is listening for. > --- > libvirt-gconfig/Makefile.am| 2 + >

[libvirt] [PATCH v3 2/4] qemu: Create common code for JSON "query-block" call

Reduce some cut-n-paste code by creating common helper. Make use of the recently added virJSONValueObjectStealArray to grab the devices list as part of the common code (we we can Free the reply) and return devices for each of the callers to continue to parse. NB: This also adds error checking to

[libvirt] [PATCH v3 1/4] util: Introduce virJSONValueObjectStealArray

Provide the Steal API for any code paths that will desire to grab the entire array and then free it afterwards rather than relying to freeing the whole chain from the reply. Signed-off-by: John Ferlan --- src/libvirt_private.syms | 1 + src/util/virjson.c | 43

[libvirt] [PATCH v3 3/4] qemu: Create helper qemuMonitorJSONGetBlockDev

This will grab the 'dev' from devices and do the common validation checks. Signed-off-by: John Ferlan --- src/qemu/qemu_monitor_json.c | 37 + 1 file changed, 21 insertions(+), 16 deletions(-) diff --git a/src/qemu/qemu_monitor_json.c

[libvirt] [PATCH v3 4/4] qemu: Create helper qemuMonitorJSONGetBlockDevDevice

This will fetch "this device" from the recently returned 'dev' and perform common error checking for the paths that call it. Signed-off-by: John Ferlan --- src/qemu/qemu_monitor_json.c | 31 ++- 1 file changed, 18 insertions(+), 13 deletions(-)

[libvirt] [PATCH v3 0/4] Combine various query-block json call paths

I'm not unreasonable ;-) - making the suggested alterations from the review and NACK of v2/v1 which combined the for loops as well. v2: http://www.redhat.com/archives/libvir-list/2016-September/msg01483.html Changes - new patch 1, 3, 4 Alteration to patch 1 of previous series to use the new

[libvirt] [libvirt-glib 15/20] gconfig: Adapt GVirConfigDomainGraphicsVnc to GVirConfigDomainGraphicsRemote

From: Fabiano Fidêncio This patch adapts GVirConfigDomainGraphicsVnc to the new GVirConfigDomainGraphicsRemote, inheriting from it and using its helper functions for getting auport and port properties. As GVirConfigDomainGraphicsVnc now inherits from

[libvirt] [libvirt-glib 20/20] gconfig: Move 'listen' handling to GVirConfigDomainGraphicsRemote

It's only useful in the remote case, and removes duplication between GVirConfigDomainGraphicsSpice and GVirConfigDomainGraphicsVnc. Since the spice/vnc listen API was not in a libvirt-gconfig release, we can remove it without breaking API/ABI. --- .../libvirt-gconfig-domain-graphics-remote.c

[libvirt] [libvirt-glib 11/20] gconfig: Implement gvir_config_domain_graphics_spice_get_tls_port()

From: Fabiano Fidêncio Signed-off-by: Fabiano Fidêncio --- libvirt-gconfig/libvirt-gconfig-domain-graphics-spice.c | 8 libvirt-gconfig/libvirt-gconfig-domain-graphics-spice.h | 1 + libvirt-gconfig/libvirt-gconfig.sym | 1

[libvirt] [libvirt-glib 19/20] gconfig: Add precondition to gvir_config_object_get_xml_node()

This will catch (among other things) cases when gvir_config_object_get_xml_node() is called with a NULL argument. Not catching this could cause a crash later on in cases when gvir_config_object_new_from_xml() is called and returns NULL, and then we call gvir_config_object_get_attribute() on it.

[libvirt] [libvirt-glib 16/20] gconfig: Add GVirCofigDomainGraphicsLocal class

From: Fabiano Fidêncio Adding this class more fore completness to the GVirConfigDomainGraphicsRemote than for any other reason. This patch introduces a new hierarchy in the project, where, instead of having GVirConfigDomainGraphics{Desktop,Sdl} inheriting from

[libvirt] [libvirt-glib 14/20] gconfig: Adapt GVirConfigDomainGraphicsRdp to GVirConfigDomainGraphicsRemote

From: Fabiano Fidêncio This patch adapts GVirConfigDomainGraphicsRdp to the new GVirConfigDomainGraphicsRemote, inheriting from it and using its helper functions for getting autoport and port properties. As GVirConfigDomainGraphicsRdp now inherits from

[libvirt] [libvirt-glib 17/20] gconfig: Adapt GVirConfigDomainGraphicsSdl to GVirConfigDomainGraphicsLocal

From: Fabiano Fidêncio This patch adapts GVirConfigDomainGraphicsSdl to the new GVirConfigDomainGraphicsLocal, inheriting from it and using its helper functions for getting the display and fullscreen properties. As GVirConfigDomainGraphicsSdl now inherits from

[libvirt] [libvirt-glib 03/20] gconfig: Introduce GVirConfigDomainGraphicsListenAddress

From: Visarion Alexandru This is needed to be able to change the address a graphics device is listening for. --- libvirt-gconfig/Makefile.am| 2 + ...ibvirt-gconfig-domain-graphics-listen-address.c | 131 +

[libvirt] [libvirt-glib 12/20] gconfig: Add GVirConfigDomainGraphicsRemote class

From: Fabiano Fidêncio Seems that GVirConfigDomainGraphics* were built with a strong focus on writing/setting configs, but not reading those. For instance, considering virt-viewer's case, where the app is just consuming an already built xml, for getting the port attribute

[libvirt] [libvirt-glib 01/20] libvirt-gconfig: Include GIO dependency

From: Visarion Alexandru We will need a GInetAddress for setting a graphics device's listen address, so let's include GIO2 in libvirt-gconfig. --- libvirt-gconfig-1.0.pc.in | 2 +- libvirt-gconfig/Makefile.am | 6 -- vapi/Makefile.am| 1 + 3 files

[libvirt] [libvirt-glib 18/20] gconfig: Adapt GVirConfigDomainGraphicsDesktop to GVirConfigDomainGraphicsLocal

From: Fabiano Fidêncio This patch adapts GVirConfigDomainGraphicsDesktop to the new GVirConfigDomainGraphicsLocal, inheriting from it and using its helper functions for getting display and fullscreen properties. As GVirConfigDomainGraphicsDesktop now inherits from

[libvirt] [libvirt-glib 05/20] config: Add spice listen getter/setter

From: Visarion Alexandru Learn to get/set the listen devices that spice graphics is using. When setting the listen devices, first remove the 'listen' attribute to avoid the inconsistencies checks between the 'listen' attribute and the 'address' attribute of the

[libvirt] [libvirt-glib 06/20] tests: Add test for GVirConfigDomainGraphicsListenAddress

From: Visarion Alexandru --- tests/test-gconfig.c | 39 ++ .../xml/gconfig-domain-device-graphics-listen.xml | 7 2 files changed, 46 insertions(+) create mode 100644

[libvirt] [libvirt-glib 07/20] gconfig: Introduce GVirConfigDomainGraphicsListenNone

--- libvirt-gconfig/Makefile.am| 2 + .../libvirt-gconfig-domain-graphics-listen-none.c | 78 ++ .../libvirt-gconfig-domain-graphics-listen-none.h | 70 +++ libvirt-gconfig/libvirt-gconfig.h | 1 +

[libvirt] [libvirt-glib 04/20] config: Add vnc listen getter/setter

From: Visarion Alexandru Learn to get/set the listen devices that vnc is using. When setting the listen devices, first remove the 'listen' attribute to avoid inconsistencies checks between the 'listen' attribute and the 'address' attribute of the 'listen' node. ---

[libvirt] [libvirt-glib 13/20] gconfig: Adapt GVirConfigDomainGraphicsSpice to GVirConfigDomainGraphicsRemote

From: Fabiano Fidêncio This patch adapts GVirConfigDomainGraphicsSpice to the new GVirConfigDomainGraphicsRemote, inheriting from it and using its helper functions for getting autoport and port properties. As GVirConfigDomainGraphicsSpice now inherits from

[libvirt] [libvirt-glib 00/20] gconfig: configuration work

Hey, This series groups 2 series which were sent previously for review, one from Visarion https://www.redhat.com/archives/libvir-list/2016-August/msg00868.html and one from Fidencio https://www.redhat.com/archives/libvir-list/2016-March/msg00993.html I'm putting them together as they touch the

[libvirt] [libvirt-glib 02/20] gconfig: Introduce GVirConfigDomainGraphicsListen

From: Visarion Alexandru Abstract class which represents a listen child node of the graphics device. --- libvirt-gconfig/Makefile.am| 2 + .../libvirt-gconfig-domain-graphics-listen.c | 49

[libvirt] [libvirt-glib 09/20] gconfig: Add gvir_config_domain_graphics_{spice, vnc}_add_listen

--- libvirt-gconfig/libvirt-gconfig-domain-graphics-spice.c | 17 + libvirt-gconfig/libvirt-gconfig-domain-graphics-spice.h | 2 ++ libvirt-gconfig/libvirt-gconfig-domain-graphics-vnc.c | 17 + libvirt-gconfig/libvirt-gconfig-domain-graphics-vnc.h | 2 ++

[libvirt] [libvirt-glib 10/20] gconfig: Remove 'socket' attribute from gvir_config_domain_graphics_{spice, vnc}_set_listen

This is a legacy attribute which is going to conflict with listen nodes when we set some. --- libvirt-gconfig/libvirt-gconfig-domain-graphics-spice.c | 2 ++ libvirt-gconfig/libvirt-gconfig-domain-graphics-vnc.c | 2 ++ 2 files changed, 4 insertions(+) diff --git

[libvirt] [libvirt-glib 08/20] gconfig: Introduce GVirConfigDomainGraphicsListenUnix

--- libvirt-gconfig/Makefile.am| 2 + .../libvirt-gconfig-domain-graphics-listen-unix.c | 98 ++ .../libvirt-gconfig-domain-graphics-listen-unix.h | 72 libvirt-gconfig/libvirt-gconfig.h | 1 +

Re: [libvirt] [PATCH 1/2] conf: Add support for preallocated fd memory

On Tue, Oct 04, 2016 at 05:07:16PM +0200, Michal Privoznik wrote: > On 29.09.2016 10:56, Jaroslav Safka wrote: > > This first change introduces xml parsing support for preallocated > > shared file descriptor based memory backing. > > It allows vhost-user to be used without hugepages. > > > > New

Re: [libvirt] [PATCH 1/2] conf: Add support for preallocated fd memory

On 29.09.2016 10:56, Jaroslav Safka wrote: > This first change introduces xml parsing support for preallocated > shared file descriptor based memory backing. > It allows vhost-user to be used without hugepages. > > New xml elements: > > > > > Okay, this is definitely interesting

[libvirt] [PATCH v2 2/3] qemu: first wait all workers finish on state cleanup

This fix the crash [1] This happens on race conditions of simultaneous exiting libvirtd and qemu process. Let's just finish all workers that keep driver pointer before disposing driver object or any of its members. [1] crash backtrace: (bt is shortened a bit): 0 0x77282f2b in

[libvirt] [PATCH v2 1/3] daemon: keep daemon until all hypervisors drivers are cleaned up

This fix SEGV with the backtrace [1] This happens due to race on simultaneous finishing of libvirtd and qemu process. We need to keep daemon object until all hypervisor drivers are cleaned up. The other option is to take reference to daemon in every hypervisor driver but this will take more work

[libvirt] [PATCH v2 3/3] util: event loop: document another reason to defer deletion

This is why we should not free callback object synchronously upon removing handle or timeout. Imagine: 1. loop thread,drops the lock and is about to call event callback 2. another thread, enters remove handle and frees callback object 3. loop thread,enters event callback, uses callback

Re: [libvirt] [PATCH 0/2] Increase bound limit for virDomainGetBlockIoTune

On 04.10.2016 15:22, John Ferlan wrote: > Related to my onlist (and ACK'd) series for adding 6 new parameters > for adding length (duration) parameters to/for iotune throttling: > > http://www.redhat.com/archives/libvir-list/2016-September/msg01090.html > > As described in a response to the

[libvirt] [PATCH v2 0/3] libvirtd: fix crashes on termination

diff from v1 1. drop patches 1-2 of v1. As to "event loop" patch seems nobody has "production" problems due to leaks on termination. Turning freeing callback objects registered in event loop on after it is finished has an impact that is hard to predict. Different parts of libvirt

Re: [libvirt] [PATCH v3 09/18] qemu: set/use info->pciConnectFlags during qemuDomainAssignDevicePCISlots

On Tue, 2016-09-20 at 15:14 -0400, Laine Stump wrote: > Set pciConnectFlags in each device's DeviceInfo prior to assigning PCI > addresses, and then use those flags later when actually assigning the > addresses with qemuDomainPCIAddressReserveNextAddr() (rather than > scattering the logic about

Re: [libvirt] Missing blockJobInfo() method from v1.2.5 Python bindings?

On Tue, Oct 04, 2016 at 03:08:24PM +0200, Michal Privoznik wrote: > On 04.10.2016 10:43, Kashyap Chamarthy wrote: [...] > > Now try to find out what is present in v1.2.5 by quickly building the > > bindings for that tag: > > > > $ git checkout v1.2.5 > > $ python setup.py build > > > >

[libvirt] [PATCH 2/2] remote: Increase bound limit for virDomainGetBlockIoTune

We are about to add 6 new values to fetch. This will put us over the current limit of 16 (we're at 13 now). Once there are more than 16 parameters, this will affect existing clients that attempt to fetch blockiotune config values for the domain from the remote host since the server side has no

[libvirt] [PATCH 0/2] Increase bound limit for virDomainGetBlockIoTune

Related to my onlist (and ACK'd) series for adding 6 new parameters for adding length (duration) parameters to/for iotune throttling: http://www.redhat.com/archives/libvir-list/2016-September/msg01090.html As described in a response to the cover:

[libvirt] [PATCH 1/2] remote: Fix erroneous usage of constant

The REMOTE_DOMAIN_MEMORY_PARAMETERS_MAX was erroneously used in the remoteDomainBlockStatsFlags and remoteDomainGetBlockIoTune calls. Change the constant to be the right one. Fortunately, all 3 are defined as 16. Signed-off-by: John Ferlan --- src/remote/remote_driver.c | 4

[libvirt] [PATCH v3] Fixes virsh save-restore/migration when memory detach not in LIFO

Currently the migration stream references the memory blocks by name (which is supplied by libvirt) rather than by there order. With the current code that is assigning aliases for memory backend objects this won't happen and since qemu is treating the memory object links differently migration does

Re: [libvirt] Missing blockJobInfo() method from v1.2.5 Python bindings?

On 04.10.2016 10:43, Kashyap Chamarthy wrote: > Last night I was trying to check whether blockJobInfo() method will > raise an error when it returns 'None' in v1.2.5 libvirt Python bindings. > (Eric Blake confirmed on IRC: "the python bindings have, as a general > rule, always raised a

Re: [libvirt] Missing blockJobInfo() method from v1.2.5 Python bindings?

On Tue, Oct 04, 2016 at 10:43:31AM +0200, Kashyap Chamarthy wrote: > Last night I was trying to check whether blockJobInfo() method will > raise an error when it returns 'None' in v1.2.5 libvirt Python bindings. > (Eric Blake confirmed on IRC: "the python bindings have, as a general > rule, always

Re: [libvirt] Some maintenance back-ports

On Tue, Oct 04, 2016 at 12:48:24PM +0200, Martin Kletzander wrote: I wanted to back-port commit 4372a7845acbc6974f6027ef68e7dd3eeb47f425 to Of course I prepared this mail before updating all the branches and forgot to fix the commit hash. The proper one is:

[libvirt] [PATCH] qemu_command: Count the cpus correctly when the are absent

qemuBuildSmpCommandLine - is ending up generating "-smp 0," after first/subsequent restarts of the guest and we see "error: internal error: qemu reported thread id for inactive vcpu 'X'" The PostParse logic which changes the hotplug = ABSENT to NO for each vcpus is not called with

Re: [libvirt] 2 major proposals to enhance libvirt and its attractivity among developers & users

On 02.10.2016 15:11, jean-christophe Manciot wrote: > Hello everyone. Hi, Thank you for your points. I often think about this as I'm trying to promote libvirt on every occasion. > > Going straight to the point: > 1) *add connection type: Docker* > This should not induce a lot of development

Re: [libvirt] Recommendations for Libvirt LTS release

On 01.10.2016 11:15, Guido Günther wrote: > Hi, > Debian is about to enter it's freeze for the Stretch release in November > and we will support the libvirt version that is in Stretch for at least > 5 years. > > The upstream version of libvirt at this point will likely be 2.4.0. Are > any other

[libvirt] Some maintenance back-ports

I wanted to back-port commit 4372a7845acbc6974f6027ef68e7dd3eeb47f425 to various maintenance branches due to the fact that it changes how migration behaves and that would fix it for future uses at leas. I found out some compilation problems (mainly because I switched to gcc 6.2.0). I wanted to

Re: [libvirt] [PATCH v3] qemu: fix command line building for iommu devices

On Mon, Oct 03, 2016 at 04:48:35PM +0100, Daniel P. Berrange wrote: The intel-iommu device has existed since QEMU 2.2.0, but it was only possible to create it with -device since QEMU 2.7.0, thanks to: commit 621d983a1f9051f4cfc3f402569b46b77d8449fc Author: Marcel Apfelbaum

Re: [libvirt] [PATCH v3] qemu: fix command line building for iommu devices

On Mon, Oct 03, 2016 at 04:48:35PM +0100, Daniel P. Berrange wrote: > The intel-iommu device has existed since QEMU 2.2.0, but > it was only possible to create it with -device since > QEMU 2.7.0, thanks to: > > commit 621d983a1f9051f4cfc3f402569b46b77d8449fc > Author: Marcel Apfelbaum

Re: [libvirt] Question about QEMU + hugepages + NUMA memory + migration

On Tue, Oct 04, 2016 at 02:34:57PM +1100, Sam Bobroff wrote: On Mon, Oct 03, 2016 at 04:27:25PM +0200, Martin Kletzander wrote: On Mon, Aug 01, 2016 at 02:01:22PM +1000, Sam Bobroff wrote: >Hi libvirt people, > >I've been looking at a (probable) bug and I'm not sure how to progress. The

[libvirt] Missing blockJobInfo() method from v1.2.5 Python bindings?

Last night I was trying to check whether blockJobInfo() method will raise an error when it returns 'None' in v1.2.5 libvirt Python bindings. (Eric Blake confirmed on IRC: "the python bindings have, as a general rule, always raised a libvirtError if the C binding code returns None"). Before asking

[libvirt] [PATCH 07/10] qemu: agent: simplify io loop

Now we don't need to differentiate error and eof cases in the loop function. So let's simplify it radically using goto instead of flags. --- src/qemu/qemu_agent.c| 185 ++- src/qemu/qemu_agent.h| 2 - src/qemu/qemu_process.c | 22

[libvirt] [PATCH 04/10] qemu: agent: handle agent connection errors in one place

--- src/qemu/qemu_driver.c| 8 +-- src/qemu/qemu_migration.c | 13 ++- src/qemu/qemu_process.c | 58 --- 3 files changed, 17 insertions(+), 62 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index

[libvirt] [PATCH 09/10] qemu: agent: fix loop error messages

--- src/qemu/qemu_agent.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c index 5dc39b6..36bc7c7 100644 --- a/src/qemu/qemu_agent.c +++ b/src/qemu/qemu_agent.c @@ -634,9 +634,15 @@ qemuAgentIO(int watch, int fd, int

[libvirt] [PATCH 05/10] qemu: agent: straigten up failed agent start case

agentError is used for 2 different cases: 1. agent monitor is failed to start 2. io error in agent monitor Actually to check for the first case we don't need the flag at all. NULL agent is always error for old qemu (QEMU_CAPS_VSERPORT_CHANGE is not supported), while for modern qemu it is an

[libvirt] [PATCH 03/10] qemu: agent: clear error flag upon init

There were a few errors in the code when this flag was not cleared upon monitor cleanup. All of them could be fixed just resetting this flag upon agent monitor initialization. --- src/qemu/qemu_process.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/qemu/qemu_process.c

[libvirt] [PATCH 10/10] qemu: agent: drop redundant referencing in loop

The caller should take care of it. In this case the caller is default event loop implementation. Actually this can be complicated because error callback can trigger unreferencing the monitor. But first this is done at the end anyway when we drop reference already, second current default loop

[libvirt] [PATCH 00/10] qemu: agent: bugfix and improvments

Patch 1 fixes the bug I dealt with. Patches 2-3 is a somewhat protection from similar bugs. Patches 5-6 drop error flag from the agent altogether, so now there are less places for bugs to lurk. Rest patches cleanup loop function. I think 1-3 can be dropped if 6 is approved. It is just 6 can

[libvirt] [PATCH 06/10] qemu: agent: drop agent error flag

Let's take a closer look at qemuAgentIO. In the case of error we stop listening to any events besides error and eof. Then set last error so that all next loop invocations do very little: 1. if it is an error then just call error callback once more. Current callback is noop for subsequent

[libvirt] [PATCH 01/10] qemu: agent: unset error flag in EOF handler

Usually on domain shutdown event comes first from qemu and the flag is unset in processSerialChangedEvent. However there is a race between this function and qemuProcessHandleAgentEOF because the former is executed in a thread pool and the latter executed synchronously. qemuProcessHandleAgentEOF do

[libvirt] [PATCH 08/10] qemu: agent: exit early if error is already set

If we catch io error in previous loop invocation we don't need to report 'unexpected fd' error only to drop it later. Let's also call error callback only once. --- src/qemu/qemu_agent.c | 28 +--- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git

[libvirt] [PATCH 02/10] qemu: agent: dont set error after agent cleanup

If there is an error event after eof event then after agent is cleaned up on eof error flag will be set back and remains set after next domain start up making agent unavailable. Thus let's check before set this flag on error event. --- src/qemu/qemu_process.c | 3 ++- 1 file changed, 2