[PATCH] ch: set shared drivers

[Wei Liu]

We want to use those shared drivers provided by libvirt to avoid
implementing our own.

Signed-off-by: Wei Liu 
---
 src/ch/ch_driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ch/ch_driver.c b/src/ch/ch_driver.c
index 7d1e97098aef..f1f88ad30cf5 100644
--- a/src/ch/ch_driver.c
+++ b/src/ch/ch_driver.c
@@ -922,7 +922,7 @@ static virStateDriver chStateDriver = {
 
 int chRegister(void)
 {
-if (virRegisterConnectDriver(, false) < 0)
+if (virRegisterConnectDriver(, true) < 0)
 return -1;
 if (virRegisterStateDriver() < 0)
 return -1;
-- 
2.30.2

Re: [libvirt] Libvirt config converter can't handle file not ending with new line

[Wei Liu]

On Mon, Nov 06, 2017 at 09:41:01PM -0700, Jim Fehlig wrote:
> On 10/30/2017 06:17 AM, Wei Liu wrote:
> > Hi Jim
> > 
> > I discover a problem when using xen_xl converter. When the file in
> > question doesn't end with a new line, I get the following error:
> > 
> >error: configuration file syntax error: memory conf:53: expecting a value
> 
> I'm not able to reproduce this issue. The libvirt.git tree I tried was a bit
> dated, but even after updating to latest master I can't reproduce.
> 
> > After digging a bit (but haven't read libvirt code), it appears that the
> > file didn't end with a new line.
> 
> I tried several files without ending new lines, going both directions
> (domxml-to-native and domxml-from-native), but didn't see the mentioned
> error. Perhaps your config is revealing another bug which is being
> improperly reported. Can you provide an example of the problematic config?
> 

I tried to get the exact file that caused the problem but it is already
destroyed by osstest.

A similar file:

http://logs.test-lab.xenproject.org/osstest/logs/115436/test-amd64-amd64-libvirt-pair/debian.guest.osstest.cfg

If you hexdump -C it, you can see the last character is 0a. Remove it and
feed the file into the converter.

Wei.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Libvirt config converter can't handle file not ending with new line

[Wei Liu]

Hi Jim

I discover a problem when using xen_xl converter. When the file in
question doesn't end with a new line, I get the following error:

  error: configuration file syntax error: memory conf:53: expecting a value


After digging a bit (but haven't read libvirt code), it appears that the
file didn't end with a new line.

I have worked around this, but I think this is an issue that should be
fixed.

Thanks,
Wei.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Libvirt xl to xml converter only picks up first occurrence of an option

[Wei Liu]

On Wed, Oct 25, 2017 at 02:53:01PM -0600, Jim Fehlig wrote:
> On 10/20/2017 08:46 AM, Wei Liu wrote:
> > Hi Jim
> 
> Hi Wei,
> 
> Sorry for the delay. Catching up on mail after some days off...
> 
> > I discovered that libvirt's native config file to xml converter for
> > libxl only pick up the first occurrence of an option.
> > 
> > For example in a xl cfg file:
> > 
> > extra = "abc"
> > ...
> > extra = "def"
> > 
> > xl will pick up "def" because that shows up later and takes precedence,
> > while the converter picks up "abc".
> > 
> > I think this is a bug in the converter and should be fixed.
> 
> Thanks for the report. I took a quick peek at libvirt's generic config
> parser and afaict it only searches for the first occurrence of a setting.
> The parser does support flags though, so we could add something like
> VIR_CONF_FLAG_{FIRST,LAST}_DUPLICATE. (Better name suggestions welcomed.)
> 

I'm normally very bad at naming things so I will refrain from making
suggestions.

> I've opened a bug report against openSUSE Factory to track this
> 
> https://bugzilla.opensuse.org/show_bug.cgi?id=1065118
> 

Thanks!

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Libvirt xl to xml converter only picks up first occurrence of an option

[Wei Liu]

Hi Jim

I discovered that libvirt's native config file to xml converter for
libxl only pick up the first occurrence of an option.

For example in a xl cfg file:

extra = "abc"
...
extra = "def"

xl will pick up "def" because that shows up later and takes precedence,
while the converter picks up "abc".

I think this is a bug in the converter and should be fixed.

Thanks
Wei.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH] libxl: fix dom0 autoballooning with Xen 4.8

[Wei Liu]

I saw this mail but didn't realise it required my input, sorry.

On Wed, Feb 01, 2017 at 04:00:54PM -0700, Jim Fehlig wrote:
> Jim Fehlig wrote:
> > xen.git commit 57f8b13c changed several of the libxl memory
> > get/set functions to take 64 bit parameters. The libvirt
> > libxl driver still uses uint32_t variables for these various
> > parameters, which is particularly problematic for the
> > libxl_set_memory_target() function.
> > 
> > When dom0 autoballooning is enabled, libvirt (like xl) determines
> > the memory needed to start a domain and the memory available. If
> > memory available is less than memory needed, dom0 is ballooned
> > down by passing a negative value to libxl_set_memory_target()
> > 'target_memkb' parameter. Prior to xen.git commit 57f8b13c,
> > 'target_memkb' was an int32_t. Subtracting a larger uint32 from
> > a smaller uint32 and assigning it to int32 resulted in a negative
> > number. After commit 57f8b13c, the same subtraction is widened
> > to a int64, resulting in a large positive number. The simple
> > fix taken by this patch is to assign the difference of the
> > uint32 values to a temporary int32 variable, which is then
> > passed to 'target_memkb' parameter of libxl_set_memory_target().
> > 
> > Note that it is undesirable to change libvirt to use 64 bit
> > variables since it requires setting LIBXL_API_VERSION to 0x040800.
> > Currently libvirt supports LIBXL_API_VERSION >= 0x040400,
> > essentially Xen >= 4.4.
> 
> Any comments on this patch? xen-devel is already in cc, but I'll add Wei (one 
> of
> the Xen tools maintainers) and Juergen (author of commit 57f8b13c) for some
> additional exposure :-).
> 
> Currently, "out-of-the-box" Xen >= 4.8 + libvirt setup (dom0 autoballooning
> enabled) is broken without this fix.
> 
> Regards,
> Jim
> 
> > 
> > Signed-off-by: Jim Fehlig 
> > ---
> >  src/libxl/libxl_domain.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > index a5314b0..ed73cd2 100644
> > --- a/src/libxl/libxl_domain.c
> > +++ b/src/libxl/libxl_domain.c
> > @@ -909,6 +909,7 @@ libxlDomainFreeMem(libxl_ctx *ctx, libxl_domain_config 
> > *d_config)
> >  {
> >  uint32_t needed_mem;
> >  uint32_t free_mem;
> > +int32_t target_mem;
> >  int tries = 3;
> >  int wait_secs = 10;
> >  
> > @@ -922,7 +923,8 @@ libxlDomainFreeMem(libxl_ctx *ctx, libxl_domain_config 
> > *d_config)
> >  if (free_mem >= needed_mem)
> >  return 0;
> >  
> > -if (libxl_set_memory_target(ctx, 0, free_mem - needed_mem,
> > +target_mem = free_mem - needed_mem;
> > +if (libxl_set_memory_target(ctx, 0, target_mem,

This should do the trick.

Wei.

> >  /* relative */ 1, 0) < 0)
> >  goto error;
> >  
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] Opinions on removing the old, legacy libvirt Xen driver

[Wei Liu]

On Fri, Nov 18, 2016 at 02:25:18PM -0700, Jim Fehlig wrote:
> Hi All,
> 
> I briefly mentioned this at an evening event during the KVM Forum / Xen Dev
> Summit, but the list is certainly a better place to discuss such a topic.
> What do folks think about finally removing the old, legacy, xend-based
> driver from the libvirt sources?
> 
> The Xen community made xl/libxl the primary toolstack in Xen 4.1. In Xen
> 4.2, it was made the default toolstack. In Xen 4.5, xm/xend was completely
> removed from the Xen source tree. According to the Xen release support
> matrix [0], upstream maintenance of Xen 4.1-4.3 has been dropped for some
> time, including "long term" security support. Xen 4.4-4.5 no longer receive
> regular maintenance support, with security support ending in March for 4.4
> and January 2018 for 4.5. In short, the fully maintained upstream Xen
> releases don't even contain xm/xend :-).
> 
> As for downstreams, I doubt anyone is interested in running the last several
> libvirt releases on an old Xen installition with xm/xend, let alone
> libvirt.git master. SUSE, which still supports Xen, has no interest in using
> a new libvirt on older (but still supported) SLES that uses the xm/xend
> toolstack. I struggle to find a good reason to keep any of the old cruft
> under src/xen/. I do think we should keep the xm/sexpr config
> parsing/formatting code src/xenconfig/ since it is useful for converting old
> xm and sexpr config to libvirt domXML.
> 
> Thanks for opinions and comments!

FWIW I agree with your analysis.

Wei.

> 
> Regards,
> Jim
> 
> [0] https://wiki.xenproject.org/wiki/Xen_Project_Release_Features
> 
> ___
> Xen-devel mailing list
> xen-de...@lists.xen.org
> https://lists.xen.org/xen-devel

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Libvirt build broken

[Wei Liu]

On Thu, Nov 03, 2016 at 03:58:04PM +0100, Pavel Hrdina wrote:
> On Thu, Nov 03, 2016 at 01:50:17PM +0000, Wei Liu wrote:
> > Hi
> > 
> > Xen Project's CI system found a build failure between libvirt changes
> > 06a7b1ff..478ddedc.  I don't think this is Xen specific FWIW.
> > 
> > The build log can be found at:
> > 
> > http://logs.test-lab.xenproject.org/osstest/logs/101868/build-amd64-libvirt/5.ts-libvirt-build.log
> > 
> > The first error:
> > 
> >   CC   libvirt_driver_la-libvirt-host.lo
> > libvirt.c:320:15: error: variable 'virTLSThreadImpl' has initializer but 
> > incomplete type
> >  static struct gcry_thread_cbs virTLSThreadImpl = {
> >^
> > Earlier in configure:
> > 
> >   configure: gnutls: no 
> 
> Hi
> 
> I've just pushed a patch that fixes this build issue:
> 
> <https://www.redhat.com/archives/libvir-list/2016-November/msg00206.html>
> 

Thanks!

Wei.

> Pavel


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Libvirt build broken

[Wei Liu]

Hi

Xen Project's CI system found a build failure between libvirt changes
06a7b1ff..478ddedc.  I don't think this is Xen specific FWIW.

The build log can be found at:

http://logs.test-lab.xenproject.org/osstest/logs/101868/build-amd64-libvirt/5.ts-libvirt-build.log

The first error:

  CC   libvirt_driver_la-libvirt-host.lo
libvirt.c:320:15: error: variable 'virTLSThreadImpl' has initializer but 
incomplete type
 static struct gcry_thread_cbs virTLSThreadImpl = {
   ^
Earlier in configure:

  configure: gnutls: no 

>From the look of it configure doesn't work properly anymore.


Wei.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] tests: fix CPUID detection tests compilation failure

[Wei Liu]

In 3704b9003 ("tests: Add CPU detection tests"), a macro called
DO_TEST_CPUID_JSON is added. But it took only two arguments when QEMU
or YAJL is not set.

Fix it by adding a third argument. Shouldn't have any effect because
that macro compiles to nothing.

Signed-off-by: Wei Liu <wei.l...@citrix.com>
---
Cc: Jiri Denemark <jdene...@redhat.com>

For error: see
http://logs.test-lab.xenproject.org/osstest/logs/95577/build-amd64-libvirt/5.ts-libvirt-build.log
---
 tests/cputest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/cputest.c b/tests/cputest.c
index f68a3ec..c374ddf 100644
--- a/tests/cputest.c
+++ b/tests/cputest.c
@@ -700,7 +700,7 @@ mymain(void)
 }   \
 } while (0)
 #else
-# define DO_TEST_CPUID_JSON(arch, host)
+# define DO_TEST_CPUID_JSON(arch, host, json)
 #endif
 
 #define DO_TEST_CPUID(arch, host, json) \
-- 
2.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Questions about virtlogd

[Wei Liu]

On Wed, Jun 08, 2016 at 11:07:16AM +0100, Daniel P. Berrange wrote:
[...]
> > situation, but that's just a matter of plumbing I think.)
> > 
> > The options we've come up with, broadly, are as follows:
> > 
> > 1. Try to use the existing syslog facilities
> > 
> > 2. Re-purpose one of our existing daemons to perform a role similar to
> > virtlogd
> > 
> > 3. "Steal" virtlogd and import it into our tree (yay GPL!)
> > 
> > 4. Work with the libvirt community to make virtlogd an independent
> > project which can be used by both libvirt and libxl directly
> 
> For completeness I'd also suggest
> 
> 5. Declare it out of scope for xl toolstack to solve the whole
>problem. Merely provide the minimal hooks to enable the layer
>above libxl to solve it. This is effectively QEMU's approach.
> 
> Of course, this would mean that any non-libvirt layer using libxl
> stil faces the same problem you're facing, so I understand if thats
> not desirable from your POV.
> 
> > None of the options are really that great.  I'm sure you guys explored
> > #1 yourselves before deciding to write your own tools, so I won't cover
> > its deficiencies.  #2 and #3 both involve a lot of duplicate effort and
> > duplicate code.
> > 
> > From a global perspective, #4 would seem to make sense, since it allows
> > the virtlogd functionality to be more generally used (and potentially
> > may be useful in non-virtualization scenarios as well). But it also has
> > the cost of working cross-community, maintaining a clean separate
> > codebase,And we realize for the libvirt project it's extra work
> > for no obvious immediate benefit.
> 
> As you say there's not really any pre-existing tools that can easily
> fit with the requirements, which is why we ended up creating virtlogd
> ourselves - it was either that or OpenStack was going to invent their
> own daemon which does what virtlogd does to solve it at the even higher
> layer (though they could only fix serial port file based output, not
> stderr outout)
> 
> So, we wanted a standard solution that libvirt and all apps using
> libvirt could rely up unconditionally. From our existing libvirtd,
> and codebase in general, we have alot of infrastructure pieces that
> made creating virtlogd a pretty easy task. In particular our formal
> RPC protocol and handling code for libvirtd and virtlockd, was
> able to serve as the basis for virtlogd with little need for extra
> code.
> 
> This in turn means that having virtlogd as a separate project would
> be a major undertaking - it relies on so much libvirt infrastructure
> code that to make it into a separate project, we'd have to pull out
> a huge pile of libvirt internal code and turn it into a more formal
> library that could be shared between an external virtlogd and libvirt.
> We've never considered any of this code to be API/ABI stable, so don't
> really want to go down that route.  This would also make your option #3
> a surprisingly large effort - there's a load of libvirt code you would
> have to pull into Xen, or alternatively re-write in a Xen friendly
> manner.
> 
> Less problematic, though still relevant, is that virtlogd is intended
> to align with libvirtd/virtlockd designs, to give a consistent model.
> By this I mean the config files are in common locations, the way we
> auto-spawn the daemons works the same way - eg we have one libvirtd
> running privileged, and one per-user account, and auto-spawn a
> corresponding virtlogd for each.

FWIW I came to the same conclusion in my own research. So I'm not really
keen on #3 and #4.

> 
> > As Wei said, we're still exploring options; even a negative response
> > narrows down the search space. :-)
> > 
> > Let us know what you think.
> 
> I don't have a great answer for you I'm afraid, but I don't think
> that #4 is really practical from the libvirt POV, due to the issue
> with the all the libvirt internal code virtlogd relies upon that
> we don't wish to turn into a stable API/ABI.
> 

Understood.

Wei.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Questions about virtlogd

[Wei Liu]

On Tue, Jun 07, 2016 at 02:21:17PM +0100, Daniel P. Berrange wrote:
> On Tue, Jun 07, 2016 at 01:11:53PM +0100, Wei Liu wrote:
> > Hello libvirt maintainers,
> > 
> > Libvirt implements virtlogd in version 1.3 which now handles logging
> > for QEMU process. I am wondering if it is possible to make it a
> > separate package and maintain stable interfaces for external users?
> 
> Ok, so you're essentially asking for us to create a libvirt-logd.so
> library for talking to virtlogd, which would basically contain the
> code currently in src/logging/log_manager.c
> 

Originally I was thinking about have virtlogd - the daemon itself - to
be a separate package. That basically means libvirt is not absolutely
required for using virtlogd. But from a policy point of view that might
not be feasible.

> That's certainly possible from a technical POV, but the real question
> is whether we want to do that from a policy POV, given the greater
> support implications that has.
> 

There will be support commitment. The interfaces (RPC or library APIs)
need to be stable.

I understand if this request doesn't align with the support policy. Just
knowing the maintainers' opinion on this matter is a good enough
starting point for me, which help me evaluate the situation better.

> > This is related to XSA-180 / CVE-2014-3672 (unrestricted QEMU
> > logging). We are evaluating using virtlogd vs writing our own
> > solution. I believe there are still some open questions on how exactly
> > the integration could be done but let's worry about that later.
> 
> I must admit I'm not familiar with the division of responsibility
> for managing QEMU between the Xen provided libxl library(s) and
> the libvirt libxl driver code. Naively I would expect the libvirt
> libxl driver code to deal with virtlogd and then configure the
> Xen libxl library / QEMU accordingly. Your request seems to imply
> that you will need the Xen libxl library to directly talk to
> virtlogd instead.
> 
> Is there any way in which it would be practical for the libvirt
> libxl driver to talk to virtlogd to acquire the file descriptors
> to use and pass those file descriptors down to the libxl library ?
> 

There are two classes of configurations.

For libvirt + libxl, There is currently no API for passing in a fd to be
used as QEMU logging fd. But I'm thinking about having one. It wouldn't
be too hard.

The other class is  configurations that don't have libvirt. We need some
sort of mechanism to handle QEMU logs. My intent of this email is mainly
for this class of configurations.

Thanks for your reply. It is very helpful.

Wei.

> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Questions about virtlogd

[Wei Liu]

Hello libvirt maintainers,

Libvirt implements virtlogd in version 1.3 which now handles logging
for QEMU process. I am wondering if it is possible to make it a
separate package and maintain stable interfaces for external users?

This is related to XSA-180 / CVE-2014-3672 (unrestricted QEMU
logging). We are evaluating using virtlogd vs writing our own
solution. I believe there are still some open questions on how exactly
the integration could be done but let's worry about that later.

Thanks
Wei.

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3672
[1] http://xenbits.xen.org/xsa/advisory-180.html

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 0/3] libxl: support Xen migration stream V2

