In general terms, how does Vimalin work?

[shazoom]

I've looked into how one might perform live backups with VMware but my search has led me to believe that this isn't supported with Fusion, at least officially. As far as I can see it takes a few steps to do a live backup with VMware:

1. Snapshot the VM with a special option to quiesce IO (ensure all IO is flushed out) on the root disk image.
2. Copy the whole VM and the root disk, leaving out the snapshot
3. Tidy up, consolidating the snapshot

This may be wrong; a lot of what I read was a bit vague.

My first question is: I got the impression that quiesced snapshots weren't supported in Fusion; this seems like the biggest problem.

My second question is: what API are you using to interface with VMware.

[wila]

Hello Shazoom,

Thanks for the questions.

You are correct that there is no quiesce IO option in VMware Fusion, I specifically looked for that and there's no such option when making snapshots. You are also correct in assuming that Vimalin uses VMware Fusion's snapshots for providing backups from live virtual machines.

Even while there is no additional quiesce option, it is however just as safe as rolling back a snapshot or using suspend is with VMware Fusion right now.

The backup process does not just save the disk file from before the snapshot, it also saves all the snapshot data that contains the memory. So as long as you restore the backup on the same host (or a host with the same processor) you have the same reliability as with normal snapshots. On restoring you get back to the state of suspend, eg. it looks as if the VM was suspended and you can continue from there.

If you restore to a host with a different processor, then in the worst case scenario you would have a crash consistent backup, eg. comparable to as if you pulled the power cord on a running machine.
While that is not 100% ideal, the loss of data is still minimal unless you are running a high transaction database on the VM and even then there's a fair chance that the transaction logs will be able to minimize the damage.
Most people would run such a VM on VMware vSphere and not VMware Fusion.
There's already a feature request on adding an option to automatically shutdown/backup/restore for such type of servers that I will look into once we get past the beta phase.

For your second question. The application depends on vmrun for its API to interface with VMware Fusion.

Hope this helps a bit, I'll see if I can get a better answer from VMware on the quiescence part.
--
Wil

[shazoom]

Hi Wil,

thanks for explaining how Vimalin works. I've written some of my own backup scripts which restart suspended VMs, shutdown my application (actually a simulation which does lots of DB stuff) and then shutdown the VMs before backup. I suspect with a bit more research I could add this method of backups to them but I'm not sure it's worth my time. The mention you made of how the memory file is saved too and its implications is enlightening.

I think your program is very much needed for most Fusion users—like another of your correspondents it won't be vital for me—and will be very glad to buy it after release. I find it astounding how little effort VMware have put into ensuring their users are backing up their VM correctly; the information is out there and users coming from enterprise won't need educating but everyone else will, I expect, eventually have a nasty surprise.

Anyway, thanks again.

[wila]

Hello,

Got an answer already.

The short answer is that saving full snapshot data like I am doing right now at the moment is the only correct way to preserve all state. But I got more tips from a couple of VMware's best.

> We don't expose the option to have a disk-only snapshot created for a powered on VM in any of the hosted products (we always save guest memory as well). This means we never create crash-consistent disk-only snapshots, nor file system or application quiesced disk-only snapshots. Only the vSphere API exposes these options when creating a snapshot.
>
> [...] When we're saving guest memory there is no point is asking the guest to flush out its buffer cache.

Because Vimalin saves memory state as well, the link between guest and host is a bit stronger as you would want in such a case.
You can however disable certain guest features that make restoring the guest -with memory state- on other hosts more reliable.

Again a quote:

To help mitigate the risk associated with restoring full snapshots on another system (or even another Fusion version or another macOS version), it might be worth recommending that the customer disable certain VM features if the virtual machine doesn't require them. The most relevant options are 3D graphics support and two advanced virtual CPU options: virtualized performance counters (vPMC) and virtualized hardware virtualization (vHV) support. Each of those options has the potential to expose some aspects of the host's hardware through to the virtual machine in a way that can make migration (a.k.a. "checkpoint compatibility") a headache. We really put an extraordinary amount of effort towards checkpoint compatibility across platforms and products (forwards *and* backwards compatibility, across many product versions!), but it can still sometimes be thwarted by the wrong combination of host conditions. For example, Apple issued a firmware update for some models of Mac about 18 months ago which caused their system to use one additional CPU performance counter on the host, which left one fewer performance counter available for Fusion, which in turn made it impossible for users to restore checkpoints of VMs with vPMC enabled taken before that update...

Note that I got those quotes on a personal title, it isn't in the doc's and you can't make any claims based on what has been shared.
It is however good to know and the extra tip on not using virtualized performance counters and vHV support in the guest will make it into Vimalin (think warnings).

As for not needing Vimalin, because you have your own scripts.
No worries, that's fine, just happy to hear you have a solution

The goal for Vimalin is to be able to give better backup possibilities to people who can't script -or do not want to script- their own backup solution. Questions like yours help me to get better answers for us all and also help to improve my product over time.

--
Wil