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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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


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