Už několikrát jsem byl dotazován ohledně správného postupu zvětšení diskového prostoru u virtuálního serveru. Postup jsem si úspěšně vyzkoušel u sebe, poradil jak na to a… pak poslouchal nářky, že to nefunguje a data jsou pryč. Nejdřív popíšu celý postup:
#dd if=/dev/sda of=oldmbr.bin bs=512 count=1
#scp oldmbr.bin bezpecne-misto.example.cz:
fdisk /dev/sda
nejprve vymažeme z tabulky rozdělení poslední oddíl a následně jej znovu vytvoříme se stejným počátečním blokem a větší velikostí.resize2fs
), nebo fyzického svazku LVM (pomocí pvresize
).Tento postup je bez problému funkční na aktuálních distribucích. Když jsem jej ale nedávno zkoušel na CentOSu, virtuální server po druhém restartu už nenalezl žádná data na disku. Kde byl problém?
Problém je samozřejmě v kroku mazání a znovuvytváření oddílu nástrojem fdisk
. V aktuálním RHELu a jeho klonech je totiž ještě verze fdisku, která ve výchozím stavu zarovnává oddíly na cylindry. Což u virtualizovaného disku dává ještě mnohem menší smysl než u fyzického disku (a u něj to aspoň 15 let smysl nedává žádný :) ). Tedy, pokud nerespektujeme upozornění, fdisk
nám jednoduše bude lhát:
# fdisk /dev/sda POZOR: Režim kompatibility s DOSem je zastaralý. Důrazně se doporučuje tento režim vypnout (příkaz „c“) a změnit jednotky výpisů na sektory (příkaz „u“). Příkaz (m pro nápovědu): p Disk /dev/sda: 10,7 GB, 10 737 418 240 bajtů hlav: 181, sektorů na stopu: 40, cylindrů: 2 896 Jednotky = cylindry po 7240 * 512 = 3 706 880 bajtech Velikost sektoru (logického/fyzického): 512 bajtů / 512 bajtů Velikost I/O (minimální/optimální): 512 bajtů / 512 bajtů Identifikátor disku: 0x00052b20 Zařízení Zavádět Začátek Konec Bloky Id Systém /dev/sda1 * 1 1449 5241856 83 Linux
O skutečném obsahu tabulky rozdělení disku se přesvědčíme příkazem p
v expertním módu:
Příkaz (m pro nápovědu): x Příkaz pro odborníky (m pro nápovědu): p Disk /dev/sda: hlav: 181, sektorů: 40, cylindrů: 2 896 Č. AF Hd Sek Cyl Hd Sek Cyl Začátek Vel. Id 1 80 32 33 0 180 40 652 2048 10483712 83 2 00 0 0 0 0 0 0 0 0 00 3 00 0 0 0 0 0 0 0 0 00 4 00 0 0 0 0 0 0 0 0 00
Teď schválně oddíl zrušíme a vytvoříme „naprosto totožný“:
Příkaz (m pro nápovědu): d Vybrán oddíl 1 Příkaz (m pro nápovědu): n Příkaz e rozšířený diskový oddíl p primární diskový oddíl (1-4) p Číslo diskového oddílu (1-4): 1 První cylindr (1-2896, implicitně 1): Používám implicitní hodnotu 1 Poslední cylindr, +cylindry nebo +velikost{K,M,G} (1-2896, implicitně 2896): 1449 Příkaz (m pro nápovědu): p Disk /dev/sda: 10,7 GB, 10 737 418 240 bajtů hlav: 181, sektorů na stopu: 40, cylindrů: 2 896 Jednotky = cylindry po 7240 * 512 = 3 706 880 bajtech Velikost sektoru (logického/fyzického): 512 bajtů / 512 bajtů Velikost I/O (minimální/optimální): 512 bajtů / 512 bajtů Identifikátor disku: 0x00052b20 Zařízení Zavádět Začátek Konec Bloky Id Systém /dev/sda1 1 1449 5245360 83 Linux
I když nový oddíl začíná a končí na stejném cylindru, rozdílná velikost počtu bloků nám může signalizovat, že tu něco nehraje. Expertní režim odhalí, že oddíl nyní začíná úplně jinde než předtím. Důležitá je hlavně hodnota označená „Začátek“. Ta totiž určuje LBA adresu prvního bloku daného oddílu. Vidíme, že „DOS-kompatibilní“ režim nám přesunul oddíl z bloku 2048 na blok 40. Není divu, že počítač po restartu nebyl schopen najít filesystém.
Příkaz (m pro nápovědu): x Příkaz pro odborníky (m pro nápovědu): p Disk /dev/sda: hlav: 181, sektorů: 40, cylindrů: 2 896 Č. AF Hd Sek Cyl Hd Sek Cyl Začátek Vel. Id 1 00 1 1 0 180 40 1023 40 10490720 83 2 00 0 0 0 0 0 0 0 0 00 3 00 0 0 0 0 0 0 0 0 00 4 00 0 0 0 0 0 0 0 0 00
Řešení problému je přitom velmi snadné. Stačí neignorovat upozornění, které fdisk
při spuštění vypisuje:
# fdisk /dev/sda POZOR: Režim kompatibility s DOSem je zastaralý. Důrazně se doporučuje tento režim vypnout (příkaz „c“) a změnit jednotky výpisů na sektory (příkaz „u“). Příkaz (m pro nápovědu): c Příznak DOSOVÉ kompatibility není nastaven. Příkaz (m pro nápovědu): u Měním jednotky v nichž jsou vypisovány informace na sektory Příkaz (m pro nápovědu): d Vybrán oddíl 1 Příkaz (m pro nápovědu): n Příkaz e rozšířený diskový oddíl p primární diskový oddíl (1-4) p Číslo diskového oddílu (1-4): 1 První sektor (2048-20971519, implicitně 2048): Používám implicitní hodnotu 2048 Poslední sektor, +sektory nebo +velikost{K,M,G} (2048-20971519, implicitně 20971519): Používám implicitní hodnotu 20971519 Příkaz (m pro nápovědu): p Disk /dev/sda: 10,7 GB, 10 737 418 240 bajtů hlav: 181, sektorů na stopu: 40, cylindrů: 2 896, celkem 20 971 520 sektorů Jednotky = sektory po 1 * 512 = 512 bajtech Velikost sektoru (logického/fyzického): 512 bajtů / 512 bajtů Velikost I/O (minimální/optimální): 512 bajtů / 512 bajtů Identifikátor disku: 0x00052b20 Zařízení Zavádět Začátek Konec Bloky Id Systém /dev/sda1 2048 20971519 10484736 83 Linux Příkaz (m pro nápovědu): x Příkaz pro odborníky (m pro nápovědu): p Disk /dev/sda: hlav: 181, sektorů: 40, cylindrů: 2 896 Č. AF Hd Sek Cyl Hd Sek Cyl Začátek Vel. Id 1 00 51 9 0 111 40 848 2048 20969472 83 2 00 0 0 0 0 0 0 0 0 00 3 00 0 0 0 0 0 0 0 0 00 4 00 0 0 0 0 0 0 0 0 00
Jak vidíte, po vypnutí kompatibility s DOSem začíná nově vytvořený oddíl na správném bloku číslo 2048. Trochu matoucí je, že nová tabulka i přesto obsahuje jiné CHS hodnoty začátku oddílu, to zřejmě souvisí se změnou virtuální geometrie zvětšeného virtuálního disku. Linux s tím ale nemá problém, tak to nejspíš nemá smysl řešit.
Poučení pro příště:
[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.
[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).
[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.
[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.
[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?
Co o sobě napsat? Absolvent ČVUT FEL, linuxák, síťař. Mimo to se zajímám o elektrotechniku, elektroniku a speciálně elektrické pohony.
Přečteno 56 673×
Přečteno 15 735×
Přečteno 15 713×
Přečteno 14 944×
Přečteno 12 953×