Szeretnék egy kicsit ismerkedni a virtualizálással. A tanulást egy virtualboxban telepített ubuntu rendszeren képzeltem el. Amit eddig tettem. Telepítettem az ubuntut, beállítottam a network bridge kapcsolatot. A gazda gépről ssh-n elérem a virtuális gépet, természetesen tudom pingelni is és ha telepítettem volna rá kiszolgálót, azt is elérném. Itt jön a csavar.
Szeretnék a virtuális gépen virtualizálni. Konkrétabban: telepítettem rá egy webmin, virtalmin, cloudmin szentháromságot, hogy grafikus felületen tudjam menedzselni a virtuális gépeimet. A kiszolgáló fut és ip alapján el is érem. De a Fully qualified domain name (ami az example.com) alapján persze már nem érem el sem a virtuális gépen, sem a gazda gépen. Gondolom valamilyen ddns szolgáltatásra lenne szükségem hozzá. Érdekesebb, hogy a gazda gépről sem érem el ip alapján. A böngészőben az
Error — Document follows
This web server is running in SSL mode. Try the URL https://example.com:10000/ instead.
üzenet fogad. Ennek mi lehet az oka?
További terveim. A virtuális gépen lévő ubuntu-n docker és lxd konténerek futtatása. Szeretném ezeket is elérhetővé tenni ezeket is a gazda gép számára. Hogyan kell beállítanom ehhez a virtalmin/cloudmin-ben a bridge kapcsolatot? Milyen egyéb tanácsokat adnátok még a tanuláshoz?
Hozzászólások
Közben az ssl-ből gondoltam, hogy https-t akar a böngésző. Így is lett, ez a probléma tehát megoldva.
― Philip K. Dick
szub
nem tudom, hogy pontosan mi a cél - mármint mit szeretnél megtanulni, de a kérdéseid olyan mellékhatásokról szólnak, amik kizárólag a 'nested virtualization' miatt léteznek... ez nyilván nem igazán való éles üzemre, de még a tesztelést/tanulást is megnehezítik rendesen ;)
De ha tényleg ezekre keresed a választ, akkor ez azon múlik, hogy a virtuális hálózatodat hogyan oldottad meg az első, és a másidik szinten.
Ha az első szint bridge - ahogy írtad - akkor csak a másidik szintre kell valamilyen port-forward megoldás, hogy a nested VM portjait is elérd a bridglet VM-en kersztül.
Ha mindezt DNS névvel szeretnéd, akkor még a használni kívánt DNS neveket a bridgel-t IP-re kell irányítani.
zrubi.hu
Szerintem kis méretű hálózat esetén nem kell DNS, elég a gépek hosts file-jába felvenni a bejegyzéseket.
(linuxon a jól ismert /etc/hosts, windowson C:\Windows\System32\drivers\etc\hosts). Nekem itthon így működik. :)
szvsz, ha tanulni szeretne, akkor a jót tanulja, ne a "lasy" módot.
és attól hogy local host fájlokba írod, attól az még DNS feloldás marad, csak sokkal több a gond vele, mintha rendesen DNS szerverekkel szolgálnád ki.
Tapasztalataim szerint aki azért nem használ alapvető DNS, NTP, DHCP szolgáltatásokat, mert "pár géphez minek", az később nagyon megbánja... és nem utolsó sorban gányolásra szoktatja magát és a környezetét. Bármilyen hálózati szolgáltatás ezek nélkül csak tákolmány.
Aztán amikor majd esetleg az SSL tanúsítványok is a képbe kerülnek, akkor meg lehet előről kezdeni az egészet, mert hát eddig jó volt az IP-vel is...
szerintem.
zrubi.hu
Köszönöm. Pont ilyen tanácsokat szerettem volna.
― Philip K. Dick
Van egy Mikrotik routerem, amihez kaptam elvileg ddns-t is. Elkezdek olvasgatni a témában. A távolabbi tervem egy kis mindenes home-server lenne, ehhez szeretnék most ismereteket gyűjteni. És ugye amíg nincs fizikai vas, addig marad a virtuális gép.
― Philip K. Dick
ddns csak akkor kell neked, ha dinamikus publikus IP-t akarsz DNS névvel elérni, az internetről.
A leírásod alapján erre semmi szükség.
elég ha a belső hálózatod, vagy akár csak a host-ról a megfelelő IP-re oldódik fel a kívánt dns név.
(ez utóbbi esetben tényleg elegendő a host file is)
zrubi.hu
Szuper. Köszönöm. Még csak annyit szeretnék kérdezni, hogy a kvm vs. Xen vonalból én kis utánnaolvasással a Xen mellett tettem le a voksom. Jó döntés volt? Mit ajánlanál még ismerkedéshez, tanuláshoz?
― Philip K. Dick
Erre nincs jó válasz, főleg mert nem mindegy, hogy type1 vagy type2 hípervisort választasz.
* a type1 az a "valódi" hypervisor, aminek a fő feladata hogy virtualizáljon, és a 'host OS' lényegében csak erre való.
ilyen pl a Xen, VMware ESXi, Hyper-V*
Ezeket komolyabb környezetekhez használják, ahol a fizikai hardver csak a VM-ek kiszolgálására való.
(tehát kell hozzá egy külön hardver, akkor is ha csak 'játszol' rajta)
* a type2 az egy általános operációs rendszer kiegészítése virtualizációs képességekkel, ahol a VM-ek csak egy szimpla processzként (alkalmazásként) futnak a host-on lévő normál (akár desktop) appok mellett.
ilyenek pl a KVM*, Virtualbox, VMware workstation, stb.
Ez utóbbival nyilván könnyebb kezdeni, mert megfér a normál OS (Linux, Windows, Mac) mellett/alatt. cserébe a VM-ek erőforrás (és biztonság) szempontjából hátrányosabb helyzetűek, a type1-es hpervisoron futtatottakkal szemben. - de tesztelésre és tanulásra ez nem szempont.
* a KVM-ről és a Hyper-V-ről a hozzáértők sem értenek egyet, hogy ez most akkor type1 vagy type2 :) de hitvitát nem akarok ebből.
Én magam leginkább VMware ESXi használok demo/labor környezetek kialakítására, és Xen-t desktopon a Qubes OS által - de ez utóbbi azért kezdőként elég sok kihívás elé állíthat ;)
zrubi.hu
Köszönöm a segítséged! Minden világos.
― Philip K. Dick
Mikrotik routereken van egy dolog DNS részen ami sokszor hasznos lehet:
https://wiki.mikrotik.com/wiki/Manual:IP/DNS#Static_DNS_Entries
Ez nagyon szuper! Köszönöm neked is!
― Philip K. Dick
Nekem a Mikrotik router is ProxMox on fut KVM be :D
Így a szerver a mindenes
Van mellette egy managelhető switch amire mennek a CAP ok... :)
virtuális gépen belül virtualizálni? Ez milyen mélységig mehet egyébként?
egész a mátrixig ;)
nincs hard limit, de a gyakorlatban már a 2 szint is csak arra jó, hogy demo/bemutató/tanulás céljából futtasd azt a valamit...
én pl ESX clustert és teljes DR site-ot is csináltam már többször egyetlen fizikai vason, amin egy szingli esx volt a host :)
majdnem ilyen, amikor ESX-en futó VM-ekből építenek openshift clustert, amin belül futnak a produktív alkalmazás konténerek :)
És nem nem teszt, meg demo, hanem éles üzem ;)
zrubi.hu
Érdekes! :)
“Az ellenség keze betette a lábát”
Ó, pedig ez mennyire általános (tényleg, nem irónia)..
a 2. szint konkretan proci szinten tamogatott AMD-nel 100%ig, de szerintem az uj Xeonon is, szoval kvazi semmi hatranya nincs egy VMben VMezni mai, modern hardveren. ez regen volt igaz, h szivas. melyebbre nem mennek.
Proxmox clustert és CEPH-et próbáltam egy vason. Gépre proxmox, abba 3 virtuális gép. A virtuális géprkre szintén proxmox, amiben voltak a CEPH-es VM-ek.
Procinak AMD-t kellett megadni. Működött.
https://blog.claryel.hu
extrém - elméleti - példa:
http://theinvisiblethings.blogspot.com/2006/06/introducing-blue-pill.ht…
(legalábbis én még ilyet nem láttam igaziból működni)
de a publikálás dátumára - 2006!! - azért felhívnám a figyelmet! - azóta ugyanis ez már sokkal könnyebben hihető ;)
zrubi.hu