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

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

On Wed, Jul 11, 2007 at 09:26:38AM -0500, Anthony Liguori wrote:
> 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.

Or you could just let the management tool enter 'stop' in the monitor
if they required that the VM be paused for save, rather than kept running
for migrate.

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

Ok, that sounds like it would be sufficient to let us implement the current
save/restore API in libvirt which allows ad-hoc files.  I do also want to
thing about an alternate API for 'managed' save/restore - where the HV manages
save/restore files internally & the tools just say 'save a snapshot'.

> The goal is to eliminate the distinction between savevm/migrate since 
> they are really the same thing (savevm just pauses the VM first).

Yep, that makes alot of sense for the QEMU impl

|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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