[Wei Liu]

On Mon, May 02, 2016 at 07:01:16PM -0600, Jim Fehlig wrote:
> Hi all,
> 
> This patch adds support for Xen migration stream V2 to the libvirt
> libxl driver. In the process it fixes save/restore and migration
> tests in OSSTest, which have been failing since libvirt commit
> e7440656.
> 
> Patch1 changes the libxl API requirement from version 4.2 to 4.4,
> enabling use of an extended libxl_domain_create_restore() function
> that allows passing restore parameters such as stream version.
> 
> Patch2 adds support for migration stream V2 in the basic save/restore
> logic, taking advantage of a save image header that includes a version
> field. The version is set to '2' if the host produces a V2 migration
> stream. This patch fixes the failing save/restore tests in OSSTest.
> 
> Patch3 adds support for migration stream V2 in the migration logic.
> The migration code does not use the save image header and instead
> uses libvirt's migration protocol to transfer domain configuration
> and other such goodies from source to destination. The patch
> enables sending version information in the Begin and Prepare
> migration phases so the correct stream version information can be
> passed to libxl_domain_create_restore(). An upshot of this approach
> is safely detecting and aborting a migration from a V2 host to a
> V1-only host. This patch fixes the failing migration tests in
> OSSTest.
> 

The general approach looks good to me.

