Re: [libvirt] [RFC]: Snapshot API

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

 



On Tue, Mar 23, 2010 at 07:35:22PM +0100, Matthias Bolte wrote:
> 2010/3/23 Chris Lalancette <clalance@xxxxxxxxxx>:
> > /* Return the number of snapshots for this domain */
> > int virDomainSnapshotNum(virDomainPtr domain, unsigned int flags);
> 
> Shouldn't this be called virDomainNumOfSnapshots to be consistent with
> the naming or other num-of functions?

  Yeah that would be a bit nicer, not fundamental though :-)

> >
> > /* Get the names of all snapshots for this domain */
> > int virDomainListSnapshotNames(virDomainPtr domain, char **names, int nameslen,
> >                               unsigned int flags);
> >
> > /* Get a handle to a named snapshot */
> > virDomainSnapshotPtr virDomainSnapshotLookupByName(virDomainPtr domain,
> >                                                   const char *name,
> >                                                   unsigned int flags);
> >
> > /* Set this snapshot as the current one for a domain, to be
> >  * used next time domain is started */
> > int virDomainSnapshotActivate(virDomainSnapshotPtr snapshot,
> >                              unsigned int flags);
> 
> This delayed semantic cannot be implemented for ESX. ESX can revert to
> a snapshot immediately only. I think the same holds true for
> VirtualBox.
> 
> Maybe I misunterstand this. What should happen if you call activate on
> a running domain?

  I guess we really need to use the flags there, and check for the flag
semantic in the driver.
  In ESX we will need a VIR_DOMAIN_SNAPSHOT_ACTIVATE_NOW flag to be passed
  In QEmu we will need a VIR_DOMAIN_SNAPSHOT_ACTIVATE_RESTART to be passed

 Or we split that as two different entry points as the semantic is
fairly different. This may be a bit cleaner, for example if you think of
a virsh command,
  virsh snap_activate --now foo snap1
  virsh snap_activate --restart foo snap1

where the command without flags would be rejected because there is no
common semantic, versus something like

  virsh snap_use foo snap1
  virsh snap_restart foo snap1

where using snap_use on qemu would raise a unsupported or snap_restart
on ESX.

  Semantic is so different, we can't use it without some flags or
have 
  virsh snap_activate foo snap1
fail while
  virsh snap_activate --restart foo snap1
would work, that's disturbing.

  So I really think we need 2 different entry point

  virDomainSnapshotActivateNow

  virDomainSnapshotActivateLater

for example (and still with flags)

> > int virDomainSnapshotFree(virDomainSnapshotPtr snapshot);

  Shouldn't we add something like virDomainSnapshotDestroy() too
assuming the semantic of Free is just to discard the libvirt object
but not remove the actual data.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel@xxxxxxxxxxxx  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]