Re: [libvirt] Questions about virtlogd

[Doug Goldstein <cardoe@cardoe.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 3910 bytes --]

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.

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.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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