Monday, November 26, 2012

Kill a VM (The HARD way)!!

Use this method only after you have tried every other method.

If you have a VM that will not power off or reboot first attempt all of the following methods to shutdown the VM:

  • Shutdown in vCenter
  • Connect vCenter client to host and shutdown
  • Perform a Stop-VM command in Powershell
    • Stop-VM -VM -Kill -Confirm:$false


If after all of these methods fail you can still power down a VM by killing the WorldID on the ESXi hosts

1.  SSH into the host
2. Get a list of all running VMs

  • esxcli vm process list

3. Once you have found your VM document is World ID
4. Issue the following command to kill the VM

  • esxcli vm process kill --type=[soft,hard,force] --world-id=WorldNumber
    • This command may require the --type=hard option to be successful.

Wednesday, November 14, 2012

Remove an inactive datastore from the vCenter Server inventory



This issue may occur if the datastore was removed from the ESX host before removing it from the vCenter Server Inventory.

To resolve this issue, you must manually remove the datastore references from the vCenter Server Inventory.

To manually remove the datastore references from the Inventory:

Notes:
  • Back up the database before proceeding.
  • Ensure that the datastore is not referenced by any virtual machine.
  1. Stop the VMware VirtualCenter Server service on the vCenter Server. 
  2. Launch SQL Management studio connected to the vCenter Server database.
  3. Run this query to identify the datastore ID in the vCenter Server database:

    select ID from VPX_ENTITY where name ='';
    Where  is the datastore to be removed. The query returns the ID of the datastore.
  4. To remove the datastore from the vCenter Server database:

    1. Run these queries to delete the datastore from the VPX_DS_ASSIGNMENT and VPX_DATASTORE tables:

      delete from VPX_DS_ASSIGNMENT where DS_ID=;
      delete from VPX_VM_DS_SPACE where DS_ID=;
      delete from VPX_DATASTORE where ID=;
      Where  is the output of Step 3.
    2. Run this query to delete the datastore from the entity table:

      delete from VPX_ENTITY where ID=;
  5. Run these queries to verify if the datastore has been removed from the VPX_ENTITYVPX_DS_ASSIGNMENT, andVPX_DATASTORE tables:

    Note: If the datastore references are successfully removed, these queries do not display any results.

    select * from VPX_DS_ASSIGNMENT where DS_ID=;
    select * from VPX_VM_DS_SPACE where DS_ID=;
    select * from VPX_DATASTORE where ID=;
    select * from VPX_ENTITY where ID=;
  6. For the database changes to take effect, restart the VMware VirtualCenter Server service on the vCenter Server.

Wednesday, August 22, 2012

Failed to remove VM: null Fix


When you perform a restore of a vCenter server that supports a VDI environment, you may encounter an issue where you start getting desktops showing up as “Error: Failed to delete VM: null”.  Here are the procedures to correct this problem

1. First disable provisioning on the VDI pool
a. Open View Administrator
b. Click on the pool with the problem
c. Click on the “Status” button
d. Select “Disable Provisioning”

2. Delete all desktops from the pool
a. Click on the “Inventory” tab
b. Shift + Click the first and last desktops
c. Click the “Remove” button

3. Wait till View has a chance to process the deletions (about 5 min)

4. After the 5 min. go into vCenter and manually delete any VMs that may have not gotten deleted. (Do not delete the template VM)

5. Go into ADUC and delete any computer objects that may not have been removed. (Do not delete the template VM computer object)

6. RDP into the View Connection Broker server and follow the instructions on this VMware KB article link to remove any orphaned objects from the ADAM DB on the Connection Broker.
______________________________________________________________________________
Removing the virtual machine from the ADAM database
Note: Before removing entries from the ADAM database, note the virtual machine name of the desktops that are being removed for reference when editing the Composer Database.

1. Connect to the View ADAM Database. For more information, see Connecting to the View ADAM Database (2012377).

2. Locate the GUID of the virtual machine.

To locate the GUID of the virtual machine:

a. Right-click the Connection View ADAM Database [localhost:389], and click New > Query.
b. Under Root of Search, click Browse.. and select the Servers organizational unit.
c. Click OK.
d. In the Query String, paste this search string:

(&(objectClass=pae-VM)(pae-displayname=VirtualMachineName))

Where VirtualMachineName is the name of the virtual machine for which you are trying to locate the GUID. You may use * or ? as wildcards to match multiple desktops.

e. Click OK to create the query.
f. Click the query in the left pane. The virtual machines that match the search are be displayed in the right pane.

3. Record the GUID in cn=
______________________________________________________________________________
Delete the pae-VM object from the ADAM database:

1. Locate the OU=SERVERS container.

2. Locate the corresponding virtual machine's GUID (from above) in the list which can be sorted in ascending or descending order, choose Properties and check the pae-DisplayName Attribute to verify the corresponding linked clone virtual machine object.

3. Delete the pae-VM object.

Notes:
Check if there are entries under OU=Desktops and OU=Applications in the ADAM database.
A broken pool that does not contain any desktops can be removed from View Manager by removing the pool entry from both the Server Groups and Applications organizational units. However, removing one entry and not the other from the ADAM database results in the java.lang.nullpointerexception error when attempting to view the pools or desktops inventory in View Manager.
______________________________________________________________________________
7. Re-enable provisioning on the VDI pool.

8. Monitor the pool to ensure desktops are created successfully

Friday, August 10, 2012

DRS Rule Export \ Import

As the title says, this is a Powershell Method for exporting all of your DRS rules to a .txt file that can later be used to import the rules back into a cluster.

It is great for cases where you wish to keep a back of your rules or are looking to migrate to a new vCenter server and do not wish to manually create all your DRS rules again.

Export: 
$outfile = "C:\rules.txt"
$rules = get-cluster | Get-DrsRule
foreach($rule in $rules){   $line = (Get-View -Id $rule.ClusterId).Name   $line += ("," + $rule.Name + "," + $rule.Enabled + "," + $rule.KeepTogether)   foreach($vmId in $rule.VMIds){     $line += ("," + (Get-View -Id $vmId).Name)   }   $line | Out-File -Append $outfile }