Wei.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1/3] libxl: switch to using libxl_domain_create_restore from v4.4 API

[Wei Liu]

On Mon, May 02, 2016 at 07:01:17PM -0600, Jim Fehlig wrote:
> In LIBXL_API_VERSION 0x040400, the libxl_domain_create_restore API
> gained a parameter for specifying restore parameters. Switch to
> using version 0x040400, which will be useful in a subsequent commit
> to specify the Xen migration stream version when restoring.
> 
> Signed-off-by: Jim Fehlig <jfeh...@suse.com>

Reviewed-by: Wei Liu <wei.l...@citrix.com>

> ---
>  configure.ac | 9 +
>  src/libxl/libxl_domain.c | 6 +-
>  2 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 88e2e20..0da0f75 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -875,10 +875,11 @@ if test "$with_libxl" != "no" ; then
>  fi
>  fi
>  
> -# Until there is a need to use enhancements of libxl APIs such as
> -# libxl_domain_create_restore and libxl_set_vcpuaffinity, stick with
> -# the APIs as defined in libxl API version 4.2.0.
> -LIBXL_CFLAGS="$LIBXL_CFLAGS -DLIBXL_API_VERSION=0x040200"
> +# LIBXL_API_VERSION 4.4.0 introduced a new parameter to
> +# libxl_domain_create_restore for specifying restore parameters.
> +# The libxl driver will make use of this new parameter for specifying
> +# the Xen migration stream version.
> +LIBXL_CFLAGS="$LIBXL_CFLAGS -DLIBXL_API_VERSION=0x040400"
>  LIBS="$old_LIBS"
>  CFLAGS="$old_CFLAGS"
>  
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 14a900c..32ad946 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -1028,6 +1028,7 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
> virDomainObjPtr vm,
>  libxlDriverConfigPtr cfg;
>  virHostdevManagerPtr hostdev_mgr = driver->hostdevMgr;
>  libxl_asyncprogress_how aop_console_how;
> +libxl_domain_restore_params params;
>  
>  libxl_domain_config_init(_config);
>  
> @@ -1115,8 +1116,11 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
> virDomainObjPtr vm,
>  ret = libxl_domain_create_new(cfg->ctx, _config,
>, NULL, _console_how);
>  } else {
> +libxl_domain_restore_params_init();
>  ret = libxl_domain_create_restore(cfg->ctx, _config, ,
> -  restore_fd, NULL, 
> _console_how);
> +  restore_fd, , NULL,
> +  _console_how);
> +libxl_domain_restore_params_dispose();
>  }
>  virObjectLock(vm);
>  
> -- 
> 2.1.4
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Wei Liu]

