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
>
Stefano Stabellini writes ("Re: [Xen-devel] Re: [libvirt] [RFC] libxenlight
driver"):
> I should also mention that one of the design goals of libxenlight is
> that no libxenlight users (toolstacks like libvirt) should need to use
> anything else but libxenlight to perform Xen operations. So you
>
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 w
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
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 seriali
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 that
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 LIBXL_HAVE_DOM
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 fai
unctional change (with
libvirt output as it currently appears to be on real hosts).
Signed-off-by: Ian Jackson
CC: Julien Grall
CC: Jim Fehlig
---
Osstest/Toolstack/libvirt.pm | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/Osstest/Toolstack/libvirt.pm
after all).
Signed-off-by: Ian Jackson
CC: Julien Grall
CC: Jim Fehlig
---
Osstest/Toolstack/libvirt.pm | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index b7db7af..250fe47 100644
--- a/Osstest/Toolstack/libvir
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 XPAT
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 resto
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
won'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:
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].
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
`rpl_can
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
> CommitDat
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 s
(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
>
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
> >
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 t
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 email.
>
> The only (hopeful
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 a
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 opti
Konrad Rzeszutek Wilk writes ("libvirtd live-locking on CTX_LOCK when doing
'virsh 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 message
Jim Fehlig writes ("Re: [PATCH 0/2] Re: libvirtd live-locking on CTX_LOCK when
doing 'virsh 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 th
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
> > -
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 r
Daniel P. Berrange writes ("Re: [libvirt] [Xen-devel] [PATCH 00/12] libxl:
fork: SIGCHLD flexibility"):
> Yes, you are correct. The threading model for libvirtd is that the
> process thread leader executes the event loop, dealing with timer
> and file descriptor I/O callbacks. There are also 'n' w
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
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 pr
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:
http://logs.test-lab.xenproject.org/osstest/logs/123046/build-i386-libvirt/6.ts-libvirt-b
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
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
n,
then 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
+
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
autom
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. Sou
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
>
38 matches
Mail list logo
