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

Re: [Libvir] Snapshots in Libvirt

On Thu, Feb 28, 2008 at 04:48:19PM +0000, Daniel P. Berrange wrote:
> On Thu, Feb 28, 2008 at 11:44:28AM -0500, Daniel Veillard wrote:
> > On Thu, Feb 28, 2008 at 06:33:13PM +0200, Gabriel Kaufmann wrote:
> > > 
> > >    Hi,
> > > 
> > > 
> > >    Can  anyone  tell  me  on  which  version  of  libvirt,  the  snapshot
> > >    functionality is  planned to be implemented fos Xen and KVM?
> > > 
> > > 
> > >    By  snapshot  I  mean  to  be able to save the state of the machine in
> > >    order to be able to revert to the snapshot.
> > 
> > Can you provide pointers to descriptions of Xen and KVM support for this ? 
> > My take was that the main problem was with snapshotting support at the
> > filesystem level, and I think only LVM has support for this,
> It needs closely co-ordination between the HV & the filesystem and is not
> possible to implement in the general case.  QEMU/KVM supports snapshots
> only if your disks are in QCow2 format. There's no way to co-ordinate its
> snapshots with LVM snapshotting.


> And if you're using raw partitions, iSCSI, FiberChannel, you're totally
> out of luck
> This is not to say we shouldn't impleemnt snapshots in the API for libvirt.
> Just that there will be *very* limited scenarios in which it will be usable

  First question is really about support, i.e. how to activate it in QEMU/KVM,
and the obvious second question is what happen if snapshoting can't or didn't
work. The hypervisor in general doesn't care what kind of filesystems are being
used by the domain, can't guess in the general case, hence how can it check
whether this will work or not. Even if QEmu could detect the domain booted
off a QCow2 disk, can it really detect that the domain used for example an
iSCSI one and that trying to snapshot will just result in corruption, without
being able to detect the problem and fail the operation.

  The main risk to me seems to come from suggesting an API which can fail
silently and lead to data corruption, doesn't sound cool.


Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

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