Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

Pavel Hrdina writes ("Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)"): > On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote: > > -git submodule update --init || exit 1 > > +if [ "x$1" = x--no-git ]; then > > + shift >

Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

Pavel Hrdina writes ("Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)"): > To be honest I don't understand why would anyone want to keep track of > all submodules of all projects for any CI and update it manually every > time the upstream project changes these submodules.

Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

Pavel Hrdina writes ("Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)"): > There should not be any need to disable this explicitly unless you want > to build libvirt with different revisions of submodules. The Xen Project CI has a cross-tree bisector. It is capable of

[PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

en perhaps a more sophisticated approach will be needed. But I think this will do for now. Signed-off-by: Ian Jackson --- autogen.sh | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/autogen.sh b/autogen.sh index 4e1bbceb0a..1c98273452 100755 --- a/autogen.sh +++ b/

Re: [libvirt] Likely build race, "/usr/bin/ld: cannot find -lvirt"

Jiri Denemark writes ("Re: [libvirt] Likely build race, "/usr/bin/ld: cannot find -lvirt""): > On Tue, Jun 12, 2018 at 07:57:40 -0500, Eric Blake wrote: > > Can you add that line directly into Makefile.am, or does doing that > > cause automake to complain and/or omit its normal rules because it

Re: [libvirt] Likely build race, "/usr/bin/ld: cannot find -lvirt"

Ian Jackson writes ("Likely build race, "/usr/bin/ld: cannot find -lvirt""): > tl;dr: > > I think there is a bug in libvirt's build system which, with > low probability, causes a build failure containing this message: > /usr/bin/ld: cannot find -lvirt >

[libvirt] Likely build race, "/usr/bin/ld: cannot find -lvirt"

tl;dr: I think there is a bug in libvirt's build system which, with low probability, causes a build failure containing this message: /usr/bin/ld: cannot find -lvirt Complete build logs of two attempts:

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

Julien Grall writes ("Re: [OSSTEST PATCH 1/2] libvirt: Check migration capabilities using proper XML parser"): > live migration is not currently the supported but will be in the future. > FWIW, there is a patch series on xen-devel to support dead migration > (first step for live migration) [1].

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

t have there > at all. Right. OK, thanks. I will add the patch below to my osstest queue. Ian. >From 5330ff9222e4e611505149945eef7dc074b4f9b5 Mon Sep 17 00:00:00 2001 In-Reply-To: <20161006104255.GP16414@wheatley> References: <20161006104255.GP16414@wheatley> From: Ian Jackson

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

Julien Grall writes ("Re: [OSSTEST PATCH 1/2] libvirt: Check migration capabilities using proper XML parser"): > On 04/10/2016 10:05, Ian Jackson wrote: > > Missing _. I didn't test this again before sending it. I'd still > > like a review from libvirt (and Xen/ARM)

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

Martin Kletzander writes ("Re: [OSSTEST PATCH 2/2] libvirt: Do not attempt save/restore when migration not advertised"): > Since offline migration (as in migrating a domain between hosts without > being running) is not that used in the code and talked about, I'm > guessing offline means save

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 pat

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

). Signed-off-by: Ian Jackson <ian.jack...@eu.citrix.com> CC: Julien Grall <julien.gr...@arm.com> CC: Jim Fehlig <jfeh...@suse.com> --- Osstest/Toolstack/libvirt.pm | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstac

[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

th libvirt output as it currently appears to be on real hosts). Signed-off-by: Ian Jackson <ian.jack...@eu.citrix.com> CC: Julien Grall <julien.gr...@arm.com> CC: Jim Fehlig <jfeh...@suse.com> --- Osstest/Toolstack/libvirt.pm | 17 ++--- 1 file changed, 14 insertions(+)

Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

Jan Beulich writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"): > On 27.06.16 at 18:54, wrote: > > OK. Thanks for the feedback. I'll go ahead with my plan with the > > git commit ids named in my earlier

Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

Jim Fehlig writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"): > On 06/27/2016 10:12 AM, Ian Jackson wrote: > > Does libvirt have stable release branches ? One approach would be to > > have osstest track

Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

Daniel P. Berrange writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"): > On Mon, Jun 27, 2016 at 04:54:35PM +0100, Ian Jackson wrote: > > Created the following branch refs on xenbits in the toplevel > > libvi

Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

(Adding Jan Beulich) Ian Jackson writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"): > It seems that the libvirt LIBXL_API_VERSION is now rather higher, at > 0x040400, since libvirt#fccf27253ced > lib

Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

Jim Fehlig writes ("Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"): > I think that is a good idea too. I've sent a patch setting > LIBXL_API_VERSION to 0x040200 > > https://www.redhat.com/archives/libvir-list/2016-April/msg00771.html It

Re: [libvirt] gnulib and 32-bit libvirt build, rpl_canonicalize_file_name

Ján Tomko writes ("Re: [libvirt] gnulib and 32-bit libvirt build, rpl_canonicalize_file_name"): > This has been fixed in gnulib already: > http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=246b3b2 > commit 246b3b28808ee5f4664be674dce573af9497fc7a > Author: Eric Blake

[libvirt] gnulib and 32-bit libvirt build, rpl_canonicalize_file_name

The Xen Project's automated test (CI) system has reported a build failure in libvirt; libvirt uses gnulib. osstest has bisected it to a specific gnulib commit. (Email from osstest is quoted below.) The error message is: ../gnulib/lib/.libs/libgnu.a(canonicalize-lgpl.o): In function

