VMware: How to save lost VMs

In this post I will show you how you can save lost VMs.
Especially those that claim they cannot find thier hard drive after a firmwareupgrade.

However if you take a look at what file on the storage that hard drive points to the file is still there.
If you now disconnect the harddrive and add a "existing hard drive" you cannot select it.

What files are relevant

To address the issue we will first have to look at what files we will have to touch

  • .vmdk - Pointer to the virtual hard drive
  • -flat.vmdk - the actual hard drive file
  • .vmx - The file describing the VM

Enable SSH

You will need to enable SSH on the hypervisor to apply the fix
Since it is just that intuitive, here a little graphic.

Setup a new VM

Create a new VM and name it what ever you want (different then the original) and give it a 10GB Harddrive with the same hardware configuration as the defect VM.
You do not want the a server that expects two network cards to boot up finding only one or be unable to start a database as it suddenly has way less RAM available.

Check how much storage is left and that a copy of the VM fits cosily into the remaining space.
(A good value to go by as proven to be 10% of the Storage should remain unused. If your storage is 10TB or more, 5% free should do.)

In this case the size of the VM is 250GB and I have about 2TB left.

Copy the hard drive

Connect to the ESXi host using SSH and navigate to the directory of your new VM.
As the storage in this example is named "Storage" the command looks like this:

cd /vmfs/volumes/Storage

Do not wonder if you prompt is showing a different path.
Storage is just a softlink pointing to the real path of the storage in the /volumes directory.

Now go ahead and delete the current -flat.vmdk of the newly created VM.

rm ./<Name der Neuen VM>-flat.vmdk

Then you copy the -flat.vmdk of the old VM into the directory of the current new one and give it the name of the -flat.vmdk you just deleted.

cp ../<NAME OF THE OLD VM>/<NAME OF THE OLD VM>-flat.vmdk ./<NAME OF THE NEW VM>-flat.vmdk

If the name of the old VM were "broken" and the name of the new VM "working" the command would look like this.

cp ../broken/broken-flat.vmdk ./working-flat.vmdk

The prompt will freeze until the copy process is complete.
This can take a while, depending on the read/write speed of the storage.

In my case it took over 1 hour to copy 250GB...
DO NOT turn on the VM once the copy process has finished.

 

Enlarge the Harddrive

The .vmx currently describes the connected harddive as 10GB in size.
Go to the settings of the new VM and enlarge the harddrive to the original size +10GB.

You should now be able to start the VM.
If you are starting a windows server it can take quite some time on the first bootup after the restore.

The server will start with DHCP as it detected a new unconfigured network card.
You cannot give the server the same IP it has before as there are still offline-adapters on the server blocking that IP.

To avoid unnecessary pain I suggest removing ALL network adapters from the VM and then go the to device management.

devmgmt.msc

Here you have to enable "show hidden objects".

Go ahead and deinstall all VMware networkadapters.

Next you will have to clean up the registry...
Start the registry editor.
(Windows + R ->  regedit)

Delete the RegistryKeys at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\NetworkCards\

Shut down the server, add the needed network adapters and then finally start it to use it.

Cheers,
Ori


VMware: Disk verkleinern

Wenn Ihr unter VMware dynamisch erweiterbare Festplatten benutzt, wird der Speicherplatz von der VM erst genutzt, wenn er wirklich gebraucht wird.
Wenn sich jetzt Daten auf der VM angesammelt haben und sie werden von euch gelöscht, steht der Speicherplatz dem Host nicht wieder zur Verfügung.

Damit der freigeräumte Platz wieder genutzt werden kann, muss die virtuelle Festplatte geschrumpft (shirnk) werden.

Bei Windows Gastbetriebssystemen ist der Task relativ trivial, solange die VMware Tools installiert sind.
Recktsklick auf die VM > Manage > Clean Up Disks...

 

Wenn der Task durchgelaufen ist, kann die Festplatte in den Einstellungen erweitert werden.

 

Unter Linux läuft der Task ähnlich und setzt auch voraus, dass die VMware tools installiert sind.
Mit folgendem Befehl könnt Ihr euch listen lassen, welche Disk gemounted sind.

vmware-toolbox-cmd disk list

Und anschließend könnt mir mit folgendem Befehl die Festplatte shrinken.

vmware-toolbox-cmd disk shrink <DISK>

Auf dem Screenshot ist /dev/sda1 der mountpoint vom Rootverzeichnis und aktuell sind nur 11GB von 48GB in Verwendung.
(Merkt euch diesen Wert!)

Jetzt könnt Ihr wie bei der Windows VM auch über Einstellungen > Compact Disk die Disk verkleinern.

Advanced Troubleshooting

