* Re: [libvirt] Questions about virtlogd [not found] <20160607121153.GL25922@citrix.com> @ 2016-06-07 13:21 ` Daniel P. Berrange 2016-06-07 15:57 ` Wei Liu 0 siblings, 1 reply; 12+ messages in thread From: Daniel P. Berrange @ 2016-06-07 13:21 UTC (permalink / raw) To: Wei Liu Cc: libvir-list, George Dunlap, Ian Jackson, Doug Goldstein, Xen-devel On Tue, Jun 07, 2016 at 01:11:53PM +0100, Wei Liu wrote: > Hello libvirt maintainers, > > Libvirt implements virtlogd in version 1.3 which now handles logging > for QEMU process. I am wondering if it is possible to make it a > separate package and maintain stable interfaces for external users? Ok, so you're essentially asking for us to create a libvirt-logd.so library for talking to virtlogd, which would basically contain the code currently in src/logging/log_manager.c That's certainly possible from a technical POV, but the real question is whether we want to do that from a policy POV, given the greater support implications that has. > This is related to XSA-180 / CVE-2014-3672 (unrestricted QEMU > logging). We are evaluating using virtlogd vs writing our own > solution. I believe there are still some open questions on how exactly > the integration could be done but let's worry about that later. 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 ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libvirt] Questions about virtlogd 2016-06-07 13:21 ` [libvirt] Questions about virtlogd Daniel P. Berrange @ 2016-06-07 15:57 ` Wei Liu 2016-06-08 9:50 ` George Dunlap [not found] ` <5757EA60.4030004@citrix.com> 0 siblings, 2 replies; 12+ messages in thread From: Wei Liu @ 2016-06-07 15:57 UTC (permalink / raw) To: Daniel P. Berrange Cc: Wei Liu, libvir-list, Doug Goldstein, Ian Jackson, George Dunlap, Xen-devel On Tue, Jun 07, 2016 at 02:21:17PM +0100, Daniel P. Berrange wrote: > On Tue, Jun 07, 2016 at 01:11:53PM +0100, Wei Liu wrote: > > Hello libvirt maintainers, > > > > Libvirt implements virtlogd in version 1.3 which now handles logging > > for QEMU process. I am wondering if it is possible to make it a > > separate package and maintain stable interfaces for external users? > > Ok, so you're essentially asking for us to create a libvirt-logd.so > library for talking to virtlogd, which would basically contain the > code currently in src/logging/log_manager.c > Originally I was thinking about have virtlogd - the daemon itself - to be a separate package. That basically means libvirt is not absolutely required for using virtlogd. But from a policy point of view that might not be feasible. > That's certainly possible from a technical POV, but the real question > is whether we want to do that from a policy POV, given the greater > support implications that has. > There will be support commitment. The interfaces (RPC or library APIs) need to be stable. I understand if this request doesn't align with the support policy. Just knowing the maintainers' opinion on this matter is a good enough starting point for me, which help me evaluate the situation better. > > This is related to XSA-180 / CVE-2014-3672 (unrestricted QEMU > > logging). We are evaluating using virtlogd vs writing our own > > solution. I believe there are still some open questions on how exactly > > the integration could be done but let's worry about that later. > > 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. Thanks for your reply. It is very helpful. Wei. > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libvirt] Questions about virtlogd 2016-06-07 15:57 ` Wei Liu @ 2016-06-08 9:50 ` George Dunlap [not found] ` <5757EA60.4030004@citrix.com> 1 sibling, 0 replies; 12+ messages in thread From: George Dunlap @ 2016-06-08 9:50 UTC (permalink / raw) To: Wei Liu, Daniel P. Berrange Cc: libvir-list, George Dunlap, Ian Jackson, Doug Goldstein, Xen-devel 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@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <5757EA60.4030004@citrix.com>]
* Re: [libvirt] Questions about virtlogd [not found] ` <5757EA60.4030004@citrix.com> @ 2016-06-08 10:07 ` Daniel P. Berrange [not found] ` <20160608100716.GD7760@redhat.com> 1 sibling, 0 replies; 12+ messages in thread From: Daniel P. Berrange @ 2016-06-08 10:07 UTC (permalink / raw) To: George Dunlap Cc: Wei Liu, libvir-list, Doug Goldstein, Ian Jackson, George Dunlap, Xen-devel 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. > 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. > 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. FWIW, for #3 you would have to take a large portion of src/util and src/rpc and src/logging from the libvirt tree, which is quite a considerable amount of code, so also not great. > * 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. NB, it is both messages from QEMU's stdout/stderr, and usage of character devices (ie seriall ports) with the 'file' backend which lets QEMU write guest serial output straight to a file. Fixing the former is possible with any QEM, while the latter requires QEMU >= 2.6 Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <20160608100716.GD7760@redhat.com>]
* Re: [libvirt] Questions about virtlogd [not found] ` <20160608100716.GD7760@redhat.com> @ 2016-06-08 10:57 ` George Dunlap 2016-06-08 11:53 ` Doug Goldstein 2016-06-08 12:11 ` Daniel P. Berrange 2016-06-08 12:25 ` Wei Liu 1 sibling, 2 replies; 12+ messages in thread From: George Dunlap @ 2016-06-08 10:57 UTC (permalink / raw) To: Daniel P. Berrange Cc: George Dunlap, Ian Jackson, Wei Liu, Doug Goldstein, Xen-devel 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@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libvirt] Questions about virtlogd 2016-06-08 10:57 ` George Dunlap @ 2016-06-08 11:53 ` Doug Goldstein 2016-06-08 12:46 ` Wei Liu 2016-06-08 12:11 ` Daniel P. Berrange 1 sibling, 1 reply; 12+ messages in thread From: Doug Goldstein @ 2016-06-08 11:53 UTC (permalink / raw) To: George Dunlap, Daniel P. Berrange Cc: George Dunlap, Ian Jackson, Wei Liu, Xen-devel [-- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libvirt] Questions about virtlogd 2016-06-08 11:53 ` Doug Goldstein @ 2016-06-08 12:46 ` Wei Liu 2016-06-08 13:05 ` George Dunlap 0 siblings, 1 reply; 12+ messages in thread From: Wei Liu @ 2016-06-08 12:46 UTC (permalink / raw) To: Doug Goldstein Cc: Wei Liu, George Dunlap, Ian Jackson, George Dunlap, Xen-devel, Daniel P. Berrange 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. Wei. > -- > Doug Goldstein > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libvirt] Questions about virtlogd 2016-06-08 12:46 ` Wei Liu @ 2016-06-08 13:05 ` George Dunlap 2016-06-08 13:09 ` Wei Liu 0 siblings, 1 reply; 12+ messages in thread From: George Dunlap @ 2016-06-08 13:05 UTC (permalink / raw) To: Wei Liu, Doug Goldstein Cc: George Dunlap, Ian Jackson, Daniel P. Berrange, Xen-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libvirt] Questions about virtlogd 2016-06-08 13:05 ` George Dunlap @ 2016-06-08 13:09 ` Wei Liu 0 siblings, 0 replies; 12+ messages in thread From: Wei Liu @ 2016-06-08 13:09 UTC (permalink / raw) To: George Dunlap Cc: Wei Liu, George Dunlap, Ian Jackson, Doug Goldstein, Xen-devel, Daniel P. Berrange On Wed, Jun 08, 2016 at 02:05:10PM +0100, George Dunlap wrote: > 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? > Not sure I follow. But I would say I have no intention to make xl more complex than it currently is. Wei. > -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libvirt] Questions about virtlogd 2016-06-08 10:57 ` George Dunlap 2016-06-08 11:53 ` Doug Goldstein @ 2016-06-08 12:11 ` Daniel P. Berrange 2016-06-08 12:57 ` George Dunlap 1 sibling, 1 reply; 12+ messages in thread From: Daniel P. Berrange @ 2016-06-08 12:11 UTC (permalink / raw) To: George Dunlap Cc: George Dunlap, Ian Jackson, Wei Liu, Doug Goldstein, Xen-devel On Wed, Jun 08, 2016 at 11:57:45AM +0100, George Dunlap wrote: > > 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. I hadn't thought of /dev/null as an option, that's a nice idea. BTW, I want to raise another item as more general food for thought which is somewhat related to this topic, albeit not useful as an solution to use today. If you consider the risk to be a compromised QEMU inflicting DoS on the host filesystem, then the stderr/out logging and serial port file writing is not the only attack vector. If you give QEMU any kind of file based disk, then (unless you have quotas in place) it can expand those disk files to arbitrary size - this is by design of course, since QEMU needs to save snapshots inside qcow2, and has the ability to resize virtual disks, etc. At the same time, it would be nice to be able to have a possibility too have a locked down solution. Conceptually it would be nice to be able to place size limits on individual files that were open. It turns out Linux introduced just such a facility under the concept "file sealing" The motivation for this was kDBus which wanted a way to share tmpfs backed file handles between processes with certain policy rules. This concept was implemented using a new fcntl() call F_ADD_SEAL which allows a number of flags to be set against a file descriptor: - SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced in size. This affects ftruncate() and open(O_TRUNC). - GROW: If SEAL_GROW is set, the file in question cannot be increased in size. This affects ftruncate(), fallocate() and write(). - WRITE: If SEAL_WRITE is set, no write operations (besides resizing) are possible. This affects fallocate(PUNCH_HOLE), mmap() and write(). - SEAL: If SEAL_SEAL is set, no further seals can be added to a file. This basically prevents the F_ADD_SEAL operation on a file and can be set to prevent others from adding further seals that you don't want. The SEAL_GROW flag seems like exactly the kind of thing QEMU could make use of. First of all we would have to assume that the QEMU disk image is fully pre-allocated, ie a non-sparse raw file, or a qcow2 file which has had its extents fully allocated. This is not unreasonable for many usage scenarios. I could imagine -drive gaining a new parameter 'growable=yes|no'. eg $QEMU -drive file=/some/image/vm.qcow2,growable=no would cause QEMU to set SEAL_GROW when it open the disk image. After that point it is not possible for a compromised QEMU to cause further disk allocation on the /some/image filesystem. This of course relies on SELinux/AppArmour/other-MAC to prevent QEMU opening/creating other arbitrary files. Hotplug is not so simple though. At the time we hotplug the disk we have to assume QEMU is already hostile, so we can't really rely on QEMU to honour the request to set SEAL_GROW. To deal with this we would have to deny QEMU any "open" permission using MAC. Instead libvirt (or equiv) would have to be responsible for opening disk images, setting SEAL_GROW and passing the file descriptor onto the running QEMU to use. This all feels remarkably simple and useful, with one huge glaring issue.... ....the kernel only implemented support for F_ADD_SEAL on the tmpfs filesystem, since that's all kDBus needs it for :-) To be useful for QEMU/libxl/libvirt/etc we'd at least need it supported on ext4 and xfs, and preferrably NFS too. I've no clue how hard this would be since I'm not at all familiar with the kernel code. So clearly this isn't something we can use at time in the forseeable future, but if people are interested in attacking the more general problem, it might be an approach worth investigating to see if it really is viable for the future. How it would relate to the bug we're talking about here, is that I could imagine pre-allocating the logfile at say 128 KB in size, opening it, setting the SEAL_GROW flag and then attaching it to QEMU stdout/err. This would let QEMU write straight to the file as normal, but not let it exceed 128 KB. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libvirt] Questions about virtlogd 2016-06-08 12:11 ` Daniel P. Berrange @ 2016-06-08 12:57 ` George Dunlap 0 siblings, 0 replies; 12+ messages in thread From: George Dunlap @ 2016-06-08 12:57 UTC (permalink / raw) To: Daniel P. Berrange Cc: George Dunlap, Ian Jackson, Wei Liu, Doug Goldstein, Xen-devel On 08/06/16 13:11, Daniel P. Berrange wrote: > On Wed, Jun 08, 2016 at 11:57:45AM +0100, George Dunlap wrote: >> >> 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. > > I hadn't thought of /dev/null as an option, that's a nice idea. > > > BTW, I want to raise another item as more general food for thought > which is somewhat related to this topic, albeit not useful as an > solution to use today. > > If you consider the risk to be a compromised QEMU inflicting DoS > on the host filesystem, then the stderr/out logging and serial > port file writing is not the only attack vector. If you give QEMU > any kind of file based disk, then (unless you have quotas in place) > it can expand those disk files to arbitrary size - this is by design > of course, since QEMU needs to save snapshots inside qcow2, and has > the ability to resize virtual disks, etc. > > At the same time, it would be nice to be able to have a possibility > too have a locked down solution. Conceptually it would be nice to be > able to place size limits on individual files that were open. It turns > out Linux introduced just such a facility under the concept "file sealing" > > The motivation for this was kDBus which wanted a way to share tmpfs backed > file handles between processes with certain policy rules. This concept was > implemented using a new fcntl() call F_ADD_SEAL which allows a number of > flags to be set against a file descriptor: > > - SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced > in size. This affects ftruncate() and open(O_TRUNC). > - GROW: If SEAL_GROW is set, the file in question cannot be increased > in size. This affects ftruncate(), fallocate() and write(). > - WRITE: If SEAL_WRITE is set, no write operations (besides resizing) > are possible. This affects fallocate(PUNCH_HOLE), mmap() and > write(). > - SEAL: If SEAL_SEAL is set, no further seals can be added to a file. > This basically prevents the F_ADD_SEAL operation on a file and > can be set to prevent others from adding further seals that you > don't want. > > The SEAL_GROW flag seems like exactly the kind of thing QEMU could make > use of. First of all we would have to assume that the QEMU disk image > is fully pre-allocated, ie a non-sparse raw file, or a qcow2 file which > has had its extents fully allocated. This is not unreasonable for many > usage scenarios. I could imagine -drive gaining a new parameter > 'growable=yes|no'. eg > > $QEMU -drive file=/some/image/vm.qcow2,growable=no > > would cause QEMU to set SEAL_GROW when it open the disk image. After > that point it is not possible for a compromised QEMU to cause further > disk allocation on the /some/image filesystem. This of course relies > on SELinux/AppArmour/other-MAC to prevent QEMU opening/creating other > arbitrary files. > > Hotplug is not so simple though. At the time we hotplug the disk we > have to assume QEMU is already hostile, so we can't really rely on > QEMU to honour the request to set SEAL_GROW. To deal with this we > would have to deny QEMU any "open" permission using MAC. Instead > libvirt (or equiv) would have to be responsible for opening disk > images, setting SEAL_GROW and passing the file descriptor onto the > running QEMU to use. > > This all feels remarkably simple and useful, with one huge glaring > issue.... > > ....the kernel only implemented support for F_ADD_SEAL on the tmpfs > filesystem, since that's all kDBus needs it for :-) To be useful for > QEMU/libxl/libvirt/etc we'd at least need it supported on ext4 and xfs, > and preferrably NFS too. I've no clue how hard this would be since I'm > not at all familiar with the kernel code. > > So clearly this isn't something we can use at time in the forseeable > future, but if people are interested in attacking the more general > problem, it might be an approach worth investigating to see if it > really is viable for the future. > > How it would relate to the bug we're talking about here, is that I > could imagine pre-allocating the logfile at say 128 KB in size, opening > it, setting the SEAL_GROW flag and then attaching it to QEMU stdout/err. > This would let QEMU write straight to the file as normal, but not let > it exceed 128 KB. Interesting -- I had actually been thinking that if there were something along these lines it would be quite useful. :-) I was actually pondering whether in the qemu case it would be possible to add this kind of limit to logging / serial output files, but having the kernel do it is as you say a lot more secure. From a Xen perspective: At the moment qemu running in dom0 cannot be properly isolated from the rest of the system anyway; if you manage to break into qemu in dom0 on a default system, you can map any guest's ram you wish (including dom0's), which (we assume) allows you to get control of the entire system. The only way at the moment to be secure against this is to run qemu in a separate domain (stubdoms). (XenServer has had deprivileged qemu running in dom0 for years, but their solution isn't directly upstreamable, since it relies on the Xen / Linux / qemu interface version being tightly linked. There is an effort being made to do this in an upstreamable manner, but it's not there yet.) All that to say: At the moment restricting qemu running in a Xen dom0 with the kernel is sort of pointless, but hopefully in the not-too-distant future it will actually become useful again. :-) -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [libvirt] Questions about virtlogd [not found] ` <20160608100716.GD7760@redhat.com> 2016-06-08 10:57 ` George Dunlap @ 2016-06-08 12:25 ` Wei Liu 1 sibling, 0 replies; 12+ messages in thread From: Wei Liu @ 2016-06-08 12:25 UTC (permalink / raw) To: Daniel P. Berrange Cc: Wei Liu, libvir-list, Doug Goldstein, Ian Jackson, George Dunlap, George Dunlap, Xen-devel 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-06-08 13:09 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20160607121153.GL25922@citrix.com> 2016-06-07 13:21 ` [libvirt] Questions about virtlogd Daniel P. Berrange 2016-06-07 15:57 ` Wei Liu 2016-06-08 9:50 ` George Dunlap [not found] ` <5757EA60.4030004@citrix.com> 2016-06-08 10:07 ` Daniel P. Berrange [not found] ` <20160608100716.GD7760@redhat.com> 2016-06-08 10:57 ` George Dunlap 2016-06-08 11:53 ` Doug Goldstein 2016-06-08 12:46 ` Wei Liu 2016-06-08 13:05 ` George Dunlap 2016-06-08 13:09 ` Wei Liu 2016-06-08 12:11 ` Daniel P. Berrange 2016-06-08 12:57 ` George Dunlap 2016-06-08 12:25 ` Wei Liu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).