[libvirt] Questions about virtlogd

[Wei Liu]

On Wed, Jun 08, 2016 at 11:07:16AM +0100, Daniel P. Berrange wrote:
[...]
> > 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.
> 
> > 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 you say there's not really any pre-existing tools that can easily
> fit with the requirements, which is why we ended up creating virtlogd
> ourselves - it was either that or OpenStack was going to invent their
> own daemon which does what virtlogd does to solve it at the even higher
> layer (though they could only fix serial port file based output, not
> stderr outout)
> 
> So, we wanted a standard solution that libvirt and all apps using
> libvirt could rely up unconditionally. From our existing libvirtd,
> and codebase in general, we have alot of infrastructure pieces that
> made creating virtlogd a pretty easy task. In particular our formal
> RPC protocol and handling code for libvirtd and virtlockd, was
> able to serve as the basis for virtlogd with little need for extra
> code.
> 
> This in turn means that having virtlogd as a separate project would
> be a major undertaking - it relies on so much libvirt infrastructure
> code that to make it into a separate project, we'd have to pull out
> a huge pile of libvirt internal code and turn it into a more formal
> library that could be shared between an external virtlogd and libvirt.
> We've never considered any of this code to be API/ABI stable, so don't
> really want to go down that route.  This would also make your option #3
> a surprisingly large effort - there's a load of libvirt code you would
> have to pull into Xen, or alternatively re-write in a Xen friendly
> manner.
> 
> Less problematic, though still relevant, is that virtlogd is intended
> to align with libvirtd/virtlockd designs, to give a consistent model.
> By this I mean the config files are in common locations, the way we
> auto-spawn the daemons works the same way - eg we have one libvirtd
> running privileged, and one per-user account, and auto-spawn a
> corresponding virtlogd for each.

FWIW I came to the same conclusion in my own research. So I'm not really
keen on #3 and #4.

> 
> > As Wei said, we're still exploring options; even a negative response
> > narrows down the search space. :-)
> > 
> > Let us know what you think.
> 
> I don't have a great answer for you I'm afraid, but I don't think
> that #4 is really practical from the libvirt POV, due to the issue
> with the all the libvirt internal code virtlogd relies upon that
> we don't wish to turn into a stable API/ABI.
> 

Understood.

Wei.