vmware Archives - Page 3 of 3

Solving the Virtual Desktop Puzzle Part 1

Posted on December 23, 2010February 11, 2019 by admin

There is no doubt that desktop virtualization can bring greater operational efficiencies to many businesses. However, one needs to design for more than just pure desktop consolidation to gain the most from this technology. There are three general components that make up a typical desktop environment. These are the Operating System, User Data, and Applications. By separating these components, each one can be managed distinctively without affecting the the other two.

This post will specifically address how technologies within VMware View can be used to better manage the Operating System in your virtual desktop environment.

A virtual desktop infrastructure with VMware View allows you to maintain multiple desktops in a pool as a single, disposable unit. This functionality is enabled by the VMware linked clone technology. Below is a diagram of what a desktop pool may look like without linked clones. Each virtual desktop is a separate 20GB image. This means that 100GB of disk space must be used to house the virtual desktop images. Also, the virtual desktops are managed almost the same way that physical desktops are managed.

Linked clones, on the other hand, allow you to manage the virtual desktops in a much more efficient manner. Below is a diagram of how a linked clone desktop pool might look.

Here, there is a master image (20GB) and the linked clone virtual disks (1GB each) are based off of that master image. Not only does this save a significant amount of disk space, but it also allows you to manage the entire desktop pool as a single entity. For example, when you make a change (such as patching on Microsoft Patch Tuesday) to the master image, the linked clones can get that change as well. No more managing patches on a per desktop basis. You can even take a new snapshot of the master image before you patch and then point back to the pre-patched image if additional testing needs to be done. The workflow goes like this:

Keep the original master image snapshot
Patch the master image and create a new snapshot based on that patching
Point the desktop pool to the new snapshot
Have your users log off their desktops and log back in
They now have their new patches
Spend the rest of Patch Tuesday doing something besides babysitting Microsoft patches

This is just one example of the flexibility that VMware View can bring to desktop management. In order to streamline this process as much as possible, we want the master desktop image to be as vanilla as possible. To do that we need strategies to address applications that the users need and user data. Parts 2 and 3 of this series will address those portions of the desktop. Until then, if you have any comments or questions feel free to post them.

Cisco Nexus 1000v and vSphere HA Slot Sizes

Posted on August 19, 2010February 11, 2019 by admin

When implementing the Cisco Nexus 1000v, High Availability (HA) Slot Sizes can be affected on your vSphere Cluster. HA slot sizes are used to calculate failover capacity for HA when the “Host Failures” HA setting is used. By default the slot size for CPU is the highest reservation of CPU among all VM’s in the cluster (or 256 MHz if no per VM reservations exist). The slot size for Memory is the highest reservation of Memory among all VM’s in the cluster (or 0 MB + Memory Overhead if no per VM reservations exist). If you want to really dive further into HA and slot size calculations, I would highly recommend reading Duncan Epping’s HA Deepdive at Yellow-Bricks.com.

Each Cisco Nexus 1000v Virtual Supervisor Module (VSM) has a reservation of 1500 MHz on the CPU and 2048 MB on the Memory so that these resources can be guaranteed for the VSM’s. So, the slot size will be affected accordingly (1500 MHz for CPU and 2048 MB for Memory).

If you do not want your slot size affected and you do not want to enable the advanced slot size parameters das.slotCpuInMHz or das.slotMemInMB there is another solution that will allow you to still guarantee resources for the Nexus 1000v VSM’s and maintain smaller slot sizes.

Create a separate resource pool for each VSM with a CPU reservation of 1500 MHz and Memory reservation of 2048 MB.

Since slot sizes are only affected by per VM reservations, the resource pools will give you the desired results without increasing your HA slot sizes. I wouldn’t recommend doing this with too many VM’s as this turn into a management nightmare very quickly. However, for the two VSM’s in a Cisco Nexus 1000v infrastructure it is manageable.

Now your Nexus 1000v VSM’s are happy and you are not wasting resources in your HA cluster by calculating larger slot sizes than are required.

References

http://www.yellow-bricks.com/vmware-high-availability-deepdiv/

http://frankdenneman.nl/2010/02/resource-pools-and-avoiding-ha-slot-sizing/

Backing up the vCenter 4.x AD LDS Instance

Posted on August 18, 2010February 11, 2019 by admin

vCenter is one of the most important components of your vSphere 4.x virtual infrastructure. Many advanced capabilities of vSphere 4 (vMotion, DRS, etc.) are not available without vCenter. Prior to vSphere 4.x, it was sufficient to backup the vCenter database and restore vCenter by building a new vCenter server, restoring the database, and reinstalling vCenter to attach to the restored database.

With the introduction of vSphere 4.x, vCenter 4.x started using Active Directory Application Mode (ADAM) on Windows Server 2003 and Active Directory Lightweight Directory Services (AD LDS) on Windows Server 2008 to accommodate Linked Mode for vCenter. The roles and permissions are stored in the ADAM or AD LDS database. In order to restore the roles and permissions, the ADAM or AD LDS database must be backed up.

