[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Re: Next features and target for development



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]