Achtung: Diese Maßnahmen können euch die VM zerschießen! Macht Backups...

Falls die Festplatte des Hostssystems schon relativ voll ist, kann das durchaus fehlschlagen.

Installiert auf der VM also gparted und startet es.

apt install gparted

Hier wählt ihr dann die zu verkleinernde Partition aus und wählt resize. Dies kann allerdings an LVM oder anderen Dingen nicht funktionieren.

Falls gparted nicht funktioniert, nutzt fdisk.

Werfen wir nochmal einen Blick auf den Output von df -h weiter oben.
Das Rootfilesystem / lieft auf dem device /dev/sda1.
Sda1 ist die erste Partition auf /dev/sda, ich will also /dev/sda verkleinern.

Startet fdisk mit dem device, das Ihr shrinken wollt.

fdisk /dev/sda

Als erstes listen wir die Partitionstabelle mit
p

Hier sehen wir, dass /dev/sda1 einen Bootflag hat, bei Sektor 2048 beginnt (wichtig! merken!), die Start und Endsektoren der Partition und dass sie 36GiB groß ist.
Wir werden die Parition jetzt löschen und neu anlegen, allerdings kürzer.

Keine Sorge, den Daten passiert nichts, solange Ihr euch merkt, wo die alte Partition begonnen hat.
Löscht die Partition also mit
d

Schauen wir uns mit p nochmal die Partitionstabelle an, ziemlich leer hier order?

Macht die neue partition nicht kleiner, als der genutzte zuvor genutzte Speicher (!)

Wir legen jetzt mit n eine neue Partition an und sagen dann mit p, dass es sich um eine primäre Partition handelt.
Da es sich wieder um die Partition 1 handeln wird und bei Sektor 2048 beginnen soll, kann ich diese beiden Werte auf default lassen.
Wenn die gelöscht Partition bei euch nicht 1 war oder nicht bei Sektor 2048 begann, passt diese Werte bitte unbedingt an!

Als nächstes definieren wir die Größe der neuen Partition.
Ich lege mit +15G fest, dass die neue Partition 15GiB Groß sein soll.

Jetzt setzen wir mit a das Bootflag auf die erste Partition.

Zu guter Letzt schrieben wir die Änderungen in die Partitionstabelle mit w.

Ihr werdet eine Warnung erhalten, dass die VM jetzt neu gestartet werden muss.
Es gibt Methoden die Rootpartition zu unmounten, zu resizen und sie dann wieder zu mounten, falls neu starten aus Gründen für euch keine Option ist.
Das behandle ich vielleicht mal in einem anderen Artikel.

Cheers,
Ori


KVM: Manage virtual networks using libvirt

Just a short refference.

List virtual networks
virsh net-list

Change the configuration of the network
virsh net-edit <network>

Cheers,
Ori


KVM: Virtuelle Netze verwalten mit Libvirt

Nur ganz kurz als Referenz zum Nachlesen.

Virtuellen Netze listen
virsh net-list

Die Configuration des jeweiligen Netzes anpassen
virsh net-edit <network>

Cheers,
Ori


Bad, bad VMware tools

Sometimes you come across things that have the potential of letting fecal matter hit the rotary impeller.
Let me warn you.

Imagine you have successfully completed the ESXi upgrades, systems are back alive, nothing broke and everything is fine and dandy.
After a while you are thinking "shit I forgot to update the VMware Tools on those Servers".
In this purely hypothetical scenario you connect to the Hypervisor select your VMs, right klick and select Guest > update VMware Tools.

A couple minutes later the VMs reboot. (!)
No warning, no check if that is fine with you, the VMs just reboot.

Conclusion: To make sure you do not melt some customers productive systems, plan your VMware Tools updates along with the ESXi upgrade downtimes.

Holy shit,
Ori


Böse böse VMware Tools

Manchmal gibt es unerwartete Effekte die das Potential bergen Exkremente auf rotierende Luftumwälzer treffen zu lassen.
Lasst mich euch warnen.

In einem rein hypothetischen Scenario hat ihr ESXi Firmware Updates bei einem Kunden eingespielt.
Nach einer Weile denkt Ihr euch "oh, wir haben die VMware Tools auf den Servern noch nicht aktualisiert".
Ohne böse Hintergedanken geht ihr die VMs durch, macht jeweils einen Rechtsklick und wählt im Kontextmenü Gastbetriebssystem > VMware Tools aktualisieren.

Ein paar Minuten später startet die jeweilige VM neu. (!)
Keine Warnung, keine Rückfrage ob Ihr damit einverstanden seid, die VM wird einfach neu gestartet.

