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.