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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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

None of the options are really that great.  I'm sure you guys explored
#1 yourselves before deciding to write your own tools, so I won't cover
its deficiencies.  #2 and #3 both involve a lot of duplicate effort and
duplicate code.

From a global perspective, #4 would seem to make sense, since it allows
the virtlogd functionality to be more generally used (and potentially
may be useful in non-virtualization scenarios as well). But it also has
the cost of working cross-community, maintaining a clean separate
codebase, &c &c.  And we realize for the libvirt project it's extra work
for no obvious immediate benefit.

As Wei said, we're still exploring options; even a negative response
narrows down the search space. :-)

Let us know what you think.

 -George

* For those not familiar: The challenge is to log debug messages from
qemu to a file, so that if there are problems it's easier to diagnose;
*without* allowing a rogue guest to fill up your disk by causing qemu to
spew useless messages.

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