Jak zvětšit disk virtuálního serveru a nepřijít o data

"Protože systém běží, odmítne načíst novou tabulku rozdělení disku. Musíme tedy virtuální server znovu restartovat." - to není pravda, stačí použít příkaz partprobe z balíku parted

[1] Pokud je ten oddíl připojený, přinejmenším jako root, nepomůže ani partprobe:

# partprobe /dev/sda
Error: Partition(s) 1 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes.

Tohle řeším obvykle tak, že ten stroj restartuju, přes PXE spustím parted magic, udělám změny (klidně v GUI - gparted), opět restart a hotovo.
fdisk bych měl strach použít právě proto, aby mi dal začátek partition tam, kde byl. To už raději sfdisk -d, ručně opravit konec a zase sfdisk na vrácení zpátky.

[1,2] Do dnes nevím, proč to někdy funguje a někdy ne, u virtuálních strojů nebývá problém s přenačtením particí (u fyzických ano).

Víte někdo, jestli ty C-H-S hodnoty v MBR mají vůbec na něco vliv?

[5]. Mají vliv podle mě hlavně na bootování DOSu a možná i některých Windows.

[5][6] Asi jedina zajimava trida veci na kterou maji vliv (kdyz se vynechaji extremne stare verze DOSu) je boot cehokoli kde se po ceste zaradi nejaky kus kodu ktery je dostatecne stary, to v sobe zahrnuje zmineny first stage bootloader DOSu a pravdepodobne nekterych Windows a co je mozna dulezitejsi to muze zahrnovat kod implementujici boot z "aktivni partition", to je resene tak, ze v MBR je kus kodu ktery najde aktivni partition a sam sebe prepise jejim zacatkem. Stari tohohle kodu zavisi na spouste ruznych veci, protoze je tam obvykle zapsan pri prvnim deleni disku a obcas necim prepsan (napr. instalatorem windows) a kdy a odkud jej autori toho daneho nastroje vzali vi buh (samozrejme bezne reseni instalace GRUBu do MBR tenhle problem vcelku elegantne odstranuje).

A nestačí místo takových harakiri prostě nabootovat jakýkoliv jiný virtualizovaný systém z jiného virt. HDD nebo CD a s napojeným zvětšovaným virt. HDD a prostě ho zvětšit standardními nástroji, obdobně jak píše [3]???

[3, 8]: Nabootování nějakého Live OS nic nemění na podstatě zápisku, totiž že fdisk v DOS-kompatibilním režimu lže a nelze ho použít pro bezpečné zvětšení oddílu bez posunutí začátku.

[8]: Co jsou standardní nástroje? Pro mě to je fdisk a resize2fs. Když budu změnu provádět z jiného OS, provedu úplně stejné úkony, jen budu navíc potřebovat donutit virtuální server nastartovat nějaký Live OS a pravděpodobně také získat přístup ke konzoli virtuálního serveru. Což nemusí být tak jednoduché jak se zdá. Například u VMware jsou k tomu potřeba buď Windows a speciální klient a IP konektivita k hypervizoru, nebo webový prohlížeč s flashem a proprietárním vmware pluginem a IPv4 konektivita k vCenter server. Než tohle rozcházet, to radši server dvakrát restartuju po SSH.

Před časem mne fdisk vyléčil a nepovažuji ho tedy za standardní nastroje, minimalně pro podnikovou sféru. No zkuste tedy pomoci fdisk udělat na poli třeba 5T partišnu. Co tak místo fdisk použít parted? Jinak upozornění na použití zmíněných parametrů kladně hodnotím. Díky.

Doplnim ještě. Nebo jit na to jinak a pokud je to možné, použít LVM. Jaké mate zkušenosti s resize2fs za "chodu", například při intenzívni práci např. databaze?

[9] V případě, že se dostanete ke konzoli serveru, předpokládám, že není problém spustit jakýkoliv systém z isa (proč proboha widle???) s napojenými disky k virtualizaci.
Fdisk NENÍ nástroj pro zvětšování partition, nejen kvůli uvedeným problémům kouká z takového použití průser.

[11] Jaké máte prosím zkušenosti s LVM? Jak je složitá správa? Co odladěnost? Stojí to za to pro běžný uživatelský desktop? (Viděl jsem, že to mají disktribuce v autoatickém rozdělení disků.)

[10]. Udělat 5TB oddíl asi těžko, tabulka oddílů v MBR má limit 2 TiB. A je nutno uznat, že jejím návrhářům se takový limit musel zdát „teoretický“ a „nikdy nedosažitelný“ :)

Použít parted je jistě dobrý nápad, určitě to s ním půjde. Ale pro mě osobně je jeho syntax nesrozumitelná a navíc v minimálních instalacích distribucí stále chybí. Takže k němu přistupuji stejně jako ke GRUBu 2: Je to něco, co je dobré, že existuje, ale pro můj konkrétní účel to nenabízí žádnou výhodu, tak nemá cenu to řešit.

Jedinou výjimkou byl případ, kdy jsem koupil disk o velikosti 3 TB a zjistil, že na něj klasické oddíly nevytvořím, tak jsem musel vzít zavděk parted a GPT.

[11]. Použití LVM moc nepomůže, ostatně všechny ty nářky na ztracená data, co jsem slyšel, byly právě na ztracená data na LVM, protože RedHatí systémy standardně do LVM instalují (a dávají tam i kořenový svazek, což mi připadá přinejmenším nevhodné). Problém je, že fyzický svazek (PV) LVM se standardně dává na oddíl, takže když zvětšíte disk, oddíl zůstane stejný. Jediná možnost, kde by LVM pomohlo, je dát PV na celý disk bez oddílů. Jenže to by zas z toho disku nešlo bootovat, přinejmenším tedy v klasickém BIOS režimu.

