At this years vForum in Sydney, I presented a TechTalk on VMware View 5.1 Desktop Deployment Solutions.
Below is the link to the recording, appologies the audio is not great as the TechTalk was done in the vForum lounge.
Josh Odgers – vForum 2012 TechTalk – VMware View 5.1 Desktop Deployment Solutions
As the video is not very clear I have provided a copy of the presentation below.
Problem Statement
What is the best way to keep time synchronized within virtual machine guest operating systems?
Assumptions
1. ESXi hosts are using an accurate and reliable NTP server
2. A level of CPU overcommitment exists in the vSphere cluster
Motivation
1. Prevent the unlikely but possible event of CPU over commitment introducing time drift into guest operating systems
Architectural Decision
Do not use VMware Tools for Time Synchronization Source for Virtual Machines and Guest operating systems need to be configured to use an NTP server
Justification
1. Excessive overcommitment can cause timekeeping drift at rates that are uncorrectable by time synchronization utilities
2. This ensures time within virtual machines is not impacted by time drift in the event of CPU overcommitment
3. Ensure time will be consistent and provided by a central source for all virtual machines
4. NTP is a industry standard method of maintaining accurate time
5. Simplifies the process of maintaining time
6. Aviods the potential issue where Time runs too fast in a Windows virtual machine when the Multimedia Timer interface is usedSee VMware KB 1005953
Implications
1. Any/all templates need to be configured to use an NTP server within the guest operating system
2. All existing servers will need to be updated to use an NTP server within the guest operating system if they currently rely on the hypervisor (VMware Tools) for time
Alternatives
1. Use VMware Tools for time synchronization
Problem Statement
What is the most suitable network failover detection policy to be used on the vSwitch or dvSwitch NIC team/s in an environment which uses IP storage and has only 2 physical NICs per vSwitch or dvSwitch?
Assumptions
1. vSphere 5.0 or greater
2. Storage is presented to the ESXi hosts is NFS via Multi Switch Link Aggregation
3. A maximum of 2 physical NICs exist per dvSwitch
4. Physical Switches support “Link state tracking”
Motivation
1. Ensure a reliable network failover detection solution
2. Ensure Multi switch link aggregation can be used for IP storage
Architectural Decision
Enable “Link state tracking” on the physical switches and Use “Link Status”
Justification
1. To work properly, Beacon Probing requires at least 3 NICs for “triangulation” otherwise a failed link cannot be determined.
2.“Link state tracking” can be enabled on the physical switch to report upstream network failures where an “edge” & “core” network topology is used, therefore preventing the link status from being OK when traffic cannot reach the destination due to an upstream failure
3. Beacon Probing and the “route based on IP hash” network load balancing option is not compatible which prevents a single VMKernel being able to use multiple interfaces for IP storage traffic
Implications
1. Link state tracking needs to be supported and enabled on the physical switches
Alternatives
1. Use “Beacon Probing”