On Wed, Apr 13, 2016 at 10:26:54AM +0100, Daniel P. Berrange wrote:
> On Wed, Apr 13, 2016 at 10:09:16AM +0100, George Dunlap wrote:
> > On Tue, Apr 12, 2016 at 10:31 PM, Jim Fehlig <jfeh...@suse.com> wrote:
> > > Wei Liu wrote:
> > >> Hi libvirt maintainers,
> > >
> > > Sorry for the delay. Slowly catching up on mail after vacation...
> > >
> > >>
> > >> Xen's control library libxenlight (libxl) requires application
> > >> (libvirt in this case) to explictily define LIBXL_API_VERSION.
> > >
> > > Where is this requirement written? :-)
> > >
> > >> This is
> > >> lacking at the moment so libvirt's libxl driver always gets the latest
> > >> APIs.
> > >
> > > IMO, that is what we want for upstream libvirt. Downstreams can choose a
> > > specific version if they want.
> > 
> > I think one of us isn't understanding the situation properly. Is it
> > not the case that currently, all releases of libvirt *will not
> > compile* against Xen 4.7 once it's released?  So people downloading
> > and building libvirt will have to either 1) root around and try to
> > figure out what version of Xen it will build against, 2) manually add
> > in a #define *with the correct API version* to a header somewhere to
> > make it build properly, or 3) update to a version of libvirt that
> > supports the new api (which at the moment hasn't even been released
> > yet)?
> > 
> > All of those options are completely unacceptable.  Older versions of
> > libvirt should Just Work when compiled against newer versions of Xen.
> > 
> > I think it does make sense to have the libvirt development branch not
> > specify an API version; but when it branches for release, it should
> > set LIBXL_API_VERSION to whatever the current version is at the time
> > of the branch.
> 
> FYI, libvirt doesn't do branching for releases - we always just cut the
> release straight from the master branch. We only actually create branches
> on demand, when we find we want to backport fixes to a previous release.
> 
> Does libvirt master really need to always use the latest API version ?
> 

No, it doesn't.

> It feels like libvirt could just set LIBXL_API_VERSION to the lowest
> version it requires in order to get the functionality we know we are
> able to currently build against. IOW, we'd only need to update the
> define for LIBXL_API_VERSION when we merge patches that actually need
> the newer functionality.
> 

That's sensible.

Wei.

> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Wei Liu]

On Tue, Apr 12, 2016 at 03:31:46PM -0600, Jim Fehlig wrote:
> Wei Liu wrote:
> > Hi libvirt maintainers,
> 
> Sorry for the delay. Slowly catching up on mail after vacation...
> 
> > 
> > Xen's control library libxenlight (libxl) requires application
> > (libvirt in this case) to explictily define LIBXL_API_VERSION.
> 
> Where is this requirement written? :-)
> 
> > This is
> > lacking at the moment so libvirt's libxl driver always gets the latest
> > APIs.
> 
> IMO, that is what we want for upstream libvirt. Downstreams can choose a
> specific version if they want.
> 
> > We changed one of the APIs in libxl so libvirt's libxl driver
> > can't build at the moment.
> 
> A quick glance ahead in my libvirt mail tells me you fixed this with the
> preferred LIBXL_HAVE_* pattern.
> 

