Re: [ovirt-devel] Snapshots & clone support from datastore
On Wed, Jun 21, 2017 at 11:03 PM Deepak Jagtap <deepak.jagtap(a)maxta.com>
wrote:
Hi Allon,
I am trying to leverage snapshot capability of underlying filesystem.
As per my understanding current snapshot works like this:
Base Image(raw)--->snap1(qcow)->snap2(qcow), i.e after each snapshot vm
starts writing on newly created qcow image.
So in this case vm is going to do all new writes on snap2(qcow) voulme and
will redirect read IOs to snap1 & Base image as required.
Right
But in my case snapshots created by the filesystem are read only and it's
in raw format.
As a result after creating snapshot vm disk configuration won't change
after taking snapshot but will continue doing writes on same base image.
So snapshots will look like this:
Base Image(raw)--->snap1(raw)->snap2(raw)
Not sure what is snap1 and snap2 - how do you create and use them
with your file system? what is the underlying file system?
Base Image will always remain writable, while the snapshots will
remain
read only raw format.
This works like ceph volumes.
Our flow for ceph is:
1. engine invokes VM.freeze vdsm api to ensure that guest file systems are
consistent
2. engine create new snapshot via cinder api
3. engine may invokes VM.snapshot vdsm api (without the ceph disk) if
memory snapshot is needed.
memory snapshot is stored in a new disk created by engine before this
flow
4. engine invokes VM.thaw to unfreeze guest file systems
Just wanted to confirm is this configurable so that vm continues
referring base image after the snapshot instead of newly created qcow
image?
No, it will use new image, this is not possible with snapshot.
Vdsm has the basic building blocks to do what you need, except creating
and deleting snapshots. To implement such feature you need to add a new
type of storage in engine that will call the right vdsm apis when creating
and deleting snapshots, and new vdsm apis to create and delete snapshots.
Nir
Attachments:
- attachment.html (text/html — 4.1 KB)