Re: [Xen-devel] [libvirt] Questions about virtlogd

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jun 08, 2016 at 02:05:10PM +0100, George Dunlap wrote:
> On 08/06/16 13:46, Wei Liu wrote:
> > 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.
> 
> If the libxl API is thought about carefully enough, then maybe any other
> solutions could just live in xl?
> 

Not sure I follow. But I would say I have no intention to make xl more
complex than it currently is.

Wei.

>  -George

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