Kill unresponsive VM from ESXi cli

Sometimes a VM can go in an unresponsive mode and you cannot shut it down or reboot it from the vSphere client. When this happens we need to be more persuasive in telling the VM to shut down. Log in to the ESXi server with SSH, find the World ID for the unresponsive VM and kill the process, this is done like this:

esxcli vm process list

This will list all the running VMs on the server, use grep -A2 to filter the VM name and the world ID, like this:

esxcli vm process list |  grep -A2 “VM Name”

Kill the process with this command:

esxcli vm process kill -t=soft -w=”WORLD_ID”

This will kill the process in a “soft” way, use -t=hard to be even more persuasive and as a last resort attempt you can use -t=force. If none of the three shuts down the VM, a reboot of the host is required.
To automate things a bit i assembled this one-liner for easy use:

esxcli vm process kill -t=soft -w=`esxcli vm process list | grep -A2 “VM Name” | grep World | awk ‘{print $3}’`

This will softly shut down the VM with “VM Name”

Add new virtualportgroup to vSwitch on multiple VMHosts with Powercli

If you dont have dvSwitches (Distributed vSwitches) in your vSphere cluster, or dont even have a cluster, you may have to add new portgroups manually, depending on the number of VMHosts this can be a pretty cumbersome task.

Luckily, we can use powercli to automate the task. In the following example i will use the -location parameter to define my tagets in the variable $hosts

Lets go ahead and define the VMhosts we want to target:

$hosts=get-vmhost -location “location”

Then, we create the new portgroup for every VMhost in the location by using a foreach loop:

foreach ($vmhost in $hosts) {Get-VMHost $vmhost | Get-VirtualSwitch -name “vSwitch0” | New-VirtualPortGroup -VLanId “10” -Name “Name”}

This will create a new VirtualPortGroup with VLAN ID 10 named “Name” on vSwitch0 on all the VMHosts in the specified location.

Remove the port again by doing this:

foreach ($vmhost in $hosts) {Get-VMHost $vmhost | Get-VirtualSwitch -name “vSwitch0” | Get-VirtualPortGroup -Name “Name” | Remove-VirtualPortGroup -Confirm:$false}

Remember that -Confirm:$false will remove the port without confirmation! Make sure you have the right targets in the $hosts variable!!!

Saving and restoring ESXi configuration, and fixing VMKCore coredump partition dump issues

Hi all.
Today i had to reinstall some ESXi 5.5 hosts as we were upgrading to SSD disks, in order to have more performance on the Citrix environment we are hosting.

Before i powered off the server, i saved the configuration to use for easy reconfiguration with the following command from powercli:

Get-VMHostFirmware -VMHost xxx-hostname-xxx -BackupConfiguration -DestinationPath C:\HostBackups\

Now i got a xxx.tgz file containing the full configuration of the original ESXi host, ready for importing back when the reinstall is done.

When the server was installed on the new disks, i connected directly to the reinstalled server by its IP address,  put the server in maintenance mode and imported the configuration backup with these commands from powercli:

Set-VMHost -State Maintenance

 

Set-VMHostFirmware -VMHost xxx-hostname-xxx -Restore -SourcePath c:\HostBackups\xxx.tgz -HostUser user -HostPassword password

Because of the new disks i got an error regarding my vmkcore vmkdumpfile that was missing. I was able to list the partition table, which showed that i had two different dump partitions, but none of them were configured for use.
To get it fixed i had to unconfigure the existing coredump partition with this command from the ESXi shell:

esxcli system coredump partition set -u

And then reconfigure the partition with this command, also from the ESXi shell:

esxcli system coredump partition set –enable true –smart

This command will let the system choose which partition to use for the coredumps. The system will now use the choosen partition, no reboot needed.

Eksportere VM’er fra VMware workstation til ESXi

En god ting ved virtualisering er at alle kan “lege” med deres eget setup lokalt på deres egen maskine, når alt så er som det skal være, vil man måske gerne have flyttet sin maskine over i et rigtigt produktionsmiljø, men hvordan gør man lige det?

VM’en skal i Workstation eksporteres som en OVF fil, det gøres sådan her:

File -> Export to OVF

Selve processen i at eksporere kan tage et stykke tid alt afhængig af størelsen på diskene.

Når VM’en er eksporeret skal den importeres i ESXi, det gøres sådan her:

File -> Deploy OVF template -> Deploy from a file or URL

Find din OVF fil, start processen.

Det var det 🙂

Update!

Hvis VMX Hardware versionen er nyere på din VMware workstation end på din ESXi installation, kan du ikke umiddelbart importere din VM. Dette kan fixes ved at rette i ovf filen der nogenlunde svarer til vmx filen i en normal installation. Åben ovf filen og led efter en linie ala denne:

<vssd:VirtualSystemType>vmx-09</vssd:VirtualSystemType>

Her skifter du nummeret ud med det der passer til din hardware version, f.eks.:

<vssd:VirtualSystemType>vmx-07</vssd:VirtualSystemType>

Når dette er gjort skal vi have lavet en ny checksum på ovf filen. Checksummen findes i mf filen og skal stemme overens med virkeligheden, ellers kan man ikke importere. Du kan f.eks. generere en ny checksum med fciv ved at køre denne kommando:

fciv.exe -sha1 vmfilename.ovf

Den nye checksum nøgle erstattes med den eksisterende i .mf filen, nu er du klar til at importere din VM.