VMware KB1023985 tells you that you need to back up the SSL certificates, vCenter Database, and the ADAM/AD LDS database. There are many well-known ways to back up a SQL database. However, backing up an AD LDS instance is a lesser known procedure. The following PowerShell script will back up the the AD LDS VMware Instance on Server 2008 and the SSL folder. As always, test it thoroughly before using it.
[powershell]#
# Name: VC_ADAM_SSL_Backup.ps1
# Author: Harley Stagner
# Version: 1.0
# Date: 08/17/2010
# Comment: PowerShell script to backup AD LDS
# and SSL folder for vCenter
#
# Thanks to Tony Murray for the AD LDS portion of the
# script.
#
#
#########################################################

# Declare variables
$BackupDir = “C:backupVMwareBackup”
$SSLDir = $env:AllUsersProfile + “VMwareVMware VirtualCenterSSL”
$IFMName = “adamntds.dit”
$cmd = $env:SystemRoot + “system32dsdbutil.exe”
$flags = “`”activate instance VMwareVCMSDS`” ifm `”create full C:backupVMwareBackup`” quit quit”
$date = Get-Date -f “yyyymmdd”
$backupfile = $date + “_adamntds.bak”
$DumpIFM = “{0} {1}” -f $cmd,$Flags
$ServiceVCWeb = “vctomcat”
$ServiceVCServer = “vpxd”

# Main
Stop-Service $ServiceVCWeb
Stop-Service $ServiceVCServer -force
# Create the folder if it doesn’t exist
if(Test-Path -path $BackupDir)
{Write-Host “The folder” $BackupDir “already exists”}
else
{New-Item $BackupDir -type directory}
# Clear the IFM folder (Dsdbutil needs folder to be empty before writing to it)
Remove-Item $BackupDir* -recurse

# Run Dsdbutil.exe to create the IFM dump file
Invoke-Expression $DumpIFM
# Rename the dump file to give the backup a unique name

Rename-Item $BackupDir””$IFMName -newname $backupfile
Copy-Item $SSLDir $BackupDir -recurse
Start-Service $ServiceVCWeb
Start-Service $ServiceVCServer

# End Main[/powershell]
This script utilizes the dsdbutil.exe utility on Windows Server 2008 to backup the AD LDS instance and SSL folder after it stops the vCenter services. By default it backs these items to “C:backupVMwareBackup”. Change it to your liking.

Now to restore the AD LDS instance data, follow the directions at Technet.

References

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1023985

http://technet.microsoft.com/en-us/library/cc725665%28WS.10%29.aspx

http://www.open-a-socket.com/index.php/category/ad-lds-adam/

Active Directory Authentication – Accountability in ESX / ESXi 4.1

Posted on August 3, 2010February 11, 2019 by admin

As a part of TBL professional services datacenter practice, I perform many health and security checks on virtual infrastructures for clients. One of the common issues that I run into is the use of the default “root” account for administering ESX servers. This is an issue for two reasons:

The “root” account has a tremendous amount of power and the password for it is typically the same shared password on each ESX host.
If all administration is done with the “root” account there is no audit trail for accountability. It could have been Joe, Bob, or Sue that logged into the ESX host. You just don’t know.

Of course, most administration should be done through vCenter, but you still occasionally need to log into an ESX host directly. The solution to this that I have recommended in the past has been to create local user accounts coinciding with the Active Directory user name on each ESX host. Then do not use root unless absolutely necessary when performing administrative tasks directly on the host. However, this meant that the IT Administrators would need to manage user accounts in Active Directory and the local accounts on the ESX / ESXi hosts.

There has been a “less than ideal” solution to Active Directory authentication for quite a while (see Scott Lowe’s article). However, this solution was very laborious, involves the command line, and only worked on ESX Classic. Not ESXi.

With the release of vSphere 4.1, native Active Directory authentication is one of the many new features. Here’s how easy it is to implement once you have ESX installed.

Connect to your ESX/ESXi server with the vSphere Client.
Click on “Inventory” and highlight your ESX/ESXi server.
Click on the “Configuration” tab.
Navigate to “Software –> Authentication Services”
Click on “Properties” on the right hand side.
Change the “Directory Service Type” from “Local Authentication” to “Active Directory”
Once you do that and enter in your Domain, click “Join Domain” and you will be prompted for appropriate credentials to join the domain.
Click “OK” when you are done.

That’s it! Now you can have accountability controlled through Active Directory Authentication. Joe, Bob, and Sue can all use their respective Active Directory accounts for authentication. Accountability!

Permissions can now be added for Active Directory users and groups as well.

You can even use it with the vSphere CLI and the Direct Console User Interface (DCUI) on ESXi.

Should you still need the local “root” account for emergencies, it will still be available to you. Otherwise, do your company a favor and maintain an audit trail for administrative actions on your infrastructure.