[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