Hi Dean,

On 05/06/2010 10:30 AM, Dean Hildebrand wrote:
>> For disk space, quiesced snapshots don't include memory information, so 
> you
>> don't pay the largest cost of snapshots (the memory state file). The
>> delta disks
>> created are not large.
> 
> I guess that is true as long as you quickly delete the snapshot and don't 
> let the delta file grow?

Unless your VM is doing quite a lot of writes, the delta disk shouldn't grow
that fast. Definitely not enough to matter if all you're doing is taking a
snapshot the filesystem and then deleting the snapshot.

>> Then after you backup the vmdk you can delete the snapshot and solve
>> both problems.
> 
> Yeah, that would be true if we were planning on copying the vmdk file. But 
> our goal is to snapshot it in our file system (we are using a NFS data 
> store to our file system), which is basically instantaneous.

If you're creating a native snapshot then yeah, your solution probably would
work and not have the problem of freezing the VM for too long. But it wouldn't
re-use the existing feature. :-) So it's up to you.

> We've also heard people complaining about the 'stun' that occurs when you 
> delete the snapshot.  I assume this 'stun' is relatively minor when you 
> only have a single snapshot, and the delta file doesn't grow too large, 
> but it would still be nice to avoid altogether.

The stun should be minor - I'm not too familiar with the internals code, but my
understanding is that the stun is needed to allow the VMX process to switch the
disk backends, so it needs the VM to be stopped when it does that. A lot of the
"delete snapshot" process is done while the VM is alive, though.

> Safety wise, what are your major concerns?  Once the VM file systems are 
> frozen, all data will reside on the NFS server, so isn't it safe to assume 
> that the data in the vmdk file on the NFS server is file system 
> consistent? 

My main concern is that you would be copying the vmdk, which would take a while.
Since you're taking a "native" snapshot, then my only concern would be
duplication of effort. :-)

> Either way, if we do end up going down this path, it would be nice to be 
> able to use the vstorage api's (VADP) to quiesce the VM file systems 
> instead of having to access the VMs ourselves.  It would seem like a big 
> benefit to customers to enable back-end storage systems to provide 
> file-system consistent backup facilities without experiencing the overhead 
> of VM snapshots. (just my 2 cents).

The VADP APIs always use VMware snapshots to do their work, as far as I know.
I've seen some work towards supporting native snapshots, but I'm not familiar
with it and don't really know details about how it's going to work.

-- 
- Marcelo

------------------------------------------------------------------------------
_______________________________________________
open-vm-tools-devel mailing list
open-vm-tools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel

Reply via email to