All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Benoît Canet" <benoit.canet@irqsave.net>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: "Benoît Canet" <benoit.canet@irqsave.net>,
	kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com,
	pbonzini@redhat.com, agrover@redhat.com
Subject: Re: [Qemu-devel] tcmu-runner and QEMU
Date: Sat, 30 Aug 2014 18:51:34 +0200	[thread overview]
Message-ID: <20140830165133.GB2212@irqsave.net> (raw)
In-Reply-To: <20140830160212.GH1302@redhat.com>

The Saturday 30 Aug 2014 à 17:02:12 (+0100), Richard W.M. Jones wrote :
> On Sat, Aug 30, 2014 at 05:53:43PM +0200, Benoît Canet wrote:
> > The Saturday 30 Aug 2014 à 15:46:41 (+0100), Richard W.M. Jones wrote :
> > > For the benefit of those who have absolutely no idea what you're
> > > talking about, could you write a simpler summary of what you're trying
> > > to do?
> > > 
> > > Rich.
> > 
> > Hello,
> > 
> > Most cloud providers sell virtualized instances either using Xen or KVM.
> >
> > However another trend is to provide bare metal instances for people
> > who want the highest CPU and network performance possible.(typicaly
> > people doing computation with MPI)
> >
> > So a cloud end user would need to be able to instanciate a virtual
> > machine use it for a while then stop the virtual machine, change the
> > hardware type to bare metal and restart the instance while keeping
> > using the same boot volume.
> >
> > QEMU will keep a virtual machine data stored in one of it's numerous
> > storage backend format like QCOW2 or QED.
> >
> > If the cloud provider want to be able to boot QCOW2 or QED images on
> > bare metal machines he will need to export QCOW2 or QED images on
> > the network.
> >
> > So far only qemu-nbd allows to do this and it is neither well
> > performing nor really convenient to boot on a bare metal machine.
> 
> So I think what you want is a `qemu-iscsi'?  ie. the same as qemu-nbd,
> but with an iSCSI frontend (to replace the NBD server).
> 
> I think this is an excellent idea, although AIUI iSCSI is a pretty
> complex protocol.  (I wrote an NBD server, and the protocol is almost
> trivial, albeit as you say, performing badly).
> 
> > So summarize I am looking for a way to export QCOW2 or QED image as
> > an ISCSI or FCOE targets while keeping all the goodies these format
> > provides (taking snapshots for backup, streaming, mirroring).
> >
> > Reusing LIO code would help tremendously to simplify this task.
> 
> I guess so.  Are you planning to integrate bits of LIO into qemu, or
> bits of qemu into LIO?
> 
> The latter has been tried various times, without much success.  See
> the many examples of people trying to make the qemu block driver code
> into a separate library, and failing.

Paolo pointed me to Andy's current work so I started this discution:
http://thread.gmane.org/gmane.linux.kernel/1771465.

I know well enough the QEMU block layer to be aware that it's riddled
with static variables so I think bits of Andy's current work on top of
a qemu-lio command would be the way.

>> Writing an iSCSI front end to qemu would be good, but qemu has some
> very particular policies about what code can be introduced, so that
> could be tricky too ...

Where can I read these policies ?

Best regards

Benoît

> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> libguestfs lets you edit virtual machines.  Supports shell scripting,
> bindings from many languages.  http://libguestfs.org

  parent reply	other threads:[~2014-08-30 16:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29 17:22 [Qemu-devel] tcmu-runner and QEMU Benoît Canet
2014-08-29 18:38 ` Andy Grover
2014-08-29 18:51   ` Benoît Canet
2014-08-29 22:36     ` Andy Grover
2014-08-29 22:46       ` Benoît Canet
2014-08-30 14:46 ` Richard W.M. Jones
2014-08-30 15:53   ` Benoît Canet
2014-08-30 16:02     ` Richard W.M. Jones
2014-08-30 16:04       ` Richard W.M. Jones
2014-08-30 17:22         ` Benoît Canet
2014-08-30 21:50           ` Benoît Canet
2014-08-30 16:51       ` Benoît Canet [this message]
2014-08-31 20:03       ` Andy Grover
2014-08-31 20:38         ` Benoît Canet
2014-09-01  8:32           ` Paolo Bonzini
2014-09-01  8:08         ` Paolo Bonzini
2014-09-02  9:25 ` Stefan Hajnoczi
2014-09-03  0:20   ` Andy Grover
2014-09-03  7:34     ` Paolo Bonzini
2014-09-03 13:11     ` Stefan Hajnoczi
2014-09-04 13:24       ` Benoît Canet
2014-09-04 15:15         ` Andy Grover
2014-09-04 15:59           ` Benoît Canet
2014-09-04 20:16           ` Stefan Hajnoczi

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=20140830165133.GB2212@irqsave.net \
    --to=benoit.canet@irqsave.net \
    --cc=agrover@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    --cc=stefanha@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.