Virtualizáció

ESXI 6.7 alatt van egy Samsung 850 Pro. Sima datastore, ezen vannak a VM-ek. Látszólag jól felismeri az ESXI, hogy SSD-ről van szó, de nemrég egy HD Sentineles ellenőrzésnél azt mondta, hogy a TRIM támogatott de nem aktív, így 80% a teljesítmény.
Keresgéltem, de csak régi találatokat dobott a google. Nem tudom mihez nyúljak, hogy bekapcsoljam, vagy legalább ellenőrizzem a TRIM(vagy annak ESXI megfelelőjének) állapotát ESXI alatt.

Hol lehetne elindulni?

Szeretnék egy gépet azure vm-re költöztetni. A gép 1-2 TB tárhellyel, ami jelentősen, de napi szinten változik. Néha azonban vannak nagyobb műveletek is, akkor minden változik.
Szeretnék a rendszerről backup és rollback célokkal snapshotokat csinálni, de azure tapasztalatlanságom miatt nem tudom mi a célravezető megoldás. Rollback esetén fontos a gyors visszaállás, a backupnál meg a költséghatékonyság (naponta letölteni a 2 TB-t tisztán nyilván drága mulatság az azure adatforgalomra való tekintettel). Örülnék, ha lehetne távolra backupolni inkrementálisan egy adott időpontbeli állapotot. Alapvetően elegendő néhány mappa snapshotolása, nem feltétlen cél a teljes gép pillanatképe, ha ez egyszerűsít/gyorsít/pénzt kímél.
Ti hogy oldanátok meg ezt? Azure natív gép szintű snapshottal, esetleg zfs snapshot/clone/send távolra másolás?
Szeretném kérni a tanácsotokat, meg mindenfajta ötletet és irányítgatást (pl van értelme egyáltalán az azure backup mellett távoli gépre backupolni? vagy jó ötlet azure diskre zfs-t rakni egy diskkel?).

Sziasztok!

A következő munkafolyamatot szeretném megvalósítani, ebben kérném a segítségeteket. Amennyiben az elgondolás hibás, akkor abban is számítok a tanácsaitokra.

Gitlabban tárolt repository-ból naponta egyszer le kellene buildelni egy Docker image-t. Amennyiben az új image tartalmaz biztonsági javítást (egyelőre Ubuntu alapú image-kről van szó), akkor automatikusan új verziószámmal kellene ellátni és felpusholni a Docker Hubra.

Ezután a szervereken automatikusan érvényesíteni kellene az új image-t.
Az egyik járható út lehet, hogy a Gitlabból ssh-val belépve egy szkript letölti az új Docker képfájlt.
A másik (általam jobban preferált), hogy a szerverek minden nap cronból lekérdeznék, hogy van-e új image és ha igen, akkor egy szkript leállítja a futó konténereket, letölti az új képfájlt, elindítja a konténereket, majd státuszt vizsgál: ha minden rendben működik, akkor az előző verziójú image-t eldobja.
Amennyiben nem megfelelő a működés, akkor visszatér a régi verziójú képfájlhoz, elindítja újra a szolgáltatásokat majd erről küld levelet.

Köszönöm a segítséget!

Sziasztok!

Céges laptopon jónéhány VM-et futtatok VirtualBoxban.
A gond az, hogy munkahelyemen csak proxyn keresztül látunk ki a netre, míg itthon nincs proxy. Ezért gyakran kell ki-bekapcsolnom a proxyt a VM-eken belül, ami ráadásul legtöbb esetben rebootot igényel.

Létezik erre vmi praktikus megoldás?
Köszi!

Udv !

Kaptem egy virtualbox imaget azzal, hogy nem indul a windows.
Ha letiltom az automata ujraindulast, akkor 'inaccessible boot device' uzenettel all meg. Javitani nem tudja magat, ha a virtualis optikai meghajtoba live rendszert teszek es bebootolom, akkor latom az adatokat, le is mentettem mindent gyorsan.
A kerdesem az, hogy mikent lehetne ezt indithato allapotba hozni ? vagyis van valami _bevalt_ eszkoz a megserult virtualbox image helyrepofozasara ?

