Next, you customize the new VM's guest OS. You can customize the VM's identity
(i.e., computer name, owner name, organization, new security ID), server license
information, time zone, and properties of each network interface. After completing
the import task creation, you can repeat the VMware Converter process for all
the servers you need to convert.
Now, you're ready to power up the newly created VM and test the applications.
You can test a sample restore from a previous backup of the source physical
server to the appropriate VM. If the test is successful, you can move the ESX
Server system to the desired recovery location. As far as maintenance is concerned,
you should always ensure that the OS and application versions and patches between
the source servers and corresponding VMs in the recovery system are always in
synch. I recommend periodically testing sample restores.
Virtual-to-Virtual Architecture
In the virtual-to-virtual architecture, you'll be running both your production
and recovery applications in VMs. Therefore, initially you'll need to convert
the source servers to VMs, and subsequently both the source and recovery platforms
will be on ESX Server. The obvious benefit of this approach is a completely
virtualized infrastructure that boasts the increased flexibility and manageability.
To migrate VMs, you can simply copy the necessary configuration and virtual
disk files from the source to the target platform. You can apply either the
backup/ restore or host-based replication mechanism to this architecture. You
have a couple of choices for the backup/restore scenario.
Back up the VM as a physical server. You would use this method
for file-level backups of the data stored within the VM's disk image. The method
requires a backup agent to be installed on each VM. You should also ensure that
the backup operation performs application quiescing of the VM that's
being backed up if possible. Quiescing ensures that the application is in a
consistent state and doesn't lose any transactions in flight. This option has
two phases: a server-consolidation phase, in which your existing physical-source
servers are converted to VMs on ESX Server, and a preparatory phase for your
recovery targets.
You first need to convert existing physical source servers to VMs. To do so,
simply follow the aforementioned instructions for selecting the servers, installing
ESX Server, and performing source conversions to VMs. Then, set up the ESX Server
systems that you plan to use as recovery targets. After you use VMware Converter
to import existing VMs from your source to recovery ESX Server systems, install
the supported backup agent of your choice on each VM that will backed up (i.e.,
the source ESX servers). For a list of supported backup agents, check VMware's
"Backup Software Compatibility for ESX Server 3.x" document (http://www.vmware.com/pdf/vi3_backup_guide.pdf).
On the source side, configure your backup server and device (disk or tape).
To do so, follow these steps:
- Configure the backup server to use the backup device and install the appropriate
drivers and backup server software of choice.
- Ensure that networking is configured for access between the backup server
and VMs that will be backed up. If both the VM to be backed up and the backup
server are on the same ESX Server host, you should use a private virtual switch
to connect them.
- Schedule the backups and manage the backup media.
On the recovery side, install a backup agent on each VM on the recovery ESX
servers. Test a sample restore from the source VM to the appropriate VM on the
recovery ESX server. In the interest of maintenance, always make sure that the
OS and application versions and patches between the source and recovery VMs
are always in sync. Be sure to periodically test sample restores.
Back up the VM as a set of files. You would use this method for
image-level backups or backups of entire VMs. This method takes advantage of
VMs' encapsulation characteristics, providing the capability to back up the
entire VM, including the system configuration, applications, and data. You can
recover VMs in their entirety by performing a restore of the individual files.
ESX Server uses the VMware File System (VMFS) to store VMs. VMFS is a simple,
high-performance file system on physical SCSI disks and partitions that's capable
of storing large files, such as the virtual disk images for ESX Server VMs and
the memory images of suspended VMs.
In ESX Server 3.x, VMFS supports directories. Typically, there's one directory
for each VM on VMFS. This directory contains all the files that comprise the
VM. For a complete list of files that comprise a VM, see Table
3.
In this backup option, individual file recovery for each VM isn't possible.
To recover a single file, you need to restore the entire VM. The virtual disk
files could be larger than a gigabyte, which will probably limit your choice
of qualified backup software. Because of the potentially large size of the virtual
disk file, restore times will definitely be longer.
The backup image will contain the state of the VM at a particular time. It
won't include uncommitted data or memory state. Because this backup process
treats the virtual disk as a whole and isn't application-aware, the backups
created through this process are only file system–consistent, resulting
in a backup that's in a crash-consistent state. To avoid this situation, you
can either power down the VM or quiesce the application (if equipped) prior
to performing the backup. Alternatively, you can use the utilities in ESX Server
to perform your image-level. (See the Web-exclusive sidebar "A VMware-specific
Backup Option,"http://www.windowsitpro.com, InstantDoc ID 95596.)
Prev. page
1
[2]
3
next page 
