[pve-devel] Snapshot questions

[Philipp Marek]

Hi Dietmar,

thanks for the answer.


> > *) The first question is - how would these get called? "pvesm" shows no 
> > matching arguments, and the GUI has no "snapshot" buttons either.
> I guess it is best to test that with Qemu VMs. You can use the GUI
...
> There is currently no snapshot support within 'pvesm', because snapshots
> are usually managed by the 'qm' tool, or directly at storage level.
Yeah, I'm looking for a CLI to the snapshots at the storage level ... so 
that I can test and debug the snapshot functions in the DRBD driver ;)

> I usually simply write small perl test scripts like this:
...
> ---END-PERL-CODE--
Thanks, I'll try that.

> > Does that hide behind backup functionality or something like that?
> Sorry, I do not understand that question. For Qemu VM, we do not use
> storage snapshots to implement backup (we use qemu block backup code instead,
> which also provides snapshot semantics).
I'm wondering why eg. the RBD driver supports snapshots, when there's 
nothing in the web frontend or CLI to use them.


> > *) The second question is - recently the "filesystem_path" function got a new 
> > line added:
...
> > In what circumstances would that function get called? 
> 
> This is experimental code, and we want to use that to implement backup
> functionality at the storage level. While we do not use that for KVM,
Why not?

> we
> want to use it with LXC containers:
> 
> https://git.proxmox.com/?p=pve-container.git;a=summary
> 
> Above container management toolkit 'pct' already supports drbd, and it would
> be really cool to have snapshots, so that we can make snapshot and 
> snapshot backups ;-)
The same should be easily possible for KVM, too.

> But that code is quite new, so I would start with qemu, and implement those
> advanced features later.
Hmmm, I'm not sure where qemu comes in, when implementing snapshots for 
DRBD.

> > While the Thin LVM 
> > snapshots that DRBDmanage uses might be addressable locally[1], accessing 
> > them is not recommended. Is that just for information purposes in the GUI?
> 
> We want to access them when making container backups. I think this should
> work with dm-thin - why not? 
Because _directly_ accessing them might change the data within them (at 
least replay the filesystem journal).

The use case we thought of is
  1) install a VM
  2) make a snapshot
  3) use that snapshot as template for new VMs

That's similar to what docker does.
Now, if after (2) the snapshot data gets modified, the VMs created via (3) 
might be different from each other (in unexpected ways, ie. the hostname, 
ip, etc. _should_ be different - but other data not), which might then 
cause support overhead.


In Cinder the workflow is to create a new volume from a snapshot, even if 
it's just being looked at ... so all the machines in (3) would have the 
same (unmodified) snapshot as base.


> We can extend the storage API with 'activate_snapshot_volume()' and 
> 'deactivate_snapshot_volume()' if required?
Well, perhaps.

Would that make the snapshot itself available for access? What if the 
snapshot data is accessible only on another node and not on the current 
one?


>> - but using a snapshot for a new ("clean") VM isn't being done, right?
> 
> don't really understand that question?
See the use case above.


> > and after rollback it can have a new filesystem_path(),correct?
> 
> Yes, that should work.
Thanks, that would be easier. Else we'd have to make sure to get the same 
drbd device again, and that's not that easy because of race conditions.


> Besides, we also have 'vdisk_clone', and some storage types supports
> to clone directly from snapshot (zfs). But I am not really sure
> if drbdmanage will support clone at all?
Well, drbdmanage already supports create_snapshot and restore_snapshot...
the combination is more or less a "clone". And may we want to put that in 
drbdmanage core - I'll discuss that.

> Normally, we only allow cloning from 'base' volumes, which are created
> with vdisk_create_base(). If most cases, this just marks the volumes as
> 'read-only' and renames them. I guess dm-thin could
> make a 'clone' by simply creating a writable snapshot of such read-only
> volumes?
Yeah, that's what we do - snapshots[1] from writable volumes, to create 
writable volumes.

Ad 1: While the Thin snapshots could be written to, too, drbdmanage uses 
them in a RO manner - it just creates new volumes from them.


Thanks for the answers!


Regards,

Phil

-- 
: Ing. Philipp Marek
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting                 http://www.linbit.com :

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.