1. 15 8月, 2018 4 次提交
  2. 10 7月, 2018 4 次提交
  3. 03 7月, 2018 1 次提交
  4. 18 6月, 2018 1 次提交
  5. 15 6月, 2018 5 次提交
  6. 12 6月, 2018 5 次提交
  7. 23 5月, 2018 8 次提交
  8. 04 5月, 2018 1 次提交
  9. 20 3月, 2018 3 次提交
  10. 19 3月, 2018 5 次提交
    • L
      block/mirror: change the semantic of 'force' of block-job-cancel · b76e4458
      Liang Li 提交于
      When doing drive mirror to a low speed shared storage, if there was heavy
      BLK IO write workload in VM after the 'ready' event, drive mirror block job
      can't be canceled immediately, it would keep running until the heavy BLK IO
      workload stopped in the VM.
      
      Libvirt depends on the current block-job-cancel semantics, which is that
      when used without a flag after the 'ready' event, the command blocks
      until data is in sync.  However, these semantics are awkward in other
      situations, for example, people may use drive mirror for realtime
      backups while still wanting to use block live migration.  Libvirt cannot
      start a block live migration while another drive mirror is in progress,
      but the user would rather abandon the backup attempt as broken and
      proceed with the live migration than be stuck waiting for the current
      drive mirror backup to finish.
      
      The drive-mirror command already includes a 'force' flag, which libvirt
      does not use, although it documented the flag as only being useful to
      quit a job which is paused.  However, since quitting a paused job has
      the same effect as abandoning a backup in a non-paused job (namely, the
      destination file is not in sync, and the command completes immediately),
      we can just improve the documentation to make the force flag obviously
      useful.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Jeff Cody <jcody@redhat.com>
      Cc: Kevin Wolf <kwolf@redhat.com>
      Cc: Max Reitz <mreitz@redhat.com>
      Cc: Eric Blake <eblake@redhat.com>
      Cc: John Snow <jsnow@redhat.com>
      Reported-by: NHuaitong Han <huanhuaitong@didichuxing.com>
      Signed-off-by: NHuaitong Han <huanhuaitong@didichuxing.com>
      Signed-off-by: NLiang Li <liliangleo@didichuxing.com>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      b76e4458
    • J
      blockjobs: Expose manual property · b40dacdc
      John Snow 提交于
      Expose the "manual" property via QAPI for the backup-related jobs.
      As of this commit, this allows the management API to request the
      "concluded" and "dismiss" semantics for backup jobs.
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      b40dacdc
    • J
      blockjobs: add block-job-finalize · 11b61fbc
      John Snow 提交于
      Instead of automatically transitioning from PENDING to CONCLUDED, gate
      the .prepare() and .commit() phases behind an explicit acknowledgement
      provided by the QMP monitor if auto_finalize = false has been requested.
      
      This allows us to perform graph changes in prepare and/or commit so that
      graph changes do not occur autonomously without knowledge of the
      controlling management layer.
      
      Transactions that have reached the "PENDING" state together can all be
      moved to invoke their finalization methods by issuing block_job_finalize
      to any one job in the transaction.
      
      Jobs in a transaction with mixed job->auto_finalize settings will all
      remain stuck in the "PENDING" state, as if the entire transaction was
      specified with auto_finalize = false. Jobs that specified
      auto_finalize = true, however, will still not emit the PENDING event.
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      11b61fbc
    • J
      blockjobs: add block_job_dismiss · 75f71059
      John Snow 提交于
      For jobs that have reached their CONCLUDED state, prior to having their
      last reference put down (meaning jobs that have completed successfully,
      unsuccessfully, or have been canceled), allow the user to dismiss the
      job's lingering status report via block-job-dismiss.
      
      This gives management APIs the chance to conclusively determine if a job
      failed or succeeded, even if the event broadcast was missed.
      
      Note: block_job_do_dismiss and block_job_decommission happen to do
      exactly the same thing, but they're called from different semantic
      contexts, so both aliases are kept to improve readability.
      
      Note 2: Don't worry about the 0x04 flag definition for AUTO_DISMISS, she
      has a friend coming in a future patch to fill the hole where 0x02 is.
      
      Verbs:
      Dismiss: operates on CONCLUDED jobs only.
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      75f71059
    • J
      blockjobs: add block_job_verb permission table · 0ec4dfb8
      John Snow 提交于
      Which commands ("verbs") are appropriate for jobs in which state is
      also somewhat burdensome to keep track of.
      
      As of this commit, it looks rather useless, but begins to look more
      interesting the more states we add to the STM table.
      
      A recurring theme is that no verb will apply to an 'undefined' job.
      
      Further, it's not presently possible to restrict the "pause" or "resume"
      verbs any more than they are in this commit because of the asynchronous
      nature of how jobs enter the PAUSED state; justifications for some
      seemingly erroneous applications are given below.
      
      =====
      Verbs
      =====
      
      Cancel:    Any state except undefined.
      Pause:     Any state except undefined;
                 'created': Requests that the job pauses as it starts.
                 'running': Normal usage. (PAUSED)
                 'paused':  The job may be paused for internal reasons,
                            but the user may wish to force an indefinite
                            user-pause, so this is allowed.
                 'ready':   Normal usage. (STANDBY)
                 'standby': Same logic as above.
      Resume:    Any state except undefined;
                 'created': Will lift a user's pause-on-start request.
                 'running': Will lift a pause request before it takes effect.
                 'paused':  Normal usage.
                 'ready':   Will lift a pause request before it takes effect.
                 'standby': Normal usage.
      Set-speed: Any state except undefined, though ready may not be meaningful.
      Complete:  Only a 'ready' job may accept a complete request.
      
      =======
      Changes
      =======
      
      (1)
      
      To facilitate "nice" error checking, all five major block-job verb
      interfaces in blockjob.c now support an errp parameter:
      
      - block_job_user_cancel is added as a new interface.
      - block_job_user_pause gains an errp paramter
      - block_job_user_resume gains an errp parameter
      - block_job_set_speed already had an errp parameter.
      - block_job_complete already had an errp parameter.
      
      (2)
      
      block-job-pause and block-job-resume will no longer no-op when trying
      to pause an already paused job, or trying to resume a job that isn't
      paused. These functions will now report that they did not perform the
      action requested because it was not possible.
      
      iotests have been adjusted to address this new behavior.
      
      (3)
      
      block-job-complete doesn't worry about checking !block_job_started,
      because the permission table guards against this.
      
      (4)
      
      test-bdrv-drain's job implementation needs to announce that it is
      'ready' now, in order to be completed.
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Reviewed-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      0ec4dfb8
  11. 14 3月, 2018 1 次提交
  12. 03 3月, 2018 1 次提交
  13. 13 2月, 2018 1 次提交
反馈
建议
客服 返回
顶部