In a virtual infrastructure, network time synchronization is critical to keep servers on the same schedule as the services they rely on. For VMware ESXi hosts, you can implement Network Time Protocol (NTP) synchronization using the vSphere Client.
There are many reasons you should synchronize time for ESXi hosts. If they are integrated with Active Directory, for instance, you need time to be properly synchronized. You also need the time to be consistent when creating and resuming snapshots, because snapshots take point-in-time images of the server state. Luckily, setting up network time synchronization with the vSphere Client is pretty easy.
VMware network time synchronization: A walkthrough
To configure NTP synchronization, select the host, and on the Configuration tab, select Time Configuration under Software. You'll now see the existing time synchronization status on that host. Next, click Properties. This selection shows the Time Configuration screen, where you can see the current time on the host. Make sure it's not too different from the actual time, because a host that's more than 1,000 seconds is considered "insane" and won't synchronize.
After you set the local time on the host, select NTP Client Enabled. This activates NTP time synchronization for your host. Reboot the server, then go to Options to make sure NTP has been enabled. This gives you access to the NTP Startup Policy, where you should select "Start and stop with host."
You're not done with network time synchronization yet, though. Now, you need to choose NTP servers that your VMware ESXi hosts should synchronize with. Click NTP Settings and you'll see the current list of NTP servers. By default, it's empty. Click Add to add the name or address of the NTP server you'd like to use. The interface prompts you for an address, but you can enter a name that can be resolved by DNS as well.
If you're not sure which NTP server to use for VMware network time synchronization, the Internet NTP servers in pool.ntp.org work well. You only need to choose one server from this group to add to the NTP servers list. If you want to synchronize with an internal or proprietary NTP server, however, you should specify at least two NTP servers.
At this point, make sure the option to restart the NTP server is selected. Click OK three times to save and apply your changes. From the Configuration screen on your ESXi host, you should now see that the NTP Client is running, and it will also show the list of current NTP servers your host is using.
With your ESXi hosts synchronized to the correct time, all the services and events that depend on time will function properly. More importantly, you won't waste any more time because of misconfigured network time.
31 Jul 2013
Virtual machine and VMware snapshot
Virtual machine snapshots can be a valuable tool to IT administrators. They provide restore points, which can minimize the damage incurred during patch or upgrade malfunction, for example. But using snapshots without understanding what they are and how they work can introduce disk space issues or malfunctioning virtual machines. Follow the links in this guide to learn how to use and benefit from snapshots.
Snapshot basics
A disk snapshot is a copy of the virtual machine (VM) disk file recorded at a specific time, much like a Windows restore point.The snapshot preserves the original VM disk file by disabling writes to the original disk file – all new writes are made to the snapshot version of the VM.
Snapshots are never larger than the original Virtual Machine Disk Format (VMDK) file. If you have a previous snapshot on a virtual machine and you create a new snapshot, the older snapshot becomes read-only. If you are satisfied with the changes (upgrades, patches) applied to the virtual machine, you can delete, or commit, the snapshots to the original VMDK file. After committing snapshots, you will no longer be able to revert a VM back to a point beyond what's encompassed in the VMDK file.
There are multiple types of snapshot files, and understanding all of them will help you understand the dynamics behind what goes into creating a snapshot.
Creating snapshots with different virtualization platforms
There are two ways to create a snapshot in VMware ESX: you can use the snapshot manager on the VMware Infrastructure Client (VI Client), or you can use the vmware-cmd command line utility.
Creating snapshots with Microsoft Hyper-V is an option from the Hyper-V management console, by right-clicking on the VM you'd like to create a snapshot of. Backing up Hyper-V virtual machines with snapshots, however, isn't as simple as a VSS-aware backup requires the use of a snapshot to complete its work. VMs that have two or more snapshots in place will fail if you try to run them after backing them up.
While no current Linux distro uses the open source Citrix XenServer stack to create a virtual machine snapshot to date, you can still create snapshots by using standard Linux tools.
Snapshot storage
Using writeable snapshots can help to optimize storage in a VMware environment, as they eliminate the need to make extra copies of data for test and development work. Simply snapshot the production VM and mount it to the test server -- no additional storage is needed until changes are made to the test snapshot.
Snapshot data can be stored in a virtual disk file or in a Storage-area Network logical unit number. If the VM uses virtual disk files, the SAN must support snapshots for the file system (VMFS or NAS). If not, VMware Consolidated Backup (VCB) snapshots must be used.
Because snapshots are software-based, they can have scalability and performance issues. The VCB version uses a dedicated server to connect to the snapshot and back the contents up to tape, which impacts the production disk subsystems. Storage array snapshots, on the other hand, have little impact on performance.
Storage snapshots are not, however, integrated with VMware ESX Server by default. To effectively use storage snapshots, VM-level file consistency is important. When the VM issues a write to disk, it passes through the virtualization layer before it gets to the storage array. For this reason hot snapshots present problems, but both warm and cold snapshots introduce different amounts of downtime.
Another issue occurs when VMs containing snapshots are moved via VMotion to a destination host that can't access the same storage network where the snapshot files are located. In this case, the VM will crash when the VMotion migration is complete, so be careful when changing snapshot file locations from the default in order to save space on the VM's disk. You also won't be able to use VMotion, HA or DRS if your VM is on shared storage and you specify local storage for the snapshots.
Deleting snapshots
When deleting multiple snapshots, there must be ample disk space on the VMFS; best practices recommend at least 25% of the VM's total disk size. This is because all of the snapshots grow in succession before they are deleted. When snapshots are deleted, they are first merged into the previous snapshot and then into the original disk file before they are actually deleted. If the extra disk space is not available to delete snapshots in the usual manner, an option is to delete snapshots one by one. But this method can be tedious.
IT admins who forget to delete snapshots before moving a VM from Workstation to ESX or VMware Server may encounter a problem, as VMware Server has no solution for deleting multiple snapshots (it can only delete the most recent snapshot). It's possible to remove the forgotten snapshots by using a trial version of Workstation to clone a VHD or collapse a snapshot chain back to one VHD file. If using Workstation is not an option, however, contributor Andrew Kutz has written a 20-step how-to that offers a workaround.
During the deletion process, VirtualCenter may report a timed-out message. VirtualCenter, however, has an automatic 15 minute timeout, so for the most part this message can be ignored. To manually check the status of a snapshot deletion, check the data store browser in the VI Client. When the delta file disappears, the snapshots have been deleted.
If you encounter an error and the delta files are still there, there are a few processes you can try. First, you can create a new snapshot and then delete all snapshots after the new one has been created. If that doesn't work, you can clone the VM or the VM's disk file.
Snapshot basics
A disk snapshot is a copy of the virtual machine (VM) disk file recorded at a specific time, much like a Windows restore point.The snapshot preserves the original VM disk file by disabling writes to the original disk file – all new writes are made to the snapshot version of the VM.
Snapshots are never larger than the original Virtual Machine Disk Format (VMDK) file. If you have a previous snapshot on a virtual machine and you create a new snapshot, the older snapshot becomes read-only. If you are satisfied with the changes (upgrades, patches) applied to the virtual machine, you can delete, or commit, the snapshots to the original VMDK file. After committing snapshots, you will no longer be able to revert a VM back to a point beyond what's encompassed in the VMDK file.
There are multiple types of snapshot files, and understanding all of them will help you understand the dynamics behind what goes into creating a snapshot.
Creating snapshots with different virtualization platforms
There are two ways to create a snapshot in VMware ESX: you can use the snapshot manager on the VMware Infrastructure Client (VI Client), or you can use the vmware-cmd command line utility.
Creating snapshots with Microsoft Hyper-V is an option from the Hyper-V management console, by right-clicking on the VM you'd like to create a snapshot of. Backing up Hyper-V virtual machines with snapshots, however, isn't as simple as a VSS-aware backup requires the use of a snapshot to complete its work. VMs that have two or more snapshots in place will fail if you try to run them after backing them up.
While no current Linux distro uses the open source Citrix XenServer stack to create a virtual machine snapshot to date, you can still create snapshots by using standard Linux tools.
Snapshot storage
Using writeable snapshots can help to optimize storage in a VMware environment, as they eliminate the need to make extra copies of data for test and development work. Simply snapshot the production VM and mount it to the test server -- no additional storage is needed until changes are made to the test snapshot.
Snapshot data can be stored in a virtual disk file or in a Storage-area Network logical unit number. If the VM uses virtual disk files, the SAN must support snapshots for the file system (VMFS or NAS). If not, VMware Consolidated Backup (VCB) snapshots must be used.
Because snapshots are software-based, they can have scalability and performance issues. The VCB version uses a dedicated server to connect to the snapshot and back the contents up to tape, which impacts the production disk subsystems. Storage array snapshots, on the other hand, have little impact on performance.
Storage snapshots are not, however, integrated with VMware ESX Server by default. To effectively use storage snapshots, VM-level file consistency is important. When the VM issues a write to disk, it passes through the virtualization layer before it gets to the storage array. For this reason hot snapshots present problems, but both warm and cold snapshots introduce different amounts of downtime.
Another issue occurs when VMs containing snapshots are moved via VMotion to a destination host that can't access the same storage network where the snapshot files are located. In this case, the VM will crash when the VMotion migration is complete, so be careful when changing snapshot file locations from the default in order to save space on the VM's disk. You also won't be able to use VMotion, HA or DRS if your VM is on shared storage and you specify local storage for the snapshots.
Deleting snapshots
When deleting multiple snapshots, there must be ample disk space on the VMFS; best practices recommend at least 25% of the VM's total disk size. This is because all of the snapshots grow in succession before they are deleted. When snapshots are deleted, they are first merged into the previous snapshot and then into the original disk file before they are actually deleted. If the extra disk space is not available to delete snapshots in the usual manner, an option is to delete snapshots one by one. But this method can be tedious.
IT admins who forget to delete snapshots before moving a VM from Workstation to ESX or VMware Server may encounter a problem, as VMware Server has no solution for deleting multiple snapshots (it can only delete the most recent snapshot). It's possible to remove the forgotten snapshots by using a trial version of Workstation to clone a VHD or collapse a snapshot chain back to one VHD file. If using Workstation is not an option, however, contributor Andrew Kutz has written a 20-step how-to that offers a workaround.
During the deletion process, VirtualCenter may report a timed-out message. VirtualCenter, however, has an automatic 15 minute timeout, so for the most part this message can be ignored. To manually check the status of a snapshot deletion, check the data store browser in the VI Client. When the delta file disappears, the snapshots have been deleted.
If you encounter an error and the delta files are still there, there are a few processes you can try. First, you can create a new snapshot and then delete all snapshots after the new one has been created. If that doesn't work, you can clone the VM or the VM's disk file.
VMware vLockstep
VMware vLockstep is technology that captures inputs and events that occur on a primary virtual machine (VM) and sends them to a secondary VM. VMware vLockstep is the technology that supports VMware's Fault Tolerance component of VMware vSphere.
VMware's Fault Tolerance works by keeping a primary virtual machine (VM) and a secondary VM in perfect sync. VMware vLockstep captures inputs and events that occur on the primary VM and sends them to the secondary VM. Because the secondary VM is always in sync with the primary VM, it can take over in the event of a primary VM failure without interruption and provide fault tolerant protection. When the secondary VM takes over, VMware FT automatically creates a new secondary VM. The name lockstep comes from a style of military march that emphasizes synchronous movement.
VMware vLockstep should be set up on a dedicated network interface card (NIC) with at least 1 GB. Although all data is synchronized between the paired VMs over a server backbone network, outputs are suppressed in the secondary VM. For instance, VMware FT ensures only the primary VM initiates write operations to storage. Certain actions and instructions that are irrelevant for the secondary VM are not synched via vLockstep, reducing the burden on disk space and processors.
For vLockstep to reproduce CPU instructions from the primary VM on the secondary VM, the Intel or AMD processors used must have the appropriate performance counter architecture and virtualization hardware assists. Both hosts supporting the VM pair must be in the same processor family.
In versions of vSphere earlier than v.5, the vLockstep VM pairs were marked "disabled" in VMware Distributed Resource Scheduler (DRS), enabling higher compatibility between VMware FT and DRS.
VMware's Fault Tolerance works by keeping a primary virtual machine (VM) and a secondary VM in perfect sync. VMware vLockstep captures inputs and events that occur on the primary VM and sends them to the secondary VM. Because the secondary VM is always in sync with the primary VM, it can take over in the event of a primary VM failure without interruption and provide fault tolerant protection. When the secondary VM takes over, VMware FT automatically creates a new secondary VM. The name lockstep comes from a style of military march that emphasizes synchronous movement.
VMware vLockstep should be set up on a dedicated network interface card (NIC) with at least 1 GB. Although all data is synchronized between the paired VMs over a server backbone network, outputs are suppressed in the secondary VM. For instance, VMware FT ensures only the primary VM initiates write operations to storage. Certain actions and instructions that are irrelevant for the secondary VM are not synched via vLockstep, reducing the burden on disk space and processors.
For vLockstep to reproduce CPU instructions from the primary VM on the secondary VM, the Intel or AMD processors used must have the appropriate performance counter architecture and virtualization hardware assists. Both hosts supporting the VM pair must be in the same processor family.
In versions of vSphere earlier than v.5, the vLockstep VM pairs were marked "disabled" in VMware Distributed Resource Scheduler (DRS), enabling higher compatibility between VMware FT and DRS.
30 Jul 2013
VMware HA (High Availability)
VMware HA (High Availability) is a utility that eliminates the need for dedicated standby hardware and software in a virtualized environment. The utility is part of a virtualization suite called VMware Infrastructure 3. In IT (information technology), the term high availability refers to a system or component that is continuously operational for long periods.
Key features of VMware HA include:
Proactive monitoring of all physical servers and virtual machines
Automatic detection of server failure
Rapid restart of virtual machines affected by server failure
Optimal placement of virtual machines after server failure
Scalable availability up to 32 nodes across multiple servers
Key features of VMware HA include:
Proactive monitoring of all physical servers and virtual machines
Automatic detection of server failure
Rapid restart of virtual machines affected by server failure
Optimal placement of virtual machines after server failure
Scalable availability up to 32 nodes across multiple servers
VMware Converter
VMware Converter is a utility that facilitates the creation of VMware virtual machines from physical systems or virtual machines associated with third-party vendors. The utility also enables migration of virtual machines between VMware platforms from a centralized management console.
With VMware Converter 3, the latest version of the utility, multiple simultaneous conversions are possible without source server downtime or OS (operating system) on the source machine. Conversion speed is enhanced by sector-based copying. The complexity of the process is minimized by user-friendly wizards. If desired, conversions and migrations can be controlled from remote locations.
VMware converter 3 is designed for use with physical machines running 64-bit Windows XP or Windows 2003, WinNT SP4+ or Windows 2000. Supported source third-party images include Microsoft Virtual Server, Microsoft Virtual PC, Symantec Backup Exec System Recovery, Norton Ghost 10 and Norton Save & Restore. Supported VMware virtual machines include VMware Workstation, VMware GSX Server, VMware Player, VMware Server and VMware ESX Server.
With VMware Converter 3, the latest version of the utility, multiple simultaneous conversions are possible without source server downtime or OS (operating system) on the source machine. Conversion speed is enhanced by sector-based copying. The complexity of the process is minimized by user-friendly wizards. If desired, conversions and migrations can be controlled from remote locations.
VMware converter 3 is designed for use with physical machines running 64-bit Windows XP or Windows 2003, WinNT SP4+ or Windows 2000. Supported source third-party images include Microsoft Virtual Server, Microsoft Virtual PC, Symantec Backup Exec System Recovery, Norton Ghost 10 and Norton Save & Restore. Supported VMware virtual machines include VMware Workstation, VMware GSX Server, VMware Player, VMware Server and VMware ESX Server.
Starting out with VMware vSphere Hypervisor 5.1
When you're starting a small-scale virtualization project with a few hosts, VMware vSphere Hypervisor 5.1 is a smart free option with low hardware requirements. Installation is a straightforward process that starts with ESXi and then the vSphere Client to manage ESXi.
The vSphere Hypervisor virtualization platform is based on the same hypervisor ESXi as VMware's enterprise-class vSphere and vCloud virtualization tools.
Hardware requirements
Before installing ESXi, make sure that you have at least one server on which to install vSphere Hypervisor. To set up vSphere Hypervisor 5.1 for a real virtualization environment, you'll also need:
- A large disk or connection to a storage area network for storing the VM disk image files.
- At least two gigabit network interface cards.
- Lots of RAM. The exact amount depends on how many VMs you want to install, but make sure that you have at least 8 GB of RAM available at the outset.
- A modern server-grade CPU that has virtualization extensions (these are found on almost any recent server-grade CPU).
You can test out vSphere Hypervisor with less infrastructure. For trial purposes, the minimal hardware requirements are 2 GB of RAM and 40 GB of disk space. Of course, you won't be able to run large Windows VMs on top of that.
Installing VMware ESXi
VMware offers vSphere Hypervisor as three software packages to download from the VMware website. Burn the ESXi 5.1 ISO file to a CD and keep the other two software files on your workstation. You'll need them later.
VMware ESXi 5.1 installation.
Install ESXi on a server by inserting the ESXi CD into the server disk drive and booting your server from the optical drive. The ESXi boot menu will show. From this boot menu, select the ESXi standard installer.
ESXi 5.1 Standard Installer.
It will take a while for the ESXi installation program to load -- up to a couple of minutes. Once all the required software has loaded, the Welcome to the VMware ESXi Installation screen will appear.
Welcome to the VMware ESXi Installation.
To acknowledge the license agreement, press the F11 key. You'll now see an overview of all the storage devices that the installation program found. If any remote storage was attached, it will list local and remote storage (see Figure 4). Without a SAN connected, just select the local storage device.
ESXi 5.1 storage options.
Specify which keyboard layout you prefer, then set the password for the ESXi administrator user. The name of this user is "root." Note this password; you'll need it to manage the host machine later. With the F11 key, confirm again that you want to start the installation, then wait a few minutes as a small disk image is copied over to the server hard drive. Once the VMware ESXi installation completes, the server will reboot and load ESXi.
After booting completely, the ESXi server shows which IP address it is using. Note this address so you can use it to manage the ESXi host.
Installing vSphere Client
With the ESXi server installed, you need a Windows client on which to install the vSphere Client management program. On the Windows client, start a browser and connect to the ESXi server's IP address. Ignore the certificate warnings that will display when you make this connection, and select "Download vSphere Client."
Logging into vSphere Hypervisor
The vSphere client installation package will download from the VMware website. Run it to start the installation, and keep all default settings. Once installation completes, a vSphere Client icon will appear on your computer desktop. This is where you will access the vSphere Client login screen. To log in, enter the IP address of the VMware ESXi host, the username root and the password that you specified while installing ESXi (see Figure 5).
You now most likely will see a certificate warning, which, again, you can ignore. Connect to the ESXi host, then assign a license to it in the VMware Evaluation Notice window. License keys are available on VMware's website. This is the final step of vSphere Hypervisor installation.
The vSphere Hypervisor virtualization platform is based on the same hypervisor ESXi as VMware's enterprise-class vSphere and vCloud virtualization tools.
Hardware requirements
Before installing ESXi, make sure that you have at least one server on which to install vSphere Hypervisor. To set up vSphere Hypervisor 5.1 for a real virtualization environment, you'll also need:
- A large disk or connection to a storage area network for storing the VM disk image files.
- At least two gigabit network interface cards.
- Lots of RAM. The exact amount depends on how many VMs you want to install, but make sure that you have at least 8 GB of RAM available at the outset.
- A modern server-grade CPU that has virtualization extensions (these are found on almost any recent server-grade CPU).
You can test out vSphere Hypervisor with less infrastructure. For trial purposes, the minimal hardware requirements are 2 GB of RAM and 40 GB of disk space. Of course, you won't be able to run large Windows VMs on top of that.
Installing VMware ESXi
VMware offers vSphere Hypervisor as three software packages to download from the VMware website. Burn the ESXi 5.1 ISO file to a CD and keep the other two software files on your workstation. You'll need them later.
VMware ESXi 5.1 installation.
Install ESXi on a server by inserting the ESXi CD into the server disk drive and booting your server from the optical drive. The ESXi boot menu will show. From this boot menu, select the ESXi standard installer.
ESXi 5.1 Standard Installer.
It will take a while for the ESXi installation program to load -- up to a couple of minutes. Once all the required software has loaded, the Welcome to the VMware ESXi Installation screen will appear.
Welcome to the VMware ESXi Installation.
To acknowledge the license agreement, press the F11 key. You'll now see an overview of all the storage devices that the installation program found. If any remote storage was attached, it will list local and remote storage (see Figure 4). Without a SAN connected, just select the local storage device.
ESXi 5.1 storage options.
Specify which keyboard layout you prefer, then set the password for the ESXi administrator user. The name of this user is "root." Note this password; you'll need it to manage the host machine later. With the F11 key, confirm again that you want to start the installation, then wait a few minutes as a small disk image is copied over to the server hard drive. Once the VMware ESXi installation completes, the server will reboot and load ESXi.
After booting completely, the ESXi server shows which IP address it is using. Note this address so you can use it to manage the ESXi host.
Installing vSphere Client
With the ESXi server installed, you need a Windows client on which to install the vSphere Client management program. On the Windows client, start a browser and connect to the ESXi server's IP address. Ignore the certificate warnings that will display when you make this connection, and select "Download vSphere Client."
Logging into vSphere Hypervisor
The vSphere client installation package will download from the VMware website. Run it to start the installation, and keep all default settings. Once installation completes, a vSphere Client icon will appear on your computer desktop. This is where you will access the vSphere Client login screen. To log in, enter the IP address of the VMware ESXi host, the username root and the password that you specified while installing ESXi (see Figure 5).
You now most likely will see a certificate warning, which, again, you can ignore. Connect to the ESXi host, then assign a license to it in the VMware Evaluation Notice window. License keys are available on VMware's website. This is the final step of vSphere Hypervisor installation.
Subscribe to:
Posts (Atom)