Resize2fs za chodu jsem už dělal a bez problémů. Ale je vhodné poznamenat, že online resizing má své limity, takže filesystém o velikosti 100 MB nelze online zvětšit na 2 TB.

[12]. To jsme si nerozumněli. Widle jsou potřeba k tomu, aby ses dostal ke konzoli virtuálního serveru VMware. Ano, opravdu je to tak, taky jsem nevěřil vlastní očím, dokud jsem to neviděl. Proto není divu, že se radši snažím bez přístupu ke konzoli obejít.

Fdisk je nástroj na editaci tabulky oddílů v MBR, takovou editací je i zvětšení. Problém to není, jen je potřeba vědět, co udělat a respektovat varování. Pak není o nic méně vhodný než kterýkoli jiný nástroj. Ostatně, když zkusíš použít parted pro zvětšení, seřve tě, že resizing filesystémů je deprecated a že máš použít nativní nástroj (tedy resize2fs).

[15] Jsem zhrozen! Není čas říci virtualizaci od VMWare pápá?
Osobně cítím podstatný rozdíl mezi „zvětšit“ a „smazat a udělat to znovu a větší“. Ten rozdíl spočívá v tom, že nástroj na zvětšování se sám postará o zachování a konzistenci dat, koneckonců kvůli tomu vzniknul. Chápu stav nouze, ale tato debata je právě o tom, zda ten stav nouze nastal.

[16] Spis je nacase udelat papa staremu .Net vSphere klientovi.
Nektery ficury uz beztak jedou uz jen v tom novem (i kdyz je pravdou ze VUM je jen pro staryho klienta a ta flashova zalezitost taky neni zadna extra vyhra).

[17] Kdyby jen flashová, to by se ještě dalo přežít (byť je to příšerně pomalé a zbytečně animované). Problém je, že třeba funkcionalita konzole ještě kromě flashe potřebuje proprietární vmware plugin, který sice existuje pro linux, ale instaluje se spuštěním neznámé binárky pod rootem (takže počítač je od té chvíle kompromitovaný). A aby toho nebylo málo, tak ten zobrazovač konzole se natvrdo připojuje na IPv4 adresu vCenter serveru. Pokud k vCenter serveru není IPv4 konektivita, nefunguje. Mají to nahlášeno asi 3 měsíce a zatím nebyly ani schopni vymyslet workaround, natož opravu.

Před časem jsem si dost vyhrál s virtualizací KVM nejenom s nastrojem VirtMan ( Virtual Machine Manager ) ale i s Ovirtem. Ten je zakladem virtualizačního řešení RedHatu. Zda se mi velmi nadějný projekt na managování většího počtu serververů. Nicméně ještě jej musím pořádně prozkoumat a podrobit "testu ohněm". Je to na samostatnou diskuzi, případně i na nějaký workshop. Tím tedy vyzývám vývojaře a komunitu kolem RedHatu ( Novel) , at něco připraví pro širší veřejnost.Díky.
Parádní na tom bylo to, že to fachá pod LVM. Jinak KVM jsem podrobil i dost brutálním testům s podnikovým systémem SAP, kdy jsem za chodu migroval virtuální aplikační servery s 32G RAM a koncový user "normálně" pracoval se systémem, jen měl jistou chvilku přesýpací hodiny. No a když to snese i plně zatížený SAP , tak to snese snad všechno.

[17] Hruby klient (Win aplikacia) je deprecated, niektore veci sa uz odtial ani nedaju vyklikat. Flashovy webklient je vyjebana skurvena domrdana kokotina, kde nie je zatial ani 1/3 user experience povodnej aplikacie (tabulky sa nedaju sortovat podla stlpcov, brutalna pomalost). Ale pri EMC ide o trend, manazmenty ich diskovych poli su podobne tragedie - leske omalovanky okravatovanych kokotov. Binarne hovno, ktore sa nevie ani korektne nainstalovat (rucne treba vyrobit symlink na niektorych systemoch) a pripaja sa na jednotlive hosty (neproxuje sa to cez vCenter)...jedina stastie ze Zimbra je uz mimo tejto tragickej korporacie, lebo od pochovania bola len kusok...

Ja postradam celkem zasadni informaci a to zda je disk pro virtualni stroj realizovan v souboru nebo na fyzickem mediu a zda je tento postup pouzitelny pro vetsi mnozstvi virtualu. Napr. pres virt-manager se da vytvaret velice pohodlne LVM pool nad nekolika disky s desitkami virtualu, zvetsovani prostoru ale popsanym zpusoben udelat nepujde.

[21]. Na tom, jak ji disk pro virtuální stroj realizován vůbec nezáleží. Pokud jde o plnou virtualizaci, virtuální disk se pro virtuální stroj vždy tváří jako blokové zařízení a změny velikosti se tedy projeví jen jako změny velikosti toho blokového zařízení.

Zápisek popisuje postup, kterak uvnitř virtuálního stroje, jehož blokové zařízení bylo od doby instalace zvětšeno, zvětšit filesystém, aby bylo možné nově alokované místo ve virtuálním stroji nějak smysluplně využít. Jestli je virtuální disk realizován souborem, oddílem na disku, nebo LVM oddílem, je z toho pohledu zcela nepodstatné.

Len pre doplnenie informácií:
Ako je to potom s tabuľkou "FAT" (pokiaľ sa nejedná o FAT32, tak táto tabuľka sa určite volá inak, ale niečo jej podobné musí existovať). Zaujímalo by ma, ak je táto tabuľka veľká tak, že pokryje pôvodnú veľkosť disku, čo sa udeje, ak sa disk zväčší? Tá tabuľka pre rozšírenie predsa potrebuje miesto alebo sa mýlim?