Re: [libvirt] Questions about virtlogd

[George Dunlap <george.dunlap@citrix.com>]

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?

 -George

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