Update Your ESX’s SSL Certs with your own Windows Domain CA Certificates using PowerCLI
Replacing ESX SSL is the easiest of all the vSphere components, in my opinion. Unlike vSphere 5.1, you can use Microsoft's Web Server SSL template, and there's no need to use the Java keytool or reregister the service with SSO.
Below is a script I use in conjunction with my vSphere/PowerShell Replace SSL script.
This is the first time I've actually used PowerCLI so I'm unsure if this script follows Best Practices, but hey, it worked for me in my lab environment
"What it does.."
- Creates the certificate directory if it does not exist
- Logs into specified vSphere Server
- Automatically downloads Root64.cer from the CA's web service
- Downloads and extracts OpenSSL if the files do not exist in the specified path
- Generates all SSL certificates for each of the services on the server.
If $upsateesx is set to true..
- Downloads Putty SCP
- Checks to see if SSH is running on the esx host. If not, it temporarily enables it
- Prompts for and validates credentials
- Backs up all SSL Certs on the server
- Uploads the new certs
- Returns SSH to previous state
Once the new certs have been uploaded, you will have to restart the ESX host, or set it into maintenance mode and restart the Management services.
##############################################################################################
#
# ESX Certificate Generation and Upload version 0.5
# Tested on: ESX 5.1 / vCenter 5.1U1 / PowerCLI 5.1 Release 2
# ESX 4.1 / vCenter 4.1U3
# No guarantees, warranties, etc.
# Blog post: http://goo.gl/OdIlF
#
##############################################################################################
# vCenter Server FQDN
$vcserver = "vcenter41.base.local"
# It is recommended that you place the certs on a network location
$basedir = "\\fileserver\share\Certs"
# Enter your Windows Certificate Authority information
# below. Make sure your $rootCA responds to certutil and web requests.
$rootCA = "dc.base.local"
$rootCAName = "BASE-DC-CA"
$email = "vmware@base.local"
$org = "NetNerds"
$city = "Kaplan"
$state = "LA"
$country = "US"
# This can be WebServer or the VMware-SSL certificate
# template found here: http://goo.gl/m98FE
$certTemplate = "CertificateTemplate:WebServer"
# Enter the path of your openssl.exe (0.x and 1.x are supported).
# If you don't have OpenSSL already, the script will download it for you.
$openssldir = "C:\OpenSSL-Win32"
$openssl = $openssldir+"\bin\openssl.exe"
# Do you want the script to automatically backup the old ESX certs
# and upload the new certs to each esx host?
$updateesx = $true
##############################################################################################
#
# You shouldn't need to change anything below.
#
##############################################################################################
if (!(Test-Path("$basedir"))) { $null = mkdir "$basedir" }
$backuptime = (get-date -uformat "%m%d%Y%H%M%S")
$esxhosts = @{}
Write-Host -Foreground "Black" -Background "White" "Logging into $vcserver."
if ($global:DefaultVIServers.Count -eq 0 -or ($global:DefaultVIServers).Name -ne $vcserver) {Connect-ViServer $vcserver}
Write-Host -Foreground "Black" -Background "White" "Getting list of esx servers."
$esxServers = (Get-VMHost).Name
foreach ($esxServer in $esxServers) {
$esxdir = "$basedir\$esxServer-esx"
$esxhosts.Add("$esxServer-esx", $esxServer)
}
Write-Host -Foreground "Black" -Background "White" "Downloading root CA Cert.."
$wc = New-Object System.Net.WebClient
$url = "http://$rootCA/certsrv/certnew.cer?ReqID=CACert&Renewal=0&Enc=b64"
$root64 = "$basedir\Root64.cer"
$wc.UseDefaultCredentials = $true
$wc.DownloadFile($url,$root64)
if (!(Test-Path($openssl))) {
Write-Host -Foreground "Black" -Background "White" "Downloading OpenSSL.."
$null = mkdir $openssldir
$sslurl = "https://openssl-for-windows.googlecode.com/files/openssl-0.9.8k_WIN32.zip"
$sslzip = "$env:temp\openssl.zip"
$wc.DownloadFile($sslurl,$sslzip)
$env:path = $env:path + ";$openssldir"
Write-Host -Foreground "Black" -Background "White" "Extracting OpenSSL.."
$shellApplication = new-object -com shell.application
$zipPackage = $shellApplication.NameSpace($sslzip)
$destinationFolder = $shellApplication.NameSpace($openssldir)
$destinationFolder.CopyHere($zipPackage.Items())
Remove-Item $sslzip
}
$wc = New-Object System.Net.WebClient
if ($updateesx -eq $true) {
Write-Host -Foreground "Black" -Background "White" "Downloading Putty SCP.."
$scpurl = "http://tartarus.org/simon/20090227-kbdint-batch/x86/pscp.exe" # patched version for keyhost prompt issue
$scp = "$env:temp\pscp.exe"
$wc.DownloadFile($scpurl,$scp)
}
######################################################################
#
# Generate Certs
#
######################################################################
Write-Host -Foreground "Black" -Background "White" "Generating service certs.."
foreach ($esxhost in $esxhosts.GetEnumerator()) {
$service = $esxhost.Name
$esxserverfqdn = $esxhost.Value
$esxserver = $esxserverfqdn.Substring(0,$esxserverfqdn.IndexOf("."))
$servicedir = "$basedir\$service"
$servicecfg = "$servicedir\$service.cfg"
$tempkey = "$servicedir\temp.key"
$ruikey = "$servicedir\rui.key"
$ruicsr = "$servicedir\rui.csr"
$ruicrt = "$servicedir\rui.crt"
$ruipfx = "$servicedir\rui.pfx"
$chainpem = "$servicedir\chain.pem"
$backupdir = "$servicedir\backup-$backuptime"
$keyalias = "rui"
if (Test-Path($servicedir)) { $null = Remove-Item "$servicedir\*.*" } else {$null = mkdir $servicedir }
Set-Content $servicecfg "[ req ]"
Add-Content $servicecfg " default_md = sha512"
Add-Content $servicecfg " default_bits = 2048"
Add-Content $servicecfg " default_keyfile = rui.key"
Add-Content $servicecfg " distinguished_name = req_distinguished_name"
Add-Content $servicecfg " encrypt_key = no"
Add-Content $servicecfg " prompt = no"
Add-Content $servicecfg " string_mask = nombstr"
Add-Content $servicecfg " req_extensions = v3_req"
Add-Content $servicecfg "`n[ v3_req ]"
Add-Content $servicecfg " basicConstraints = CA:FALSE"
Add-Content $servicecfg " keyUsage = digitalSignature, keyEncipherment, dataEncipherment"
Add-Content $servicecfg " extendedKeyUsage = serverAuth"
Add-Content $servicecfg " subjectAltName = DNS:$esxserver, DNS:$esxserverfqdn"
Add-Content $servicecfg "`n[ req_distinguished_name ]"
Add-Content $servicecfg " countryName = $country"
Add-Content $servicecfg " stateOrProvinceName = $state"
Add-Content $servicecfg " localityName = $city"
Add-Content $servicecfg " 0.organizationName = $org"
Add-Content $servicecfg " organizationalUnitName = $service"
Add-Content $servicecfg " commonName = $esxserverfqdn"
&$openssl req -new -nodes -out $ruicsr -keyout $tempkey -config $servicecfg
&$openssl rsa -in $tempkey -out $ruikey
Remove-Item $tempkey
certreq -submit -config "$rootCA\$rootCAName" -attrib $certTemplate $ruicsr $ruicrt
&$openssl pkcs12 -export -in $ruicrt -inkey $ruikey -certfile $root64 -name $keyalias -passout pass:testpassword -out $ruipfx
Get-Content $ruicrt > $chainpem; Get-Content $root64 >> $chainpem
### Start ESX cert upload if updateesx is true and certificate generation is successful
if ($updateesx -eq $true -and (Test-Path($ruikey)) -and (Test-Path($ruicrt))) {
$disablessh = $null; $failedauth = 0
$sshservice = (Get-VMHostService -VMHost $esxserverfqdn -Server $vcserver | Where { $_.Key -eq "TSM-SSH"})
if ($sshservice.Running -eq $false) {
Write-Host -Foreground "Black" -Background "White" "Temporarily enabling SSH on $esxserverfqdn" ; $disablessh = $true
$null = Start-VMHostService -HostService $sshservice -Confirm:$false
}
Write-Host -Foreground "Black" -Background "White" "Validating authentication."
Write-Host -Foreground "Black" -Background "White" "You can ignore any SSH keyhost prompts you may see.."
do {
$msg = "Enter the username and password for $esxserverfqdn";
$creds = $Host.UI.PromptForCredential($caption,$msg,"root",$domain)
$esxusername = $creds.username; $esxpassword = $creds.GetNetworkCredential().password
$esxsslpath = "$esxusername@$esxserverfqdn"+":/etc/vmware/ssl/"
$authenticated = $null
$checkauth = (Echo "Y" | &($scp) -scp -pw $esxpassword -ls $esxsslpath)
if ($checkauth -eq $null) {
$authenticated = $false
$failedauth++
}
} until ($authenticated -ne $false -or $failedauth -gt 4)
if ($failedauth -gt 4) { Write-Host -Foreground "Black" -Background "White" "Sorry, too many failed logins."; Break }
Write-Host -Foreground "Black" -Background "White" "`rAuthentication accepted!"
Write-Host -Foreground "Black" -Background "White" "Backing up current certs.."
$null = (New-Item -Type Directory $backupdir)
echo "Y" | &($scp) -scp -batch -pw $esxpassword "$esxsslpath/rui.key" $backupdir
echo "Y" | &($scp) -scp -batch -pw $esxpassword "$esxsslpath/rui.crt" $backupdir
Write-Host -Foreground "Black" -Background "White" "Uploading new certs.."
echo "Y" | &($scp) -scp -batch -pw $esxpassword "$ruikey" $esxsslpath
echo "Y" | &($scp) -scp -batch -pw $esxpassword "$ruicrt" $esxsslpath
if ($disablessh) {
Write-Host -Foreground "Black" -Background "White" "Returning SSH to disabled state on $esxserverfqdn"
$null = Stop-VMHostService -HostService $sshservice -Confirm:$false
}
Write-Host -Foreground "Black" -Background "White" "Finished uploading files on $esxserverfqdn. Reboot the ESX host to activate new certificates."
}
}
if ($updateesx -eq $true) { $null = Remove-Item $scp }
Alternatively, you can download the .ps1 file from here.
Note that you will have to re-add ESX to vCenter because the host's SSL thumbprint has changed. Regarding updating ESX's SSL, Derek Seaman suggests:
If your ESXi host is already managed by vCenter, the HA agent can get very confused by the new SSL certificate thumbprint. I would strongly suggest you first put your host in maintenance mode, remove it from the vCenter inventory, update the SSL certificate, reboot the ESXi host, then re-add it to the vCenter inventory.
Update vSphere 5.1 SSL Certs with your own Windows Domain CA Certificates using PowerShell
One month ago when I finally got my vSphere lab set up, I had no idea that getting rid of those annoying untrusted SSL errors would be such a colossal undertaking. I have my own domain CA and thought it would be easy to automate the process of replacing the self-signed vSphere SSl certs with my own trusted certs.
At first, I attempted to use strictly Windows commands (certutil, certreq, etc) and PowerShell, but eventually gave in and incorporated OpenSSL into my script. Generating the certs were just the beginning, though.
Replacing the certificates in an automated fashion and getting each service to behave after the change was an extremely time-consuming task. VMware's documentation and KB articles leave a lot of room for improvement, but fortunately, David Seaman's blog was able to provide a lot of information that was either easy to miss, or missing entirely.
Numerous articles suggested using VMware's Certificate Automation Tool but the tool wasn't automated enough for my liking, even with supplemental scripts provided by other bloggers. I looked into guts of the Certificate Automation tool and, after a good bit of trial and error, replicated many of its techniques using PowerShell. Using these techniques, and following the suggestions found on forums and blogs, I was able to create a script that can replace the SSL certs of all of my vSphere lab servers in under 20 minutes, a majority of which is spent watching PowerShell stop and start services.
This script requires you to enter less than 15 variables as seen in the snippet below:
# SSO Server FQDN
$ssoserver = "vcenter.base.local"
# Place the certs on a network location if your farm is larger than one server
$basedir = "\\fileserver\share\Certs"
# Enter your SSO master password below. You will be prompted for your vCenter Server
# credentials at runtime.
$masteradmin = "admin@System-Domain"
$masterpass = "Fakepass.123"
# Enter your Windows Certificate Authority information below.
# Make sure it responds to certutil and web requests.
$rootCA = "dc.base.local"
$rootCAName = "BASE-DC-CA"
$email = "vmware@base.local"
$org = "NetNerds"
$city = "Kaplan"
$state = "LA"
$country = "US"
# Make sure you follow Derek Seaman's instructions
# to create a new certificate template @ http://goo.gl/m98FE
$certTemplate = "CertificateTemplate:VMware-SSL"
# Enter the path of your openssl.exe (0.x and 1.x are supported).
# If you don't have OpenSSL already, the script will download it for you.
$openssldir = "C:\OpenSSL-Win32"
$openssl = $openssldir+"\bin\openssl.exe"You can see that the SSO admin username and password are in plain text. Unlike vCenter credentials, there was no easy way to validate the SSO username/password and the pros of placing the username and password there in plain text outweighed the cons. vCenter credentials were easier to validate and more of a priority for me to protect since they're usually Windows credentials.
Also, note that the default "Web Server" SSL certificate template is no longer adequate. Please visit Derek Seaman's blog for instructions on how to create a certificate template which will work for all of the vSphere services.
"What it does.."
Start up
- If the server running the script is not the SSO server, it ensures the remote SSO Server's SSL certs have been updated first
- Checks the registry to see which vSphere services exist on the server running the script and sets service variables
- Creates the certificate directory if it does not exist
- Backs up all SSL Certs on the server
- Validates vCenter authentication if vCenter or VUM exist on the server
- Automatically downloads Root64.cer from the CA's web service
- Downloads and extracts OpenSSL if the files do not exist in the specified path
- Generates all SSL certificates for each of the services on the server. Uses server name + service name as the OU so that each cert can be distinguished.
If SSO service exists
- Stops SSO Service
- Generates new SSO keystore using the newly created SSO SSL certificate
- Copies Root64.cer to %programdata%\VMware\SSL\ca_certificates.cer
- Creates new hash file in %programdata%\VMware\SSL
- Updates SSO using rsautil.cmd
- Starts SSO Service
- Automatically builds service.properties and service_id files and stores them in %programdata%\VMware\ServiceIDs
- Reregisters all services using new root certificate
- Restarts SSO, and if they exist Log Browser, Web Client and Inventory services.
If Inventory service exists
- Unregisters Inventory service with SSO
- Stops Inventory service
- Copies new certs to the Inventory service SSL directory
- Starts Inventory Service
- Registers Inventory service with SSO
If vCenter service exists
- Copies new certs to the vCenter service SSL directory
- Using credentials previously entered, logs into vCenter service's mob website to automatically invoke reloadSslCertificate
- Restarts all vCenter related services
- Reregisters vCenter with Inventory Service
If WebClient services exists
- Stops WebClient and LogBrowser services
- Removes all files from SerenityDB directory
- Copies new certs to the Web Client and Log Browser service SSL directories
- Stops vCenter and Inventory Services if they exist on the local server
- Restarts SSO service on local or remote server
- Starts vCenter and Inventory Services if they exist on the local server
- Starts WebClient and LogBrowser services
If Update Manager exists
- Stops Update Manager services
- Copies new certs to the Update Manager service SSL directory
- Generates new Update Manager keystore using the newly minted Update Manager Certificates
- Updates registry entry with keystore password (testpassword)
- Runs vciInstallUtils to update VUM using credentials previously entered
- Starts Update Manager services
If Orchestrator exists
- Copies new certs to the Orchestrator service SSL directory
- Stops services if necessary
- Generates new Orchestrator keystore using newly created Orchestrator certificates
- Adds SSO Certificate to keystore
- Restarts Orchestrator services then returns them to their previous state of Running or Stopped
If you have vCenter servers in linked mode and are running the Web Client, you may run into the error message "Cannot connect to Inventory Service on [server]" when logging into the Web Client. I have not found a predictable way to fix this. Usually, it can be solved by first restarting the server running Web Client, then restarting the vCenter/Inventory server.
This script also has other limitations, many of them similar to the Certificate Automation Tool.
Limitations
Limitations specific to this script
- Only uses Windows Domain Certificate Authorities
- Does not account for intermediary CAs
- Has not been tested in large environments with HA and DRS
- Has not been tested with environments running: VMware Site Recovery Manager, vSphere Data Recovery, vCloud Director, or third-party solutions
- Does not have a rollback feature, yet. For rollback, I relied on Snapshots and database backups.
- Does not have advanced logging
- I don't recommend running this in a production environment until it's been vetted by far more people
Limitations that exist in VMware's tool that likely exist within this script
- vCenter Single Sign-On Password cannot contain spaces
- vCenter Orchestrator may fail to connect when using multiple vCenter Servers.
- You can update add additional vCenter Server SSL certificates using the VMO Configuration Webpage (https://vmoserver:8283/ default login: vmware/vmware -> vCenter Server -> SSL Certificates.
- Add all vCenter Certificates found in your Certs directory.
- Note that if vCenter and VMO are running on the same server, the vCenter cert will be automatically added.
- Client Not authenticated error when connecting to VMware Inventory service in Linked Mode Configurations. Wait 10 minutes and this should resolve itself.
Why I prefer using this script over VMware's
- Requires minimal information and interaction
- Automatically downloads OpenSSL if neccessary
- Automatically generates the certificates based off of a few variables
- Automatically detects services and runs the SSL updates in the necessary order without user intervention
- If vCenter or VUM exists on the server, you wil be prompted for your vCenter credentials. This is the extent of interaction that the script will require:
- Replaces all of the same certificates: SSO, Inventory Service, vCenter, Update Manager, Web Client/Log Browser, and Orchestrator
- Also, works on vSphere farms with multiple servers (you must update the SSO server first)
- It's all contained in just one (nearly 600 line) script
- Works on 5.1 and 5.1U1
In the end, your Cert collection will look something like this:

* Note that the esx certificate output was created using this script.
And each of your services will be encrypted with trusted certificates:

Getting started
- Ensure your Windows Domain CA certificate is trusted by members of your domain
- Take a snapshot of each vSphere server on which you will run this script
- Backup each of your databases
- Find a secure location on the network to store your certs (ie. \\fileserver\share\Certs)
- Visit Derek Seaman's blog and create a new certificate template
- Shut down the following services if they exist: VMware Site Recovery Manager, vSphere Data Recovery, vCloud Director, third-party solutions that connect to vCenter.
- Download the ReplaceSSL-vSphere51.ps1 script
- Change the variables
- Run the script first on the server running the SSO
- Run the script on all other servers
- If the Web Client connects to multiple vCenter servers, reboot the server running Web Client, as well as the server(s) running Inventory Service and vCenter.
- Consider running the complimentary ESX Script
Once the scripts are complete, you can visit each of your sites to confirm the SSL Certificates have been replaced. Please note that Log Browser and the Web Client take up to 5 minutes to fully restart.
Finally, bask in the glory of your trusted SSL certificates:
[Solved] Parallels Desktop: Interface vmnet1 is not present. This should be created at boot time.
I recently modified my Parallels DHCP settings because I'm really particular about the internal subnets I work with in the lab (192.168 is the ugliest subnet ever). Once I modified the file at /Library/Preferences/VMware\ Fusion/networking (OS X) my Parallels Desktop erred out and said
Interface vmnet1 is not present. This should be created at boot time.
Someone on this thread suggested a reinstall but that only worked as a temporary fix. Turns out, when you modify the networking file, you also need to restart your vmnet-cli service. You can do this with the following commands:
/Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop
/Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --config
/Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start
/Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --status
I ended up just throwing the stop and start commands into a script and running it each time I modified my settings.
VMware ESXi 4.0: Create Virtual Machine Error Caused by NSF File on Western Digital MyBook WE
Such an awkward title, I know. It's just hard to encapsulate the following error message into a blog post title:
Create virtual machine 172.16.1.129 Error caused by file /vmfs/volumes/0-cb8d2a5-20-f15722/win-2k8.vmdk
Basically, I'm taking ghetto to the next level by using my Dell Optiplex 745 workstation as an ESXi 4.0 server, and using a Western Digital MyBook World Edition as an NFS server which will store the VM images. The MyBook is actually very cool; it's a quiet, visually appealing mirrored 1TB NAS. After manually enabling the NFS server, I was able to mount the shares in VMware but was unable to write to it. Attempting to create a VM would error out with the following in the messages log:
Hostd: [2010-01-22 19:45:36.384 5AA03B90 verbose 'ha-host'] ModeMgr::Begin: op = normal, current = normal, count = 0
Hostd: [2010-01-22 19:45:36.385 5AA03B90 info 'ha-eventmgr'] Event 18 : Creating win2k8 on host whateves.lan in ha-datacenter
Hostd: [2010-01-22 19:45:36.385 5AA03B90 verbose 'HostsvcPlugin'] CreateEntry '64'
Hostd: [2010-01-22 19:45:36.385 5AA03B90 verbose 'ResourcePool ha-root-pool'] Added child 64 to pool
Hostd: [2010-01-22 19:45:36.385 5AA03B90 verbose 'Vmsvc'] Create VM initiated [64]: /vmfs/volumes/0cb8d2a5-20f15722/win2k8/win2k8.vmx
Hostd: [2010-01-22 19:45:36.387 5AA03B90 verbose 'vm:/vmfs/volumes/0cb8d2a5-20f15722/win2k8/win2k8.vmx'] CreateVmDirectory: Creating vm dir (as vm principal user) '/vmfs/volumes/0cb8d2a5-20f15722/win2k8'
Hostd: [2010-01-22 19:45:36.388 5AA03B90 info 'App'] CreateDirectory: Calling _file->CreateDirectory with _file = [N7Vmacore6System8FileImplE:0x5af0ae58]
Hostd: [2010-01-22 19:45:36.388 5AA03B90 info 'App'] CreateDirectory: Calling _file->CreateDirectory for /vmfs/volumes/0cb8d2a5-20f15722/win2k8
Hostd: [2010-01-22 19:45:36.389 5AA03B90 verbose 'vm:/vmfs/volumes/0cb8d2a5-20f15722/win2k8/win2k8.vmx'] CreateVmDirectory: Failed to create vm dir (as vm principal user) '/vmfs/volumes/0cb8d2a5-20f15722/win2k8'.
Hostd: [2010-01-22 19:45:36.389 5AA03B90 verbose 'vm:/vmfs/volumes/0cb8d2a5-20f15722/win2k8/win2k8.vmx'] CreateVmDirectory: Creating vm dir (as superuser) '/vmfs/volumes/0cb8d2a5-20f15722/win2k8'
Hostd: [2010-01-22 19:45:36.390 5AA03B90 warning 'vm:/vmfs/volumes/0cb8d2a5-20f15722/win2k8/win2k8.vmx'] CreateVmDirectory: Failed to create vm dir '/vmfs/volumes/0cb8d2a5-20f15722/win2k8'
Hostd: [2010-01-22 19:45:36.391 5AA03B90 info 'vm:/vmfs/volumes/0cb8d2a5-20f15722/win2k8/win2k8.vmx'] Create failed with given spec: /vmfs/volumes/0cb8d2a5-20f15722/win2k8/win2k8.vmx
Hostd: (vim.vm.ConfigSpec) { dynamicType = <unset>, changeVersion = <unset>, name = "win2k8", version = "vmx-07", uuid = <unset>, instanceUuid = <unset>, npivWorldWideNameType = <unset>, npivDesiredNodeW
wns = <unset>, npivDesiredPortWwns = <unset>, npivTemporaryDisabled = <unset>, npivOnNonRdmDisks = <unset>, npivWorldWideNameOp = <unset>, locationId = <unset>, guestId = "winLonghorn64Guest", alternateGuestName = "Microsoft Wi
ndows Server 2008 (64-bit)", annotation = <unset>, files = (vim.vm.FileInfo) { dynamicType = <unset>, vmPathName = "[VMs]", snapshotDirectory = "[VMs]", suspendDirectory = <unset>, logDirectory = <unset>, },
tools = (vim.vm.ToolsConfigInfo) { dynamicType = <unset>, toolsVersion = <unset>, afterPowerOn = true, afterResume = true, beforeGuestStandby = true, beforeGuestShutdown = true, beforeGuestReboot = true,
toolsUpgradePolicy = <unset>, pendingCustomization = <unset>, syncTimeWithHost = <unset>, }, flags = (vim.vm.FlagInfo) null, consolePreferences = (
Hostd: [2010-01-22 19:45:36.391 5AA03B90 info 'vm:/vmfs/volumes/0cb8d2a5-20f15722/win2k8/win2k8.vmx'] Exception thrown vim.fault.FileFault
Hostd: [2010-01-22 19:45:36.391 5AA03B90 info 'TaskManager'] Task Completed : haTask-ha-folder-vm-vim.Folder.createVm-172 Status error
Hostd: [2010-01-22 19:45:36.391 5AA03B90 verbose 'ha-host'] ModeMgr::End: op = normal, current = normal, count = 1
Hostd: [2010-01-22 19:45:36.391 5AA03B90 verbose 'vm:/vmfs/volumes/0cb8d2a5-20f15722/win2k8/win2k8.vmx'] RemoveFromAutoStart
Hostd: [2010-01-22 19:45:36.391 5AA03B90 verbose 'Hostsvc::AutoStartManager'] Request spec is (vim.host.AutoStartManager.Config) { dynamicType = <unset>, defaults = (vim.host.AutoStartManager.SystemDefaults) null, powerInfo
= (vim.host.AutoStartManager.AutoPowerInfo) [ (vim.host.AutoStartManager.AutoPowerInfo) { dynamicType = <unset>, key = 'vim.VirtualMachine:64', startOrder = -1, startDelay = -1, waitForHeartbeat = "n
o", startAction = "none", stopDelay = -1, stopAction = "none", } ], }
Hostd: [2010-01-22 19:45:36.391 5AA03B90 verbose 'Hostsvc::AutoStartManager'] Updated AutoStart sequence.
Hostd: [2010-01-22 19:45:36.392 5AA03B90 verbose 'Hostsvc::AutoStartManager'] Autostart info after reconfiguration: (vim.host.AutoStartManager.Config) { dynamicType = <unset>, defaults = (vim.host.AutoStartManager.SystemDefault
s) { dynamicType = <unset>, enabled = <unset>, startDelay = 120, stopDelay = 120, waitForHeartbeat = false, stopAction = "PowerOff", }, }
Hostd: [2010-01-22 19:45:36.392 5AA03B90 verbose 'Vmsvc'] Released Vm Id: 64.
Hostd: [2010-01-22 19:45:36.392 5AA03B90 verbose 'HostsvcPlugin'] RemoveEntry '64'
Hostd: [2010-01-22 19:45:36.392 5AA03B90 verbose 'HostsvcPlugin'] RemoveEntry succeeded
Hostd: [2010-01-22 19:45:36.392 5AA03B90 verbose 'ResourcePool ha-root-pool'] Removed child 64 from pool
Hostd: [2010-01-22 19:45:36.392 5A9C2B90 verbose 'App'] Looking up object with name = "64" failed.
Hostd: [2010-01-22 19:45:36.392 5AA03B90 info 'vm:/vmfs/volumes/0cb8d2a5-20f15722/win2k8/win2k8.vmx'] Create worker thread failed
Hostd: [2010-01-22 19:45:36.393 5AA03B90 verbose 'Statssvc'] EntityRemovedListener: Deleting stats for entity 64
Hostd: [2010-01-22 19:45:36.565 5AA44B90 verbose 'DvsTracker'] FetchDVPortgroups: added 0 items
Hostd: [2010-01-22 19:45:41.690 5AA03B90 verbose 'App'] Looking up object with name = "haTask-ha-host-vim.host.DatastoreSystem.removeDatastore-114" failed.
After searching the 'nets for about an hour, I found a post on MyBook World that addressed my issue. By default the MyBook mounts NFS shares as read-only. To change that, I modified the /etc/exports file, changing all instances of "ro" to "rw."
/nfs/Public *(rw,all_squash,sync,insecure,anonuid=65534,anongid=65534)
/nfs/Download *(rw,all_squash,sync,insecure,anonuid=65534,anongid=65534)
Then, I restarted the service by issuing /etc/init.d/S80nfsd restart. Once the restart was complete, my VM creation was successful
VMWare ESXi 3.5: Creating an ISO Image from a CD/DVD-ROM
I always use ISOs in the datastore as CD/DVD devices in my virtual machines. Tonight, I had to make images of my Windows 2008 DVDs but because my tiny laptop doesn't have a DVD/CD-ROM build-in, I had to rely on my ESXi servers to create the ISOs. Creating an ISO in ESXi is as almost easy as creating one in Linux -- the only thing that presents a small challenge is VMware's use of an unconventional device path for the DVD/CD-ROM. Ultimately, I used VIC (VM->Properties->CD/DVD->Host Device) to find the name of my device, which turned out to be "/vmfs/devices/genide/vmhba0\:0\:0"

After opening up the SSH port on ESXI by using this tutorial, I created an ISOs folder in the datastore, placed the DVD in the drive and, finally, created the ISO by issuing the following command:
dd if=/vmfs/devices/genide/vmhba0\:0\:0 of=/vmfs/volumes/datastore3/isos/win2k8EEx64.isoVMware Server 2 for Linux: HOW-TO Disable VMware Virtual Infrastructure Web Access
Many people are not aware that VMware Server's resource intensive Web Access/Web MUI is not required to administer VMware Server 2. As I detailed in a previous post, the same Windows-only thick client used to administer ESX Server, Virtual Infrastructure Client (VIC) 2.5, can also be used for administration.
While the "webAccess" MUI can be disabled, disabling the rather lightweight HTTP/HTTPS services entirely is not recommended, as they are required for VIC to work. I still can't believe how much RAM webAccess requires -- more than quadruple that of the virtualization engine itself!
According to pmap, webAccess (which can be found at /usr/lib/vmware/webAccess/java/jre1.5.0_15/bin/webAccess) uses ~485MB of RAM while the virtualization engine, hostd uses just 120MB. So if you'd like to disable that monstrosity, you will have to modify one file. If you don't want to do so without shutting down the virtualization engine itself, you will have to modify the same file twice. Here's how to do it without shutting down the engine.
Modify /etc/init.d/vmware, comment out line 1202:
#vmware_stop_hostdNext, shut down webAccess.
service vmware-mgmt stopThen, open up /etc/init.d/vmware again and uncomment line 1202 then comment out line 1901.
#vmware_start_webAccesshostd is already running so you don't need to stop/restart anything at this point. Now you're done -- later hosebeast of a poorly designed MUI.
Btw, If you want to turn off HTTP/HTTPS access completely (strangely, I didn't see any reduction in memory usage when I did this), comment out the _entire_ <proxysvc> section in the file /etc/vmware/hostd/proxy.xml and restart hostd.
service vmware-mgmt stop && service vmware-mgmt startEdit: Joe @ 4sysops.net points out a downside:
The only down side to doing that is if you use the VI Client you can only create and manage virtual machines at version 4, not version 7 like the web interface uses. So, if you create a VM in WI, you can’t manage it with VI Client. You would want to pick one or the other to use primarily. I prefer the web interface, unless I were to add a VMware Server 2.0 machine to Virtual Center. I am hoping they update virtual center at some point to support version 7 virtual machines.
So you may want to consider that before disabling webAccess. Ultimately, I ended up wiping VMWare Server 2 and using ESXi 3.5 instead.
HP DL380 G4 and VMware: Will NOT Run 64-bit Virtualized Guests.
I mean, I'm not upset about it. I'm just sayin. I read all the Internet debates about how it might or it might not and I can confirm that I tried it and it didn't work. The server runs the host OS, SuSE Linux 64-bit, beautifully but it totally craps out when a 64-bit guest OS install is attempted. EM64T doesn't do VT so.. if that's what you're looking for, start with the HP DL380 G5.
This server still has its benefits however. Including 6 drive slots (2x72,2x147,2x36 SCSI YAY), capacity for up to 12 GB of RAM (I installed 10) and it's decently affordable. Another thing that I love about it is that I can change the POST text. How fun is that? So I made it say something that makes me laugh everytime. See if you can spot it:

Mmm 10240 MB Initialized... *drool*
VMware Server 2 Beta: Use Virtual Infrastructure Client to Speed Up Administration
The web interface for VMware Server 2 Beta for Linux is garbage; it's both slow and unattractive. Even VMware Server 1 and ESX Server 2.5 from years ago had a faster/nicer web interface. VMware Server looks a bit like ESX and my experience with ESX taught me that it can be administered with both the web interface and Virtual Infrastructure Client (VIC). I wondered if perhaps Server 2 could be administered with VIC too and fortunately, my hunch was confirmed by the VMware forums.
VIC on VMware Server Beta 2 is much faster than the web interface and even provides a more information about the VMs resource histories. It can be assumed that pushing the slower web interface for the free product isn't so much tech driven as it is marketing/$$ driven but that's only a guess. VIC is a big part of the high end, high price ESX server but can be also be found hidden in the rpms and tarballs of VMware Server. I could not find it, however, in the Windows version of VMware Server 2, even after extracting contents of the executable using the /a option.
To find the VIC (Windows only client, Linux clients are out of luck) in an RPM, run the following commands:
mkdir vmware
mv VMware-server-e.x.p-63231.x86_64.rpm vmware/
cd vmware
rpm2cpio VMware-server-e.x.p-63231.x86_64.rpm | cpio -i --make-directoriesThe file can then be found at ./usr/lib/vmware/hostd/docroot/client/VMware-viclient.exe. As for the tarball, expand it (tar -xvzf or WinRAR in Windows) and the file can be found at ./vmware-server-distrib/lib/hostd/docroot/client/VMware-viclient.exe.
The thick client is so much nicer; I know it's unlikely that I'll ever use the resource intensive MUI so I uninstalled it by running:
chkconfig httpd.vmware off
vmware-uninstall-mui.plEven though I ran the uninstaller, the MUI magically started up on the next reboot so I modified the permissions on /etc/init.d/vmware and then commented out the following line: $watchdog -s webAccess -u 30 -q 5 "$webAccess $webAccessOpts start" > /dev/null 2>&1 &. I then restarted the vmware service and it worked exactly as I hoped.
Aside from the bad web interface, I'm really impressed by this version of VMware server and I'm definitely recommending it at work once the final arrives. I honestly hope that Microsoft's new virtualization platform can impress me as much and even more once their product matures. As for xen, I successfully set it up in SuSE, it was eas as pie. However, my Opteron 270 doesn't appear to support hardware virtualization (even though AMD's docs say they do, perhaps I have to upgrade my BIOS) so I can't run Windows VMs. Totally unacceptable. xen is something I want to keep an eye on, though. Big companies like Citrix, Oracle and Sun are using it in their own virtualization platforms. Now to find a test server that supports hardware VT...
Update: You can also find the VMware-viclient.exe here on some .edu website. I haven't used it and can't vouch for its safety, but it's there (at least for now) in the event that you don't want to go through all of the above steps. The timestamp on it is December 2007 which is good for now, but I woudln't use it past June 2008.
Install VMware Server 1.0 on SuSE 10.2 x64
Ahh! One of my servers had a bad stick of RAM and caused all sorts of problems with VMWare ESX Server. At first, I thought ESX was too sensitive but later realized the stick was just super bad. Meanwhile, my evaluation version expired and so I decided to use VMware Server 1.0 (free) on top of SuSE 10.2 (also free).
Thankfully, this dude setup a really nice guide to get around some kernel issues in SuSE. It's pretty simple; before installing the VMware Server RPM, I ran the following:
# cd /usr/src/linux
# make mrproper; make cloneconfig; make modules_prepare
After installing the RPM, I ran vmware-config.pl and VMWare complained that a few files were missing. As it turns out, I needed the x86 version of a few packages. I loaded up
Yast -> Software -> Software Management -> Search -> [X] Provides -> [Missing Filename here]. I believe I ended up installing the following packages:
Several.. (many auto-selected themselves)
xorg-x11-libICE-32bit-7.2-13.x86_64.rpm
xorg-x11-libXau-32bit-7.2-8.x86_64.rpm
xorg-x11-libXdmcp-32bit-7.2-8.x86_64.rpm
xorg-x11-libSM-32bit-7.2-12.x86_64.rpm
xorg-x11-libX11-32bit-7.2-13.x86_64.rpm
xorg-x11-libXext-32bit-7.2-12.x86_64.rpm
xorg-x11-libXrender-32bit-7.2-12.x86_64.rpm
xorg-x11-libXt-32bit-7.2-13.x86_64.rpm
expat-32bit-2.0.0-32.x86_64.rpm
xorg-x11-libXfixes-32bit-7.2-13.x86_64.rpm
xorg-x11-libXmu-32bit-7.2-13.x86_64.rpm
xorg-x11-libXp-32bit-7.2-8.x86_64.rpm
xorg-x11-libXpm-32bit-7.2-12.x86_64.rpm
xorg-x11-libXv-32bit-7.2-8.x86_64.rpm
xorg-x11-libxkbfile-32bit-7.2-12.x86_64.rpm
zlib-32bit-1.2.3-33.x86_64.rpm
freetype2-32bit-2.2.1.20061027-11.x86_64.rpm
xorg-x11-libXprintUtil-32bit-7.2-8.x86_64.rpm
xorg-x11-libfontenc-32bit-7.2-12.x86_64.rpm
fontconfig-32bit-2.4.1-19.x86_64.rpm
xorg-x11-libs-32bit-7.2-19.x86_64.rpm
audit-libs-32bit-1.2.6-20.x86_64.rpm
cracklib-32bit-2.8.9-20.x86_64.rpm
libstdc++41-32bit-4.1.2_20061115-5.x86_64.rpm
libxcrypt-32bit-2.4-30.x86_64.rpm
db-32bit-4.4.20-16.x86_64.rpm
pam-32bit-0.99.6.3-24.x86_64.rpmNext, used YaST to open up my firewall's port 902. Everything seemed to go well until I ran into PAM issues while attempting to remotely manage it using the VMWare Server Console (Windows). I received the error Permission denied: Login (username/password) incorrect. So I took a look at /var/log/messages and found this crappy news:
vmware-authd: PAM unable to dlopen(/usr/lib/vmware/lib/libpam.so.0/security/pam_unix2.so)
vmware-authd: PAM [error: /usr/lib/vmware/lib/libpam.so.0/security/pam_unix2.so: cannot open shared object file: No such file or directory]After searching the web for a solution (thanks web!), I edited /etc/vmware/pam.d/vmware-authd and now it looks like the following:
#%PAM-1.0
#auth sufficient /usr/lib/vmware/lib/libpam.so.0/security/pam_unix2.so shadow nullok
#auth required /usr/lib/vmware/lib/libpam.so.0/security/pam_unix_auth.so shadow nullok
#account sufficient /usr/lib/vmware/lib/libpam.so.0/security/pam_unix2.so
#account required /usr/lib/vmware/lib/libpam.so.0/security/pam_unix_acct.so
auth sufficient /lib/security/pam_unix.so shadow nullok
auth required /lib/security/pam_unix_auth.so shadow nullok
account sufficient /lib/security/pam_unix.so
account required /lib/security/pam_unix_acct.soOnce that was done, I created a symbolic link to make restarting VMWare more comfy (ln -s /etc/init.d/vmware /usr/sbin/rcvmware), then I restarted the vmware service (rcvmware restart) and connected successfully from my remote machine. Now I'm happily installing Windows Server 2008 RC0. Hooray!
And my procrastination paid off -- while I was waiting for the motivation to troubleshoot the RAM issue, the price of my server's RAM dropped drastically -- from $160 to $99. Niiiice! I'm buying 5 for a total of 8 Gigs
Installing Longhorn x64 on VMWare ESX Server 3.0.x
I recently attended a Longhorn Roadshow in Santa Clara and learned quite a bit about Microsoft's emphasis on virtualization in Longhorn. A lot of companies are going towards virutalizing servers, even those still running NT or Exchange 5.5. The main reasons seem to be saving rackspace and saving electricity (fewer machines, less A/C) which both translate to saving money. Fortunately, my employer now has the infrastructure setup and virtualization on a mass scale seems like a possiblity. After a quick evaluation, I don't have much faith in Microsoft's current Virtual Server product but an evaluation of ESX Server 3.0 has proven impressive. VMWare has it together and it is likely the solution I'll be recommending in '08 when we're ready to move forward.
That said, it's been tough installing Longhorn x64 on VMWare ESX server. It should be expected, though; the support for Longhorn x64 isn't even experimental yet -- it's non-existent. I had to select Vista 64-bit Experimental as my base VM and hope for the best. What I've experienced is almost as painful as installing Windows 2003 R2 on a Macbook
Most of the frustration revolves around the CD-ROM drivers. The initial install of Longhorn on ESX is so promising but then a message pops up that says: "A required CD/DVD drive device driver is missing." At first, I thought this was because I was using an external USB DVD-R drive but that turned out not to be the case. I figured that gem out only after going through all these steps:
- I installed some dumb .flp that never loaded the CD-ROM drivers as promised
- I asked a friend to bring me an internal CDROM only to find out it's EIDE and my server doesn't support it
- I took my work workstation's IDE CD-ROM and hooked it half-up to my server (the IDE cable) and half-up to a workstation (the power cable because my server didn't have any free power cables left).
- Enabled IDE in the BIOS and finally had ESX recognize the drive
- Still had the same problem
So then I got creative and decided to create the Longhorn image on another workstation. Doh! The workstation's CPU was not 64-bit enabled. So then I tried it on my laptop.. doh! It's 64-bit enabled but doesn't have some special VT chip that's often times not found in laptops. This is why I hate hardware.
So I gave in and ..
- Wiped ESX and reinstalled Longhorn 64-bit.
- Installed the free VMware server, created a Longhorn Virtual Machine and installed Longhorn
- Once the install was complete, I backed up the vmdk to another machine
- I then wiped Longhorn on the server, resinstalled ESX and copied the vmdk to /vmfs/volumes/storage1/longhorn
- Next, I ran vmkfstools -i longhorn-64ws.vmdk longhorn-64esx.vmdk
- Once that was done, I created a new Virtual Machine within ESX and selected Custom then used the new image longhorn-64esx.vmdk
Ahhh, that worked! But now VMWare tools was giving me trouble. The CD-ROM still didn't work (the CD-ROM, listed as NECVMWar VMWare IDE CDR00 ATA Device, gives the status of "The Device Cannot Start" (Code 10)) so I had to figure out another way around the problem. I copied the windows.iso from /vmimages/tools-isoimages to my workstation using Veeam FastSCP, mounted the ISO, saved the files as a zip under my web root then used IE on the Longhorn server to fetch the zip. Installed and voila, it works!





