Minden virtuális gép pár fájlban – VVol és VSAN esetén objektumban – reprezentálódik és míg igen sok fájlról pontosan tudjuk miért van ott és mi a dolga, addig van egy aminek elhelyezése és alapvetően a méretével való tervezés, néha kihívások elé állítja a embert.
Mielőtt azonban belemerülnénk a részletekbe, nézzük meg mik ezek a fájlok:

Haladjunk sorban:
- log: Kiterjesztése magáért beszél, naplózásra használt, méghozzá a VM-et közvetlenül érintő folyamatok és akciók, események esetén.
- vswp: na itt rögvest két ilyen fájl látható. Az egyik, amelyiknek „vmx” kezdete van, az az ESXi által, a virtuális gép egészének kezelésére felhasznált memória – pl virtual machine monitor (konzol), a virtuális hardver elemei stb. A másik az érdekesebb, az lényegében a virtuális gépnek adott memória méretével egyezik – kivéve ha van reservation.
- hlog: Ez egy vCenter Server által használt állomány és olyan állományok nyilvántartására használt, amelyek ideiglenesen jönnek létre bizonyos akciók során. Ebben tárolja le ezeket és törli le ha nincs azokra többé szükség.
- flat-vmdk: Ha nem RDM-et használunk, akkor pontosan ez az a fájl ami reprezentálja a VMDK tartalmát.
- nvram: a virtuális gép BIOS-ának konfigurációját tartalmazza. Minden amit a BIOS-ban beállítunk, azt itt tárolja le. Ha letöröljük, akkor ez a fájl például a VM bekapcsolásakor létrejön.
- vmdk: az adatot tartalmazó flat fájl descriptor/leíró állománya. Pointer-t tartalmaz a flat fájlra és egyéb információkat a virtuális disz szektorairól, fejekről és az adapter fajtájáról.
- vmsd: A snapshot-okról tartalmaz metaadatokat. Akkor is ott van, ha egyébként nincs snapshot.
- vmx: a virtuális gép konfigurációját leíró fájl és bár nem kifejezetten barátságos, azért kideríthető belőle a részletes kiépítés.

Látható fentebb a vCPU-k száma, a SCSI vezérlő fajtája, a VMDK descriptor-ra való hivatkozás, a hálózati kártya fajtáka, mely hálózathoz csatlakozik, milyen MAC-je van, mi a guest OS. Szeretném felhívni a figyelmet a vm.CreateDate bejegyzésre. Ez egy igen régóta várt dolog és a 6.7-tel jelent meg végre. Amennyiben a vCenter és az ESXi is 6.7-es verzión van, akkor lehet használni. Természetesen csak olyan gépekről tudja mikor hozták létre, amelyeket a 6.7 upgrade után hoztak létre, visszamenőleg nem képes előállítani a dátumot.

Na térjünk vissza a VSWP-re. Miért fontos ez a fájl és miért kell számolni a méretével és még kiemeltebben az elhelyezésével?
Fontos megérteni, hogy ezeket a fájlokat akkor használja az ESXi, mikor fizikai RAM szűkébe kerül. Négy állapot különböztetett meg és azokhoz különböző akciók tartoznak:

Hogyan határozza meg milyen állapotban van éppen? A minfree érték alapján, aminek képlete:
minFree = Az első 28 GB RAM-nál 899 MB + a 28 GB-on felüli rész 1%-a
A fenti példában az EPYC szerverben 128 GB RAM van, így ennél ez 899 MB + 1 GB, azaz 1899 MB. A hoszton is vizsgálható az állapot az ESXtop segítségével:

Méretük csökkenthető ha az adott VM-en reservation-t állítunk be, de én minden esetben, kivétel nélkül ellenzem a reservation használatát. Ha a fenti VM-nek adott 4GB memóriából 1 GB-ot rezerválok, akkor a vswp fájl mérete 1 GB-tal csökken. Ha mind a 4 GB-ot rezerválom akkor a vswp fájl mérete 0-ra csökken. Gyakori hiedelem, hogy ha beállítjuk a rezervációt, akkor azonnal csökken a fáj mérete, holott ez csak akkor történik meg ha kikapcsoljuk a VM-et, majd újra elindítjuk. A reservation hátránya, hogy ha a RAM-ot minden VM-nél dedikáljuk, akkor a hosztban lévő fizikai RAM-ot nem lehet túlfoglalni, szóval igazából oda a virtualizáció egyik legnagyobb előnye. Ezzel szemben nyilvánvalóan spórolhatunk a fizikai tárolónkon, hiszen ha egy nagyobb klaszterről beszélünk (például 8 darab, 1 TB RAM-mal szerelt kiszolgáló), akkor a fizikai RAM mérete 8 TB, amit ha teljesen kihasználunk akkor is minimum ennyi területre van szükség a virtuális gépek virtuális lemezei mellett. Ha túlfoglaljuk, azaz rendeltetésszerűen használjuk az ESXi-t, akkor ez felmehet magasabbra is.
Láthattuk fentebb, hogy a vswp fájlok alapértelmezetten a VM könyvtárában vannak, de ezt módosíthatjuk. Ha a hoszt, egy klaszter tagja, akkor azt klaszter szinten kell beállítani (Configure->General), míg ha standalone, akkor a beállítás a „Configure->Virtual Machines->Swap File Location” alatt van. Kusza, mert klaszter szinten azt tudjuk beállítani, hogy a hoszt szinten megadottat alkalmazza vagy a VM könyvtárban tárolja.

Mikor lehet érdekes, hogy ne a VM könyvtárban legyen a swap?
Például stretched cluster esetén lehet opció. Tehát ha van egy olyan Metro Cluster kiépítésem, ahol a VMware alatt szolgáló tárolók szinkronban replikálják egymás között a datastore-okat jelentő volume-okat. Ekkor ha például a VM-ek normál mozgása elsősorban adatközponton belül értelmezett – manuálisan vagy DRS host és VM szabályokkal – akkor igazából semmi érteme a vswp fájlokat is szinkronizálni. Tehát ha az egyik telephely kiesik, akkor az elérhetetlenné vált telephelyen addig futó virtuális gépeket a VMware HA újraindítja a másik telephelyen, ahhoz meg nincs szükség a swap-ra. Akkor pedig miért is kellene az ilyen „drága” tárterületeken elhelyezni ezeket a fájlokat, mikor amúgy csak akkor használja őket az ESXi, ha RAM limitált állapotba kerül.
Akkor is érdekes lehet, ha a hosztokban van valami tényleg gyors média, például NVMe SSD vagy Optane. Az biztosan gyorsabb lesz ha kevés a RAM és swap-ra van szükség, mint bármilyen SAN-on keresztül elért tároló. Hátránya az, hogy ilyen szűkösebb RAM állapotok mellett a vMotion-nak át kell vinnie a teljes vswp fájlt a VM futásával egy másik hosztra, mivel az nem közös tárolón van ebben az esetben. Ezt egyre kevésbé érzem problémának, mivel ma már nem ritka a 10/25/50 Gbit-es kapcsolat a hosztok között.
Mikor legyen mégis a VM könyvtárában?
Nem véletlenül ez az alapértelmezett, szóval az esetek 99%-ban használjuk ezt, de van pár eset, mikor érdemes kipróbálni a másik opciót. Ha nem probléma a plusz tárterülettel kapcsolatos igény és sokszor kerül valamelyik hoszt RAM constrained állapotba, akkor célravezető a vMotion életét megkönnyíteni azzal, hogy legalább a swap-ot nem kell átmozgatnia.