<p dir="ltr"><br>
On Feb 2, 2016 7:41 AM, "Preston L. Bannister" <<a href="mailto:preston@bannister.us">preston@bannister.us</a>> wrote:<br>
><br>
> Oh, for the other folk reading, in QEMU you want to look at:<br>
><br>
> <a href="http://wiki.qemu.org/Features/IncrementalBackup">http://wiki.qemu.org/Features/IncrementalBackup</a><br>
><br>
> 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. :)</p>
<p dir="ltr">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.</p>
<p dir="ltr">><br>
><br>
><br>
><br>
><br>
> On Tue, Feb 2, 2016 at 4:04 AM, Preston L. Bannister <<a href="mailto:preston@bannister.us">preston@bannister.us</a>> wrote:<br>
>><br>
>> 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. :)<br>
>><br>
>> 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.<br>
>><br>
>> To offer suggestions...<br>
>><br>
>> 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.)<br>
>><br>
>> (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.)</p>
<p dir="ltr">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).<br>
>><br>
>> While wary of bypassing Nova/Cinder, my suggestion would to be rude in the beginning, with every intent of becoming civil in the end.<br>
>><br>
>> 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. :)<br>
>><br>
>> When QEMU usage is working, talk to the libvirt folk about proven needs, and what is needed to become civil.<br>
>><br>
>> 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.)</p>
<p dir="ltr">It's like you are a mind reader! This is my exact thoughts on the approach as well.<br>
>><br>
>> 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.<br>
>><br>
>> All the above is a sufficiently ambitious project, just by itself. To my mind, that justifies Ekko as a unique, focused project.<br>
>><br>
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.</p>