Megjelent a "kulcsrakész" virtualizációs platform, az XCP-ng 8.3-as verziója

Címkék

Próbálják meglovagolni az VMware körül felcsapott hullámokat. Részletek, újdonságok a bejelentésben.

Hozzászólások

Ez tud LUN-t raw-ként kezelni, mint a VMware (és ahogy a Proxmox nem)?

trey @ gépház

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 :-)

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.

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

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?

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.

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

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”

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) 

Í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

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).

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

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. 

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.

"

https://pve.proxmox.com/wiki/Storage:_LVM

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”

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.

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

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.

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.

 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

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 ;)

É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

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.

fixme, de a proxmox doksi azt irja hogy iscsi az shared storage. es lvm doksi is ir egy ilyet (kvazi lvm over iscsi):

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.

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!

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!

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 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).

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.

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...

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...

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

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...

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

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...

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

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...

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 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...

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 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...

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

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

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 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

É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. 

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

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...

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

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

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

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...

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

"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.

https://xcp-ng.org/docs/storage.html#smapiv3-the-future

neked aztan fura humorod van...

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”