thx.

Sziasztok!

Adott egy dualboot windows 8.1 és linux mint rendszerekkel, uefi telepítésben.
Linux alá feltelepítettem egy vmware workstationt és beállítottam a fizikai windowst virtuális gépnek. A célom az, hogy ne keljen átlépkednem windows alá újraindítások közepette, hanem a vmware-ben elindítva is tudjak ténykedni benne. Egyéb esetekben pedig ha szükséges, akkor tudjam indítani fizikailag is a windowst, egyszerűen kiválasztva a grubból.
Vmwareben ezt szépen meg lehet neki adni. A problémám ott van, hogy a vm beállításoknál meg kell adnom, hogy uefi módban telepített windowsról van szó. Csak így hajlandó elindulni. Szépen betölt, ténykedek rajta, leállítom. A laptopot újraindítva a grub továbbra is fogad, teszt kedvéért kiválasztom a windowst. Betöltődik, minden rendben. Újraindítást követően azonban már csak a windows töltődik be, grub nincs. Linux live lemezzel visszaállítom a grub installal a grubot, ez nem probléma.
Azonban ezt minden egyes alkalommal eljátssza, amikor a windowst elindítom vm-ben.
Olybá tűnik nekem, a windows vm-ben történő tartózkodása miatt a következő fizikai belépést és újraindítást követően mintha átírná az efi beállításokat, mivel a virtuális környezetben csak magát látja, az alatta működő fizikai linuxot nem.
Nem tudom ez hogyan lehetséges, nem is igazán értem.
Milyen megoldást lehetne találni arra, hogy a windows ne "bántsa" az efi beállításokat és gond nélkül üzemeljen vmben és fizikailag is?
Régebben próbáltam már ezt a variációt, akkor nem uefi telepítés volt, rendben működött.
Olyat próbáltam, hogy beállítom vmben, a virtuális környezetben ne mentse a módosításokat, de nyilván így nem sok értelme lenne a történetnek. Egyébként ennél a beállításnál meg is marad a grub, tehát tényleg nem módosít semmit.
Az esetleges válaszokat, ötleteket szívesen fogadom, és előre is köszönöm!

Üdvözlettel,
János

A virtuális gépeken belül nem tudom 127.0.0.1-gyel vagy localhost-tal elérni a postgresql szervert, csak 172.20.0.3 -mal. Hogy lehetne ezen segíteni? (Tehát hogy 127.0.0.1-el is látsszon.)

Ilyen a docker-compose.yml fájlom: https://pastebin.com/j9baN9Us

Szerk: végül is nem okoz gondot.

Kérdés: Otthoni kiszolgáló esetén, a lentebb felsorolt szolgáltatások virtualizációjára mit javasoltok? Mivel a témában nincs túl sok tapasztalatom, így ötleteket várok. A cél az lenne, hogy viszonylag egyszerű legyen karbantartani a rendszert. Illetve a virtuális gépek másolásával könnyen lehessen másik gépre migrálni, és ne kelljen küzdeni a szolgáltatások konfigurálásával. A proxmox-ra ránéztem, de nem világos előttem, hogy subscription nélkül mennyire használható. A Qubes OS-re is rákukkantottam, de ott meg az nem világos, hogy headless módban mennyire használható. Esetleg mik vannak még, amik szóba jöhetnek?

Az otthoni kiszolgálómon jelenleg Ubuntu van rajta, és azon futnak a szolgáltatások:
- MPD szerver
- Fájl szerver
- HomeAssistant
- MQTT szerver
- MongoDB adatbázis
- GitLab szerver

