Lesson of the day: Use vCenter Linked Mode with extreme caution. Make sure you understand the potential security implications as well as the vCenter Server outages that could occur if not careful!
What I learned:
- With vCenter Linked Mode, the search service queries AD for information about user permissions. As such, you must be logged in to a domain account in order to search all vCenter Server systems. If you log in using a local account, searches return results only for the local vCenter Server system, even if it is joined to other servers in a Linked Mode group. This comes as a surprise because if at least two linked vCenter Server instances have an identical local user account (i.e. same credentials), you can view everything that user has permissions to view in both linked vCenter Server instances. However, if you perform a search, you will only see results for the local vCenter Server instance the you logged in to.
- When adding a vCenter Server instance to a Linked Mode group, the user running the installer must be either a domain user with permission on all vCenter Server instances to be linked or provide credentials to a local administrator on the target vCenter Server instance in addition to all vCenter Server instances currently in the linked group. If this is not the case then you get the following error message:
The currently logged on user does not have sufficient privileges on the LDAP server <vCenter_Server_name> to be able to configure replication.
By default, the currently logged on user account needs to be a member of the local administrators group on the remote server. If you are using a local administrator account on this server then the same named account with the same password needs to exist on the remote server. This account also needs to be a members of the local administrators group on the remote server.
Alternatively, perform this installation using a domain account and ensure the account is a member of the local administrators group on the remote server. You can use a domain administrator account for this as normally domain administrators are automatically a member of a local administrators group.
- If you have vCenter Servers in linked mode and you log onto a vCenter Server instance with a local account that is not identical on each vCenter Server instance (i.e. either the the local user does not exist on all vCenter Server instances or the credentials are not consistent on all vCenter Server instances) and you attempt to isolate the vCenter Server instance (i.e. remove it from the linked group) the task will fail and stop the vCenter Server progress on the vCenter Server instance you are currently logged in to. Looking at the logs you will notice:
[2010-08-05 08:37:16 SEVERE] Operation “Isolate instance VMwareVCMSDS” failed: : Action: Prepare for Isolate Problem: Unable to reach a peer instance
This means the the credentials used did not work, poor error message in my book. In addition, you will notice above this error message that the vCenter Server process stopped:
[2010-08-05 08:37:16 INFO] Service ‘VMware VirtualCenter Management Webservices’ is shutdown
[2010-08-05 08:37:16 INFO] Service ‘VMware VirtualCenter Server’ is shutdownYou can force the isolation, but the force will only apply to the vCenter Server instance you are currently logged in to and will need to be performed on all other vCenter Server instances in the linked group. As such, the best practice would be to use a domain account that is known to exist and have permissions on all vCenter Server instances in the linked group.
- If a VMs swap file (i.e. .vswp) is not accessible to the destination host, VMotion must be able to create a swap file accessible to the destination host before migration can begin. As an example, this means if a VM is stored on a shared datastore, but the swap file is stored locally on an ESX host and the VM is migrated to a different ESX host, the swap file must and will be created on a datastore accessible to the destination ESX host depending on the configuration of the ESX host or else the migration will fail.
Clarifications I made:
- Student Manual: For DPM to work, the VMotion NIC on each host must support WOL.
Comments: This is important to keep in mind when architecting the network configuration of ESX hosts. In the case of on-board and expansion cards NICs, best practice is to NIC team mixing both. Ensure the expansion card NIC allocated for VMotion traffic supports WOL. - Instructors: DPM + Alarms will result in notifications when hosts are put into standby mode.
Comments: Given the default alarm definitions this is not true. A clear distinction is given between unavailable and standby ESX hosts. In addition, a default alert exists to notify when a host fails to come out of standby mode. - Instructors: HA works without vCenter Server.
Comments: While it is true that vCenter Server is only needed to initially configure HA and then HA can run independently, if vCenter Server and the five primary HA nodes go down HA will not work. - Instructors: A host can only be removed from a cluster if in maintenance mode.
Comments: The only way you should remove a host from a cluster is by putting it in maintenance mode. You could also disconnect and then remove the ESX host from vCenter Server and then re-add the ESX host to vCenter Server, but this can cause issue. For example, this approach will remove performance statistics, may corrupt vDS, and will move VMs out of folders. - Student Manual: Requirement of FT is that VMs must be provisioned with thick virtual disks.
Instructors: They actually need to be eager zero thick virtual disks
Comments: Actually this is not true to NAS!
Questions I raised:
- Does DPM and HA play nice? They said yes, in fact all VMware features play nice and in the following order of priority: FT, HA, DRS, and DPM.
- Why does the slot size set default to the maximum reservations for CPU and memory? Since multiple slots can be used in the case of large VMs with no allocation would it not make more sense to just default to a very small slot size? They said the reason was because of overhead associated with doing this.
© 2010, Steve Flanders. All rights reserved.
