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).