[Qemu-devel] Re: [PATCH 07/18] Introduce fault tolerant VM transaction QEMUFile and ft_mode.

[ya su]

Juan:

     It's especailly important for ft to be a standalone thread, as it
may cause monitor to  be blocked by network problems.  what's your
schedule, maybe I can help some.

Yoshi:

     in the following code:

+
+    s->file = qemu_fopen_ops(s, ft_trans_put_buffer, ft_trans_get_buffer,
+                             ft_trans_close, ft_trans_rate_limit,
+                             ft_trans_set_rate_limit, NULL);
+
+    return s->file;
+}

    I think you should register ft_trans_get_rate_limit function,
otherwise it will not transfer any block data at stage 2 in
block_save_live function:

    if (stage == 2) {
        /* control the rate of transfer */
        while ((block_mig_state.submitted +
                block_mig_state.read_done) * BLOCK_SIZE <
               qemu_file_get_rate_limit(f)) {

     qemu_file_get_rate_limit will return 0, then it will not proceed
to copy dirty block data.

     FYI.

Green.


2011/2/24 Yoshiaki Tamura <address@hidden>:
> 2011/2/24 Juan Quintela <address@hidden>:
>>
>> [ trimming cc to kvm & qemu lists]
>>
>> Yoshiaki Tamura <address@hidden> wrote:
>>> Juan Quintela wrote:
>>>> Yoshiaki Tamura<address@hidden>  wrote:
>>>>> This code implements VM transaction protocol.  Like buffered_file, it
>>>>> sits between savevm and migration layer.  With this architecture, VM
>>>>> transaction protocol is implemented mostly independent from other
>>>>> existing code.
>>>>
>>>> Could you explain what is the difference with buffered_file.c?
>>>> I am fixing problems on buffered_file, and having something that copies
>>>> lot of code from there makes me nervous.
>>>
>>> The objective is different:
>>>
>>> buffered_file buffers data for transmission control.
>>> ft_trans_file adds headers to the stream, and controls the transaction
>>> between sender and receiver.
>>>
>>> Although ft_trans_file sometimes buffers date, but it's not the main 
>>> objective.
>>> If you're fixing the problems on buffered_file, I'll keep eyes on them.
>>>
>>>>> +typedef ssize_t (FtTransPutBufferFunc)(void *opaque, const void *data, 
>>>>> size_t size);
>>>>
>>>> Can we get some sharing here?
>>>> typedef ssize_t (BufferedPutFunc)(void *opaque, const void *data, size_t 
>>>> size);
>>>>
>>>> There are not so much types for a write function that the 1st element is
>>>> one opaque :p
>>>
>>> You're right, but I want to keep ft_trans_file independent of
>>> buffered_file at this point.  Once Kemari gets merged, I'm happy to
>>> work with you to fix the problems on buffered_file and ft_trans_file,
>>> and refactoring them.
>>
>> My goal is getting its own thread for migration on 0.15, that
>> basically means that we can do rm buffered_file.c.  I guess that
>> something similar could happen for kemari.
>
> That means both gets initiated by it's own thread, not like
> current poll based.  I'm still skeptical whether Anthony agrees,
> but I'll keep it in my mind.
>
>> But for now, this is just the start + handwaving, once I start doing the
>> work I will told you.
>
> Yes, please.
>
> Yoshi
>
>>
>> Later, Juan.
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to address@hidden
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>