This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] PATCH: 0/10: Merge xenfb & xenconsoled into qemu-dm

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Subject: Re: [Xen-devel] PATCH: 0/10: Merge xenfb & xenconsoled into qemu-dm
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Thu, 16 Aug 2007 17:04:22 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 16 Aug 2007 09:05:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070816153415.GH16779@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfgHxvlWpsv5kwSEdymygAX8io7RQ==
Thread-topic: [Xen-devel] PATCH: 0/10: Merge xenfb & xenconsoled into qemu-dm
User-agent: Microsoft-Entourage/
On 16/8/07 16:34, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote:

>> My own feeling is that the xenfb merge is very sensible, but I don't see
>> much of a win from merging xenconsoled, and the downside is that you then
>> need a qemu-dm instance for every PV guest. I think that requiring qemu-dm
>> for more 'featureful' PV guests -- framebuffer, USB, etc -- is well and
>> good, but someone who is running more minimal domU configurations --
>> console, net, block -- isn't going to want or welcome the rather unnecessary
>> per-domU overhead of qemu-dm.
> Yep, I can see that would be useful for some folks working in constrained
> environments. Of course they probably don't want the XenD overhead either,
> but that's a can of worms I won't get into right now ;-)

At least the xend overhead is largely one-off rather than per-domain.

> Thinking about this, I think I can easily re-work the last two patches so
> that xenconsoled will continue to process the guest consoles, if-and-only-if
> the guest doesn't have a QEMU instance already doing it. That would give us
> choice between both deployment scenarios per-guest.

That seems fair. The guest-console-over-vnc scenario is a compelling
argument for supporting console-in-qemu as an option.

 -- Keir

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>