Lerne: Um nicht die Produktivsysteme eurer Kunden einzuschmelzen, plant die Aktualisierung der VMware Tools zusammen mit den abgesprochenen Downtimes der Systeme.

Holy shit,
Ori


Troubleshooting of windows server hard disk extensions / ESXi

This article desribes how to handle issues you can run into when extending windows server hard disks on ESXi.
In this perticular case the C:\ Partition should be extended from 139GB to 156GB.

After the extending the disk the C:\ Partition to 156GB the Explorer and Monitoring still show that the volume size is 139GB.

 

 

Troubleshooting

Always check that there is enaugh disk space remaining on the storage.
If a full storage is not the cause of this issue, keep looking.

A reboot always is a good idea, however in a production envoirement that is not always possible and does not help in this case.
A good trick is to extend the harddrive for one more GB.

After a refresh of the disk management utility using F5 there should be 1GB that is showing as "unallocated".

After extending the volume again, issues like this are normally solved.

Do not wonder that the harddrive is showing as 156GB angezeigt wird...

... this is Windows, and there is a 100MB reserved partition in front of C:\ and the explorer only counts full GB.

 

Cheers,
Ori


Extend hard disk windows server / ESXi

In this article i will show how to extend the hard disk of a virtual windows server on a ESXi (VMware) hypervisor.
The task is relativley trivial but has to be performed every once in a while so I thought why not write a short article on it.

How to 

At first take a look at what you want to extend.
In this case it is the E:\ drive of a windows server 2016.

Before changing anything we need to check that the host has enough resources available.
Start, depending on the ESXi version, the vSphere console or a browser and connect to the ESXi Hypervisor or the vCenter.

Open the VM settings and check on what storage the virtual harddrive (the .vdk or .vmdk file) is located on.
In this case the Storage is called "Datastore-VM".

 

After that hightlight the hypervisor on the left hand and check how much free space there is left on the storage.

Since there is still over 6TB left, extending the harddrive for 60GB should not be a problem.
Now change the size of the harddrive in the settings of the virtual machine.

When you check the harddrive in the explorer it appears to still have the same size.
The reason for this is that we still need to extend the volume on this harddrive.

Start the Diskmanagement using windows + r -> diskmgmt.msc

Rightklick the E:\ Volume and select "Expand volume..."
After you have gone trough the wizard your job should be done.

Cheers,
Ori


Updating ESXi

In this article I will show you how to install ESXi Updates using ssh.

Checking the Compatibility

You have to check what version of the hypervisor is supported by the hardware you are running.
You can do this using the Hardware Compatibility List or HCL.

Search for your server and check what versions are supported.
In this case the server is a IBM x3550 M4.

If you have no physical access and are unsure what hardware the ESXi is running on, see if you can find an IMM or IDRAC in the network.

The screenshot above shows that the IBM x3550 M4 supports ESXi up to the current version 6.7.
The Lenovo X3550 M4 on the other hand only supports up until ESXi 6.0.

Check the VM bootorder

Before patching the ESXi host make sure that the automatic start of VMs is in right order.

  1. What VM starts first?
    > DC / DNS? Radius? etc.
  2. Are intentionally turned off VMs maybe still in the autostart?
    > If so and the hypervisor is already running close to full capacity, turned off testing envoirements in the autostart can have you run into serious issues:
    > Worstcase could be a bootloop

Installing the ESXI updates

Installing the ESXi updates gets quite easy when using the Update-Commands provided by v-front.
Select the ESXi Version (top page) that you want to update to and then select the imageprofile link of the release you want.

This opens up a Pop-Up with a Copy&Paste command for the CLI of the ESXi host.

# Cut and paste these commands into an ESXi shell to update your host with this Imageprofile
# See the Help page for more instructions
#
esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -p ESXi-6.7.0-8169922-standard \
-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
esxcli network firewall ruleset set -e false -r httpClient
#
# Reboot to complete the upgrade

As you can see it sets a firewallrule, pulls the image from the official hostupdate.vmware.com resource and then sets the firewall rule again.
We are going to need this one soon.

Now shut down all VMs that are running on this Hypervisor.
(Please make sure that you have up2date backups of all the Machines BEFORE applying the upgrades)

Now connect via SSH and opaste the command above.
Depending on your Internet Connection it is normal for the prompt to freeze for 30min or more, dont panic.

After you are on the commandline again reboot and the server will load the new image and start the upgrade process.
This might take another 30min and might cause the server to reboot multiple times.

Once the Upgradeprocess is complete please check that all the VMs are starting correctly.

Cheers,
Ori


VMware: Verwaiste VMs retten

In diesem Post soll es darum gehen, wie man VMs retten kann.
Speziell jene, die nach einem Neustart oder Firmwareupgrade behaupten Sie würden ihre Festplatte nicht mehr finden.

