Re: [libvirt] Questions about virtlogd

From: Wei Liu <wei.liu2@citrix.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	libvir-list@redhat.com, Doug Goldstein <cardoe@cardoe.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [libvirt] Questions about virtlogd
Date: Tue, 7 Jun 2016 16:57:08 +0100	[thread overview]
Message-ID: <20160607155708.GM25922@citrix.com> (raw)
In-Reply-To: <20160607132116.GD20196@redhat.com>

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 :|

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