VMware guest partíció átméretezése

 ( pekob | 2019. június 4., kedd - 18:40 )

Sziasztok!

Van egy Debian egy Vmware alatt, amin nincs LVM. A diszk mérete meg lett növelve a host konfigban, valahogy szeretném rávenni a guest-et, hogy ki is tudjam használni. Az fdisk látja a nagyobb lemezt, a kérdés csak az, hogy egy adott partíciót hogyan tudnék átméretezni, ha az nem az utolsó.

/dev/sda lemez: 64.4 GB, 64424509440 bájt

255 fej, 63 szektor, 7832 cilinder
Egység: cilinderek 16065 * 512 = 8225280 bájt
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Lemezazonosító: 0x00030d15

Eszköz Indítás Eleje Vége Blokkok Az Rendszer
/dev/sda1 * 1 43 340992 83 Linux
A(z) 1. partíció nem cilinderhatáron végződik.
/dev/sda2 43 5222 41598977 5 Kiterjesztett
/dev/sda5 43 1137 8787968 83 Linux
/dev/sda6 1137 1502 2928640 83 Linux
/dev/sda7 1502 1966 3729408 82 Linux lapozó / Solaris
/dev/sda8 1967 2015 389120 83 Linux
/dev/sda9 2015 5222 25759744 83 Linux

Az sda6-ot kellene megnövelnem, ez megoldható?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ez a kérdés teljesen független a VMware-től.

Mivel a /dev/sda6 után a diszken közvetlenül a /dev/sda7 következik, ezért a partíciót csak úgy tudod nagyobbra méretezni, ha csinálsz utána szabad helyet, magyarul, az utána lévő partíció(k)at áthelyezed.

GParted és társai a barátod.

Nincs rajta x :(

gpartedlive
google

Megoldás lehet az, ha csinálok egy új partíciót, a 7-8-9-ről oda elmásolom az adatokat (az egyik swap, a másik /tmp, a harmadik a /home), utána ki tudnám tolni a 6-os végét?

Ha méretben kiadja, akkor persze.

+1

Egy pillanat alatt árméretezi neked.

Nem is biztos hogy kell rá X, ha van egy Windows akkor Xming és PuTTY, ha egy másik Linux X-el akkor arra is át lehet vinni az ablakot.
Hely viszont kell neki, xauth, xlib meg még egy pár X-hez tartozó csomag kellhet még, de úgyis kiírja hogy mi hiányzik plusz ssh x-forwarding ami kell hozzá.
Aztán ami nem kell le kell szedni, persze csak a policy engedi hogy telepíts ezt-azt.

Egyszerubb, ha egy uj virtualis diszket adsz neki (/dev/sdb), es arra koltoztetsz at adatot. Particiok mozgatasaba nem erdemes belekezdeni.

> Particiok mozgatasaba nem erdemes belekezdeni.

A topicnyitó alapján 64 GB-os virtuális diszkről van szó, márpedig, ilyen méretek és a mai I/O sebességek mellett valószínűleg pár perc alatt odébb lehet tolni a partíciókat.

Terabájtok esetén nyilván az ember kétszer is meggondolja, mit hová tologat... (nem tologat)

ha meg egyszer piszkalja akkor LVMre vele... nem ordogtol valo az.

+1, de inkább +qrvasok. Virtuál izélt :) környezetben meg pláne...

sysrescuecd bebootolsz, startx, gparted, majd szepen az sda7..9-et odebb helyezed, majd sda6-ot meg atmeretezed

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Én egyátalán nem bajlódnék partíciókkal, VM-ben ez teljesen felesleges hiszen:
- bármennyi diszket bele tudsz rakni - utólag is.
- bármikor átméretezheted.

OS-en belül sem LVM, sem partíciós táblákkal nem kell ilyenkor vacakolni.

szerintem.
--
zrubi.hu

Azert az LVM hasznos tud lenni VM-ben is, hiszen menet kozben lehet attranszformalni (pl. migralni adatot masik vdiskre) a rendszert.

Azért az sem mindegy, hogy 23 diszket kell menteni, vagy csak egyet. A több diszkre szétpakolni akkor jó, ha manuális tiering van storage tekintetében, vagy ha az adatokat várhatóan szükséges lesz mozgatni gépek között - ez utóbbi esetben a "hurcolós" diszken simán lehet partícionálás nélkül fájlrendszert csinálni, de általában több az lvm-re pakolás előnye, mint hátránya.

nyilván, felhasználás függő a dolog.

