Virtualizáció

Nagyon keveset értek a témához, de kíváncsi vagyok.

Annak idején webes frontend fejlesztőként praktikusnak találtam, hogy Dockerben futtattuk az applikációkat, mert így félreértések nélkül lehetett dolgozni új feature-ökön és tesztelhettünk különböző verziókat. Kis gyakorlás után nem volt nagy ügy egy Dockerfile összeállítása, és tisztább, szárazabb, jobb érzést nyújtott ez a munkamódszer.

Mostanában játékprogram-fejlesztéssel kísérletezem, és egyik visszatérő probléma, hogy ha ismerősöket kérek meg a fejlesztések kipróbálására, a Windowsuk pánikol az internetről letöltött játékprogram miatt (a Macen meg alapból notarizálni kell mindent, ami szerencsére elfogadható sebességű folyamat). Persze, vannak módszerek, amivel "megbízhatóbbá" lehet tenni egy programot (be lehet jelenteni az adott verziót a Microsoftnak, és akkor a következő Defender frissítéssel amiatt a verzió miatt már nem fog reklamálni, de a Steamről letöltött programokkal szemben a bizalom már meg van előlegezve, amit személy szerint nem értek, hiszen a gyakorlatban akárki, akármit publikálhat, mert nem ellenőrzi senki, legfeljebb utólag), de nem értem, miért nem futnak a játékok izoláltan, valami Docker-szerű környezetben.

És ugyanígy, miért nem az az alap, hogy az operációs rendszer csak egy réteg, ami közvetít a hardver és a konténerek között? Miért nem fut minden program a saját konténerében?

Nyilván van valami oka amellett, hogy ez így "lassabb" lenne, de a mai gépek már úgy is eszement módon fürgék, míg a kód egyre moslékabbá, terjedelmesebbé, törékenyebbé és lassabbá válik, így ideje lenne egy újratervezésnek.

Mit a rejtély magyarázata?

SZERKESZTÉS: Nem is annyira azt szeretném, hogy olyan OS-eket ajánljatok, ahol a konténer-szemlélettel kísérleteznek. Inkább azt szeretném megérteni, hogy miért nem ez a fő irány (általános használatra), illetve hogy lehet-e egyáltalán ez a fő irány valaha.

virtualis win10 "meghajtok optimalizalasa" programban a mediatipus merevlemez-meghajto.

ezt szeretnem modositani szilardtest-meghajtora, mert a merevlemez tipusunal toredezettseg optimalizas van, ami az alatta levo ssd miatt nem a legjobb.

a C: meghajtot sikerult is modositanom a "winsat disk" "egyertelmuen erre szolgalo" paranccsal, de a D:-t nem a "winsat disk -drive d" paranccsal.

mind a C: mind a D: alatt ssd van.

valakinek sikerult ezt modositani?

Sziasztok!

2021-ben vasaroltam egy szoftvert amit VirtualBox-ban egymastol tavol eso helyeken, kulonbozo hostokon, szoval lenyegeben barhol barmilyen gepen tudtam hasznalni. Tegnap azonban miutan upgradeltem a 2023-as kiadasra, (regi uninstall, uj fel, + friss uj licence aktival) valami megvaltozhatott, mert mas host ala rakva a klonozott VM-et mar nem tudtam hasznalni a szoban forgo programot, ujra keri a kulcsot.

Legjobb tudomasom szerint a host a guest iranyaba nem mutat semmit a vasbol... de ha megis, akkor szerintetek merre erdemes kutakodni?

Host /Arch, Guest /Windows 10 (latest)

szerk.: kozben kiderult, hogy valoszinuleg a Host CPU ID alapjan dobja el a guest VM-et.

A szolgaltatok doksijaibol nem mindenhol latszik, olyan VPS szolgaltatot keresek, ahol van mukodo nested virtualizacio a VPS-en. Pluszpont, ha valakinek gyakorlati tapasztalatai is vannak, sajnos megbizhatosag es teljesitmeny szempontjabol eleg nagy a szoras.

A feladat egyebkent annyi, hogy Rocky + Cockpit + egy elore elkeszitett image a gepen + 0..n szamu parhuzamosan futo VM. Affele gyakorlos/lab rendszer, nem kell neki hatkilences SLA.

Sziasztok!

Most vettem észre, hogy a wine leállt a 3.1-es és a 98-as vonal támogatásával. Igaz ez, vagy csak rosszul látom?

Sziasztok!

Jogi elvárások miatt néhány ESXi alatt futó virtuális gépet át kellene tennem USA területre. Tud valaki olyan szolgáltatót, ahol lehet fizikai vasat bérelni amin elfut egy ESXi és lehet hozzá /29-es subnetet bérelni?

Amiket eddig találtam mind 3-4-szeres áron van a Hetznerhez képest, tehát vagy nem találtam még meg az igazit, vagy odakint tényleg ilyen áron mennek?

Köszönöm!

par debiannal regebbig meg latszottak, de egy upgrade utan eltuntek belole.

a libvirt-daemon-driver-xen fel van teve, xen list mutatja mind a pvh mind a hvm guesteket, de a virt-manager csak a hvm guesteket mutatja.

a pvh guestek a xen-tools-al lettek letrehozva, a configjuk az /etc/xen alatt van.

a hvm guestek a virt-managerrel lettek letrehozva, a configjuk az /etc/libvirt/libxl alatt van.

valakinek sikerult megoldania, hogy mindegyik latsszon benne? mit kell hozza csinalni?

Sziasztok!

VMWare-rel kapcsolatban szeretném a segítségeteket kérni.

Adott egy cluster 3 hoszttal, valamint egy Dell PowerVault MD3200i storage.

A clusterben egy régi Dell T710-es szervert kicseréltem R550-re.

Az új hoston szeretném felvenni (iscsi) datastore-ként a PowerVault MD3200i 2 kötetét.

A vCenterben létrehoztam a vSwitch1-et, az ISCSI1, ISCSI2 port groupokat, VMkernel NIC-eket, storage adapterként az „iSCSI Software Adaptert”.

Az adapteren belül megvolt a Network Port Binding, és a Dynamic Discoveryben felvettem az iSCSI szerver IP címeit.

Azonban a Devicenál és a Path-nál nem jelenik meg a 2 kötet, pedig a Static Discovery alatt a Dynamic Discovery-ben felvett iSCSI szerverek alapján szépen kilistázza a powervault-okat Target Name-mel együtt.

Refresh, Rescan-ek voltak többször.

A cluster másik 2 host-ja is használja a storage-ot, a beállítások (látszólag) egyeznek.

Teljesen megakadtam, akinek van ötlete, kérem segítsen!

Docker Swarm klaszter szolgátlatásai között a névfeloldás néha nem működik, a Docker belső DNS-e nem oldja fel a service neveket IP címekké. Azonban ez nem mindig fordul elő, sok esetben tökéletesen működik a névfeloldás.

Láttam ezt a topikot már: https://hup.hu/node/181972 De nem releváns, nem Windows konténereket használunk.

Sajnos nem tudtam a különféle fórumokon választ találni a problémámra sehol. A moby GtiHub repositoryjában bejelentett hibákat már végignéztem, rengeteg több éves nyitott Swarm+DNS probléma van, régi verziókkal kapcsolatban, és nagyon sok nem is releváns már, nem vitt előrébb.

Ti tapasztaltatok már ilyet? Ha igen, és sikerült megoldani, mi volt a gyökérok és mi volt a megoldás?

A Docker Engine verziója 24.0.2, a kernel verzió 3.10 (CentOS 7, még egy évig támogatott).