Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 05 12月, 2011 3 次提交
  3. 22 11月, 2011 1 次提交
    • A
      block: allow migration to work with image files (v3) · 0f15423c
      由 Anthony Liguori 提交于 
      Image files have two types of data: immutable data that describes things like
image size, backing files, etc. and mutable data that includes offset and
reference count tables.

Today, image formats aggressively cache mutable data to improve performance.  In
some cases, this happens before a guest even starts.  When dealing with live
migration, since a file is open on two machines, the caching of meta data can
lead to data corruption.

This patch addresses this by introducing a mechanism to invalidate any cached
mutable data a block driver may have which is then used by the live migration
code.

NB, this still requires coherent shared storage.  Addressing migration without
coherent shared storage (i.e. NFS) requires additional work.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      0f15423c
  5. 11 11月, 2011 4 次提交
    • K
      block: Make cache=unsafe flush to the OS · ca716364
      由 Kevin Wolf 提交于 
      cache=unsafe completely ignored bdrv_flush, because flushing the host disk
costs a lot of performance. However, this means that qcow2 images (and
potentially any other format) can lose data even after the guest has issued a
flush if the qemu process crashes/is killed. In case of a host crash, data loss
is certainly expected with cache=unsafe, but if just the qemu process dies this
is a bit too unsafe.

Now that we have two separate flush functions, we can choose to flush
everythign to the OS, but don't enforce that it's physically written to the
disk.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      ca716364
    • K
      block: Introduce bdrv_co_flush_to_os · eb489bb1
      由 Kevin Wolf 提交于 
      qcow2 has a writeback metadata cache, so flushing a qcow2 image actually
consists of writing back that cache to the protocol and only then flushes the
protocol in order to get everything stable on disk.

This introduces a separate bdrv_co_flush_to_os to reflect the split.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      eb489bb1
    • K
      block: Rename bdrv_co_flush to bdrv_co_flush_to_disk · c68b89ac
      由 Kevin Wolf 提交于 
      There are two different types of flush that you can do: Flushing one level up
to the OS (i.e. writing data to the host page cache) or flushing it all the way
down to the disk. The existing functions flush to the disk, reflect this in the
function name.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      c68b89ac
    • P
      block: add eject request callback · 025ccaa7
      由 Paolo Bonzini 提交于 
      Recent versions of udev always keep the tray locked so that the kernel
can observe "eject request" events (aka tray button presses) even on
discs that aren't mounted.  Add support for these events in the ATAPI
and SCSI cd drive device models.

To let management cope with the behavior of udev, an event should also
be added for "tray opened/closed".  This way, after issuing an "eject"
command, management can poll until the guests actually reacts to the
command.  They can then issue the "change" command after the tray has been
opened, or try with "eject -f" after a (configurable?) timeout.  However,
with this patch and the corresponding support in the device models,
at least it is possible to do a manual two-step eject+change sequence.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      025ccaa7
  7. 29 10月, 2011 4 次提交
  9. 27 10月, 2011 5 次提交
  11. 21 10月, 2011 5 次提交
  13. 14 10月, 2011 3 次提交
  15. 13 10月, 2011 7 次提交
  17. 11 10月, 2011 3 次提交
  19. 03 10月, 2011 2 次提交
  21. 12 9月, 2011 3 次提交