[libvirt] RFC New virDomainBlockPull API family to libvirt

[Stefan Hajnoczi]

On Wed, Jul 20, 2011 at 3:25 PM, Stefan Hajnoczi <stefanha at gmail.com> wrote:
> On Wed, Jul 20, 2011 at 2:40 PM, Kevin Wolf <kwolf at redhat.com> wrote:
>> Am 20.07.2011 15:12, schrieb Stefan Hajnoczi:
>>> On Wed, Jul 20, 2011 at 2:00 PM, Stefan Hajnoczi <stefanha at gmail.com> wrote:
>>>> On Mon, Jul 18, 2011 at 9:10 PM, Adam Litke <agl at us.ibm.com> wrote:
>>>>> On 07/18/2011 09:35 AM, Stefan Hajnoczi wrote:
>>>>>>>>>>   On the other hand I suspect that we are missing the mechanism to
>>>>>>>>>> control the rate of the transfer in the new API, which is something
>>>>>>>>>> which could be implemented in the old incremental mechanism, but not
>>>>>>>>>> anymore. So I wonder if the virDomainBlockPull() shouldn't get an
>>>>>>>>>> "unsigned long bandwidth" (to stay coherent with migration APIs)
>>>>>>>>>> before the flags. I don't know if the support is ready in QEmu but
>>>>>>>>>> I suspect that will be an important point, so if not present will
>>>>>>>>>> be added :-)
>>>>>>>>>
>>>>>>>>> Hopefully Stefan can comment on any throttling mechanisms that might be
>>>>>>>>> added to the qemu implementation.  It would be nice to have this feature
>>>>>>>>> built into the API to match the migration APIs, but if that is not
>>>>>>>>> feasible then we could always add it later.
>>>>>>>>
>>>>>>>> If we follow the live migration API then a block_stream_set_speed
>>>>>>>> command would be used.  libvirt would issue it as a separate command
>>>>>>>> immediately after starting the streaming operation.  There is the
>>>>>>>> window of time after streaming has started but before
>>>>>>>> block_stream_set_speed has been called where no throttling takes
>>>>>>>> place, but I don't think this is a practical problem.
>>>>>>>>
>>>>>>>> It also opens the possibility of allowing the user to change the rate
>>>>>>>> limit value while the block streaming operation is active.
>>>>>>>
>>>>>>> In light of our decision to provide a generic BlockJobAbort/BlockJobInfo
>>>>>>> interface, should SetSpeed be generic too?
>>>>>>>
>>>>>>> virDomainBlockJobSetSpeed() or virDomainBlockPullSetSpeed() ?
>>>>>>
>>>>>> The block_stream_set_speed semantics allow the command to be used when
>>>>>> no streaming operation is active.  This can be used to set the speed
>>>>>> without a window of time after creation and before set_speed is
>>>>>> called.
>>>>>>
>>>>>> If we switch to block_job_set_speed then it is cleaner to restrict the
>>>>>> command to work on active jobs only.  This is because there is only
>>>>>> one "speed" variable kept but there might be multiple job types
>>>>>> (streaming, compaction, etc) which would need different settings.
>>>>>>
>>>>>> What do you think about this?
>>>>>
>>>>> I think the block_job_set_speed semantics seem reasonable to me. What is
>>>>> the method for querying the current speed setting?  I would suggest
>>>>> extending the query-block-job command to include this information.  In
>>>>> this case, I would extend virDomainBlockJobInfo to contain:
>>>>>
>>>>>        /* The maximum allowable bandwidth for this job (MB/s) */
>>>>>        unsigned long bandwidth;
>>>>
>>>> Working QEMU code is pushed to:
>>>> http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/stream-command
>>>>
>>>> I am updating the QEMU wiki page with the latest changes.
>>>
>>> v4 posted:
>>> http://wiki.qemu.org/Features/LiveBlockMigration/ImageStreamingAPI
>>>
>>> Adam: block_job_set_speed fully updated.
>>>
>>> Kevin: we talked about error values earlier.  Internally we really
>>> only have an errno value when streaming fails.  I have converted this
>>> to a human-readable string.
>>
>> If the human can read English. :-)
>>
>> And even though I do, I really don't like messages like I got from the
>> Fedora updater in earlier versions ("You have 42 Aktualisierungen"), so
>> plain strings aren't going to work well. This is true even for localised
>> strerror output, as the client may use a different language than the server.
>>
>> I think this has been discussed multiple time in the past (we wanted to
>> somehow expose something useful on I/O errors).
>
> That's true but is there a better solution?
>
> I'm not very enthusiastic about localizing systems software because
> the error messages end up being gibberish in other languages anyway.
> The translations are often literal or babelfish-style when it comes to
> systems software.  Segmentation fault, Bus error, Overflow - I cringe
> when I see them translated.  It's a bit of a personal rant, I know,
> but wasted effort IMO.  Still better than error code #1524-1352 :).

Also, there's the reverse problem of when someone has an error they
need help with.  They go on IRC or mailing lists but their errors are
in a language no one able to help speaks.  Way to go :).

Stefan