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

[Benoît Canet]

The Thursday 04 Sep 2014 à 08:15:39 (-0700), Andy Grover wrote :
> On 09/04/2014 06:24 AM, Benoît Canet wrote:
> >>There are other commands for snapshots and backup which are issued via
> >>QMP.
> >>
> >>It might even make sense to make the tcmu interface available at
> >>run-time in QEMU like the run-time NBD server.  This allows you to get
> >>at read-only point-in-time snapshots while the guest is accessing the
> >>disk.  See the nbd-server-start command in qapi/block.json.
> >>
> >>Stefan
> >
> >Andy: ping
> >
> >I hope we didn't scaried you with our monster block backend and it's
> >associated QMP socket ;)
> 
> Hi Benoît,
> 
> No, I've gone off to work on a initial proof-of-concept implementation of a
> qemu-lio-tcmu.so module, hopefully it'll be ready to look at shortly and
> then we can shoot arrows at it. :)

Great !!

> 
> But in the meantime, do you have a use case or user story for the QMP
> support that might help me understand better how it might all fit together?
> 

Ok,


1) The cloud end user story
---------------------------

My customer has implemented the AWS EC2 API to build his cloud.
Simply said they are an AWS EC2 clone.

The EC2 api provide a way for the end users (customers of my customer) to
take snapshots of their VMs volumes programatically.
Openstack surelly provide this too.

The end users are taking snapshot every days since it's an easy way for
them to have a point in time snapshot of their virtual machine.
They can accumulate over 600 snapshots as the days pass.

So the end users really needs snapshots.

The EC2 compatible cloud only sane way to trigger a snapshotis to use a QMP 
socket.

Right now my customer provide virtualized instances but the new use case is to 
provide
bare metal instances. tcmu could be used for this.

I guess the openstack people will want to do the same at some point.

The point is that the end users would still want to take snapshots of their 
bare metal
instances volumes. Not having this would break the EC2 API and make the 
instances
unusuable.

2) The cloud provider story
---------------------------

End users make snapshot like crazy and eventually the QCOW2 backing chain will
make QEMU open more than FD_MAX files at once. QEMU will crash.

Also the cloud provider has interest to shorten the backing chains
(drop the oldest snapshots) in order to minimize the risk caused by a common
QCOW2 ancestor snapshot corruption.

QEMU allows to do this with streaming. Streaming is triggered with a QMP 
command.

3) The CEPH user story
----------------------

I know Red Hat is big on CEPH so:
CEPH provide it's own kind of snapshotting. QEMU support it via QMP.

4) The any block operation you want to do with QEMU storage story
-----------------------------------------------------------------

simple things such as collecting a block device statistic is also done via QMP.
And so on ...

you can look in qapi/block-core.json to have an idea of QMP usefullness while
working with QEMU block devices.

Best regards

Benoît

> Regards -- Andy
> 
>