qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] tcmu-runner and QEMU


From: Benoît Canet
Subject: Re: [Qemu-devel] tcmu-runner and QEMU
Date: Sat, 30 Aug 2014 18:51:34 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]