Re: [libvirt RFCv8 00/27] multifd save restore prototype
On 5/12/22 3:38 PM, Claudio Fontana wrote:
On 5/11/22 7:46 PM, Daniel P. Berrangé wrote:
> On Wed, May 11, 2022 at 07:31:45PM +0200, Claudio Fontana wrote:
>> That's great, I love when things are simple.
>>
>> If indeed we want to remove the copy in libvirt (which will also mean explicitly
fsyncing elsewhere, as the iohelper would not be there anymore to do that for us on image
creation),
>> with QEMU having a "file" protocol support for migration,
>>
>> do we plan to have libvirt and QEMU both open the file for writing concurrently,
with QEMU opening O_DIRECT?
>
> For non-libvirt users, I expect QEMU would open the
> file directly . For libvirt usage, it is likely
> preferrable to pass the pre-opened FD, because that
> simplifies file permission handling.
>
>> The alternative being having libvirt open the file with
>> O_DIRECT, write some libvirt stuff in a new, O_DIRECT-
>> friendly format, and then pass the fd to qemu to migrate to,
>> and QEMU sending its new O_DIRECT friendly stream there.
>
> Yep.
Currently I am working on this part, and I can use my prototype to test that the Direct
part of the I/O works.
Just as a follow up and heads up that I am reworking the Image Write and Read code in
qemu_saveimage.c
and while doing that I see quite a few things that need improvement, especially missing
validations on lengths etc.
Ciao,
Claudio
I can split things more to be able to provide more generally useful
parts to the series,
that we can use to test out things while the qemu stuff is hopefully also tackled.
Thanks,
Claudio
>
>> In any case, the expectation here is to have a new
>> "file://pathname" or "file:://fdname" as an added feature in
QEMU,
>> where QEMU would write a new O_DIRECT friendly stream
>> directly into the file, taking care of both optional
>> parallelization and compression.
>
> I could see several distinct building blocks
>
> * First a "file:/some/path" migration protocol
> that can just do "normal" I/O, but still writing
> in the traditional migration data stream
>
> * Modify existing 'fd:' protocol so that it fstat()s
> and passes over to the 'file' protocol handler if
> it sees the FD is not a socket/pipe
>
> * Add a migration capability "direct-mapped" to
> indicate we want the RAM data written/read directly
> to/from fixed positions in the file, as opposed to
> a stream. Obviously only valid with a sub-set
> of migration protocols (file, and fd: if a seekable
> FD).
>
> * Add a migration capability "bypass-cache" to
> indicate we want O_DIRECT to bypass host I/O
> cache. Again limited to some migration protocols
>
>
> With regards,
> Daniel
>