Fájl szerver: Jelenleg lvm alapon, ext4, néhány könyvtár nfs-sel megosztva (Windows-os gép nincs). Az nfs megosztást gyakorlatilag a MiBox-ról szoktam használni, a Kodival. A fontos fájlok szinkronizálva vannak felhős tárhelyre, illetve időnként backup is készül külső merevlemezre. A legfontosabb fájlok az asztali gépre és egy másik felhős tárhelyre is szinkronizálva vannak. Raid most biztosan nem lesz. Egyszerre maximum 2 gépről kell elérni, a hálózati másolás sebessége nem lényeges.

Az adatbázis az elsősorban tanulási célt szolgál, és nem várható, hogy nagyméretű adatbázisokat kezelnék vele.

Az MQTT-t a HomeAssistant-tal tervezem egy virtuális gépre, mert leginkább azzal lesz használva.

A GitLab is csak saját, otthoni projektjeimhez lesz használva.

Hardware (amit nem tervezek változtatni):
- ASRock QC5000M-ITX/PH alaplap
- 8 vagy 16 GByte RAM
- egy 64 GB-os SSD, és egy nagy HDD.

Sziasztok!

Adott az alabbi konfig.

i3 5005U (4 core)

8 Gb RAM

Egy proxmox fut rajta, 2 VM-el az alabbi elosztasban:

1. VM (VyOS) 1 core, 1 Gb RAM

2. VM (Ubuntu Server) 2 core 4 Gb RAM

Ez modositottam most az alabbira:

1. VM (VyOS) 1 core, 1 Gb RAM

2. VM (Ubuntu Server) 4 core 8 Gb RAM

A memoria mindkett VM-en balloning

A kerdesem.

Nem gond, ha a Proxmox-nak nem hagyok ugymond "semmit"? iletve nem gond ha a logikai eroforras kiosztas tobb mint a fizikai? Az volt az elgondolasom, hogy eddig sok eroforras kihasznalatlan volt, viszont az Ubuntu szervernek neha szuksege lenne a pluszra... Fixen "kihajtva" viszont nincs egyik VM-sem, tehat az eroforrasnak elegnek kene lennie, kerdes csak az elosztas :)

Sziasztok!

Egy egzotikus probléma megoldásához OVF Tool-t kell futtatnom 6.5 és/vagy 6.7-es ESXi host-on, kickstart-ból.

ESXi 6.7-tel (már) nincs probléma, működik az OVF Tool 4.3.0, azonban 6.5U2 alatt kapok egy hibaüzenetet (mint látható, a 4.2.0 és a 4.1.0 fut):

[root@esxi01:/vmfs/volumes/5b112475-555add4f-64d9-005056914e87] vmware -v
VMware ESXi 6.5.0 build-8294253
[root@esxi01:/vmfs/volumes/5b112475-555add4f-64d9-005056914e87] sh ./ovftool.410/ovftool -v
VMware ovftool 4.1.0 (build-2459827)
[root@esxi01:/vmfs/volumes/5b112475-555add4f-64d9-005056914e87] sh ./ovftool.420/ovftool -v
VMware ovftool 4.2.0 (build-5965791)
[root@esxi01:/vmfs/volumes/5b112475-555add4f-64d9-005056914e87] sh ./ovftool.430/ovftool -v
./ovftool.430/ovftool.bin: error while loading shared libraries: libicudata.so.58: failed to map text segment from shared object: Error 28

Van valakinek ötlete, hogyan lehetne megoldani, vagy legalábbis debug-olni a 4.3.0 futtatását ESXi 6.5 alatt?

Megjegyzések:
- tisztában vagyok vele, hogy az OVF Tool futtatása nem támogatott ESXi-n
- OVF Tool 4.2.0 működik 6.5 és 6.7-en is, azonban...
-- ESXi 6.7 hivatalosan nem támogatott ezzel a verzióval
-- a 4.3.0 tartalmaz olyan új feature-t, amit használnom kell (link)
- egyelőre nem használhatok ESXi 6.7-et

Bármilyen, a probléma megoldására nézve konstruktív javaslatot örömmel fogadok.