Nálam alapelv, hogy egy VM csak egy feladatot lát el.
Kb így néz ki egy átlagos VM diszk ügyileg:
- root
- data (felhasználástól függően /home vagy /var/www vagy valami más:)
- tmp
- swap

Ezek közül csak a data amit menteni kell, a többi vagy eldobható, vagy distróból jövő binárisok.
(A konfigokat meg file szinten mentem - ha szükség van rá.)

--
zrubi.hu

"csak a data amit menteni kell" - meg a logok, meg a konfigok, meg... Persze a kérdés az, hogy mennyi kiesést visel el az adott szolgáltatás...

Most off: A jövőben érdemes ezért minden partíciót külön diszkként kiajánlani a virtuális gépnek.
Mert akkor a hypervisorban megnövelt diszket elég guest rendszeren belül fdisk-kel partíciót törölni, létrehozni (adatok nem vesznek el) és ext2resize.
Illetve swapra tökéletesen elég egy fájl, pl. /swap.bin és ezt az fstabba tenni. Bármikor növelhető. Egy diszkkel/partícióval kevesebb.

Ha van 10-15 külön kezelendő adatterületed (2-3 csoportban) egy gépen, akkor ennyi diszk? És ha van 100+ ilyen géped? Ha már egyszerűsítés, akkor minek partíció? Az mkfs /dev/sdX is tökéletesen működő megoldást ad - ekkor még partíció törlés/újra létrehozás sem köll, csak a diszk új méretét kell a rendszerrel felnyalatni - az meg simán működik :-)
A swap meg, ha már f0ssuk a diszkeket a gép alá simán mehet úgy, hogy új diszket adsz a gépnek, mksap /dev/sdx && swapon /dev/sdx, utána meg swapoff /dev/sd_regi_swap_, aztán amikor tényleg kidobta a régit, akkor fstab matyizás, régi diszk kikukázás.

1 virtuális gépben 10-15 kezelendő adatterület? El tudom képzelni, hogy én hagytam még ki valamit az elmúlt sok év üzemeltetéséből, de szerintem 5-nél megállt mindig.
root, data (jellemzően www), ideiglenes gyors backup (dump, bármi), mysql, log.
Mit lehet még külön szedni 15 felé?
A swap partíció vs. fájl ez kicsit hitvita is. Nekem nagyon kényelmes rendszeren belül bármikor el tudom dobni, a hypervisort még csak meg sem kell nyitnom meg emiatt plusz partíciót esetleg az én hülye megoldásomban diszket kezelni :)

mkfs partíció nélküli esetben rögtön frissíti a méretét, ha változik a diszk méret? egy érdekes és elborult, bár logikus ötlet, nem próbáltam még :) Valahol a hős korban olvastam, hogy partíció kell, mert úgy illik úgy a jó és ezt nem firtattam.

Egyébként ez az egész 1 partíció 1 diszk téma az opensource xen időszakból jött. Könnyebb volt Dom0-ból felcsatolni az LVM-en lévő 1 db virtuális diszket 1 db partícióval, mint csatolás előtt offsettel vagy egyéb partícót felnyaló programmal játszani.

Több hasonló rendszer adatait kellett egy gépen elérni, manuális tiering mellett: különböző iops igény volt az egyes kötetekre, egy - mondjuk így - rendszer 2-3 tier-ben használt diszkeket, miközben az egyes "rendszerek" gépek közötti migrálhatóságát is meg kellett oldani. Igen, tudom, miért nem egy rendszer-egy gép volt a felállás: CPU-ban, illetve gépek darabszámában erősen szuboptimális lett volna a dolog (nem 1-2, hanem jóval több ilyen vm-ről volt szó).

A swap/page terület néhol arra (is) szolgál, hogy a rendszer összeomlásakor oda kerül a dump, amit a következő boot során elő lehet vakarni. A swap területet fs-be kirakni plusz egy "layer" a kezelése során - nem véletlen, hogy szinte sehol sem ez a standard - a Windows lapozófájl kivételével :-)

A "partíció kell" az akkor jön a képbe, ha darabolni akarod a diszket, netán Má$ gyártó rendszerével sem szeretnél összeveszni - egyébként fölösleges - a /dev/sdx is ugyanolyon blokkdevide, mint a /dev/sdx23, ugyanúcs kell írni-olvasni :-) ugyanúcs használható mkfs-sel vagy épp pvcreate-tel :-)

Szerintem nem jó megoldás, nagyon nem. 1-2 lemez még elmegy mert lehet más felhasználás, más IO limit, stb, de mindenen LVM és máris lehet bármikor, bármit mozgatni.