- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Ez tud LUN-t raw-ként kezelni, mint a VMware (és ahogy a Proxmox nem)?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
ahogy a Proxmox nem
Direkt emiatt csináltam openmediavault alatt egy iscsi targetet (nincs itthon "igazi" storage-om), azt felcsatoltam a proxmoxomba, arra feltettem egy vm-et, és sima ügy volt.
Vagy mást értünk RAW alatt?
- A hozzászóláshoz be kell jelentkezni
Tudsz rajta VM snapshotot létrehozni?
- A hozzászóláshoz be kell jelentkezni
Nem próbáltam. Élt 5 percet :-)
Egy különbséget észrevettem a VMware-hez képest, Proxmoxon egy iSCSI LUN-ba egy VM-et tehetsz (legalább is az 5 perces tesztem alapján ezt tapasztaltam).
Cégnél VMware-t használunk (kötelező jelleggel), itthon minden igényemet kielégíti a Proxmox. iSCSI funkcióra pont nincs szükségem :-)
- A hozzászóláshoz be kell jelentkezni
de tud
- A hozzászóláshoz be kell jelentkezni
Ez tud LUN-t raw-ként kezelni, mint a VMware
tudni tud, de csak az adott hypervisorhoz kötődő 'local disk' lesz belőle, mert a VMFS-hez hasonló máshol máig nincs (használható állapotban).
- A hozzászóláshoz be kell jelentkezni
Mögötte áll a Linux Foundation. Szóval ez nagy pénz, kis foci! :-)
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Ha kérdésed az volt, hogy egy LUN-t tud -e clusterben kezelni, shared storage-ként, akkor a válasz igen.
De szerintem te arra gondoltál, hogy egy LUN-t raw device-ként direktben odaadsz egy VM-nek (passtrhrough), és működik így is a live migration, ez esetben pedig a válasz: nem.
- A hozzászóláshoz be kell jelentkezni
Ha kérdésed az volt, hogy egy LUN-t tud -e clusterben kezelni, shared storage-ként, akkor a válasz igen.
Tud-e LUN-ot - iSCSI, FC tök mindegy - értelmes, shared storage fájlrendszerrel - mint a VMFS - formázni és legalább azokkal a feature set-ekkel használni.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
nyilván nem tudja ugyanazt a feature set-et mint a vmware, de árban sem ugyanaz a liga.
Nem nagyon találtam még linuxra olyan cluster file rendszert, ami egy szinten említhető a vmfs-el.
XCP-NG alatt a shared block device-ra nem file rendszer kerül, hanem egy volume group. Minden virtuális diszknek egy külön volume-ot csinál, a volume groupot a cluster minden node-ja látja, volume szinten van a lockolás. Egyébként meg ha ezt nem tudod, akkor észre sem veszed, hogy nem file rendszer. Látsz egy storage repo-t, amiben tudsz diszkeket létrehozni a VM-eknek, a VM-eket meg bármelyik node-on futtathatod, ide-oda költöztetheted, mint vmware alatt.
Live migration, storage migration, snapshot működik. Online resize 2 éve még nem ment, roadmap-en rajta, nem tudom, azóta megoldották -e.
Thin provision, csak NFS storage-el. (meg gluster, ceph, moose FS-ekkel, de azok officially not supported)
Ha sokat akar az ember snapshotolni, akkor ne használjon block device-et, mert zabálja a helyet, használjon inkább NFS-t. A block device (kb. egyetlen) előnye leginkább az, hogy ha van egy duál controller storage, akkor megfelelően redundáns multipath topológia építhető vele.
Milyen egyéb feature kell még?
- A hozzászóláshoz be kell jelentkezni
Milyen egyéb feature kell még?
Ezek stabilitása. Ha az megvan, akkor jó a sarkalatos kérdés: mivel fogjuk menteni. Ahogy a Proxmox-nál is előjött, de ott mondjuk a Veeam megoldotta (vagy legalábbis rajta van az ügyön).
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nem értek vmware-hez,VMFS shared vagy mi ? Mert az iSCSI LUN is shared ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Mert az iSCSI LUN is shared
:)
Igen, csak míg a LUN egy block device, a VMFS pedig egy filerendszer.
Egy shared filerendszer, amit egyszerre több node (esetünkben hypervisor) is írhat olvashat.
(Nem mellesleg ez is általában egy LUN-on lakik ;)
Tehát, egy shared LUN, az kezdésnek jó, már csak egy shared filesystem is kellene, hogy 'utolérjük' és/vagy kiváltsuk a VMFS-t.
Ha el is olvasod amit linkeltél, ott a 'storage types' közül a shared-et kell keresni, a supported jelzővel együtt.
Ez pedig - egyelőre - csak az NFS.
persze, találsz ott ilyeneket, mint:
GlusterFS, CephFS, MooseFS - de ezek össze sem hasonlíthatóak a VMFS-sel. Ezenk sokkal inkább shared storage service-ek, jelentős hardver igénnyel.
a VMFS ezze lszemben egy 'szimpla' filrendszer. A probléma vele csupán az, hogy zárt és szbadalom alatt álló. Ami a gyakorlatban azt jelenti, hogy csak a VMware/Broadcom termékei képesek írni/olvasni.
- A hozzászóláshoz be kell jelentkezni
Ok tehát akkor VMFS helyett van NFS :D
Mi szól a VMFS mellett, vagy mi az a feature amit az NFS nem tud, de nagyon szeretik VMFS -ben ?
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Ok tehát akkor VMFS helyett van NFS
Van. :)
Csak ez olyan, mintha az iPhone 16 Pro Max -odat (nem személyeskedés, csak példa) lecserélnéd egy Nokia 3310-re. - mert hát végülis telefonálni mindkettővel lehetséges ;)
Komolyabbra fordítva a szót - az VMFS vs NFS témában igen sok dolgot találsz, de aki már mindkettőt használta, annak általában a facepalm az első és egyetlen reakciója :D
- A hozzászóláshoz be kell jelentkezni
Csak ez olyan, mintha az iPhone 16 Pro Max -odat (nem személyeskedés, csak példa) lecserélnéd egy Nokia 3310-re.
Gondolom árban is ekkora a különbség ... :D
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
jó látod:
NFS ~ ingyen van vs. a VMFS (vSphere) - a Broadcom újraárazása után...
- A hozzászóláshoz be kell jelentkezni
Egyrészt ha ott állsz a semmi közepén lerobbant autóval a kezedben egy lemerült iPhone 16 Pro Max mobillal, amit naponta kellene tölteni már nem lesz olyan fasza választás az iPhone. Ha viszont működő Nokia 3310 mobil van nálad ami két hétig is bírja egy feltöltéssel máris az lesz a nyerő mobil.
Ha VMFS vs NFS párharcra az iPhone 16 pro max kontra Nokia 3310 párhuzamot hoztad, akkor a VMFS vs Kubernetes összevetésben a VMFS továbbra is iPhone 16 max pro még a Kubernetes a Nexus 6 replikáns android autonóm mesterséges intelligencia aggyal és embereket messze meghaladó kognitív képességekkel és fizikai erőnléttel. :-)
De Ceph is klasszikokkal kifinomultabb megoldás mint a VMFS, amire a Nexus 6-os replikánsok adamantium csontváza épül. :-D
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Mondjuk hogy van 80+ TB enterprise Storageon ami iscsin/FC-n adja ki LUN-t
- A hozzászóláshoz be kell jelentkezni
És ? Simán kezel iSCSI -t az xcp-ng is, csak nem VMFS kerül rá ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Még mindig nem érted. Kezeli. De exclusive accessel. Ergo nincs olyan shared filerendszer mint vmwaren a VMFS vagy Hypervn a ClusterFS amit a multinode cluster minden tagja paralell ír és olvas. Ergo minden vmdk/vhd kulon LUNra kell hogy kerüljön.
Ami sokszor indokolt lehet pl performance okokbol, de managelhetoseg/mentes/snapshot szemponból egy rémálom.
(visszasírom a VxFSt pedig az se volt egy egyszerű jószág)
- A hozzászóláshoz be kell jelentkezni
Így van lehet én értem félre.
Szóval van egy 4 node os xcp-ng clusterem. Csatolok hozzá remote NFS / iSCSI LUN-t stb. Azt mind a 4 node írja olvassa szimultán, mert ezken vannak a VM-ek diskjei.
Szóval mondhatni, minden hypervisor használja belőle a azt a részt ami a VM-jéhez tartozik ...
Ezek szerint vmware alatt 1 vmdk-t lehet több VPS-nek írni olvasni egyidőben (úgy, hogy VM alatt a disken mondjuk ext4 fs van ...) ?
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Ott érted fére hogy az NFS alma az iSCSI körte.
Az NFS maga ad egy (Network)FileSystem-et (funkcionálisan)
Az iscsi blokkdevicet ad, amin van -valamilyen- filesystem (cluster aware pl: vmfs, microsoft clusterfs - vagy non cluster aware: ext4, xfs, ntfs)
Az NFS kezel lockingot de nem blokkeszközt ad. És a mid-size enterprise storageok 95%-a nem támogatja (a Netapp a kivétel).
- A hozzászóláshoz be kell jelentkezni
Tudom mi az NFS mi az iSCSI
Nekem a VMFS maradt ki az életemből.
Ergo nincs olyan shared filerendszer mint vmwaren a VMFS vagy Hypervn a ClusterFS amit a multinode cluster minden tagja paralell ír és olvas.
Ezért írtam a példát, hogy mit ír és olvas ? Írtam NFS en is minden node tud írni és olvasni. az iSCSI LUN-t is megkapja minden node. stb
Ezért kérdeztem, hogy a VM diskje ezek szerint VMFS-en van. A kérdés az, hogy 1 VM diskjét csatolhatom-e több VM-hez is, és ezeken írhatom/olvashatom-e stb.
Vagy akkor mit értesz azalatt "multinode cluster minden tagja paralell ír és olvas."
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Nem biztos, hogy ezt értette alatta, de egyébként a kérdésedre a válasz az, hogy igen, a vmfs támogat multiwrite-ot 1db vmdk-ra értelmezve is. Pl. ezzel a funkcióval tudsz meglevő egyéb clustereket (pl. WSFC-t) virtualizálni.
- A hozzászóláshoz be kell jelentkezni
Nem az a lényeg hogy több VM olvassa az VMDK-t. (amúgy tud ilyet, de nyilván a VMDK-n (ami a VM fele blokkeszközként látszódik) cluster aware filerendszer kell)
iSCSIn felcsatolsz proxmoxon egy LUN-t, 2 nodera, ezen van 25 VM hdd file (a formátum tokmindegy), mivel nincs cluster aware filerendszered, semmi nem védi a fileokat és a filrendszer attól hogy a két node kersztbe írja ugyanazt a területet.
- A hozzászóláshoz be kell jelentkezni
Miért kéne ehhez cluster FS ?
XCP-ng az iSCSI -ra egy LVM-et rak. a VM-ek pedig LV-t kapnak. Értelemszerűen az LV adott node lockolja másik node nem tudja írni, és így nem is fogja ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Bocsánat, rosszul/félreérthetően fogalmaztam. Tud lockot, de csak az egész VG-re.
Vagy lockot tud, vagy shared storageot.
Proxmox doksi:
"LVM is a typical block storage, but this backend does not support snapshots and clones. Unfortunately, normal LVM snapshots are quite inefficient, because they interfere with all writes on the entire volume group during snapshot time.
One big advantage is that you can use it on top of a shared storage, for example, an iSCSI LUN. The backend itself implements proper cluster-wide locking.
The newer LVM-thin backend allows snapshots and clones, but does not support shared storage. |
"
- A hozzászóláshoz be kell jelentkezni
Nem, az xcp-ng volume szinten lockol. Ugyanaz a lun több node-on is írható olvasható, és nem lesz korrupt.
- A hozzászóláshoz be kell jelentkezni
Ceph-hez képest ezek amatőr megoldások örök középhaladóknak.
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Köszönjük a mély szakmai hozzászólást.
- A hozzászóláshoz be kell jelentkezni
Nem tetszik a tükör kedves "szakmai" RoLi? Te ismersz egy adott technológiát ezért azt isteníted és leszólod az alternatívákat. Egyébként objektív, tényszerű érvek alapján a Ceph egy magasabb szintű megoldás, ami ugyanakkor nagyobb szaktudást is igényel. Ha nem tudod mi az a Ceph ne rohanj tátott szájjal abba a bizonyos fütyköserdőbe!
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni
Ha távolabbról nézzük a feladatot, és nem ragaszkodunk a "vágjátok ki ezt az erdőt ezzel a heringgel" szisztémához (úgy fogalmazom meg a feladatot, a körülményeket, hogy csak a VMFS legyen alkalmas az elvégzésére), akkor lehet előrébb jutnánk ebben a vitában.
Ha van egy proprietary enterprise storage-om, ami csak iSCSI-n ad LUN-t, akkor valóban a VMFS lesz az egyetlen jó megoldás VMware termékekkel (vagy Hyper-V ClusterFS-sel, de azért nemár...). Értem, hogy akinek egy ilyen ki van fizetve, az ragaszkodik olyan megoldáshoz, ami ezzel jól működik.
De ha tervezek egy új rendszert (szerintem a VMware-ről elmigrálók jelentős része nem in-place migrációt végez), akkor eltekinthetek a méregdrága proprietary enterprise storage-től, és tervezhetek pl. Ceph-fel, ami viszont nagyságrendekkel több flexibilitást ad, valószínű olcsóbban, és nem lesz vendor lock-in a tárolásban (sem). A tanulási görbéje meg nem rosszabb az enterprise SAN-oknál, szerintem.
Ráadásul a Ceph-et nem kötelező hyperconverged módon használni (sőt), lehet egy külön Ceph cluster (bármekkora), amit akár Proxmox-ról, akár xcp-ng-ről el lehet érni. Sőt, iSCSI-n kiajánlva VMware-ről is, ami pl. egy migrációt eléggé megkönnyíthet. Lesz tömörítés, deduplikáció, rétegezett tárolás, snapshot, valódi többszörös elérés akár virtuális diszk szinten, stb.
Lehet úgy kell ezt nézni, hogy a VMware elengedésével márt is el kell engedni, vagy fordítva, amíg a mást (meglévő storage) meg akarom tartani teljes funkcionalitással, addig a VMware-rel is együtt kell élnem.
- A hozzászóláshoz be kell jelentkezni
Ergo minden vmdk/vhd kulon LUNra kell hogy kerüljön.
Ez nem igaz. Block dev-re cluster LVM-et rak, és volume szinten lockol. Vagyis egy LUN-on lehet bármennyi vm diszk, és azokat más-más cluster node tudja kezelni.
FC-n és iSCSI-n is működik
- A hozzászóláshoz be kell jelentkezni
Ha el is olvasod amit linkeltél, ott a 'storage types' közül a shared-et kell keresni, a supported jelzővel együtt.
Ez pedig - egyelőre - csak az NFS.
Nem. Az icsi és a HBA (FC) is shared, és supported is. Egy LUN-ra rak egy volume groupot, és volume szinten tud lockolni. Minden külön volume-ot más-más node tud kezelni. Vagyis egy LUn-on tud több VM is futni, más más fizikai node-okon, és megy a live migration is, meg a storage migration is.
Így használom már 10+ éve, FC és icsi targetekkel.
- A hozzászóláshoz be kell jelentkezni
De itt még mindig block szintű lockolás van, tehát minden node.nak kell egy külön block device. Hogy ez direktben egy LUN, vagy LVM az mindegy.
Amivel mi (és minden VMware-es) hasonlítja, az a VMFS, ami egy filerendszer, nem block device. Tehát az egész clusterhez elég egyetlen LUN, azon egyetlen VMFS filerendszer. Ezen lakik az összes VM, attól függetlenül, hogy melyik node-on fut. igy itt a lockolás filerendszer szinten van.
Ennek rengeteg előnye van, a feljebb vázolt 'workaround'-okhoz képest:
- thin disk support
- effektíb több helyed marad, mert nem kell előre 'szétdarabolni'
- +1 node esetén sem kell semmit sem változtatni
- vmotion esetében nem kell a file-okat sehová sem mozgatni
- stb. stb.
Ehhez 'hasonló' módon működik az NFS, ezért ez az egyetlen összehasonlítható megoldás. Azonban ez is messze elmarad a VMFS kínálta megbízhatóságtól, rendelkezésre állsától, és egyéb fícsöreitől.
Biztosan lehet élni ezek nélkül is, de aki ezeket megszokta, akkor már nehéz elengedni ;) - ezt használja ki nagyon durván és pofátlanul a Broadcom.
Szerintem.
- A hozzászóláshoz be kell jelentkezni
tehát minden node.nak kell egy külön block device.
Nem, nem kell. XCP-ng ben nem kell
Be is baszna ha van egy 16 node-os pool om és minden node külön LUN kéne ... 1 LUN oszt jóvan, szépen megosztoznak rajta ...
Mondjuk pont a thin miatt már mindenhol NFS-t használom. Amennyiben jó az "NFS" + network szerver nincsen gond a megbízhatósággal.
akkor már nehéz elengedni
Nem nehéz azt, csak ár kérdése :D Migráltam már én is vmware ről xcp-ng-re ....
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
1 LUN oszt jóvan, szépen megosztoznak rajta
És hogyan is pontosan?
És ki csinál akkor rajta filerendszert? és pontosan milyet? Mert szerintem akármilyet is, az végül egy 'local' filerendszer lesz, amit csak az adott node használ - javíts ki ha tévedek.
link is jó, tényleg érdekel nem csak kötekszem ;)
- A hozzászóláshoz be kell jelentkezni
És ki csinál akkor rajta filerendszert?
Nem FS lesz rajta. Ha FS kell akkor NFS vagy a többi.
Ez klasszikus LVM. Ha kell egy disk akkor az LV-ra kerül. Így ezt is minden node látni fogja, aktív viszont azon a node-on lesz ahol fut a hozzá tartozó VM fut.
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Nincs file rendszer. Egy LUN-ra egy volume group kerül. Minden virtuális diszk egy külön volume. A lockolás volume szintű, tehát ugyanzon a LUN-on lehet több VM, amit eltérő fizikai node-ok futtatnak. Keress rá ha érdekel. :). dokumentációt régen olvastam, jó ideje így használom (4 node, ~40 Vm, most épp 2 db iSCSI LUN, korábban , meg FC storage-on 2 LUN.)
Ugyanúgy nem mozgatja vmotion esetén a diszkeket, csak átkapcsolja a másik node-ra. A live migration kb ugyanannyi idő mint vmware alatt.
Amit nem tud, az a thin provisioning, pont azért, mert ez nem file rendszer. Emiatt a snapshot is elég sok diszket használ.
- A hozzászóláshoz be kell jelentkezni
.
- A hozzászóláshoz be kell jelentkezni
fixme, de a proxmox doksi azt irja hogy iscsi az shared storage. es lvm doksi is ir egy ilyet (kvazi lvm over iscsi):
nyilvan nemtud annyit mint a vmware, de akinek kellenek a plusz ficsorok, az nyissa ki a penztarcat! \o/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Nincs se klon se snapshot ebben az esetben.
A penztarcas resszel egyetértek, ezért migrálok kínomban HyperV clusterekre, mert még mindig nagységrendel olcsóbb mint a vmware. (pedig GSX serverrel kezdtem)
- A hozzászóláshoz be kell jelentkezni
ha ismered az lvm-et akkor tudod hogy van abban snapshot. csak tul sok megkotessel jar, amit a proxmox fejlesztok nem akartak lekezelni, ezert egyszeruen nem implementaltak az lvm pluginben a szukseges hivasokat. (amugy 3k meretu a patch ami beleirja, hogy megis legyen ;) ).
aki naponta 23 snapshotot gyart, annak valoban nemjo a proxmox. neki ott a vmware, lop-szop-bakotugrik! az egyes kassza nyitva! \o/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Nem vagyok VMware-ben jártas, így kérdezem, hogy a snapshot-ja korlátlan ideig megőrizhető, vagy befolyásolja a teljesítményt és a helyfoglalást?
Nagyon régen, szóló ESXi-n kellett megnéznem, miért fogyott el a hely, és akkor láttam, hogy a valamikor valaki által készített snapshot ette meg a tárterületet. Meg mondták, hogy egyébként bazi lassú is egy ideje a VM.
Nem tudom, hogy ez csak bizonyos módon használt ESXi esetén van így, bizonyos storage esetén (ez sima helyi diszkes VMFS5 vagy 6 volt), rossz beállítás, rossz használat, vagy mindig ilyen?
- A hozzászóláshoz be kell jelentkezni
Snapshot rontja a performanciat a copy-on-write miatt. A vmware oktatáson azt mondták, hogy 1-2 napig illik meghagyni. Nyilvan i/o függő, de a lehető leghamarabb illik torolni. Jellemzően addig él, amíg lehúzzuk a backupot.
- A hozzászóláshoz be kell jelentkezni
A Vmware snapshot nem CoW (és nem is RoW). Faék egyszerű a működése, sanpshot készítés pillanatában az eredeti disket simán csak lezárja, kvázi read-only lesz, a változásokat pedig egy snapshot vmdk-ba írja. Performanciavesztés akkor van, amikor törlöd a snapshotot, ugyanis össze kell fűznie a két disket, és ez az, amiért nem tanácsos nagyon hosszú ideig rajta hagyni (persze ez is fals, hiszen valójában nem az időtől függ a dolog, hanem a snapshot készítése utáni írás mennyiségétől).
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy ez a sztori most más, már túlmutat a majmon és a banánon, itt a banán már rég meg lett véve. A Broadcom akkorát húzott, hogy konkrétan megkérdőjelezendő, hogy ha nem változik semmi, akkor egyáltalán itthon lesz e a jövőben VMware bárhol (include multik, kormányzati infra, stb..). Nem véletlen, hogy az EU is vizsgálódik az ügyben. Adott esetben *20-as áremelkedésekről beszélünk. Ha hirtelen az éves 1 millió EUR-os (mert ugye kiköhögték, lett banán) licence költségekből 20 millió lesz, arra azért már mindenki felkapja a fejét.
A másik baj vele, hogy ezeken a helyeken iSCSI sincs nagyon, sokkal inkább FC tárolók dolgoznak + hozzájuk kiépített nagy kiterjedésű SAN-ok. Ahogy a dolgok jelenleg állnak, úgy tűnik, hogy vSphere-n vagy Hyper-V-n nélkül nincs olyan megoldás, amikkel ezeket a továbbiakban használni lehet ugyanolyan funkcionalitás mellett. Pl. sokan a nevető harmadikban (Nutanix) látják a jövőt, de ők is HCI only megoldást tudnak csak felmutatni. Vagy tényleg ki kell köhögni a hússzoros árat, de mi a garancia arra, hogy jövőre nem lesz ötvenszeres? Aztán meg az is nyilvánvaló, hogy aki csak tudja, az tovább fogja terhelni az ügyfelekre ezeket az összegeket.
- A hozzászóláshoz be kell jelentkezni
Ebben az esetben az hogy a SAN protokoll iSCSi / FC az mind1.
A többi résszel egyetértek.
PS: ugyanitt HA NFS szerver kerestetik.
- A hozzászóláshoz be kell jelentkezni
PS: ugyanitt HA NFS szerver kerestetik.
Szólj ha találtál. :)
De még ha találsz is, azt nem fogod switch szinten redundáns multipath konfigban kiépíteni, mint egy rendes duál controlleres block storage-ot.
- A hozzászóláshoz be kell jelentkezni
el kell donteni mi a fontosabb: a featureset vagy a penztarca.
oregapam szokta mondani: "futni, kozben szarni, es egyhelyre is potyogjon. nem megy!" :D
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Tudtommal HVM, és PVHVM van. PVH nem is volt.
A PV -t meg már nincs is. 32 bites már a 8.2 ben se futott, 8.3 nál már asszem a 64 bites se fog.
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Nem. HVM PV és PVHVM , ahogy a xenserver ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
xenserverre mar nem emlekszem, nem hasznalom evek ota, debian/xen alatt megy nekem a pvh.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Én fordítva vagyok, 1x éve debian / xen ről lett váltva xenserverre utána XCP-ng re. vagy 7-8 éve a srácok által fejlesztett XenOrchestra (webes management az xcp-ng/xenserverhez) is bőven kielégíti az alap igényeket, vagy még többet is.
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
nalam debian/xen -> citrix xenserver -> debian/xen :)
es a libvirt, mert az van hozza.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
A xoa rohadt kényelmes webes cucc. 1 felületen tudod kezelni az összes hypervisorod minden szarját ... Xenapi szerintem jobb mint a libvirt, és végre van hozzá rendes felület is ...
Persze kinek mi ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
na igen, debianbol nem csak a tudasa alapjan dobhatnak ki valamit, mas oka is lehet :)
regen azt is xen-api-val hasznaltam.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Igen, próbálkoztam ezzel én is annó, de hagytam a francba mert minek, ha a vendor szállítja. Aztán hogy a hypervisor milyen linux OS sokadlagos ssh/xenapi meg az a pár alap cucc elfut bármelyiken.
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
mintha azt olvastam volna, xcp-ng-t lanra ajanljak. nekem kit van a gepem a neten.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Igazából minden hypervisor-t LAN-on kéne tartani mert mit keres publikus neten ...
Nekem is van olyan ami publikus neten log évek óta. Értelemszerűen naprakészen tartva. Persze érdemes iptables-el korlátozni ami nem kell ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
es a vm-ek a publikus interfesszel 1 bridge-ben vannak, vagy van egy kulon privat bridge, es portforwarddal erhetoek el?
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Egyrészt openvswitch a default.
is-is Lehet VM ugyanazon az ifacen publikus ipvel, de mindig kreálok belső lan-t is, és többnyire abban vannak a VM-ek, és előtte a publikus lábon egy virtuális router lóg és portforward ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
hat akkor mar nem emlekszem, mi volt az oka, hogy nem ismerkedtem meg vele kozelebbrol :)
mondjuk ahogy hasznalom, arra megfelel a libvirt es az /etc/nftables.conf
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
A VM-ek backupolását régebben még XCP-ng alatt is sima xe vm-snapshot xe vm-export al toltam, de már évek óta XOA-val mangelem, vissztöltés is 1 kattintás ...
Meg van pár jósága a XOA -nak.
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
erre lvm snapshotot hasznalok, es irtam egy programot, hogy csak azokat a szektorokat masolja at a bak lvm-be, ami valtozott, hogy ne degradalodjon az ssd.
md-nel pl. nem ertem, hogy mikor letrehozza a raid1-et, miert kell az egyik 0-val tele levo ssd-rol a masik 0-val tele levo ssd-re atmasolni a 0-akat...
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Már sehol nem használok LVM-et. Pazarlás. SSD-k NVMe világában nem hoz már annyit. Csak thin provision ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
ennek akkor van elonye, ha tobbszorosen fel akarod hasznalni/el akarod adni a tarhelyet.
ha pl. fel ora alatt mindegyik vm tele akarja irni a ketszeresen provisionalt tarhelyet, ott lehalnak a vm-ek. ha ez nem gond, belefer a rendelkezesreallasba, akkor jo.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Nem, ennek már ott is előnye van ha egyik storageról el akarom költöztetni a VM-eket másikra. Mert nem mind1, hogy 500G-s diskből amit eleve befoglal mégha 100-at használ belőle, lesz még 500G tehát 1T-t használ addig (ami a valóságban 100G) míg össze nem fűzi. Pár T-s NVMe SSD nél pikk pakk elfogyhat a hely pár ilyen VPS-nél.
A többszintű snapshtotot nem is említem ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
asztali gepnel kvm alatt nezegettem, csak meg nem tudom mire lenne jo.
home assistant valamiert nem indult el xen alatt, ezert kvm-ben fut.
a bejelentesben levo kepernyokepen latom hogy fut, nalam bootloopba kerul.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
worksforme :D
Igaz én annó a HA-t még debian alapra raktam fel ... supervised vagy hogy a francba hívja ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
ezt nem latom a tamogatottak kozott, virtualbox, unraid, kvm es vmware van. a kvm-hez valo qcow2-t toltottem le es konvertaltam raw-ba, hogy egy lv-re ra tudjam tenni. valoszinuleg fel kell csatolnom es beleneznem, ha azt akarom, hogy mukodjon.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Most letöltöttem a qcow2 konvertáltam raw-ban majd importáltam. Simán bootol, csak UEFI módot kell használni.
UI.: sőt, már az integrációs szolgáltatás is bele van telepíve ... Szóval simán xcp-ng kompatibilis ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
en is igy csinaltam, azert nem ertem.
na telepitek egy xcp-ng hostot :)
felment, elindult, de nem tudok vm-et csinalni vele.
van egy deploy xoa, de az meg azt mondja, hogy "sorry, deployment failed!" check out the errors: INTERNAL_ERROR
kene kicsit hasznosabb hibauzenet.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Lehet mindenki töltené lefele ...
Amúgy az a XOA, elég korlátos. mondjuk az alap dolgokra elég szokott lenni. Amúgy kell egy alap debian meg arra git nodejs és pikk pakk felrakható.
Amennyiben ha magadnak buildeled a legtöbb feature meglesz.
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
eloszor pikk-pakk tudjak elinditani rajta egy debiant, mert jelen allapotaban erre alkalmatlan. :)
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Nem-nem. Alkalmas, max nem értesz hozzá :D Ez nem proxmox ,virt-manager és társai szóval afféle kattingatós cucc amatőröknek. Ez vérprofi cucc. CLI -vel vagy API-val :D
Ha más nem akkor proxmox alá teszel debian-t rá felrakod a XOA-t és kész is vagy, utána addolod az XCP-ng hostot. Vagy megvárod míg a XOA deploy menni fog.
UI.: vagy ott a cli .. :D
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
ettol feltem :) a citrix xenserveres emlekeket hozza vissza, ahol a grafikus managerbol letiltottak a beallithatosagat annak, hogy automatikusan induljon a vm (mert clusterben ez gond, de cluster a speci nem volt, ezt nem vette eszre valamiert) ezert CLI-bol kellett mindig beallitani hogy induljon, illetve ha egy vm-rol csinaltam egy mentes vm-et, akkor abban meg azt, hogy ne induljon el a mentes IS. es meg a host indulasa es a konzolon a felulet is ugyanaz, csak mas a logo :)
aszem varok mig mukodni fog, addig kikapcsoltam a hostot.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
es meg a host indulasa es a konzolon a felulet is ugyanaz, csak mas a logo
Igen, mondtam is hogy egyelőre hasonló uton haladnak. Afféle openxenserver, csak jobb :D
Viszont mint mondtam, fogsz egy debian-t majd https://xen-orchestra.com/docs/installation.html#from-the-sources
Ezalá már csak be kell húzni az xcp-ng hostokat, mert 1 ilyenről elmanageled mindet is ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
a dmesg nagyon hasonlo kimenet ad pvh es hvm eseten.
mindkettonel: Hypervisor detected: Xen HVM
pvh-nal: Booting kernel on Xen PVH
hvm-nel: Booting paravirtualized kernel on Xen HVM
ezert (es hogy virt managerben vagy xcp-ng-ben kezelheto legyen) at akarom konvertalni a regi, xen-tools altal keszitett pvh virtualis gepeket hvm-re.
van valami tool, amivel az xvda1 - root, xvda2 - swap atkonvertalhato egy olyan raw (vagy qcow2 de ez mar csak konvertalas kerdese) diskbe, ahol van particios tabla, es lvm?
tehat lesz egy xvda, amin lesz egy dos particio, azon lvm, az lvm-en az xvda1-bol root lv, xvda2-bol swap lv, bar ez utobbi el is hagyhato, ha xvdb-re teszem.
lepesenkent es fajl masolassal meg tudnam csinalni, de hatha van ra valami amivel egyszerubb lenne.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Hát ööö :D
Igazából mivel HVM az egész disk xvda, most is minden VPS-em xvda és azon belül van ami van. Szóval ha van raw imaged ami a komplett disk az fogod és beimportálod majd odaadod a VM-nek. Ugyanugy grubbal bootol, mintha fizikai gép lenne ...
Amúgy sose használtam semmilyen spéci toolt költözésekre dd-n kívül meg qemu-img convert en kívül, pedig jó párát konvertáltam már XCP-ng alá, akár fizikai gép, akár vmware, akár kvm-es volt.
A lényeg, hogy a xen driverek legyenek a kernelben vagy initrdben, esetleg egy sysrescuecd is jól jöhet majd.
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
a xen-tools-t akkor hasznaltam, amikor sem xapi sem libvirt vagy ilyesmi nem letezett meg :)
az nem csinal xvda-t, csak xvda1 es xvda2 van
ezt az update-grub jelzi is:
# update-grub
Generating grub configuration file ...
/usr/sbin/grub-probe: figyelmeztetés: a lemez nem létezik, így visszatérés a(z) /dev/xvda1 partícióeszközre.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
PV idokben mikor config fájlban adtad meg akkor így ment 15 éve.
Utána már volt pygrub amivel a konfigban csak xvda ként hivatkoztál a diskre, és az image ugyanúgy partíciókat tartalmazott. Viszont az OS-ben nem kellett grub.
Szóval ha van valamilyen imaged ami tartalmazza a komplett disket, akkor azt csak xe-vdi imporrtal behúzod oda ahova kell. Aztán mehet a boot, ha nem bootol akkor sysrescue stb ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
"ha van valamilyen imaged ami tartalmazza a komplett disket"
nincs. csak particiom van.
abbol kene disket csinalni.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Többi mödja is van a migrálásnak. Mindkettő lényege, hogy fogsz imaget megcsinálod a partíciót, oda rsyncel átmásolsz mindent. grub fstab beállít
Talán legegyszerűbb módja ennek, ha xcp-ng ben létrehozol egy olyan VM-et aminek az oprendszere megegyezik azzal amit migrálni akarsz, akár fel is telepítheted, a minimalt. Majd leállít sysrescue cd bootol, fs-t törlöd, rsyncel áthúzod amit akarsz, fstab grub stb helyrerak és meg is vagy.
Azért érdemes olyan OS-el formázni a disket mint amit költöztetsz mert jártam úgy, hogy CentOS 6 ost migráltam a fentihez hasonló módon, de kihagytam a telepítést és csak sysrescue val formáztam a disket. Aztán bootkor a centos 6 kernele nem tudott mit kezdene vele mondván újabb formátum ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
"lepesenkent es fajl masolassal meg tudnam csinalni, de hatha van ra valami amivel egyszerubb lenne."
ezt akartam megsporolni, mivel nem 1 vm-rol van szo :) de majd csinalok neki sctiptet
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
na atmigraltam mindet.
ami nem mukodott:
losetup -o 1048576 /dev/loop0 /dev/vg0/vm.img
utan a /dev/loop0 formazasaval a guest indithatatlanna valt. azt irta valami nem jo meretu.
mindent ugyanugy csinaltam mint a sima rsync -a --del masolasnal, csak elott formaztam.
emiatt a formazast kihagytam, igy jo lett.
itt felmerul bennem a kerdes, hogy a losetup/ext4 mennyire robosztus ilyen esetben.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
VM-et csak az XCP-ng Centerrel lehet létrehozni, ami meg csak windowsra van. Meglehetősen furcsa ez így.
- A hozzászóláshoz be kell jelentkezni
A 8.3 -as verzióval az xcp-ng Center ha jól tudom már nem is működik. A fejlesztése is abbamaradt, próbálták feléleszteni nem tudom milyen sikerrel. A hivatalos management felület a Xen Orchestra
Van egy alap webes felület, ahol lehet importálni egy XOA vm-et, azzal el lehet kezdeni a munkát.
Kreálható VM cli -vel mivel minden fenti program a xenapi-t használja, viszont az tény, hogy nem proxmoxon nevelkedett kattingatósoknak való :D
Meglehetősen furcsa ez így.
Megítélés kérdése. Ahova az ember hypervisort rak ott már van valami infra, ott azért szokott már futni valami, ahova a XOA felrakható. Onnantól meg több nem is kell, mert azzal az összes hyervisorod egyben tudod majd kezelni ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
Én még korábbit használtam. Abban a CLI csak alap dolgokra volt alkalmas. A Lite webfelülete (ha jól emlékszem a nevére) nem tudott új VM-met létrehozni. Az Xcp-ng Center kellett hozzá akkor. Ha a mostaniban ez már webfelületről megoldható az pozitív előrelépés.
Másik problémám az volt, hogy az alap rendszer elég sok ramot foglalt például egy Proxmox-hoz képest. Ez mostanában mennyi? Xen Orchestraval együtt persze.
- A hozzászóláshoz be kell jelentkezni
Abban a CLI csak alap dolgokra volt alkalmas. A
Nem hinném, mivel a cli eleve a xenapit használja, amit minden más is, legyen az windows os felület, vagy a xen-orchestra.
Itt egy példa 2018 ból: https://linuxconfig.org/how-to-create-a-new-virtual-machine-on-xenserve…
Azért egy gui kellemesebb ...
Másik problémám az volt, hogy az alap rendszer elég sok ramot foglalt például egy Proxmox-hoz képest.
Amennyire beállítod ...
Általában kisebb ramos felépítésnel 32GB alatt 2-4GB között lövi be magát a hypervisor. több ramnál már 8G-t kap a dom0
Doksi szerint min 2GB RAM kell, az ajánlott pedig 4GB vagy afelett. Én Xen Orchestrat futtató gépet 2GB vel hajtom, meg raktam alá swapet, mert ha buildelem, akkor sipákol hogy 4GB jobb lenne
Viszont 1 XenOrchestrával elkezeled az összes hypervisort.
Jelenleg fejlesztés alatt az xo-lite is, ami a jövendőbeli 6-os XO egy butitott változata, ami a hypervisoron fog futni. Célja pár alapművelet segítése.
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
tegnap ejjel elinditottam megint, most sikerult a xoa vm-et megcsinalnia.
ahhoz hogy a haos vm-et el tudjam inditani kell a fullos xoa, vagy meg kene csinalnia ennek is?
a raw disket sikerult importalnom, de vm kesziteskor nem latom hogy lehetne letezo lemezkepet hasznalni.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
ahhoz hogy a haos vm-et el tudjam inditani kell a fullos xoa, vagy meg kene csinalnia ennek is?
Az alapok mennek majd azzal is.
a raw disket sikerult importalnom, de vm kesziteskor nem latom hogy lehetne letezo lemezkepet hasznalni.
Ha jól rémlik sehogy, megcsinálod disk nélkül, és utána addolod a meglévőt
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
itt a snapshot nem lassitja ugy, mint lvm-nel?
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Szerintem hasonló lehet, mivel attól hogy LVM, arra is ugyanúgy VHD kerül mint az ext4 nél.
Mondjuk nnyira nem érdekel, mert nekem a snapshot 98% ban backup idejére kell, nekem fontosabb volt, hogy nem allokálja egyből a teljes méretet, mert azzal már bőven voltak gondjaim ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
jol latom, csak qcow2-n lehet snapshotot csinalni, raw-on nem?
abbol hogy csinalsz backupot?
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Nem jól látod, nincsen qcow2 csak VHD van és az támogat snapshotot, raw image nem támogatja.
Ha raw akkor kb offline export van.
Sajna egyik nagy hátránya az XCP-ng nek, a régi SMAPIv1 ami még a régi VHD-t használja, ami nem lenne gond ha nem lenne ~2T a max méret limit. Évek óta igérik az SMAPIv3 (citrix kezdte fejleszteni) -at ami ezt megoldja, de eddig nagyon alpha és nagyon korlátozott dolgokat adtak ki (pl. ZFS már v3 at használja).
Érdemes átfutni: https://xcp-ng.org/docs/storage.html
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
atfutottam, vagyis az apin mulik, hogy vhd (xapi) vagy qcow2 (libvirt) van xen alatt, ami tamogatja a snapshotot.
visszajott, hogy citrix alatt volt 7 napi backupom beallitva, amit mutatott a centerben, tovabba be volt allitva, hogy a 7 napnal regebbieket meg torolje.
bar sosem volt ra szukseg, de neha jol johet.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Nah jó de itt xcp-ng ről van szó tudtommal, ott pedig csak xenapi van SMAPIv1 es ami meg vhd.
Én xen-orchestraval backupolok. Bár én csak fullos backupot tolok hetente 1x, de persze akár óránként is lehet, meg tud inkrementálist stbstb ...
Ettől még a snapshot értelemszerűen csak backup idejére van meg ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
"Nah jó de itt xcp-ng ről van szó tudtommal"
igen, ezert volt a felreertes a qcow2-vel, mert mar elfelejtettem, hogy a citrix (es xcp-ng) mast tamogat, mint a libvirt.
amugy ha gyorsabban fejlesztenenek, akkor mar qcow2 is lehetne xcp-ng alatt, azt is irtak a linken amit ide tettel.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Igen, de nem árt szem előtt tartani hogy az SMAPIv3 ról már 2019 óta blogolgatnak :D
pl.: https://xcp-ng.org/forum/topic/1969/deprecated-smapiv3-feedback-bug-rep…
Itthon nekem van SMAPIv3 ZFS-el ...
Fedora 40, Thinkpad x280
- A hozzászóláshoz be kell jelentkezni
--assume-clean
- A hozzászóláshoz be kell jelentkezni
ez nem teljesen ugyanaz, mint amire en gondoltam.
nekem olyan kellene, hogy ugy szinkronizal, hogy beolvassa mindket diskrol a szektort, megnezi hogy kulonbozik-e, es ha egyforma, akkor nem irja ki.
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
Tudtommal HVM, és PVHVM van. PVH nem is volt.
Nem is értem miért nem ezt mondta Bud Spencer. Jobban hangzik mint fagyival :-)
- A hozzászóláshoz be kell jelentkezni
Ha ezen valóban működik az MxGPU, azaz AMD vGPU az már önmagában megér egy próbát.
“Az ellenség keze betette a lábát”
- A hozzászóláshoz be kell jelentkezni