Import: (Assumes your export was written to c:\rules.txt)
$file = "C:\rules.txt"
$rules = Get-Content $file
foreach($rule in $rules){   $ruleArr = $rule.Split(",")   if($ruleArr[2] -eq "True"){$rEnabled = $true} else {$rEnabled = $false}   if($ruleArr[3] -eq "True"){$rTogether = $true} else {$rTogether = $false}   get-cluster $ruleArr[0] | `     New-DrsRule -Name $ruleArr[1] -Enabled $rEnabled -KeepTogether $rTogether\     -VM (Get-VM -Name ($ruleArr[4..($ruleArr.Count - 1)])) }

Delete VM then Clone VM Powershell script

I recently found myself in a situation where I needed to create an automated taks that would create a clone of a VM on a weekly basis.

Now I know there are tools and software out there that can take full VM backup and I run vRanger on the majority of my VMs, but this was a special case senerio.

So below is a script that will first check to see if there is already a snapshot of my vm, if so it deletes it, then it will make a new clone. If there are any errors in the process it will email me.

$date = Get-Date
$vcServer = "vcenter.you.com"
$fromVMname = "SourceVM"
$newVMName = "CloneVM"
$tgtEsxName = "ESXi.you.com"
$tgtDatastoreName = "Datastore1"
$userName = "account"
$passWord = "password"
$notes = ("Clone of: " + $fromVMname + " for backup. Created on: " + $date)

# Connect to the vCenter Server

Connect-VIServer -Server $vcServer -User $username -Password $passWord




#
# Test to see if $newVMname already exists in vCenter Server and 
# set $vmExist to a value other than $null if it does
$vmExist = Get-VM -Name $newVMname -ErrorAction SilentlyContinue


#
# Delete the VM $newVMname if $vmExist returns a value other than $null
if ($vmExist -ne $null)
{
 Remove-VM -deletefromdisk -VM $newVMName -confirm:$false
}
#
# Create a clone of $fromVMname to $newVMName, email if there is an error
$cloneTask = New-VM -Name $newVMName -VM (Get-VM $fromVMname) -VMHost (Get-VMHost $tgtEsxName) -Datastore (Get-Datastore $tgtDatastoreName) -RunAsync
Wait-Task -Task $cloneTask -ErrorAction SilentlyContinue
Get-Task | where {$_.Id -eq $cloneTask.Id} | %{
     if($_.State -eq "Error"){
          $event = Get-VIEvent -Start $_.FinishTime | where {$_.DestName -eq $newVMName} | select -First 1
          $emailFrom = VDIPowerCLI@you.com
          $emailTo = me@you.com
          $subject = "Clone of " + $newVMName + " failed"
          $body = $event.FullFormattedMessage
          $smtpServer = smtp.you.com
          $smtp = new-object Net.Mail.SmtpClient($smtpServer)
          $smtp.Send($emailFrom, $emailTo, $subject, $body)
     }
}
#
# Set the notes field of the VM $notes
Set-VM -VM $newVMName -Notes $notes -confirm:$false
#
#Disconnect from the vCenter Server
Disconnect-VIServer -Server $vcServer -Confirm:$false 


With the script created I setup a Windows Scheduled task on my vCenter server to run this script once a week.

So far it has been working well.

Helpful VMware View PowerShell Scripts

Disable Provisioning in all linked clone pools:
$pools = get-pool
$pools | Update-AutomaticLinkedClonePool -isProvisioningEnabled:$false
Gets list of all View related cmdlets:

get-command | where {$_.modulename -match 'vmware.view'}
#Below is so you can include it into the 
#add-pssnapin.ps1 under your View installation directory
function get-viewcommand {get-command | where {$_.modulename -match 'vmware.view'}}
Gets list of pools, max number of VM's, and datastores associated:

#Helps in making sure your pools are distributed across evenly among datastores.
Get-Pool | Select Pool_ID, MaximumCount, DatastorePaths

Tuesday, April 24, 2012

Installing offline bundles onto an ESXi server remotely.

Installing offline bundles onto an ESXi server may sound difficult at first, but it is actually very easy. 

1. First aquire your 'offline-bundle.zip' file and store it in the same directory you installed the RemoteCLI to.
2. Open a RemoteCLI window
3. Run the vihostupdate.pl command using the following parameters:
              --server 'servername'
              --username
              --password
              --install
              --bundle 'bundle file from step 1'
              --nosigcheck

An example of a complete command string:
         vihostupdate.pl --server ABCD.your.domain --username joe --password abcd1234 --install --bundle offline-bundle.zip --nosigcheck

Change Pathing Policy Script

The following commands can be ran in PowerCLI to display / change the pathing policy of your datastores in ESX and ESXi.

!!! Before you perform any of these commands, I do recommend the ESX\ESXi host be placed in maintenance mode, to prevent any possible service interruptions!!!

'Display all Storage Information
Get-VMHost servername.your.domain | Get-ScsiLun | Select CanonicalName, MultiPathPolicy, Model

'Check Path Selection and path model name (model name will be needed later)
Get-VMHost servername.your.domain |Get-ScsiLun -LunType “disk” |format-table VMHost,CanonicalName,MultiPathPolicy,Model –autosize

The above command should give you results that look something like:


VMHost                            CanonicalName                   MultipathPolicy     Model
------                                 -------------                       ---------------         -----
servername.your.domain     naa.################a   Fixed                ABCD
servername.your.domain     naa.################b   Fixed                ABCD

' Using model name from above (ABCD), Verify selection criteria this criteria will be used on the next command to change things so verify to be sure you get the right results,
Get-VMHost servername.your.domain |Get-ScsiLun -LunType “disk” |where {$_.MultipathPolicy –ne “RoundRobin” -and $_.model -like “*ABCD*”} |format-table VMHost,CanonicalName,MultiPathPolicy,Model –autosize

' Change Path Selection for all luns that match the above selection criteria
Get-VMHost servername.your.domain |Get-ScsiLun -LunType “disk” |where {$_.MultipathPolicy –ne “RoundRobin” -and $_.model -like “*ABCD*”} |Set-ScsiLun -MultipathPolicy "RoundRobin"

' Run this command again, you should now get no results
Get-VMHost servername.your.domain |Get-ScsiLun -LunType “disk” |where {$_.MultipathPolicy –ne “RoundRobin” -and $_.model -like “*ABCD*”} |format-table VMHost,CanonicalName,MultiPathPolicy,Model –autosize

' Run this command and verify you get RoundRobin for all paths
Get-VMHost servername.your.domain |Get-ScsiLun -LunType “disk” |where {$_.model -like “*ABCD*”} |format-table VMHost,CanonicalName,MultiPathPolicy,Model –autosize

Wednesday, March 14, 2012

Force mounting LUNs in ESXi


  • Log in as root to the ESX host which cannot mount the datastore using an SSH client. For more information, see Unable to connect to an ESX host using Secure Shell (SSH) (1003807).
    Note: All of the commands listed are available in ESXi via the vSphere CLI.
  • Run the command:

    # esxcfg-volume -l
    The results appear similar to:


    VMFS3 UUID/label: 4b057ec3-6bd10428-b37c-005056ab552a/ TestDS
    Can mount: Yes
    Can resignature: Yes
    Extent name: naa.6000eb391530aa26000000000000130c:1 range: 0 - 1791 (MB)
    Record the UUID portion of the output. In the above example the UUID is 4b057ec3-6bd10428-b37c-005056ab552a.
    Note: The Can mount value must be Yes to proceed with this workaround.
    Note: The esxcfg-volume command has been depreciated in ESXi 5.0 in favor of the esxclicommand. For more/related information, see vSphere handling of LUNs detected as snapshot (1011387).
     
  • Run the command:

    # esxcfg-volume -M
    Where the  is the value recorded in step 3.

    Note: If you do not wish the volume mount to persist a reboot, the -m switch can be used instead.
  • Monday, February 6, 2012

    Converting a VMDK from IDE to SCSI

    Yet another great tip that just saved me some time.  Follow these instructions to convert an IDE VMDK to a SCSI VMDK.

    KB Article: 1016192
    • Important note: You cannot increase the size of an IDE drive in Virtual Center so converting to SCSI is handy in the event that you need to make the disk bigger.

    Converting a virtual IDE disk to a virtual SCSI disk

    Symptoms


    • Virtual machine contains an IDE virtual disk as the primary OS bootable disk after conversion from physical source.
    • Virtual machine has an IDE virtual disk but the additional secondary virtual disks are SCSI with an LSI or Bus Logic controller.
    • Virtual machine fails to boot with only a black screen after conversion with possible underscore. The Primary disk is an IDE virtual disk but LSI or Bus Logic was selected during conversion.
    • After conversion using P2V, the virtual machine fails to boot.
    • Virtual machine created after P2V failed between 95% and 99% and fails to boot.
    • After powering off a virtual machine, you are unable to increase the size of its hard disk(s) when the disk is not SCSI based.

    Resolution


    When converting a physical machine to a virtual machine using VMware Converter or vCenter Converter Enterprise, if an adapter type is not selected during the initial customization the resulting virtual machine may contain an IDE disk as the primary OS disk.

    You must convert the IDE disk to SCSI to get the best performance. If the primary disk is an IDE virtual disk, the newly converted virtual machine may fail to boot because the guest OS does not support the driver. Second reason for this issue is that in ESX 4.x the default disk type for Windows XP 32bit virtual machine creation is IDE. This default value can be manually changed during the virtual machine creation wizard by selecting the custom option. Windows XP 64bit will still use SCSI by default.
    Note: For newer versions of Windows and Linux OS guests, the typical SCSI adapter types are the LSI Logic controllers. When using LSI Logic SCSI controllers in the Windows XP virtual machine, ensure to download and install the appropriate LSI driver before proceeding. For more information on downloading and installing LSI Logic SCSI drivers, see Storage Drivers for ESX 3.5.x and Microsoft Windows XP When Using the VMware LSI Logic Storage Adapter (1007035).

    To convert the IDE disk to SCSI:
    1. Locate the datastore path where the virtual machine resides.For example:/vmfs/volumes///
    2. From the ESX Service Console, open the primary disk (.vmdk) in a text editor.
    3. Look for the line:ddb.adapterType = "ide"
    4. To change the adapter type to LSI Logic change the line to:
      ddb.adapterType = "lsilogic"

      To change the adapter type to Bus Logic change the line to:

      ddb.adapterType = "buslogic"
    5. Save the file.
    6. From VMware Infrastructure/vSphere Client:
      1. Click Edit Settings for the virtual machine.
      2. Select the IDE virtual disk.
      3. Choose to Remove the Disk from the virtual machine.
      4. Click OK.

        Caution: Make sure that you do not choose Remove from disk.
    7. From the Edit Settings menu for this virtual machine:
      1. Click Add > Hard Disk > Use Existing Virtual Disk.
      2. Navigate to the location of the disk and select to add it into the virtual machine.
      3. Choose the same controller as in Step 3 as the adapter type. The SCSI ID should read SCSI 0:0.
    8. If a CDROM device exists in the virtual machine it may need to have the IDE channel adjusted from IDE 0:1 to IDE 0:0. If this option is greyed out, remove the CD-ROM from the virtual machine and add it back. This sets it to IDE 0:0.

    Additional Information


    In some cases, a primary operating system virtual disk is set up as IDE while the additional virtual disks are set up as LSI or Bus Logic SCSI disks. In this situation, after editing the IDE disk adapter type and removing the disk from the virtual machine in Edit Settings, you must change the SCSI channel for the secondary disks to free up SCSI 0:0 for the main OS disk.
    Change the SCSI 0:0 disk to SCSI 0:1, then when you add the primary OS disk back into the virtual machine with the new LSI Logic adapter type, you can select SCSI 0:0 for the disk.
    Target virtual machines that were converted to ESX 4.0 or ESXi 4.0 hosts using volume-based cloning fail to start up if they contain IDE disks. For more information, see the VMware vCenter Converter Standalone 4.0.1 Release Notes.