Re: [libvirt] Questions about virtlogd

[Wei Liu <wei.liu2@citrix.com>]

On Wed, Jun 08, 2016 at 07:53:53AM -0400, Doug Goldstein wrote:
> On 6/8/16 6:57 AM, George Dunlap wrote:
> > On 08/06/16 11:07, Daniel P. Berrange wrote:
> >> On Wed, Jun 08, 2016 at 10:50:24AM +0100, George Dunlap wrote:
> >>> On 07/06/16 16:57, Wei Liu wrote:
> >>>>> 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.
> >>>
> >>> Just to be clear -- internally we're investigating options for dealing
> >>> with the "qemu logging" problem* for XenProject for people not running
> >>> libvirt -- people who use the xl toolstack, or people who build their
> >>> own toolstack on top of libxl.
> >>>
> >>> (We *also* need to figure out how to deal with  the libxl+libvirt
> >>> 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.
> > 
> > [Removing libvirt-list]
> > 
> > Well we definitely want to make it possible for people to use xl while
> > still avoiding DoSes.  But at the simplest level this could be done by
> > having qemu's stderr/stdout piped to /dev/null by default, and allowing
> > an option for the admin to enable piping it to a file on a per-guest
> > basis when necessary.
> > 
> > This would effectively be declaring a "proper solution" out-of-scope,
> > while not opening up our users to security issues.
> > 
> >  -George
> > 
> 
> I'm in favor of an approach like this that declares it out of scope. In
> a world of finite resources Xen has to focus on what its strengths are
> in the virtualization space and being the best possible solution for the
> use cases where its strengths can shine. This requires some tough
> choices and acknowledging that being the complete vertical stack and
> legitimately competing against a number of other pieces that build the
> stack for other hypervisor solutions is just not a situation that will
> allow Xen to shine.
> 

I'm more than happy to make this someone else's problem. :-)

> You mentioned it earlier in the thread and we've talked about this
> before but libxl should be enhanced to allow everything it needs to be
> passed in as an fd and let the actual toolstack (be it xl or libvirt or
> something else) do the actual open() and supply the fd.
> 

Yeah, I do want to have something like this -- that is regardless of
whatever we end up with the conclusion of the internal machinery for
QEMU logging (declare it out of scope, use virtlogd, use xenconsoled etc
etc). But I haven't had a clear idea how the interface should look like.

My original plan is that if someone provides an fd via the new
interface, libxl would use that; if not, libxl would use whatever thing
we have for logging.  This way is a bit nicer for setup that doesn't use
the new API -- the output will still be available somewhere.

But since there are many different opinions on this matter, while I
don't really care which one ends up "winning", I will just implement the
new API, redirect logging to /dev/null by default, and let other people
worry about the rest.

Wei.

> -- 
> Doug Goldstein
> 




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