Daniel P. Berrange wrote:
On Wed, Jul 11, 2007 at 08:59:08AM -0500, Anthony Liguori wrote:
Till Maas wrote:
On Mi Juli 11 2007, Richard W.M. Jones wrote:
I'm interested to know how VirtualBox / VMWare deal with disk storage.
Do they provide their own storage subsystems which support this or do
they interact with things like LVM?
The use their own subsystem. VMWare uses .vmdk files to store the harddisk
contents. When a snapshot is created, it creates a new one that depends on
the old one and stores every change in the new one. When the machine is
running during the snapshot, the complete state of the machine is stored,
too. I guess VirtualBox does it similiar.
Qemu also provides this feature, except that afaik it is only possible to
savely create snapshots of powered off machines with the qcow2 image type.
This is not correct. QEMU has supported (for a very long time) the
ability to save/restore snapshots of running machines. In QEMU 0.9.0,
instead of saving snapshots to an external file, snapshots are saved
along with disk snapshots to the actual disk file. This of course
requires that the disk format support this and currently qcow2 is the
only format that does.
Which makes it rather useless - pretty much all my guests are either LVM
or partitions, and sometimes raw files. I understand why this was done
because it lets you do incremental checkpointing & restore. I think it'd
be usefult to also add back support for saving to external files. I was
looking at the code & think it would be really very easy to do, without
impacting current code.
My plan was to make the migrate URI flexible such that an unknown URI
called out to an external program. Somehow, an fd to a monitor would be
passed so that the program could decide whether to "pause" before doing
the save or to do the save live.
This would allow you to write a "lvm" script that knew how to checkpoint
LVM and could redirect the saved state to an external file using some
sort of common naming convention. That way, "savevm lvm://foo" would
result in the lvm volumes being checkpointed and the state being saved
to /var/run/qemu/foo.state or something like that.
The goal is to eliminate the distinction between savevm/migrate since
they are really the same thing (savevm just pauses the VM first).
Regards,
Anthony Liguori
Dan.
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list