Re: [libvirt] [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

Dario Faggioli writes ("Re: [Xen-devel] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?"): > And, in those cases, usage should be gated by the appropriate > LIBXL_HAVE_FOOBAR symbol, which I see in the sources (e.g., > for LIBXL_HAVE_NO_SUSPEND_RESUME or 

Re: [libvirt] [PATCH] libxl: libxl_domain_create_restore has an extra argument

Wei Liu writes ("Re: [PATCH] libxl: libxl_domain_create_restore has an extra argument"): > CC Jim as well > > On Tue, Apr 05, 2016 at 03:20:12PM +0100, Wei Liu wrote: > > In the latest libxenlight code, libxl_domain_create_restore accepts a > > new argument. Update libvirt's libxl driver for

Re: [libvirt] [PATCH RFC] libxl: use libxl_event_wait to process libxl events

wait() is used to collect events. This allows processing > libxl events asynchronously in libvirt, avoiding the deadlock. The reasoning is sound and the remedy is IMO correct. (However, you mean "this allows processing libxl events _synchronously_", since what you are doing is serialising t

Re: [libvirt] [Xen-devel] [vbox-dev] Assert with libvirt + xen hvm

Cole Robinson writes ("Re: [Xen-devel] [libvirt] [vbox-dev] Assert with libvirt + xen hvm"): > I took a cursory look at libxl's sigchld handling... it's intense to say the > least, but there's some driver options that tweak the handling. Maybe there's > a simple fix. Sadly the way that there's a

Re: [libvirt] [PATCH 0/2] Re: libvirtd live-locking on CTX_LOCK when doing 'virsh domid save /tmp/blah' with guest corrupting memory (on purpose).

Jim Fehlig writes (Re: [PATCH 0/2] Re: libvirtd live-locking on CTX_LOCK when doing 'virsh domid save /tmp/blah' with guest corrupting memory (on purpose).): On 04/14/2015 11:31 AM, Ian Jackson wrote: I have produced what I think are two patches that will fix this. I have compiled them

[libvirt] [PATCH 0/2] Re: libvirtd live-locking on CTX_LOCK when doing 'virsh domid save /tmp/blah' with guest corrupting memory (on purpose).

Konrad Rzeszutek Wilk writes (libvirtd live-locking on CTX_LOCK when doing 'virsh domid save /tmp/blah' with guest corrupting memory (on purpose).): It looks like thread #10 is blocking in libxl_read_exactly waiting for 'libxl-save-helper'. Said application (see below) has dispatched an

Re: [libvirt] [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup.

Anthony PERARD writes (Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup.): On Tue, Dec 16, 2014 at 09:30:28AM +, Ian Campbell wrote: Unless by not running you meant bottlenecked or not keeping up perhaps. Well, I did meant no xenconsoled process. But after, I

Re: [libvirt] [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup.

Ian Jackson writes (Re: [Xen-devel] [PATCH V2] libxl: Set path to console on domain startup.): I mention all of these for completeness, and for future reference for anyone reading the archives later. In libxl you want option I. I mean `in xl you want option I'. In libvirt you probably want

Re: [libvirt] [Xen-devel] [PATCH 00/12] libxl: fork: SIGCHLD flexibility

Jim Fehlig writes (Re: [Xen-devel] [PATCH 00/12] libxl: fork: SIGCHLD flexibility): Looking at the libvirt code again, it seems a single thread services the event loop. See virNetServerRun() in src/util/virnetserver.c. Indeed, I see the same thread ID in all the timer and fd callbacks. One of

Re: [libvirt] [Xen-devel] [PATCH 00/12] libxl: fork: SIGCHLD flexibility

Jim Fehlig writes (Re: [Xen-devel] [PATCH 00/12] libxl: fork: SIGCHLD flexibility): Ok, thanks. I'm currently testing on your git branch referenced earlier in this thread git://xenbits.xen.org/people/iwj/xen.git#wip.enumerate-pids-v2.1 Great. That's the one. My current version is pretty

Re: [libvirt] Segfault in libxl_osevent_occurred_timeout [Was: Re: [libvirt-users] About debugging of libvirt.]

Dario Faggioli writes (Segfault in libxl_osevent_occurred_timeout [Was: Re: [libvirt-users] About debugging of libvirt.]): [Moving this to libvir, libvir-users in Bcc. Also, added xen-devel] 4.2.1 is lacking libxl: fix stale timeout event callback race libxl: fix stale fd event callback

Re: [libvirt] libxl: cannot connect to PV console

Jim Fehlig writes (Re: libxl: cannot connect to PV console): Dario Faggioli wrote: Hey Jim, I'm on libvirt.git's trunk and I see the following: [xen@ghoul3 libvirt.git]$ sudo ./tools/virsh list IdName State

[libvirt] [Xen-devel] Re: [PATCH V2] Add libxenlight driver

Paolo Bonzini writes ([Xen-devel] Re: [PATCH V2] Add libxenlight driver): On 02/23/2011 03:56 AM, Jim Fehlig wrote: Add a new xen driver based on libxenlight [1], which is the primary toolstack starting with Xen 4.1.0. The driver is stateful, runs privileged only, and is accessed with

Re: [libvirt] [Xen-devel] Re: [RFC] libxenlight driver

Jim Fehlig writes (Re: [Xen-devel] Re: [libvirt] [RFC] libxenlight driver): Ian Campbell wrote: The xapi toolstack which implements XenAPI is now open source as well and is used in XCP (as well as XenServer). But there is no intent on putting this toolstack in the traditional Xen releases