qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "Julien Grall (Intern)" <julien.grall@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Julian Pidancet <julian.pidancet@citrix.com>
Subject: Re: [Qemu-devel] Qemu disaggregation in Xen environment
Date: Mon, 05 Mar 2012 19:45:33 -0600	[thread overview]
Message-ID: <4F556C3D.3060008@codemonkey.ws> (raw)
In-Reply-To: <alpine.DEB.2.00.1203052246160.923@kaball-desktop>

On 03/05/2012 04:53 PM, Stefano Stabellini wrote:
> On Mon, 5 Mar 2012, Anthony Liguori wrote:
>> On 02/28/2012 05:46 AM, Julien Grall wrote:
>>> Hello,
>>>
>>> In the current model, only one instance of qemu is running for each running HVM
>>> domain.
>>>
>>> We are looking at disaggregating qemu to have, for example, an instance to
>>> emulate only
>>> network controllers, another to emulate block devices, etc...
>>
>> Why would you want to do this?
>
> We are trying to disaggregate QEMU, the same way we do with Linux.
>
> On Xen we can run a Linux guest to drive the network card, another Linux
> guest to drive the SATA controller, another one for the management
> stack, etc. This helps both with scalability and isolation.
>
> In this scenario is only natural that we run a QEMU that only emulates
> a SATA controller in the storage domain, a QEMU that only emulates the
> network card in the network domain and everything else in a stubdom.
>
> What's better than using QEMU as emulator? Using three QEMUs per guest
> as emulators! :-)

My concern is that this moves the Xen use case pretty far from what the typical 
QEMU use case would be (running one emulator per guest).

If it was done in a non-invasive way, maybe it would be acceptable but at a high 
level, I don't see how that's possible.

I almost think you would be better off working to build a second front end 
(reusing the device model, and nothing else) specifically for Xen.

Almost like qemu-io but instead of using the block layer, use the device model.

Regards,

Anthony Liguori

>

  reply	other threads:[~2012-03-06  1:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-28 11:46 [Qemu-devel] Qemu disaggregation in Xen environment Julien Grall
2012-03-05 22:06 ` [Qemu-devel] [Xen-devel] " Ian Campbell
2012-03-12 13:42   ` Julien Grall
2012-03-05 22:20 ` [Qemu-devel] " Anthony Liguori
2012-03-05 22:53   ` Stefano Stabellini
2012-03-06  1:45     ` Anthony Liguori [this message]
2012-03-06  8:22       ` Markus Armbruster
2012-03-06 15:11         ` Anthony Liguori
2012-03-12 13:17       ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F556C3D.3060008@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=julian.pidancet@citrix.com \
    --cc=julien.grall@citrix.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).