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.

Forbinde til en VM i KVM med virsh console

En nem måde at forbinde til en KVM VM er ved brug af kommandoen virsh console ‘vm-name’. Man forbinder direkte til konsollen, og på den måde er man uafhængig af netværk. Mon ikke de fleste har prøvet at rive sig selv i håret, når man opdager at man har lukket sig selv ude fra SSH.

Når man først er inde skal man jo også ud igen, hvis man er vant til at arbejde med SSH skriver man naturligt exit når man vil ud, men så ender man bare i login prompten, stadig på den samme maskine. Når man logger ind kommer et fint lille hint der fortæller at “Escape character is ^]”, og hvad betyder så det? Jo, det må være noget med “Ctrl+AltGr+9”, jeg kan afsløre med det samme at det virker ikke. På min maskine med dansk tastatur layout er det “Ctrl+5”, det er jo dejligt nemt, når man først har brugt ½-1 time på at finde ud af det 🙂

Alt i alt en nem og hurtig måde at logge ind på de enkelte virtuelle maskine og måske endnu vigtigere en god backup, hvis man har dummet sig med netværket.

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.

Langsom opstart af citrix sessioner på linux.

Jeg har tit undret mig over at mine Citrix xendesktop sessioner der startes op via et webinterfcae på en citrix access gateway, starter langsommere op på linux maskiner end på windows, i dag fandt jeg så en løsning (og en forklaring).

Vi starter med løsningen:

sudo ln -sf /dev/urandom /dev/random

Forklaringen må i få en anden dag 🙂

Og den kommer nu….

Både /dev/random og /dev/urandom bruges til at lave tilfældig data på et linux system. Begge filer opbygges ved at opsamle tilfældige data på systemet f.eks. når man arbejder med et program der placerer data i hukommelsen. Forskellen er at /dev/random stopper med at producere data når der ikke længere produceres data på maskinen, det er derfor man kan starte Citrix sessionen hurtigere op ved at køre musen rundt på skærmen, eller ved at åbne andre programmer mens man venter. /dev/urandom stopper derimod ikke med at producere tilfældig data, den genbruger den data der allerede er opsamlet, og bygger videre med eksisterende data.

Derfor er det også anbefalingen at bruge /dev/random når den tilfældige data skal bruges til at lave kryptering, da der teoretisk er en mulighed for at forudsige den tilfældige data.

Citrix gør altså hvad de skal, men det tager bare så lang tid 🙁

Hvordan gøres dette på Windows? Her starter sessionen også med det samme, ligesom hvis man bruger /dev/urandom på linux.

Fejl i Citrix Receiver for Linux amd64 (x86_64)

Den for tiden nyeste Citrix Receiver for Linux der er frigivet d. 23 April 2012 kan downloades i en 64bit deb pakke fra Citrix’ download område. Men der er et problem med pakken der gør at man får en irriterende fejl under installationen.

Jeg have hentet pakken og forsøgte at installere den på min Ubuntu 12.10 med kommandoen:

sudo dpkg -i icaclient_12.1.0_amd64.deb

Ovenstående resulterer i denne fejl:

E: Sub-process /usr/bin/dpkg returned an error code (1)

Fejlen skyldes at der under installationen laves at arkitektur check der fejler og derfor ikke kan finde den korrekte arkitektur for systemet. Dette rettes ved at finde denne fil:

/var/lib/dpkg/info/icaclient.postinst

Her skal følgende rettes:

echo $Arch|grep “i[0-9]86” >/dev/null
if [ $? -ne 0 ]; then
NotIntel=1
fi

Til:

echo $Arch|grep -E “i[0-9]86|x86_64” >/dev/null
if [ $? -ne 0 ]; then
NotIntel=1
fi

Nu finder scriptet arkitekturen og kører igennem uden fejl. Koden der skal rettes begynder i linie 2648.

Citrix Receiver for Linux, SSL error 61

Citrix leverer af en eller anden grund ikke SSL certifikater fra de dominerende udbydere med i deres installation af receiver klienten. Det betyder at man får denne fejl når man forsøger at logge på f.eks. en VDI maskine:

Citrix receiver error messageLøsningen er at kopiere det nødvendige certifikat fra udbyderen man bruger ind i cacerts mappen der ligger under: /opt/Citrix/ICAClient/keystore/

Den hurtige løsning er at tage de certifikater der følger med firefox installationen (hvis man har den installeret) og kopiere dem ind:

sudo cp /usr/share/ca-certificates/mozilla/*.crt /opt/Citrix/ICAClient/keystore/cacerts/

Ovenstående kommando løser problemet i de tilfælde hvor man bruger en leverandør som er med i de certifikater firefox installerer. (De fleste jeg har prøvet)

Citrix receiver til Linux med flere skærme.

Der sker desværre ikke så meget i udviklingen af citrix klienten til Linux kaldet “Citrix Receiver for Linux”. Windows og Mac versionerne er en del foran når det kommer til brugervenlighed på klienten. Med brugervenlighed mener jeg at man i de andre klienter super nemt kan konfigurere brugen af USB, HDX og brugen af flere skærme, det skal selvfølgelig være super svært og nørdet i Linux klienten. Jeg vil herunder komme med et eksempel fra det virkelige liv (mit) for at understrege forskellighederne.

Hvis man på en windows maskine vil have sin citrix session til at strække sig over flere skærme gør man følgende:

  1. Start en session op og sørg for at den kører i “window” mode. (altså ikke maximeret)
  2. Træk vinduet ind midt på de to skærme, så halvdelen af vinduet med citrix sessionen er på hver skærm.
  3. Maximer vinduet.

Nu kører du i en session der strækker sig over to skærme.

På en linux klient skal man gøre følgende:

  1. Brug adskellige timer, måske dage på at søge i diverse forummer og i dokumentation fra citrix.
  2. Find ud af at wfica programmet i /usr/lib/ICAClient/ mappen understøtter en række attributter.
  3. Prøv at køre programmet med -span attributten og modtag følgende fejlmeddelelse:
    kasper@laptop:/usr/lib/ICAClient$ ./wfica -span h
    Error: 12 (E_MISSING_INI_ENTRY)
    Please refer to the documentation.
    Error in configuration file.
    Section “ApplicationServers” must contain an entry “”.
    kasper@laptop:/usr/lib/ICAClient$ ./wfica -span o
    Error: 12 (E_MISSING_INI_ENTRY)
    Please refer to the documentation.
    Error in configuration file.
    Section “ApplicationServers” must contain an entry “”.
    kasper@laptop:/usr/lib/ICAClient$ ./wfica -span a
    Error: 12 (E_MISSING_INI_ENTRY)
    Please refer to the documentation.
    Error in configuration file.
    Section “ApplicationServers” must contain an entry “”.
    kasper@laptop:/usr/lib/ICAClient$
  4. Find på ubeskrivelig vis frem til at der skal stå “-span 1,2” og forsøg nu at finde ud af hvordan man sørger for at denne attribut bliver kørt når man vil starte en virtuel desktop fra citrix webinterfacet.
  5. Find ud af at attributten skal sættes ind som en environment variabel.

Kommandoen “wfica -span h” burde returnere en liste med de skærme man kan angive som aktive, og som man gerne vil have strukket sessionen ud over, jeg aner ikke hvorfor jeg får ovenstående fejl.

Altså: for at citrix sessionen skal strække sig over 2 eller flere skærme skal man definere environment variablen WFICA_OPTS. Det gøres sådan her:

export WFICA_OPTS=”-span 1,2″

Dette kan f.eks. sættes ind i /$HOME$/.bash_profile eller en anden fil der køres når maskinen starter op.

Nu skulle det gerne virke 🙂

Jeg siger ikke at alle er ligeså tungnemme som mig, og skal bruge både halve og hele dage på at finde ud af ovenstående, men min påstand er altså at det er langt nemmere på windows platformen. Og det irriterer mig grænseløst når man tænker på at hele virtualiserings cirkusset (for Vmware og Citrix’ vedkommende) er bygget på Linux.