Il 21/05/2012 15:07, Kevin Wolf ha scritto: > Am 21.05.2012 13:02, schrieb Paolo Bonzini: >> Il 21/05/2012 12:32, Kevin Wolf ha scritto: >>> Am 21.05.2012 12:02, schrieb Paolo Bonzini: >>>> Il 21/05/2012 11:29, Kevin Wolf ha scritto: >>> If source/target is really the distinction we want to have, should the >>> available options be specific to the job type, so that you could have >>> src_error and dst_error for mirroring? >> >> Yes, that would make sense. > > Of course, at the same time it also makes the implementation a bit more > complicated.
Not much, I'd have rerror/werror already split if I followed my spec. >>> Management doesn't necessarily exist. >> >> Even a human sitting at a console is management. (Though I don't plan >> HMP to expose rerror/werror; so you can assume in some sense that >> management exists). > > But it's management that cares about good defaults. :-) > > Why not expose the options in HMP? Honestly, because it's a pain. HMP doesn't have options with arguments, and I don't really care if HMP users curse at me because they end out-of-disk-space and their migration is dropped. If you're using HMP, more than likely: 1) you can just stop the VM and copy the storage manually; 2) even if you can't, if you get an EIO you can just stop the VM and figure the root cause. As far as storage migration is concerned (and quite a few other scenarios) HMP is a nice debugging tool, nothing more. >>>> Management may want to keep the VM stopped even for an error on the >>>> target, as long as mirroring has finished the initial synchronization >>>> step. The VM can perform large amounts of I/O while the job is paused, >>>> and then completing the job can take a large amount of time. >>> >>> If management wants to limit the impact of this, it can decide to >>> explicitly stop the VM when it receives the error event. >> >> That can be too late. >> >> Eric, is it a problem for libvirt if a pause or target error during >> mirroring causes the job to exit steady state? That means that after a >> target error the offset can go back from 100% to <100%. > > "too late" in what respect? Too late to properly show the error... though actually there is no guarantee that the VM will not clobber the error even with vm_stop, so it doesn't make a big difference in that, too. >> So for now I'll keep my proposed extension of query-block-jobs; later it >> can be modified so that the target will have a name if you started the >> mirroring with blockdev_mirror instead of drive_mirror. > > You mean the same QMP field is a string when the block device was added > with blockdev_add and a dict when it was added with drive_add? > Maintaining this sounds like a nightmare to me. No, the same QMP field is a dict. With blockdev_add it will have a name, and it will just be a shortcut to info block/info blockstat. With drive_add it will have no name. Paolo