VMware server 2

6.7.2011 21:01 | Přečteno: 1986× | poslední úprava: 6.7.2011 20:59

Postupne rusim vsechny VMware servery a prechazim na jinou virtualizacni technologii. Predchozi zapisek o VMware mne inspiroval k tomu, abych si zazalohoval nejake postrehy, ktere jsem onehda dohledal nekde na netu, nebo ktere jsem si vytvoril.
Vysvetlim svoje duvody odchodu, potom popisu optimalizace vykonu vmware serveru a nakonec i snapshotove zalohovani.
Uz si nejsem touto platformou jisty, protoze posledni verze serveru je nekdy z konce roku 2009. Ukazalo se, ze firma opravdu ukoncila vyvoj a jiz nikdy zadny dalsi update nevyjde.
Zrejme nikdy tedy nebude opraven problem s firefoxem a zrejme nikdy nebude podporovan zadny jiny browser nez IE pod windows.
Vadi mi, ze musim nekde drzet virtualku s windows jen kvuli tomu, abych mohl administrovat dalsi virtualky.
Chybi mi nejaka pokrocilejsi sprava bezicich virtualek, kde bych mohl sledovat aktualni zatizeni procesoru, disku a site. Pokud mi tedy zacne nektera z virtualek divocit, tak je o to pracnejsi zjistit kdo je vinikem - je nutne hledat uvnitr kazde z nich a analyzovat vsechny najednou nez dojde k odhaleni vinika.
Chybi podpora pro novejsi systemy - napr. problem s 64bit w2k8R2, ktere tuhnou kazde 2 dny. Zkoumani na netu smeruje k problemu ve VMwrae serveru, ktery neni a nebude vyresen (je vyresen v ESXi a tyka se to sitove karty).
Na novejsich jadrech je nutne aplikovat patch aby bylo mozne zkompilovat server, ale ani tento patch ci jine reseni problemu se doposud neobjevilo ve vmware download centru.
Jako zasadni problem se ukazal fakt, ze se jedna o jediny subjekt, ktery odpovida za vyvoj, protoze kdykoliv hrozi zruseni produktu, nebo podpory dulezite soucasti atd... S tim take souvisi problem meho neuspesneho pokusu prejit na ESXi. Problem je v nepodporovanem hw, ale take v tom, ze je to postavene na nejakem silne orezanem linuxu, ktery nepodporuje vse co potrebuju (napr. mdadm, ktery uprednostnuju pred hw raidy po urcitych zkusenostech).
Dost mi vadi divoke a dlouhe retezce v seznamu bezicich procesu, kdy tam je v kazdem z nich vypsan dlouhy nazev licence, ale kdyz chci identifikovat konkretni proces (napr. pomoci htop), tak to temer nejde (priklad: /usr/lib/vmware/bin/vmware-vmx -# product=2;name=VMware Server;version=2.0.2;buildnumber=203138;licensename=VMware GSX Server for Linux;licenseversion=3.0 build-203138; -@ pipe=/tmp/vmhsdaemon-0/vmx4d5e367c6c630785;readyEvent=45....).
Dalsi problem je obcasne zatuhnuti nejakeho procesu managera a pak neni mozne se pripojit k administraci (jde poodstrilet nektere procesy, ale jednak je to otravne a druhak se tu a tam stane, ze se podela neco dalsiho a pak se musi resuscituovat server a postihne to vsechny virtualky - dokonce jsem musel za tech nekolik let u dvou serveru reinstalovat vmware server pricemz v jednom pripade to bylo dost v nervech, protoze se to podelalo zrovna ve chvili kdy mely probihat videoprenosy a bylo to velmi neprijemne - nestihal jsem ani prekopirovani na vedlejsi server).
Dalsi problem (uznam ze resitelny) jsou lck soubory a adresare, kdy po padu serveru (napr. watchdog zjisti pruser a watchdog karta retartne server) nenabehnou virtualky dokud nesmazu rucne lck soubory (ale to by slo osetrit scriptem, uznavam).
Rovnez se ukazalo, ze zatizeni hostitele je neprimerene vysoke a vykon diskovych image je celkem nizky.
Stejne tak vytvoreni image (s predalokovanym prostorem) zpusobi takove pretizeni serveru, ze desitky minut stoji vsechny ostatni virtualky (tohle bohuzel optimalizovat neumim - resenim je vytvareni image na jinem pocitaci a pak to prekopirovat).

Vykon disku nastesti lze velmi vyrazne vylepsit oproti vychozi instalaci, ale i tak to neni uplne idealni.
Bez optimalizace nastane problem napr. pri kopirovani ve windows, kdy zatizeni cpu ve windows stoupne na 100% a kopirovani probiha velmi pomalu. Nebo v linuxu kdy enormne roste load pokud se intenzivneji vyuziva disk.

Optimalizace diskovych operaci:

do /etc/fstab pridat nasledujici radek, ktery nam vytvori ramdisk a ten pripoji do tmp:

tmpfs /tmp tmpfs defaults,size=100% 0 0

Do /etc/vmware/config pridat na konec tyto radky:

tmpDirectory="/tmp"
mainMem.useNamedFile="FALSE"
sched.mem.pshare.enable="FALSE"
MemTrimRate="0"
MemAllowAutoScaleDown="FALSE"
prefvmx.useRecommendedLockedMemSize="TRUE"
prefvmx.minVmMemPct = "100"

Restart vmware a pojede to neporovnatelne rychleji.

Zalohovani:

VMware ma perfektni snapshoty! Sezere to sice asi 20% diskoveho vykonu pokud existuje snapshot, ale furt je to dost dobre (oproti LVM snapshotum, ktere s vmware neni uplne nejvhodnejsi a nejbezpecnejsi pouzivat...) a deje se to bez preruseni behu hostovaneho systemu.
Na netu jsem nachazel ruzne sripty, ktere to resi, ale ty scripty mely potrebu rozumet formatu image a ruznym detailum a z toho plynuly ruzne potize.

Ja na to sel jinak: zjistil jsem, ze pri vytvoreni snapshotu se nedeje nic jineho nez to, ze nekde vznikne nekolik souboru navic a do souboru, ktere existovaly pred vytvorenim image se jiz nezapisuje. Dale se zapise nejaka informace do souboru .vmx. To je cele.
Takze nejprve prochazim folderama a hledam ty, ktere obsahuji vmx. Pak zjistim zda virtualka bezi a pokud ano, tak nejprve stahnu do zalohy vmx soubor (ten dosud neobsahuje info o snapshotu), potom vytvorim seznam souboru, ktere v tom folderu existuji, potom vytvorim snapshot a tim mi vzniknou nejake ty soubory navic, ktere budu ignorovat. Kopiruju soubory do zalohy (bez tech novych, ktere tvori snapshot) a po zkopirovani souboru zase snapshot zrusim.

Jeste uvedu, ze mam lokalni folder pro zalohy aby snapshot nemusel existovat dlouho. Teprve odsud si potom nejaky zalohovaci proces bude v klidu stahovat data do zalohy nekam na vedlejsi server, nebo treba i pres net pryc (konkretne je to dirvish, ten spusti script na zalohovanem stroji, ktery vytvori lokalni kopie a potom to sosa k sobe. Na starne zalohovaciho serveru mam svepomoci zajisteno, ze se nikdy nespusti zaloha konkretniho stroje dokud nedobehla predesla zaloha tehoz stroje. Zaroven pokud script na zalohovanem serveru vrati error kod jiny nez nula tak dirvish usoudi, ze zaloha selhala a o jakemkoliv selhani mne poinformuje nagios a info o neuspesne zaloze mi dopluje pomoci push az do mobilu - pokud vse probehne dobre, tak dirvish pouziva rsync, takze po siti se toho taha malo diky tomu, ze se stahuji jen ty casti souboru, ktere byly zmeneny - tedy se skutecne taha jen cast vmdk souboru).

Mam na to script a pro mne je dost dobry na to abych se mu uz nevenoval, ale ma par omezeni, ktera je potreba vedet a mit je na pameti:
- soubory nmesmi obsahovat mezery nebo divoke znaky typu zavorky atd... rsync s tim ma problem a neni zadny problem tohle dodrzet, jen to admin musi mit na pameti!!
- nikdy nikde (ve vmware) nepouzivam independent disky, takze je nemam osetrene a pokud jsou potreba, tak navrhuju je premistit do specialnich folderu mimo ty zalohovane (snapshot pro ne neplati a normalne se do nich zapisuje i kdyz existuje snapshot)
- ve vmware musi byt vytvoren zalohovaci user a musi mit pravo console interaction, create snapshot a remove snapshot (zadne dalsi pravo neni potreba!)

Dirvish loguje vse co na stdout vypsal vzdaleny script, tak proto ma vyznam aby byl script trochu ukecany.
Kopiruju pomoci rsync a rychlost omezuju na 5 mega aby se zbytecne nepretizil hostitel, ale lze zkouset namisto toho pouzit nice a rychlost neomezovat.

#!/bin/bash
SOURCE='/vmmachines' #folder se zivymi VM
DESTINATION='/vmshadow' # folder kam se zalohuji vm
STORAGE='standard'  # nazev storage
USERNAME={backup user username}  # tento user musi mit vyse zminena prava
PASSWORD={backup user poassword}
LOCATION='localhost'  #adresa vmware serveru

function prepare_vm_snapshot {

  
  cd $machinedir
  echo "["`date`"] {$machine}             ""Cistim pripadny drivejsi snapshot stroje "$machine" a nacitam adresarovou strukturu"
  vmrun -T server -u $USERNAME -h 'https://'$LOCATION':8333/sdk' -p $PASSWORD deleteSnapshot "["$STORAGE"] "$machine >/dev/null
  original=$(ls)
 
  echo "["`date`"] {$machine}             ""Vytvarim snapshot stroje "$machine" a nacitam zmeny v adresarove strukture"
  vmrun -T server -u $USERNAME -h 'https://'$LOCATION':8333/sdk' -p $PASSWORD Snapshot "["$STORAGE"] "$machine
  sleep 15
  all=$(ls)
  exclude=''
  texclude=''

  for folder in $all; do
        found=0
        for remove in $original; do
                if [ "$folder" == "$remove" ]
                then
                        found=1
                fi
        done
        if [ $found != 1 ]
        then
                texclude=$texclude' '$folder
        fi
  done
  texclude=$texclude" *.lck *.vmx *.vmsd *.log"

  for ex in $texclude; do
        exclude=$exclude' --exclude '$ex 
  done

  echo "["`date`"] {$machine}             ""pouziju nasledujici exclude: "$exclude
  echo "["`date`"] {$machine}             ""Kopiruju data stroje "$machine
  rsync --inplace --bwlimit=5120 --delete-before $exclude --delete-excluded -v -ra $SOURCE'/'$machinedir $DESTINATION

  echo "["`date`"] {$machine}             ""Odstranuji snapshot stroje "$machine
  vmrun -T server -u $USERNAME -h 'https://'$LOCATION':8333/sdk' -p $PASSWORD deleteSnapshot "["$STORAGE"] "$machine >/dev/null
  sleep 5

  echo "["`date`"] {$machine}             ""Kopiruju konfiguracni soubory po odstraneni snapshotu stroje "$machine

  rsync ./*.vmx $DESTINATION'/'$machinedir
  rsync ./*.vmsd $DESTINATION'/'$machinedir


  cd $SOURCE
}

cd $SOURCE
for dire in ./*/*.vmx ; do
        machine=${dire:2}
        machinedir=`dirname $machine`

        prepare_vm_snapshot
done

Dirvish a kontrola pomoci nagios se nachazi na mnoha mych zalohovacich serverech, takze to nepotrebuju popisovat/zalohovat. Pokud by byl zajem, tak bych to nekdy mozna popsal, ale nejedna se o nic buh vi jak svetoborneho.        

Komentáře

[jan.xxx]

Na jakou technologii přecházíte?

[CandySan]

Studoval jsem na netu ruzne studie a zaroven i jeden celkem zajimavy test vykonu diskovych obrazu a postupne vse zacalo smerovat ke qemu kvm. Potom jsem si sestavil checklist vlastnosti, ktere musim prozkoumat a doresit a zacal jsem si je postupne odskrtavat s kvm. Zdalo se, ze to ma mnoho uzasnych vyhod (ve spojeni s libvirt, ale pocinaje uz od uzasneho radkoveho klienta). V ramci tohoto checklistu jsem nastudoval a objevil spoustu dulezitych veci ze kterych vznikla jakasi soukroma norma ci predpis a po testech nasledovalo zkusebni nasazeni do realneho provozu. S tim se samozrejme svezla i nutnost konverze stavajicich vm.

Po ruznych obtizich, ktere bylo nutno vyresit (at uz primo souvisely s kvm nebo ne) se nakonec ukazalo, ze ve srovnani s vmware serverem (i s tema optimalizacema) je tahle platforma velmi vykonna, velmi pohodlna na pouzivani, bohata na nastroje a i pri zatizeni ma celkem slusne rezervy ve vykonu a hostitel ani hosti nevykazuji temer zadne zatizeni.

Napr. host, ktery v nekonecne smycce cetl vystup ze vzdaleneho telnetu a naustale zapisoval udaje do mysql a zaroven x klientu se strachalo pres apache v ruznych vyhodnocenich mel permanentne load kolem 8 (je to teda hodne a buh vi proc tomu tak bylo), tak v kvm ma 0.16 az max 0.5.

Ruzne ostatni pocitace behaji vyznamne svizneji i kdyz u nich nenamerim takovy skok v load, ale napr. na hostitelech je taky zatizeni neustale kolem nuly pokud nejsou virtualky pouzvane a samozrejme load vzroste kdyz jsou vm zatizene, ale stale to je v rozumnych hodnotach.

Priznam se, ze to bylo pro me velkym a velmi prijemnym prekvapenim.

Tech zajimavych, uzitecnych, nebo prijemnych veci je tolik, ze by to bylo na clanek. Z meho pohledu to je neoddiskutovatelne dobry krok a myslim, ze mnohe uzivatele vmware serveru to zrejme ceka taky. Tech serveru jsem postupne uz prevedl nekolik a jsou par tydnu v realnem provozu a mam jen same dobre vysledky.

Problemy jsem mel s qcow2 snapshotama - po vytvoreni snapshotu se casto poskodil image. Takze ted zalohuju jinak, ale vse ostatni bylo nad ocekavani.

[jan.xxx]

Děkuji za odpověď. Já jsem přecházel vloni z VMware serveru 2. O KVM jsem hodně uvažoval, nicméně v té době to bylo pro mě moc pracné. Takže nakonec vyhrál VirtualBox.

[Aleš Kapica]

Momentálně finišuji se svým řešením, při kterém využívám xNBD a live migrace. Původně jsem myslel že s tím budu hotov mnohem dřív, ale zasekal jsem se při řešení mnoha dílčích prkotin.

Je to v podstatě obslužný skript, skrz který lze virtuální stroje spouštět, zastavovat, snapshotovat, migrovat a kopírovat v rámci clusteru.

Snapshoty jsou dvou typů - havarijní, které se ukládají v případě síťového výpadku na virtualizační stroj. A zálohovací, kdy může být vytvořen buď živý snapshot běžícího virtuálu, nebo čistě snapshot blokového zařízení. Tyto snpshoty jsou uložené v datovém úložišti. Stejně jako virtuální disky.

[CandySan]

Tak to je super tip! xNBD jsem neznal a rad kolem nej zacenicham. Diky!

[Aleš Kapica]

Rád se podělím s tím co mám, akorát teď je dovolenkové běsnění, což pro mě znamená opakovanou nakládku a vykládku všemožných krámů, takže skriptování je teď trochu stranou. Ale během následujícího týdne bych to chtěl dotáhnout do takové podoby aby to mohl prubnout i někdo jiný.

V kostce. Mám cluster se čtyřmi stroji. Každý z nich může fungovat jako virtualizační host, ale pouze dva z nich fungují i jako datové stroje ze kterých se přes xnbd publikují virtuální stroje. Je to především proto, že ty zbylé dva mají diskový řadič, který neumožňuje hotswap.

Na každém z těchto strojů je úložiště konfiguráků virtuálních strojů, které se replikují při každé změně konfigurace. Spuštění probíhá tak, že skript nejprve nahodí xNBD servery, pak připojí na hostiteli virtuálů nbd zařízení, zkontroluje jestli náhodou nebyl při předchozím běhu vytvořen havarijní snapshot. Pokud ho najde, tak ho natáhne. Jinak normálně spustí vlastní virtuál.

Základem je qemu a jeho monitorovací konzole. Pri připojení k virtuálům používám spice, i když vnc by šlo použít taky. Virtuály jsou identifikované jak přes jméno tak uuid.

Důvod, proč jsem začal dělat vlastní řešení byl především v tom že mám (alespoň dle svého mínění) lépe vyřešené snapshotování než libvirt.

[Aleš Kapica]

Havarijní snapshot využívá možností xnbd klienta, který umožňuje navázat na zařízení skript, který se spustí v okamžiku kdy ztratí konektivitu - to bylo nejtěžší. Napsat skript, generující skript, který generuje havarijní skript .

Ten v případě přerušení spojení provede korektní ukončení všech aplikací, umount nbd zařízení a navíc, v případě že s tímto zařízením pracuje i nějaký virtuál, přes monitorovací konzoli stroj zapauzuje a odsnapshotuje do souboru.

[CandySan]

To zni velmi zajimave! Na to bych se pak rad podival.

[ext3fs]

Chybi mi nejaka pokrocilejsi sprava bezicich virtualek, kde bych mohl sledovat aktualni zatizeni procesoru, disku a site. Pokud mi tedy zacne nektera z virtualek divocit, tak je o to pracnejsi zjistit kdo je vinikem - je nutne hledat uvnitr kazde z nich a analyzovat vsechny najednou nez dojde k odhaleni vinika.

To co hledate se jmenuje vCenter Operations. Lze stahnout k vyzkouseni (60dnu zdarma). Potrebuje to vCenter, cela appliance bezi pod SLES a potrebuje pro beh cca 130GB disk a 8GB RAM (coz je docela dost).

[Aleš Kapica]

Existuje více řešení. I open source. Kolegové používají kupř. munin, nebo nagios, který má nejrůznější moduly.

[ext3fs]

Urcite ano, problem je ten, ze vCenter Operations ma jednu nespornou vyhodu. Hned to jede, prakticky na par kliku....to klobouk dolu. Uz vidim jak se propojuje s vCenterem treba Nagios nebo Zabbix.

[Aleš Kapica]

Tyhle monitorovací systémy fungují jinak. Monitorují přímo stroj, nebo služby a je úplně jedno, jestli je virtuální, nebo fyzický. vCenter je řešení pouze pro VMware.

[CandySan]

Pri pouziti kvm a libvirt je mozne zobrazit si grafiky zateze a vse je videt uz na prvni pohled - tohle je super Nebo virt-top a verim ze i dalsi nastroje se najdou (nebo i standardni linuxove nastroje).

[CandySan]

Ted uz to ani nehledam kdyz uz vsechno mam, ale faktem je, ze jsem byl vzdy odrazovan mnozstvim cool nazvu. Kdykoliv tohle firma dela, tak to na mne pusobi negativne... ale to neni kritika, protoze verim, ze to maji dokonale vymyslene a ze zakaznici takove veci miluji, jen jsem asi divny ja, ze pak odmitam studovat co se skryva za matoucimi nazvy... ted uz je to kazdopadne jedno, ale dobre ze to je zde uvedene, protoze asi se to muze spouste dalsich jeste hodit.

[ext3fs]

S tim take souvisi problem meho neuspesneho pokusu prejit na ESXi. Problem je v nepodporovanem hw, ale take v tom, ze je to postavene na nejakem silne orezanem linuxu, ktery nepodporuje vse co potrebuju (napr. mdadm, ktery uprednostnuju pred hw raidy po urcitych zkusenostech).

Tak on cely vSphere od vmwaru je urcen pro trosku jiny hw. Chce to minimalne 2 stejne masiny (v clusteru ) pripojene ke sdilenemu datovemu ulozisti SAN/NAS jinak nelze vyuzit nektere funkce jako HA, FT,...

[CandySan]

Tim jsem v podstate mimo ucel pro ktery vetsinu virtualek provozuju. Pochopil jsem, ze to je pro jiny hw a tudiz to je jeden z duvodu toho neuspechu. Podminkou mimo jine je take to, ze to musi byt kompletni linux (nebo system, ktery poskytuje vse co linux). Musi byt mozne recyklovat temer kazde zelezo, protoze spousta tech virtualek je umistena v mensich firmach, kde jim o zadnou virtualizaci vubec nejde. Nejedna se o datova centra, ale o firmy, kde maji tu a tam nejake ty windows "servery" (jen zbytecne drazsi desktopy, kde bezi nejake ty samocinne aplikace), ktere nejsou (nebyly) dostatecne zalohovane nebo nahraditelne (nekde maji napr. windows domenu a spoustu historickych udelatek kterym ani nechci rozumet tak do detailu, ze kdyby se odporoucel stroj tak bych je nedej boze musel reinstalovat). Jiny duvod pro tyhle male instalace je potreba izolovat windows (nebo velmi casto i linuxove virtualky, kterych mam nejvice) tak, aby pripadna jejich selhani bylo mozne resit vzdalene. Abych nebyl zaujaty jen proti windows, ktere obcas potrebuji restart, tak i v linuxovych virtualkach se tu a tam muze stat, ze dojde pamet a vyleti load a pokud jsem nebyl na nejakou tu neocekavanou udalost pripraveny, tak se mi velmi hodi, ze to je jen virtualka, kterou na dalku umravnim.

Takze i u mensich stroju ma virtualizace vetsi vyznam a mam tendenci virtualizovat samostatny stroj tak, ze kdyz mi padne do spravy a jsou na nem napr. jen jedny windows s nejakou tou desne dulezitou aplikaci, tak je prevedu na virtualku a z puvodniho zeleza udelam virtualizacni serverik a nehledim na to, ze to je jen kvuli jednomu stroji. Pozdeji pak tezim z toho, ze muzu kdykoliv naklikat novou virtualku a rozjet tam pod linuxem dalsi sluzby a casto to jsou ty, ktere puvodne mel na starosti ten win stroj, protoze cim mene toho dela tim mensi je s nim problem.

Jiny duvod pro male stroje a mdadm je nahraditelnost. Pokud nekomu takovy stroj umre, tak se nekde vezme jakekoliv jine zelezo, zastrci se tam ty disky a jede se bez nutnych ladeni nejakych prastarych historickych instalaci. Kdyz umre disk, jen se pichne novy a okopci se virtualky ze zalohy a zase je vse pri starem.

Mam i rack, kde jsou vetsi stroje a je jich tam dost a mozna bych tam vyuzil ty slozitosti o kterych se bavime, ale opet bych prisel o kouzlo jednoduchosti, ktera se skryva v tom, ze vsechny stroje (od malych k velkym) funguji na stejnem principu a jsou ruzne zamenitelne. Kdyz pak nastane krizova situace a clovek musi ve stresu vyresit problem, tak se vzdy hodi kdyz neni nutne spekulovat nad konkretni implementaci. Nebo kdyz mam nekoho navadet telefonem a rikat mu z pameti co ma delat pro zachranu atd...

Takze nekde se hodi HA, ale neni to zas az takova nutnost a na vetsine mist jde hlave o to aby sprava byla snadna, rychla jen relativne a hlavne spolehliva a aby necihaly nikde pasticky az me prejede rychlik a bude potreba me nahradit (nebo kdyz mam menit zamestnance).

[kyytaM]

Xen.

[CandySan]

Taky se zucastnil souteze, ale nakonec to vyhral kvm.

[D-Evil]

Bugy a aktualizace nehrozej, VMWare Server 2 je už hodně dlouho discontinued. A brzo bude discontinued i ESX.

Co se týká grafů - je to sice nepodporovaný, ale k VMWare Serveru 2 se dá připojit klientem Infrastructure Client (VI Client). První release dokonce obsahoval i instalačku pro Windows. Nepodporovaný to je, protože tam skoro nic nefunguje (neseděj verze API). Ale funguje tam právě ta jedna věc, kterou VMWare Server nikde jinde nenabízí - grafy. Sice jen realtime za poslední hodinu, ale lepší než nic.

Jinak pro jednoduchý instalace se SW RAID zatim nic lepšího hotovýho neni. Snad jedině RHEV, ale to stojí $$$. Zbejvá jedině bastlit si to po svym. Celej trh směřuje spíš k datacentrům, cloudům atd., všude se předpokládá alespoň iSCSI SAN a tyhle malý nasazení nikoho nezajímaj, protože z toho žádný $$$ nekapou.

[rudiik]

Mimochodem, nemate nekdo dobry navrh na nejake jednoduche web gui pro KVM? Rad bych to mel postavene na vlastnim Debianu, ne nejaky hotovy bundle. Zkousel jsem OpenQRM, ale pro single server s par masinama je to desne neprakticky reseni. Chci od toho jen zakladni prehled VM, zastaveni, spusteni, vytvoreni, smazani nic vic v zasade nepotrebuju. Ma nekdo s necim zkusenost. Vim, ze to tu padne, tak rovnou rikam, ze Proxmox VE je "plan B"

[polymorf]

Ubastlist nieco v php?