It's already done that way. :-)

Wei.

> Regards,
> Jim

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Wei Liu]

On Thu, Apr 07, 2016 at 05:35:33PM +0100, Daniel P. Berrange wrote:
> On Wed, Apr 06, 2016 at 04:43:07PM -0500, Doug Goldstein wrote:
> > On 4/5/16 9:20 AM, Wei Liu wrote:
> > > In the latest libxenlight code, libxl_domain_create_restore accepts a
> > > new argument. Update libvirt's libxl driver for that. Use the macro
> > > provided by libxenlight to detect which version should be used.
> > > 
> > > The new parameter (send_back_fd) is set to -1 because libvirt provides
> > > no such fd.
> > > 
> > > Signed-off-by: Wei Liu <wei.l...@citrix.com>
> > > ---
> > > Build test with Xen 4.6.1 (old API) and Xen unstable (new API).
> > > ---
> > >  src/libxl/libxl_domain.c | 7 ++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> > > index 04962a0..aed904b 100644
> > > --- a/src/libxl/libxl_domain.c
> > > +++ b/src/libxl/libxl_domain.c
> > > @@ -1070,7 +1070,12 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
> > > virDomainObjPtr vm,
> > >  ret = libxl_domain_create_new(cfg->ctx, _config,
> > >, NULL, _console_how);
> > >  } else {
> > > -#ifdef LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS
> > > +#if defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_SEND_BACK_FD)
> > > +params.checkpointed_stream = 0;
> > > +ret = libxl_domain_create_restore(cfg->ctx, _config, ,
> > > +  restore_fd, -1, , NULL,
> > > +  _console_how);
> > > +#elif defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS)
> > >  params.checkpointed_stream = 0;
> > >  ret = libxl_domain_create_restore(cfg->ctx, _config, ,
> > >restore_fd, , NULL,
> > > 
> > 
> > ACK
> > 
> > This fixes integration testing that Xen Project does with libvirt and
> > Xen so it would be nice to get in for 1.3.3.
> 
> It missed the boat for 1.3.3, but I've pushed it now
> 

Thank you very much for pushing this!

Wei.

> 
> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Wei Liu]

On Tue, Apr 05, 2016 at 04:12:57PM +0100, Ian Jackson wrote:
> 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. Use the macro
> > > provided by libxenlight to detect which version should be used.
> > > 
> > > The new parameter (send_back_fd) is set to -1 because libvirt provides
> > > no such fd.
> ...
> > > -#ifdef LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS
> > > +#if defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_SEND_BACK_FD)
> > > +params.checkpointed_stream = 0;
> > > +ret = libxl_domain_create_restore(cfg->ctx, _config, ,
> > > +  restore_fd, -1, , NULL,
> > > +  _console_how);
> > > +#elif defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS)
> > >  params.checkpointed_stream = 0;
> > >  ret = libxl_domain_create_restore(cfg->ctx, _config, ,
> > >restore_fd, , NULL,
> 
> Another approach would be 
> 
>  ret = libxl_domain_create_restore(cfg->ctx, _config, ,
>restore_fd,
> #ifdef LIBXL_HAVE_DOMAIN_CREATE_RESTORE_SEND_BACK_FD
>-1,
> #endif
> #ifdef LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS
>,
> #endif
>NULL, _console_how);
> 
> But which to choose is a matter of taste.
> 

I merely followed the existing style. Let's keep it that way for now.

Wei.

> Ian.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Wei Liu]

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. Use the macro
> provided by libxenlight to detect which version should be used.
> 
> The new parameter (send_back_fd) is set to -1 because libvirt provides
> no such fd.
> 
> Signed-off-by: Wei Liu <wei.l...@citrix.com>
> ---
> Build test with Xen 4.6.1 (old API) and Xen unstable (new API).
> ---
>  src/libxl/libxl_domain.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
> index 04962a0..aed904b 100644
> --- a/src/libxl/libxl_domain.c
> +++ b/src/libxl/libxl_domain.c
> @@ -1070,7 +1070,12 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
> virDomainObjPtr vm,
>  ret = libxl_domain_create_new(cfg->ctx, _config,
>, NULL, _console_how);
>  } else {
> -#ifdef LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS
> +#if defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_SEND_BACK_FD)
> +params.checkpointed_stream = 0;
> +ret = libxl_domain_create_restore(cfg->ctx, _config, ,
> +  restore_fd, -1, , NULL,
> +  _console_how);
> +#elif defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS)
>  params.checkpointed_stream = 0;
>  ret = libxl_domain_create_restore(cfg->ctx, _config, ,
>restore_fd, , NULL,
> -- 
> 2.1.4
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

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

[Wei Liu]

In the latest libxenlight code, libxl_domain_create_restore accepts a
new argument. Update libvirt's libxl driver for that. Use the macro
provided by libxenlight to detect which version should be used.

The new parameter (send_back_fd) is set to -1 because libvirt provides
no such fd.

Signed-off-by: Wei Liu <wei.l...@citrix.com>
---
Build test with Xen 4.6.1 (old API) and Xen unstable (new API).
---
 src/libxl/libxl_domain.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 04962a0..aed904b 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1070,7 +1070,12 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
virDomainObjPtr vm,
 ret = libxl_domain_create_new(cfg->ctx, _config,
   , NULL, _console_how);
 } else {
-#ifdef LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS
+#if defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_SEND_BACK_FD)
+params.checkpointed_stream = 0;
+ret = libxl_domain_create_restore(cfg->ctx, _config, ,
+  restore_fd, -1, , NULL,
+  _console_how);
+#elif defined(LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS)
 params.checkpointed_stream = 0;
 ret = libxl_domain_create_restore(cfg->ctx, _config, ,
   restore_fd, , NULL,
-- 
2.1.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Fixing libvirt's libxl driver breakage -- where to define LIBXL_API_VERSION?

[Wei Liu]

Hi libvirt maintainers,

Xen's control library libxenlight (libxl) requires application
(libvirt in this case) to explictily define LIBXL_API_VERSION. This is
lacking at the moment so libvirt's libxl driver always gets the latest
APIs. We changed one of the APIs in libxl so libvirt's libxl driver
can't build at the moment.

I want to submit a patch for libvirt to define LIBXL_API_VERSION, but
I'm not sure where I should add that to. Can you give me some
pointers? Or even better -- a specific file that I should edit?
src/Makefile.am and src/Makfile.in are good candicate to me as far as
I can tell.

Thanks
Wei.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH] libxl: include a XLU_Config in _libxlDriverConfig

[Wei Liu]

On Thu, May 07, 2015 at 10:20:23AM +0200, Olaf Hering wrote:
 On Wed, May 06, Wei Liu wrote:
 
  On Wed, May 06, 2015 at 10:58:11AM +0200, Olaf Hering wrote:
   On Wed, May 06, Olaf Hering wrote:
   
Since libvirtd runs forever there is very little code to undo most
things. But I will see if there is any unload function, did not actively
look for such thing.
   
   Looking through libxlStateDriver it seems that libxl and libxlu remains
   as is. Not sure if thats supposed that way or if perhaps libxl should be
   fully reinitialized during -stateReload, and if logfiles should be
   closed in -stateCleanup.
   
  
  FWIW libxl ctx is destroy in libxlDriverConfigDispose. You can probably
  just call xlu_cfg_destroy there.
 
 In libvirt libxlDriverConfigDispose calls both libxl_ctx_free and
 xtl_logger_destroy. Both functions check if the input is valid, just
 xlu_cfg_destroy dereferences the input unconditionally. Should
 xlu_cfg_destroy be changed to do nothing if it gets passed a NULL
 pointer?
 

That is orthogonal to this patch. I don't particularly care if it's
NULL-tolerant or not. In any case,  You will need to check validity for
older libxl's xlu_cfg_destroy.

Wei.

 Olaf

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH] libxl: include a XLU_Config in _libxlDriverConfig

[Wei Liu]

On Wed, May 06, 2015 at 10:58:11AM +0200, Olaf Hering wrote:
 On Wed, May 06, Olaf Hering wrote:
 
  Since libvirtd runs forever there is very little code to undo most
  things. But I will see if there is any unload function, did not actively
  look for such thing.
 
 Looking through libxlStateDriver it seems that libxl and libxlu remains
 as is. Not sure if thats supposed that way or if perhaps libxl should be
 fully reinitialized during -stateReload, and if logfiles should be
 closed in -stateCleanup.
 

FWIW libxl ctx is destroy in libxlDriverConfigDispose. You can probably
just call xlu_cfg_destroy there.

Anyway, I'm not a libvirt expert. I just don't like leaking memory. :-)

