[Libvir] Re: Next features and target for development

[Anthony Liguori]

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