On Wed, Feb 8, 2012 at 2:59 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Wed, Feb 8, 2012 at 1:28 PM, Ori Mamluk <omam...@zerto.com> wrote: >> Hi, >> Thanks for all the valuable inputs provided so far, I'll try to suggest a >> design based on them. >> The main inputs were about the use a new transport protocol between repagent >> and rephub. >> It was suggested to use some standard network storage protocol instead, and >> use QMP commands for the control path. >> >> The main idea is to use two NBD connections per protected volume: >> NBD tap - protected VM is the client, rephub is the server, used to report >> writes. >> The tap is not a standard NBD backing - it is for replication, meaning >> that its importance is lesser than >> the main image path. Errors are not reported to the protected VM as IO >> error. > > You mentioned a future feature that sends request metadata (offset, > length) to the rephub synchronously so that protection is 100%. > (Otherwise a network failure or crash might result in missed writes > that the rephub does not know about.) > > The NBD tap might not be the right channel for sending synchronous > request metadata, since the protocol is geared towards block I/O > requests that include the actual data. I'm not sure that QMP should > be used either - even though we have the concept of QMP events - > because it's not a low-latency, high ops communications channel. > > Which channel do you use in your existing products for synchronous > request metadata?
BTW, your design makes sense to me. Stefan
