napp-it autosnap: include ESXi hot snaps in ZFS snaps

[gea]

New function in napp-it dev (0.9f4=unstable 0.9)
autosnap: include ESXi hot snaps in ZFS snaps on NFS datastores

The idea:
- create a hot ESXi snap with memory state (remotely via SSH)
- create a ZFS snap
- delete ESXi snap

in case of problems
- restore ZFS snap
- restore hot ESXi snap with Vsphere

see menu Services >> SSH >> SSH keys and menu Jobs >> ESXi hot-snaps [Help] and
napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Changelog

Are there any problems to be expected?

 

[TuxDude]

I'm not certain about standalone ESXi hosts as I don't use them often (and virtually never with any external storage), but in a larger environment with vCenter that is likely to cause minor problems. When you delete the vSphere snap it will also be recorded in the vCenter database that it was deleted. In case of problems and wanting to roll-back, getting vCenter to realize that there is a snapshot available is going to require unregistering the VM, then restoring the ZFS snapshot, then browse the datastore and re-register the VM in its ESX-snapshotted state, and then finally tell vCenter to roll-back the VM.

 

[rubylaser]

New function in napp-it dev (0.9f4=unstable 0.9)
autosnap: include ESXi hot snaps in ZFS snaps on NFS datastores

The idea:
- create a hot ESXi snap with memory state (remotely via SSH)
- create a ZFS snap
- delete ESXi snap

in case of problems
- restore ZFS snap
- restore hot ESXi snap with Vsphere

see menu Services >> SSH >> SSH keys and menu Jobs >> ESXi hot-snaps [Help] and
napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Changelog

Are there any problems to be expected?

I'd like to do this on my OmniOS vm on ESXi, but I don't see either one of those menus on my 0.9f4 napp-it install. My Services > SSH menu does not contain a keys option and my Jobs Menue does not contain an ESXi hot-snaps option. Could you provide a little more guidance for this? This could a great feature for my single standalone All-in-One ESXi box. Thanks!

Edit... it looks like I'd need a Pro license for this version of napp-it. I'm running
0.9f4_dev (from December 22nd) and I need 0.9f4 (released on January 5th).

 

[gea]

Update to newest dev and bugfix releases is a Pro feature.
ESXi snaps included in ZFS snaps is a free feature in next stable.

A more up to date version is 0.9 unstable (a newer f4 than yours) that include ESXi snaps that you can update with the free release

 

[rubylaser]

Thanks Gea. I was confused by the versioning. I just updated and have all the options now

 

[gea]

0.9f3 is last stable
0.9f4 is current dev/nightly with newest features/bugfixes/problems

0.9 unstable is a support release that should be used only on demand

 

[rubylaser]

I have the SSH keys setup, and I can query my VMs on the ESXi server, but I can't figure out how to use this. Any advice to get this working? Thanks!

 

[gea]

have you read the infos from napp-it menus
- services >> SSH >> SSH keys (you to exchange keys)
- Jobs >> ESXi hotsnaps >> help (how to setup a pre and post ZFS snap commands to create/delete ESXi snaps)

 

[Daniel_GT]

I would like to be able to use this feature alongside replication. As I understand it, the process of replication for a source (say zfs1) to a target host (say zfs2) involves taking a standard snapshot on the source, then pulling the stream onto the target - updating the replicated file system incrementally each time the job runs. I cannot see a way (certainly within the GUI) to run the ESXi pre and post scripts before the replication snap is taken. As I have running VMs on zfs1 this is quite important.

I suspect I need to look into editing the script files manually, which I'm happy to do myself, though I did want to check that my understanding of the process is accurate or whether there is something I am missing?

 

[gea]

You need only one manual action: setup SSH access to Esxi.
The pre and post script to do and delete ESXi hotsnaps prior/after the ZFS snap can be created and managed in the Web-Gui in menu Jobs >> ESXi hotsnaps. When you create/ edit an autosnap job, you can enable/disable pre and post script processing.

The replication of the ZFS snaps (with included ESXi hot memory snaps) is a regular zfs send process.

 

[Daniel_GT]

You need only one manual action: setup SSH access to Esxi.
The pre and post script to do and delete ESXi hotsnaps prior/after the ZFS snap can be created and managed in the Web-Gui in menu Jobs >> ESXi hotsnaps. When you create/ edit an autosnap job, you can enable/disable pre and post script processing.

The replication of the ZFS snaps (with included ESXi hot memory snaps) is a regular zfs send process.

Thanks gea, I understand that and run ESXi hot snaps on both zfs1 and zfs2 every day. If I create a new replication job in the GUI I don't see an option to run the pre and post scripts on that new snap.

 

[Daniel_GT]

Thanks gea, I understand that and run ESXi hot snaps on both zfs1 and zfs2 every day. If I create a new replication job in the GUI I don't see an option to run the pre and post scripts on that new snap.

gea, your thread reply here suggests I may need to modify the job number in the replication script to point to an ESXi hot-snapped stream, rather than the new snap that the new replication job creates automatically? Is that how I should be viewing it?

 

[gea]

Replication and snapping (with included ESXi snaps or not) work completely independent.

When you do a ZFS snap, the state of a snap is like a sudden power down what mean, that a ESXi VM on the snap may be corruped. The pre job does an ESXi snap prior the ZFS snap. The post job deletes the ESXi snap after the ZFS snap is done as ESXi snaps slow down performance. In case of a restore, you can restore a ZFS snap and restore then the hot running state within vsphere from the included ESXi snap.

 

[Daniel_GT]

Thank you gea, I'm aware of all of that - I think you misunderstood my question. Unless I'm fundamentally mistaken, replication and snapping cannot be completely different, the replication job must create a snapshot on the source filesystem and use this (and zfs send | receive) to incrementally or otherwise update the replicated filesystem on the target. In the GUI I cannot use ESXi hot snap pre and post scripts on the source snap that the replication job creates in the first place so if I schedule a replication job at some point in the process the plug is pulled to the VMs on the source.

Don't worry, I think I know what I need to do. I want to use the GUI for scheduling/ rescheduling and setting target and source filesystems, but recognise I'm going to need to edit the send | receive script some way - otherwise I could forget about the in built replication and run a cron job to send | recv the ESXi hot snaps instead.

 

[gea]

There is a fundamental difference between ESXi snaps and ZFS snaps.
An ESXi snap is a delta file that represents the changes after it was created. This file increase over time of usage. The delta file is worthless without the base vmdk so you cannot backup the ESXi snap alone.

But if you do a ZFS snap after an ESXi snap, you can restore both, the ESXi base vmdk and the ESXi snap. The ZFS snap is the whole state of the filesystem. This is what you can send to another location.

This is why ESXi snap is related to ZFS snaps regarding pre and post job . Zfs send replicates the whole filesystem with all files - the ESXi snap is only one of the files.