Wei.

 Olaf

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH] libxl: include a XLU_Config in _libxlDriverConfig

[Wei Liu]

On Tue, Apr 28, 2015 at 06:40:05AM +, Olaf Hering wrote:
 Upcoming changes for vscsi will use libxlutil.so to prepare the
 configuration for libxl. The helpers needs a xlu struct for logging.
 Provide one and reuse the existing output as log target.
 

Do you not need to call xlu_cfg_destroy at some point?

Wei.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 8/9] libxl: pass cmdline to HVM guests

[Wei Liu]

On Fri, Mar 20, 2015 at 11:18:36AM -0600, Jim Fehlig wrote:
 Marek Marczykowski-Górecki wrote:
  Signed-off-by: Marek Marczykowski-Górecki marma...@invisiblethingslab.com
  ---
   src/libxl/libxl_conf.c | 8 
   1 file changed, 8 insertions(+)
 
  diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
  index 8ec3c75..d78d2b2 100644
  --- a/src/libxl/libxl_conf.c
  +++ b/src/libxl/libxl_conf.c
  @@ -735,6 +735,14 @@ libxlMakeDomBuildInfo(virDomainDefPtr def,
   libxl_defbool_set(b_info-device_model_stubdomain,
 def-stubdomain == VIR_TRISTATE_BOOL_YES);
   
  +if (def-os.cmdline  def-os.cmdline[0]) {
  +b_info-extra_hvm = virStringSplit(def-os.cmdline,  , 0);

 
 What is the difference between b_info-extra_hvm and b_info-cmdline? 
 How are these two reconciled in libxl?  I.e., what if they contained

In short, I don't think you should use that field at all.

b_info-extra_hvm contains the parameters passed to QEMU specifically
for HVM guest. Those parameters are not meant to be kernel command line.

That field is introduced so that user can append arbitrary parameters to
QEMU. I think it's only a stopgap for things we have not implemented in
libxl or things we don't want to put into libxl. In reality I think it
is rarely used.

 different values?  Chunyan added the latter with xen commit 11dffa235
 when implementing hvm direct kernel boot.  She also submitted a patch
 for libvirt
 
 https://www.redhat.com/archives/libvir-list/2014-September/msg01006.html
 
 I reworked that patch to support the recent breakout of xl and xm config
 in src/xenconfig.  While doing so, I fixed other os related issues and
 posted this series
 
 https://www.redhat.com/archives/libvir-list/2015-March/msg01088.html
 
 Patch 5 in that series supports cmdline for HVM guests, but only if
 LIBXL_HAVE_BUILDINFO_KERNEL is defined (introduced in Xen4.5 IIRC).  Do
 we need to populate both b_info-extra_hvm and b_info-cmdline?
 

No. See above.

Wei.

 Regards,
 Jim

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] libxl: use xenlight pkgconfig file if present

[Wei Liu]

On Wed, Mar 18, 2015 at 04:25:41PM -0600, Jim Fehlig wrote:
 xen.git commit babeca32 added a pkgconfig file for libxenlight,
 allowing libxl apps to determine the location of Xen binaries
 such as firmware blobs, device emulator, etc.
 
 This patch adds support for xenlight.pc in the libxl driver, falling
 back to the previous configure logic if not found.  It introduces
 LIBXL_FIRMWARE_DIR and LIBXL_EXECBIN_DIR to define the firmware and
 libexec_bin locations.  If xenlight.pc does not exist, the defines
 are set to the current hardcoded paths.  The capabilities'
 emulator and loader elements are updated to use the paths.
 
 Signed-off-by: Jim Fehlig jfeh...@suse.com

Reviewed-by: Wei Liu wei.l...@citrix.com

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH RFC] libxl: fix paths in capability string

[Wei Liu]

On Tue, Jan 06, 2015 at 10:28:13AM -0700, Eric Blake wrote:
 On 01/06/2015 09:12 AM, Wei Liu wrote:
  Currently libxl driver hardcodes some paths in its capability string,
  which might not be the correct paths.
  
  This patch introduces --with-libxl-prefix, so that user can specify the
  prefix used to build Xen tools. The default value is /usr/local which is
  the default --prefix for Xen tools.
 
 Why can't you just make '--with-libxl=/path/to/alt' work?  That is,
 --with-libxl=yes uses a default (which matches the prefix where LIBVIRT
 will be installed [1]), --with-libxl=no turns it off, and specifying a
 path says to use that path.  Then you don't need to add a new option.
 

