Managing and Utilizing VMware Snapshots

A snapshot is a "moment in time." It can also be a "restore point." Using snapshots, we can roll back to the moment that the snapshot was taken, effectively going back before any changes were made. In this white paper, discover ways to use VMware Snapshots responsibly, issues that could arise from misuse, and how to address problems resulting from misuse, or from common issues even with proper use.

Using snapshots in a vSphere environment is deceptively easy, and there are many problems that can arise from nonchalantly utilizing them.

A snapshot is a "moment in time." It could also be thought of as a "restore point." However, you want to describe it, a snapshot is a safe rollback point so that if there are any issues, we can roll back to the moment in time that the snapshot was initially taken, effectively going back before the change was made.

Care must be taken not just when taking snapshots but in managing snapshots. This white paper outlines ways to use snapshots responsibly, issues that could arise from misuse, and how to address problems resulting from misuse, or from common issues even with proper use.

There are two main problems that people encounter with snapshots: the snapshot goes unchecked, grows and, ultimately, takes up all free space in the datastore, causing the virtual machine (VM) to crash (as well as any other VMs with snapshots on the same datastore). The second problem is a misunderstanding of the buttons inside the snapshot manager, leading people to accidentally roll back too far in time.

We will address these problems in detail, but first let's look at the virtual machine files created when a snapshot is taken.

.vmsd - This file is always part of a virtual machine regardless of whether a snapshot is present. This file describes the snapshots.

.vmsn - This file contains all of the memory that was in the virtual machine at the time the snapshot was taken.

delta.v mdk - This file is a change file, or redo log. It logs all ongoing changes to the virtual machine.

These changes are recorded sequentially, meaning the file starts empty, but as changes get written to the disk, this file grows. The flat.vmdk file is no longer locked and also no longer written to while the snapshot is present. All changes get written to this file.

0001.v mdk - This file (and others similarly named) is a text file linking the delta back to the original flat.vmdk file.

flat.vm dk - This is the preallocated virtual disk file. It is sometimes referred to as a monolithic file, meaning it is the size of your configured virtual disk (unless thin-provisioned).

As time goes on, the delta file will grow. Left unchecked, it can consume all free space on the datastore, eventually crashing if there is no more space. If this situation occurs, there are some options: Commit all changes to the virtual machine and consolidate the snapshots, or move the virtual machine to a different datastore with more available space. If you manually delete the snapshot files from the datastore, your virtual machine will have lost all changes since the snapshot was taken.

If you take a snapshot when an existing snapshot is present, a new series of files will be created (a new delta, text file, and memory snapshot file). The old delta will no longer be modified, and all ongoing changes now get logged in the new delta. The more snapshots there are, the more space is taken up. If there are many snapshots, as a result of misusing snapshots as backups, for example, then a lot of space could be consumed by these snapshots and committing the changes from all of these snapshots may be problematic. If we have taken multiple snapshots, say one each week, and each one is several GB in size, it can take several hours to potentially days to consolidate these snapshots. During the consolidation, space in the datastore could run out, and the VM could still crash. One option would be to consolidate, or commit, one snapshot at a time. Another option would be to simply try to clone this VM to a new virtual machine. The snapshot you are currently running on will be copied to the brand new virtual machine, and the new VM will not include any of the snapshots. Once this is done, the old virtual machine can be destroyed.

Go To

When you right-click a virtual machine and select Snapshot ! Snapshot Manager, you are faced with a deceptively simple interface. The hierarchy of snapshots is listed with a description box to the right, and three seemingly straightforward buttons at the bottom: Go To, Delete, and Delete All. These buttons can be misleading. First, let's explore the Go To button with the following example (Figure 1).

View the original article here

Understanding and Managing the Risk of Change

Every organization faces change. These changes include everything from regular, almost mundane modification to large-scale deployments of new IT services. Regardless of the scale of the change, all changes have one thing in common: risk. This white paper discusses how ITIL? Change Management mitigates risk to ensure architectural integrity and enterprise focus, while discussing the tangible return on investment (ROI) and intangible value on investment (VOI) of effective Change Management.

Change Management involves understanding and controlling the exposure to hazards such that overall risk to the business is handled in an efficient and effective manner. For example, if an organization were deploying a new desktop operating system across the enterprise, an effective Change Management process would understand the risks involved, assess the impact, and coordinate the change so impact to the business was minimized. Therefore, the intent of Change Management is to act as an enabler that provides a mechanism by which the business can quickly adapt and respond to changing conditions, without the negative consequences that are often associated with hasty action.

Change Management supports business adaptation in several ways. First, effective Change Management offers a standardized method that efficiently evaluates the potential positive and negative aspects of change, and allows for the prompt handling of all change-related activities. Second, Change Management ensures that all changes are recorded, evaluated, properly planned, and accounted for, such that the organization has an ongoing living history of change-related activities. Finally, Change Management minimizes the disruptions often associated with change at all levels.

A formal Change Management process is described by ITIL? v3. This process includes steps that ensure that changes are formally described, adequately reviewed for their impact on the business, assessed, and coordinated in-line with other changes and ongoing business activities. Even the simplest changes entail risk. For example, even a regular update to a desktop operating system, if not properly assessed and coordinated, can result in users being unable to use desktop applications to complete the work of the business, resulting in unanticipated downtime and significant business impact. The ITIL Change Management best practices provide a mechanism by which organizations can control the risks associated with change. The risk of change often avails itself in five ways.

The risk of unauthorized and properly assessed changes
The risk of unplanned outages
The risk of a low change success rate
The risk of high numbers of emergency changes
The risk of significant project delays

The ITIL Change Management best practices propose that to address these five risks, seven questions must be answered about every change. These seven questions are:

Who raised the change?
What is the reason for the change?
What is the return required from the change?
What are the risks involved in the change?
What resources are required to deliver the change?
Who is responsible for the build, test, and implementation of the change?
What is the relationship between this change and other changes?

How do these questions reduce risk? How does knowing "who raised the change" affect my risk? By following a standardized process that answers these seven questions for every change, organizations regularly reduce the numerous risks associated with change.

For example, let's consider a change that many organizations frequently face; an update to a set of firewall rules driven by an updated security policy. Using the seven questions, we might arrive at the following answers.

Who raised the change? This identifies both the business and IT sponsors of the change.
What is the reason for the change? Firewall rules are being updated to match recent security policy changes.
What is the return required from the change? The policy changes were specific to a new business partner, so the return expected is that internet traffic from this new business partner will be allowed through the firewall, which facilitates new business transactions at an estimated daily value of $25,000.
What are the risks involved in the change? Firewall rules could be incorrectly set, resulting in malicious traffic being allowed into the enterprise, and/or resulting in an inability to accept traffic from the new business partner.
What resources are required to deliver the change? This identifies the specific tools and equipment used to deploy the change, as well as the target configuration items for the change.
Who is responsible for the build, test, and implementation of the change? This question identifies the people responsible for ensuring the change is correctly built, tested, and implemented as intended.
What is the relationship between this change and other changes? Are any other mutually exclusive changes occurring at or near the same time as that proposed for this change? Is there any known interaction between this change and any other changes?

View the original article here