Open Stack

On Feb 2, 2016 7:41 AM, "Preston L. Bannister" <preston at bannister.us> wrote:
>
> Oh, for the other folk reading, in QEMU you want to look at:
>
> http://wiki.qemu.org/Features/IncrementalBackup
>
> The above page looks to be current. The QEMU wiki seems to have a number
of stale pages that describe proposed function that was abandoned / never
implemented. Originally, I ended up reading the QEMU mailing list and
source code to figure out which bits were real. :)

Unfortunately the link you provided is old as well. Source code is the only
way to go at this point for valid information. But I have a working
structure for a backup using QMP directly if not manually at this point.

>
>
>
>
>
> On Tue, Feb 2, 2016 at 4:04 AM, Preston L. Bannister <preston at bannister.us>
wrote:
>>
>> To be clear, I work for EMC, and we are building a backup product for
OpenStack (which at this point is very far along). The primary lack is a
good means to efficiently extract changed-block information from OpenStack.
About a year ago I worked through the entire Nova/Cinder/libvirt/QEMU
stack, to see what was possible. The changes to QEMU (which have been
in-flight since 2011) looked most promising, but when they would land was
unclear. They are starting to land. This is big news. :)
>>
>> That is not the end of the problem. Unless the QEMU folk are perfect,
there are likely bugs to be found when the code is put into production.
(With more exercise, the sooner any problems can be identified and
addressed.) OpenStack uses libvirt to talk to QEMU, and libvirt is a fairly
thick abstraction. Likely there will want to be adjustments to libvirt.
Bypassing Nova and chatting with libvirt directly is a bit suspect (but may
be needed). There might be adjustments needed in Nova.
>>
>> To offer suggestions...
>>
>> Ekko is an opinionated approach to backup. This is not the only way to
solve the problem. I happen very much like the approach, but as a specific
approach, it probably does not belong in Cinder or Nova. (I believe it was
Jay who offered a similar argument about backup more generally.)
>>
>> (Keep in mind QEMU is not the only hypervisor supported by Nova, if the
majority of use. Would you want to attempt a design that works for all
hypervisors? I would not!  ...at least at this point. Also, last I checked
the Cinder folk were a bit hung up on replication, as finding common
abstractions across storage was not easy. This problem looks similar.)

Actually, now that you mention it, the approach Ekko takes _does_ work
against all hypervisors that support changed-block-tracking. At this point
that includes QEMU, VMWare, and HyperV (no Xen).
>>
>> While wary of bypassing Nova/Cinder, my suggestion would to be rude in
the beginning, with every intent of becoming civil in the end.
>>
>> Start by talking to libvirt directly. (The was a bypass mechanism in
libvirt that looked like it might be sufficient.) Break QEMU early, and get
it fixed. :)
>>
>> When QEMU usage is working, talk to the libvirt folk about proven needs,
and what is needed to become civil.
>>
>> When libvirt is updated (or not), talk to Nova folk about proven needs,
and what is needed to become civil. (Perhaps simply awareness, or a small
set of primitives.)

It's like you are a mind reader! This is my exact thoughts on the approach
as well.
>>
>> It might take quite a while for the latest QEMU and libvirt to ripple
through into OpenStack distributions. Getting any fixes into QEMU early (or
addressing discovered gaps in needed function) seems like a good thing.
>>
>> All the above is a sufficiently ambitious project, just by itself. To my
mind, that justifies Ekko as a unique, focused project.
>>
Thank you for you input. This is the case in my mind as well, but if this
goal can be achieved _better_ with Freezer we absolutely should meld with
Freezer. That's the question we are trying to figure out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160202/014baf12/attachment.html>