On Wed, Jul 20, 2011 at 3:25 PM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > On Wed, Jul 20, 2011 at 2:40 PM, Kevin Wolf <kwolf@xxxxxxxxxx> wrote: >> Am 20.07.2011 15:12, schrieb Stefan Hajnoczi: >>> On Wed, Jul 20, 2011 at 2:00 PM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: >>>> On Mon, Jul 18, 2011 at 9:10 PM, Adam Litke <agl@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list