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 <tamura.yoshi...@lab.ntt.co.jp>:
> 2011/2/24 Juan Quintela <quint...@redhat.com>:
>>
>> [ trimming cc to kvm & qemu lists]
>>
>> Yoshiaki Tamura <tamura.yoshi...@lab.ntt.co.jp> wrote:
>>> Juan Quintela wrote:
>>>> Yoshiaki Tamura<tamura.yoshi...@lab.ntt.co.jp> 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 majord...@vger.kernel.org
>> 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 majord...@vger.kernel.org
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