Wenn man dann nachschaut, auf welche Datei auf dem Storage sie zeigen ist diese noch da.
Wenn man die Festplatte allerdings manuell entfernt und eine Neue vom Typ "bereits bestehend" einbindet, ist die Festplatte nicht sichtbar.

Welche Dateien relevant sind

Um das Problem anzugehen müssen wir uns erstmal ansehen, welche Dateien wir anfassen werden.

  • .vmdk - Pointer auf die virtuelle Festplatte
  • -flat.vmdk - Virtuelle Festplatte
  • .vmx - Die VM beschreibende Konfigurationsdatei

SSH aktivieren

Als erstes müsst ihr SSH aktivieren.
Da es so intuitiv ist, hier eine kleine Grafik.

Neue VM erstellen

Legt eine VM mit einem Namen eurer Wahl (anders als die Defekte) an und gebt ihr eine 10 GB Große Festplatte mit der Selben Konfiguration wie die der defekten VM. Gebt dem Server sonst die Selben Hardwarespecs wie der defekten VM.
Ihr wollt nicht, dass ein Server der zwei Netzwerkkarten erwartet nur eine vorfindet oder die Datenbanken nicht starten kann, weil er plötzlich viel weniger Arbeitsspeicher hat als vorher.

Schaut euch an, wie groß die Festplatte der defekten VM ist und stellt sicher, dass noch eine Kopie davon auf den Storage passt.
(Ein guter Erfahrungswert ist es immer mindestens 10% des Storage ungenutzt zu lassen. Ab etwa 10TB reichen auch 5%)

In diesem Fall sind das 250GB und ich habe noch knapp 2TB frei.

Festplatte kopieren

Verbindet euch per SSH mit dem ESXi Host und navigiert in das Verzeichnis euer neuen VM.
Da der Storage in diesem Beispiel "Storage" genannt wurde, lautet der Befehl dazu:

cd /vmfs/volumes/Storage

Wundert euch nicht, dass der Prompt einen anderen Pfad anzeigt.
Es befindet sich nur ein Softlink mit dem Namen, den Ihr dem Storage gegeben habt, in dem Volumes Verzeichnis.
Dieser Softlink pointed dann auf das jeweilige Volume.

Jetzt löscht ihr die aktuelle -flat.vmdk der neuen VM.
rm ./<Name der Neuen VM>-flat.vmdk

Anschließend kopiert Ihr die -flat.vmdk der alten VM in das aktuelle Verzeichnis und gebt ihr den namen der grade gelöschten -flat.vmdk.

cp ../<Name der Alten VM>/<Name der Alten VM>-flat.vmdk ./<Name der neuen VM>-flat.vmdk

Wäre der Name der alten VM "kaputt" und der Name der neuen VM "heile", so sähe der Befehl folgendermaßen aus.

cp ../kaputt/kaputt-flat.vmdk ./heile-flat.vmdk

Der prompt wird jetzt einfrieren, bis der Kopiervorgang abgeschlossen ist.
Dies kann eine Weile dauern, je nach Lese- und Schreibgeschwindigkeit des Storage.
Bei 250GB hat es bei mir über eine Stunde gedauert...

Schaltet die VM noch NICHT ein, wenn der Kopiervorgang abgeschlossen ist.

 

Festplatte erweitern

Aktuell wird die Festplatte der VM von der beschreibenden .vmx noch mit 10GB gelisted.
Geht in die Einstellungen der neuen VM und erweitert die Festplatte auf Orginalgröße +10GB.

Die VM sollte jetzt wieder starten.
Bei Windows Servern kann es dann nochmal eine Weile dauern, bis der Server wieder sauber anläuft.

Der Server startet erstmal mit DHCP, da eine neue Netzwerkschnittstelle erkannt wurde.
Ihr könnt dieser Schnittstelle nicht die gleich IP Adresse geben, wie der Server sie vorher hatte, da es noch Offline Adapter mit der selben IP gibt.

Ich empfehle euch große Schmerzen zu umgehen, indem Ihr zunächst ALLE Netzwerkadapter der VM entfernt und dann in die Geräteverwaltung wechselt.

devmgmt.msc

Hier müsst Ihr unter Ansicht die ausgeblendeten Geräte anzeigen lassen.

Anschließend deinstalliert Ihr alle VMware Netzwerkadapter.

Jetzt muss noch die Registry aufgeräumt werden.
Startet den Registry Editor.
(Windows + R ->  regedit)

Löscht die RegistryKeys unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\NetworkCards\

Fahrt den Server herunter, fügt eine neue Netzwerkkarte hinzu und Startet die VM wieder.

 

Cheers,
Ori