In any case, snapshots should be used only occasionally. Many vSphere admins use snapshots to keep their environment in a certain state after testing patches, etc. The main difference between this mode and the traditional dependent mode is that when you delete the snapshot or shut down the VM, all changes captured to the redo log are gone. In this mode, the VM creates a redo log that captures all the writes to the disk. If you change to this disk mode when you are deleting a snapshot of your VM, your data on that particular disk will remain intact if you start or stop the VM. You cannot go back in time like you could if you had traditional dependent mode configured. What happens when you delete the snapshot? All changes are preserved. This means that during snapshot operation, all changes are written directly to the disk. Independent persistent mode is when you create a snapshot, and you see no delta disk created. You can see and change the disk mode via the vSphere Web client (via vCenter Server).ĭisk modes via ESXi host client Independent persistent mode This is not the case for independent disks. When a snapshot is in use, this disk is included in the snapshot. This is the standard virtual disk configured out of the box. The disk modes act on each individual VMDK, not on a whole VM. To start with, you should know that those states only matter when you actually use snapshots and when a virtual machine snapshot is taken.
The default option is "dependent," but let's first explain the other options. Note that this configuration is done when you select VM > Edit settings and is on a "per-disk" basis, so you can have one disk that is dependent, while other disks are configured as independent persistent or non-persistent. The option lays in the Disk Mode section, where you can pick one of three different options for a VMDK. VMware ESXi has an option that can expand the possibilities for using a VM. So you not only penalize the VM itself because this one becomes slow, but you also penalize other VMs running on the same datastore, which might experience high IO reads and writes. During the time of a snapshot, some heavily used VMs can take a very long time for the commit phase and generate a large number of IOs. During this snapshot commit phase, there is a second snapshot file created, and this one stores the data that is written by the VM during the commit phase. When you delete or commit a snapshot, all data that have temporarily been written to the snapshot file are purged into the VMDK file. So the best thing to do is to avoid using snapshots if you can.
Many admins have been burned by relying on snapshots, even though we all know that snapshots have a very large impact on performance and availability. We all know that using snapshots is risky.
0 kommentar(er)
