Category Archives: vmware

Find and unmount CD drives with PowerCLI

Posted on by
Reply

Sometimes someone forgets to unmount the CD drive of a VM. This will interfere with operation tasks like setting a host in maintenance mode or using Update Manager.

I recently had this issue, and the “update manager compliance check” told me that several VM’s where connected to a CD drive, which may interrupt the update process. I quickly found my favorite tool for vcenter management, the powerCLI. The quick and dirty oneliner ended up like this:

get-cluster %clustername% | get-vm | where {(($_ | Get-CDDrive).isopath) -gt ""} | %{$_ | Get-CDDrive | Set-CDDrive -NoMedia -Confirm:$false}

Replace %clustername% with your cluster name, and all your troubles will be over 🙂

I have always loved oneliners. I have spent the part time of my time working in bash terminals, where the history has always been persistent. Luckily Microsoft has also seen the light, and history is now persistent (and searchable) in powershell. Search for a phrase using ctrl+r, search further back by pressing ctrl+r again. I’m sure you will learn to love it, if you don’t already do.

Upgrading from vSphere VCSA 6.5 pre version U1d to post version U1d not possible

Posted on by
Reply

Yesterday I had to upgrade a VCSA 6.5 U1b to U2e, but I got stuck in the process because the VCSA manager said this:

Latest updates already installed on vCSA, Nothing to stage/install

Hmm, thats not right… google, google, google
Seems that vmware changed the build numbering scheme, and they have an article about my issue:
https://kb.vmware.com/s/article/59659
Unfortunately the link to the attachement was dead 🙁 I had to create a case with vmware support to get the shell script.
So, to prevent this from happening again, heres the four lines thats in the script:

sed -i “s/if metadata[‘buildnumber’] <= _getBaseBuildNumber():/if int(metadata[‘buildnumber’]) <= int(_getBaseBuildNumber()):/g” /usr/lib/applmgmt/base/py/vmware/vherd/base/software_update.py
service-control –stop applmgmt
service-control –start applmgmt

Create a file on your VCSA in /root/ called buildversion.sh, paste the four lines above into it. Make it executable, run it, upgrade your VCSA.

SFTP files to vSphere vcenter Appliance 6.5 or vSphere PSC

Posted on by
Reply

When logging in with SSH the default shell on these platforms is some vmware specific menu based system. In order to get a real shell you need to type shell. But this is not possible when using sftp, therefore you need to tell your tool to use a real shell.

In WinSCP this is done by configuring the advanced connection parameters for the sftp protocol connection. Press the advanced button and head for the sftp paragraph. In here you need to specify the sftp-server as your shell in the SFTP server text box.
The sftp-server path may change depending on specific version, find the path on your system by running: “find / -name sftp-server”.

On my system the sftp-server was in /usr/libexec/sftp-server. Therefore i had to specify “shell /usr/libexec/sftp-server” as the SFTP-server.

 

Kill unresponsive VM from ESXi cli

Posted on by
Reply

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

Posted on by
Reply

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

Posted on by
Reply

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

Posted on by
Reply

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.