But --with-libxl is used to specify build time path which can be
different from runtime path if I build libvirt against a non-installed
version of xen.

Consider I have a non-installed build of libxl in
/local/scratch/xen.git/dist/install/usr/local but not /usr/local. I
don't want that /local/scratch... end up in capability string.

Wei.

 [1] The assumption generally is that whoever is building libvirt has
 also built libxl to be installed in the same location - which is a nicer
 default than hard-coding a /usr/local default that libxl uses in
 isolation. Of course, libvirt also defaults to /usr/local in isolation,
 so if you don't specify anything at all, then ./configure will see that
 libvirt is going into /usr/local and will therefore default to looking
 for libxl also in /usr/local; but for a distro packager, it is nicer to
 have the mere specification of --prefix switch all other relative
 defaults to play nicely with everything else in the distro.
 
 -- 
 Eric Blake   eblake redhat com+1-919-301-3266
 Libvirt virtualization library http://libvirt.org
 



 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH RFC] libxl: fix paths in capability string

[Wei Liu]

On Tue, Jan 06, 2015 at 05:36:57PM +, Daniel P. Berrange wrote:
 On Tue, Jan 06, 2015 at 10:28:13AM -0700, Eric Blake wrote:
  On 01/06/2015 09:12 AM, Wei Liu wrote:
   Currently libxl driver hardcodes some paths in its capability string,
   which might not be the correct paths.
   
   This patch introduces --with-libxl-prefix, so that user can specify the
   prefix used to build Xen tools. The default value is /usr/local which is
   the default --prefix for Xen tools.
  
  Why can't you just make '--with-libxl=/path/to/alt' work?  That is,
  --with-libxl=yes uses a default (which matches the prefix where LIBVIRT
  will be installed [1]), --with-libxl=no turns it off, and specifying a
  path says to use that path.  Then you don't need to add a new option.
 
 Yep, that would be preferrable.
 
 Alternatively the next best would be for xen to include a pkg-config
 configuration file, with a custom variable that reports the paths
 required
 

This might be a useful thing in its own right. Thanks for the
suggestion.

Wei.

 Regards,
 Daniel
 -- 
 |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
 |: http://libvirt.org  -o- http://virt-manager.org :|
 |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
 |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
 
 ___
 Xen-devel mailing list
 xen-de...@lists.xen.org
 http://lists.xen.org/xen-devel

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH RFC] libxl: fix paths in capability string

[Wei Liu]

Jim, another idea: if those strings are likely to be wrong and in fact
not used, can we just not print them?

Wei.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH RFC] libxl: fix paths in capability string

[Wei Liu]

Currently libxl driver hardcodes some paths in its capability string,
which might not be the correct paths.

This patch introduces --with-libxl-prefix, so that user can specify the
prefix used to build Xen tools. The default value is /usr/local which is
the default --prefix for Xen tools.

Change emualtor from qemu-dm to qemu-system-i386 because libxl (in Xen)
use this as the default emulator.

No need to check hostarch to determine whether to use lib or lib64
anymore because we now always use lib.

Signed-off-by: Wei Liu wei.l...@citrix.com
---
This patch is RFC because I introduce --with-libxl-prefix and I don't know
whether it's acceptable.

Right now libvirt's driver doesn't seem to use these default paths so
everything just works. But it would be nice for libvirt to report the
correct paths instead of hardcoded (and possibly wrong) ones.
---
 configure.ac   |4 
 src/libxl/libxl_conf.c |6 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 167b875..8d10361 100644
--- a/configure.ac
+++ b/configure.ac
@@ -533,6 +533,9 @@ AC_ARG_WITH([libxl],
   [AS_HELP_STRING([--with-libxl],
 [add libxenlight support @:@default=check@:@])])
 m4_divert_text([DEFAULTS], [with_libxl=check])
+AC_ARG_WITH([libxl-prefix], [AS_HELP_STRING([--with-libxl-prefix=path],
+[prefix used to build libxl, default /usr/local])],
+[LIBXL_PREFIX=$withval], [LIBXL_PREFIX=/usr/local])
 AC_ARG_WITH([vbox],
   [AS_HELP_STRING([--with-vbox=@:@PFX@:@],
 [VirtualBox XPCOMC location @:@default=yes@:@])])
@@ -893,6 +896,7 @@ fi
 
 if test $with_libxl = yes; then
 AC_DEFINE_UNQUOTED([WITH_LIBXL], 1, [whether libxenlight driver is 
enabled])
+AC_DEFINE_UNQUOTED([LIBXL_PREFIX], [$LIBXL_PREFIX], [libxl prefix])
 fi
 AM_CONDITIONAL([WITH_LIBXL], [test $with_libxl = yes])
 
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 0555b91..fbb4e29 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -428,11 +428,9 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCapsPtr caps)
 if ((guest = virCapabilitiesAddGuest(caps,
  guest_archs[i].hvm ? hvm : 
xen,
  guest_archs[i].arch,
- ((hostarch == VIR_ARCH_X86_64) ?
-  /usr/lib64/xen/bin/qemu-dm :
-  /usr/lib/xen/bin/qemu-dm),
+ LIBXL_PREFIX 
/lib/xen/bin/qemu-system-i386,
  (guest_archs[i].hvm ?
-  /usr/lib/xen/boot/hvmloader :
+  LIBXL_PREFIX 
/lib/xen/boot/hvmloader :
   NULL),
  1,
  machines)) == NULL) {
-- 
1.7.10.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH RFC] libxl: fix paths in capability string

[Wei Liu]

On Tue, Jan 06, 2015 at 04:50:53PM +, Frediano Ziglio wrote:
 2015-01-06 16:12 GMT+00:00 Wei Liu wei.l...@citrix.com:
  Currently libxl driver hardcodes some paths in its capability string,
  which might not be the correct paths.
 
  This patch introduces --with-libxl-prefix, so that user can specify the
  prefix used to build Xen tools. The default value is /usr/local which is
  the default --prefix for Xen tools.
 
  Change emualtor from qemu-dm to qemu-system-i386 because libxl (in Xen)
  use this as the default emulator.
 
  No need to check hostarch to determine whether to use lib or lib64
  anymore because we now always use lib.
 
 
 Wouldn't then better to separate it in a different patch?
 
 Also this make libvirt not compatible with former Xen versions. Is
 this expected?
 

