2016-12-13, 10:10:51
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.
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:
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
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.
Quote:> 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:
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