Guest application notification: This allows guest applications to register and be notified prior to a snapshot, in order for them to allow flushing their data to disk.File system freeze (fsfreeze/fsthaw): This puts the guest file systems into a consistent state, avoiding the need for fsck next time they are mounted.The two main guest agent features of interest to live snapshots are: Please check the guest Guest Agent page for design and implementation details.
These features will be implemented in the Guest Agent. it is possible to make a QCOW2 snapshot of a RAW image, or a QED snapshot of a QED image.Ĭertain operations in the snapshot process can be improved through support from within the guest. The snapshot image will have to be in a format which support backing files, ie QCOW2 and QED, however the original image can be of any supported format. Unfortunately there is no way to detect that a backing file has been booted, making it important for administrators to take care to not rely on snapshot files being valid after a roll-back. Roll-back to a previous version requires one to boot from the previous backing file, at which point the snapshot file becomes invalid. This will allow the original image file to be backed up. The idea is to be able to issue a command to QEMU via the monitor or QMP, which causes QEMU to create a new snapshot image with the original image as the backing file, mounted read-only. It is a work in progress and things may change as we progress.
This document is describing the current design of live snapshots for QEMU.
3.2 fd passed as target for snapshot file/device.2.1.3.1 Streaming to an Intermediate Layer.2.1.2 Design of Block Streaming to Active Layer.1.6 Atomic Snapshots of Multiple Devices.
0 kommentar(er)