No. I don't want to break compatibility. However these strings are not
used in libxl driver so there's nothing to break.

I'm not very familiar with libvirt so I could be wrong.  Corrections
welcome. :-/

Wei.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH RFC] libxl: fix paths in capability string

[Wei Liu]

On Tue, Jan 06, 2015 at 05:03:59PM +, Ian Campbell wrote:
 On Tue, 2015-01-06 at 16:12 +, Wei Liu wrote:
  No need to check hostarch to determine whether to use lib or lib64
  anymore because we now always use lib.
 
 What about people who use --libdir=/path/to/lib64, as I believe Red Hat
 derived distros still do, don't they?
 

Good point. I can't say for sure.

If they do so we might need to add more --with-libxl-FOO? Essentially we
need to export all dirs configured for Xen?

Wei.

 Ian.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1/2] xenconfig: set HVM pae/apic/acpi/ default to 1

[Wei Liu]

On Thu, Dec 18, 2014 at 05:14:48PM +0800, Chunyan Liu wrote:
 According to xm.config manual, HVM pae|apic|acpi feature default
 is 1 (enabled). But in conversion from xm config to libvirt xml,
 if xm config doesn't contain pae|apic|acpi, it sets default value
 to 0, this causes some problems in HVM guest.
 
 Update parser codes to set HVM pae|apic|acpi default value to 1
 to match xm config convension.
 
 Signed-off-by: Chunyan Liu cy...@suse.com

Reviewed-by: Wei Liu wei.l...@citrix.com

 ---
  src/xenconfig/xen_common.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
 index 25bdf26..221509a 100644
 --- a/src/xenconfig/xen_common.c
 +++ b/src/xenconfig/xen_common.c
 @@ -512,17 +512,17 @@ xenParseCPUFeatures(virConfPtr conf, virDomainDefPtr 
 def)
  return -1;
  
  if (STREQ(def-os.type, hvm)) {
 -if (xenConfigGetBool(conf, pae, val, 0)  0)
 +if (xenConfigGetBool(conf, pae, val, 1)  0)
  return -1;
  
  else if (val)
  def-features[VIR_DOMAIN_FEATURE_PAE] = VIR_TRISTATE_SWITCH_ON;
 -if (xenConfigGetBool(conf, acpi, val, 0)  0)
 +if (xenConfigGetBool(conf, acpi, val, 1)  0)
  return -1;
  
  else if (val)
  def-features[VIR_DOMAIN_FEATURE_ACPI] = VIR_TRISTATE_SWITCH_ON;
 -if (xenConfigGetBool(conf, apic, val, 0)  0)
 +if (xenConfigGetBool(conf, apic, val, 1)  0)
  return -1;
  
  else if (val)
 -- 
 1.8.4.5

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] xenconfig: fix boot device parsing

[Wei Liu]

The original code always checked *boot which was in effect boot[0]. It
should use boot[i].

Signed-off-by: Wei Liu wei.l...@citrix.com
---
 src/xenconfig/xen_common.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
index 7f4ec89..48431a7 100644
--- a/src/xenconfig/xen_common.c
+++ b/src/xenconfig/xen_common.c
@@ -1071,7 +1071,7 @@ xenParseOS(virConfPtr conf, virDomainDefPtr def)
 return -1;
 
 for (i = 0; i  VIR_DOMAIN_BOOT_LAST  boot[i]; i++) {
-switch (*boot) {
+switch (boot[i]) {
 case 'a':
 def-os.bootDevs[i] = VIR_DOMAIN_BOOT_FLOPPY;
 break;
-- 
1.7.10.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH] libxl: support domainReset

[Wei Liu]

On Tue, Aug 05, 2014 at 04:30:47PM +0100, Ian Campbell wrote:
 On Tue, 2014-08-05 at 09:10 -0600, Jim Fehlig wrote:
  Ian Campbell wrote:
   On Tue, 2014-08-05 at 08:06 -0600, Jim Fehlig wrote:
 
   Ian Campbell wrote:
   
   On Tue, 2014-08-05 at 10:55 +0200, Olaf Hering wrote:
 
 
   The original report was that 'Reset' does not work from GUI, like
   virt-manager or virsh. I think the expected outcome is like pushing the
   reset button on a physical board. Xen doesnt do it that way, no idea
   about others.
   
   
   Sounds like you want libxl_domain_reboot then, perhaps with a fallback
   on ERROR_NOPARAVIRT for an HVM guest to sending a trigger.
 
 
   Hrm, I don't think that's right .  It should be a hard reset
  
   http://libvirt.org/html/libvirt-libvirt.html#virDomainReset
  
   destroy/start seems the correct way to implement this.
   
  
   Yes, given that requirement it is. Sorry for the noise.
  
   Would some sort of hard reset API be useful in libxl?
 
  
  Sure.  I think having an API that emulates a power reset button would be
  a nice addition to libxl's domain operations.  The destroy/start
  approach incurs a small bit of overhead, which would be avoided with
  such an API.  Clients (perhaps incorrectly) implementing their own
  notion of reset  would also be avoided.
 
 I think this ought to become pretty easy once Wei's patches to record
 the guest cfg in libxl are completed. Wei -- what do you think?
 

I don't think this reset API will need to record any state, i.e. this
feature looks unrelated to my work. What do I miss?

Wei.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Xen-devel] [PATCH] libxl: support domainReset

[Wei Liu]

On Tue, Aug 05, 2014 at 07:45:48PM +0100, Ian Campbell wrote:
[...]
Sure.  I think having an API that emulates a power reset button would be
a nice addition to libxl's domain operations.  The destroy/start
approach incurs a small bit of overhead, which would be avoided with
such an API.  Clients (perhaps incorrectly) implementing their own
notion of reset  would also be avoided.
   
   I think this ought to become pretty easy once Wei's patches to record
   the guest cfg in libxl are completed. Wei -- what do you think?
   
  
  I don't think this reset API will need to record any state, i.e. this
  feature looks unrelated to my work. What do I miss?
 
 It's a forced reboot, so the API would need to destroy and then recreate
 the domain. Recreate would need to use the state your patches arrange
 for libxl to store.
 

Oh you were talking about pesisting state across hard reset, that's of
course achievable. I think hard reset is more or less the same as
reboot.

That's still somewhat orthogonal to my work though. Not having the
capability to presist state across in libxl doesn't prevent us from
introducing reset. I think this is the status quo of reboot API,
isn't it?

Wei.


 Ian.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list