1. 26 4月, 2014 1 次提交
  2. 22 4月, 2014 1 次提交
  3. 25 3月, 2014 2 次提交
  4. 06 3月, 2014 1 次提交
  5. 15 2月, 2014 2 次提交
  6. 24 1月, 2014 2 次提交
  7. 20 12月, 2013 4 次提交
  8. 29 11月, 2013 1 次提交
    • F
      block: per caller dirty bitmap · e4654d2d
      Fam Zheng 提交于
      Previously a BlockDriverState has only one dirty bitmap, so only one
      caller (e.g. a block job) can keep track of writing. This changes the
      dirty bitmap to a list and creates a BdrvDirtyBitmap for each caller, the
      lifecycle is managed with these new functions:
      
          bdrv_create_dirty_bitmap
          bdrv_release_dirty_bitmap
      
      Where BdrvDirtyBitmap is a linked list wrapper structure of HBitmap.
      
      In place of bdrv_set_dirty_tracking, a BdrvDirtyBitmap pointer argument
      is added to these functions, since each caller has its own dirty bitmap:
      
          bdrv_get_dirty
          bdrv_dirty_iter_init
          bdrv_get_dirty_count
      
      bdrv_set_dirty and bdrv_reset_dirty prototypes are unchanged but will
      internally walk the list of all dirty bitmaps and set them one by one.
      Signed-off-by: NFam Zheng <famz@redhat.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      e4654d2d
  9. 11 10月, 2013 2 次提交
  10. 12 9月, 2013 1 次提交
  11. 06 9月, 2013 2 次提交
  12. 23 8月, 2013 2 次提交
  13. 28 6月, 2013 1 次提交
  14. 17 6月, 2013 1 次提交
  15. 22 4月, 2013 1 次提交
    • K
      block: Add driver-specific options for backing files · 31ca6d07
      Kevin Wolf 提交于
      Options starting in "backing." are passed to the backing file now. If
      you don't need to specify the filename for the backing file, you can add
      it on the command line instead of in the image file:
      
      $ qemu-nbd -t /tmp/test.img
      $ qemu-img create -f qcow2 empty.qcow2 1G
      $ qemu-system-x86_64 -drive file=empty.qcow2,backing.file.driver=nbd,\
          backing.file.host=localhost
      
      Note that this doesn't override the backing filename from the image. If
      the image has one, this will fail because NBD doesn't want the options
      and a filename at the same time.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      31ca6d07
  16. 26 1月, 2013 10 次提交
  17. 16 1月, 2013 1 次提交
  18. 19 12月, 2012 1 次提交
  19. 11 12月, 2012 1 次提交
  20. 24 10月, 2012 3 次提交
    • P
      mirror: add support for on-source-error/on-target-error · b952b558
      Paolo Bonzini 提交于
      Error management is important for mirroring; otherwise, an error on the
      target (even something as "innocent" as ENOSPC) requires to start again
      with a full copy.  Similar to on_read_error/on_write_error, two separate
      knobs are provided for on_source_error (reads) and on_target_error (writes).
      The default is 'report' for both.
      
      The 'ignore' policy will leave the sector dirty, so that it will be
      retried later.  Thus, it will not cause corruption.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      b952b558
    • P
      mirror: implement completion · d63ffd87
      Paolo Bonzini 提交于
      Switching to the target of the migration is done mostly asynchronously,
      and reported to management via the BLOCK_JOB_COMPLETED event; the only
      synchronous phase is opening the backing files.  bdrv_open_backing_file
      can always be done, even for migration of the full image (aka sync:
      'full').  In this case, qmp_drive_mirror will create the target disk
      with no backing file at all, and bdrv_open_backing_file will be a no-op.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      d63ffd87
    • P
      mirror: introduce mirror job · 893f7eba
      Paolo Bonzini 提交于
      This patch adds the implementation of a new job that mirrors a disk to
      a new image while letting the guest continue using the old image.
      The target is treated as a "black box" and data is copied from the
      source to the target in the background.  This can be used for several
      purposes, including storage migration, continuous replication, and
      observation of the guest I/O in an external program.  It is also a
      first step in replacing the inefficient block migration code that is
      part of QEMU.
      
      The job is possibly never-ending, but it is logically structured into
      two phases: 1) copy all data as fast as possible until the target
      first gets in sync with the source; 2) keep target in sync and
      ensure that reopening to the target gets a correct (full) copy
      of the source data.
      
      The second phase is indicated by the progress in "info block-jobs"
      reporting the current offset to be equal to the length of the file.
      When the job is cancelled in the second phase, QEMU will run the
      job until the source is clean and quiescent, then it will report
      successful completion of the job.
      
      In other words, the BLOCK_JOB_CANCELLED event means that the target
      may _not_ be consistent with a past state of the source; the
      BLOCK_JOB_COMPLETED event means that the target is consistent with
      a past state of the source.  (Note that it could already happen
      that management lost the race against QEMU and got a completion
      event instead of cancellation).
      
      It is not yet possible to complete the job and switch over to the target
      disk.  The next patches will fix this and add many refinements to the
      basic idea introduced here.  These include improved error management,
      some tunable knobs and performance optimizations.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      893f7eba