Názory k článku Jak přidělit virtuálnímu počítači vlastní IP adresu
-
Proč by nemohlo? Potíž je, pokud má něco pouze klikací rozhraní, proto je důležité, že VirtualBox má i to konsolové rozhraní. Hodně lidí nemá na serveru Xka ;-) resp. grafická instalace se dá ještě přežít – tunelovat přes SSH – ale pro běh je to prakticky nepoužitelné, tam je negrafický/démonizovaný režim nutnost.
-
Ray (neregistrovaný)
Až ti někdy něco padne a budeš připojenej pár kilobitama, tak u terminál je někdy nesnesitelně pomalej… Další potíž s klikátkama je, že nejdou obvykle rozumně oskriptovat a automatizovat. Pak třebas to, že u klikacího rozhraní je možné to, na co autor myslel a udělal tam patříčnej edit, check, … Když chceš něco víc, máš smůlu… A tak by se dalo pokračovat :)
R. -
Hlavně tahle otázka se řešila už před (hodně) lety a došlo se k víceméně všeobecné shodě, že na serveru je grafika nadbytečná, resp. může být jako možnost, ale neměla by být nutná, služby mají běžet jako démoni, bez grafického výstupu, jestliže grafika není potřeba, proč by tam byla? Jestliže grafika je potřeba jen občas nebo i často, beztak je dobré rozseknout službu na klientskou a serverovou část, které můžou v pohodě komunikovat po síti, vzdáleně – klientská grafiku má, serverová nemá. Jednoduché :-)
Pokud někdo potřebuje na serveru provozovat aplikaci s grafikou*, pravděpodobně tu aplikaci používá jinak, než bylo zamýšleno, ohýbá si ji, nebude to asi to pravé ořechové. Kdyby původního autora napadlo, že by se aplikace mohla provozovat na serveru, tak by udělal negrafické rozhraní – takže buď to zvoral autor, nebo ten, kdo aplikaci používá „divným“ způsobem :-)
*) neříkám, že člověk nemůže mít na serveru Xka, aby se mu to líp spravovalo – když mu to pomáhá tak budiž, ale on je může kdykoli vypnout a server poběží i bez nich. Služby jsou na grafice nezávislé. Ještě z Windows si pamatuji takovou historku – na jeden server jsme se připojovali přes VNC, tam běžela nějaká „serverová“ aplikace a přes ní byl otevřený Word a v něm napsáno velkým písmem: NEZAVÍRAT TO OKNO!!! -
Sutrak (neregistrovaný)
Problem je, ze to jsou same „kdyby“ a „co by“. Prognozy dostacujicich 640kb pameti jsou jiz davno za nami…
Jiste ze si muzes vymyslet tisic duvodu, ovsem napriklad monitorovaci software, kde potrebujes videt vsechno najednou a pohromade pro „prvni“ pohled je neco, co jaksi radkova aplikace nezvlada…
Kdo ma pomalou linku, tam je to jasne. Ale kdo ma rychlou linku, nebo sedi „vedle“ serveru v serverovne, ten grafickou aplikaci ocenit muze a neni to nic proti nicemu.
Bezpecnost ci stabilita neni narusena o nic vic nez radkova aplikace…
Tak jeste bych poprosil o nejake ty padne duvody… -
pantaril (neregistrovaný)
Pokud mate rozumne novy virtualbox (me tohle funguje minimalne pul roku zpatky, momentalne na verzi 3.1.4_OSE) tak staci v nastaveni virtualniho stroje kliknout na sekci Network, vybrat virtualni rozhrani, ktere chcete konfigurovat, nastavit polozku „attached to“ na „Bridged adapter“ a vybrat fyzicke rozhrani, na ktere bude to virtualni bridgovane (u me eth0)
Pak uz pouze ve virtualnim stroji nastavite spravnou IP, masku a branu a je hotovo. -
Vasek (neregistrovaný)
Zdravím,
VirtualBox to opravdu umí. Jelikož, ale na server to není stále ono tak bych také raději uvítal jak virtualizovat více strojů pomocí KVMtak aby každý virtuální systém mohl mít vlastní veřejnou IP. Nějak se toho nemůžu dobrat. Na serveru mám jednu síťovou kartu.
Pár postupů jsem odzkoušel, ale moc nezadařilo. Proto bych uvítal článek v češtině o KVM a síťování.
Vašek -
Petr (neregistrovaný)
Toto je výsek ze startovacího skriptu, co používám.
Předpokládá existující bridge br0:# vytvoříme tap rozhraní pro jednotlivé stroje a přidáme je do bridge br0 tunctl -p -t vm0 brctl addif br0 vm0 ifconfig vm0 up tunctl -p -t vm1 brctl addif br0 vm1 ifconfig vm1 up ... # spustíme KVM mašiny kvm \ -name vm0 -pidfile /kvm/vm0/kvm.pid -daemonize \ -m 768 -mem-path /mnt/hugetlb \ -drive file=/dev/mapper/vm0,format=raw,index=0,if=ide,boot=on \ -net nic,vlan=0,model=virtio,macaddr=a0:00:00:00:00:01 -net tap,vlan=0,ifname=vm0,script=no \ -serial none -parallel none \ -monitor telnet:127.0.0.1:4000,server,nowait \ -vnc 127.0.0.1:0 kvm \ -name vm1 -pidfile /kvm/vm1/kvm.pid -daemonize \ -m 1024 -mem-path /mnt/hugetlb \ -drive file=/dev/mapper/vm1,format=raw,index=0,if=ide,boot=on \ -net nic,vlan=1,model=virtio,macaddr=a0:00:00:00:01:01 -net tap,vlan=1,ifname=vm1,script=no \ -serial none -parallel none \ -monitor telnet:127.0.0.1:4001,server,nowait \ -vnc 127.0.0.1:1 ...
Popis:
Spustíme KVM a udáním jméne (vm0…), zadám si cestu k PID souboru v daemon režimu. Přidělil jsem paměť (768/1024 MiB) v HugeTLB. Následně jsou tam cesty k diskům emulovaným jako IDE rozhraní. Virtuálové budou bez sériových a paralelních portů, monitor strojů běží v telnet režimu na portech 4000… a VNC rozhraní je definováno jako poslední 0…
No a nyní k síti: ze zde nepodstatných důvodů si pakety značkuji do VLAN, používá se virtio s definovanou mac adresou (pro každý stroj jinou, pozor, aby bit 0 v bytu 0 mac nebyl 1, ty se užívají pro multicast (http://www.cisco.com/warp/public/cc/techno/tity/prodlit/ipmlt_wp/ipmlt_w2.jpg), používá se TAP, zadáno jméno a určeno, že se nemají používat skripty pro ovládání rozhraní (to jsme již udělali manuálně – osvědčilo se mi to více).
Jednoduché, snad to pomůže. Pak je samozřejmě potřeba zkonfigurovat iptables, forwardování packetů, pokud není aktivní… ale to je již síťařina mimo KVM.
Petr -
HH (neregistrovaný)
Pokud nemáte nějaký zásadní důvod proč nepoužít libvirt, tak to jde i bez toho zběsilého skriptování. Bridge pouze mezi hostitelem a virtuály se nadefinují přímo v libvirt (virsh net-define), bridge ve kterých má být i nějaká fyzická síťovka hostitele se nadefinují v startup skriptech způsobem vlastním dané distribuci (/etc/sysconfig/network-scripts v rh-like, /etc/network/interfaces v debian-like atp.) a ve definici virtuálu se pak jen uvede do jakého existujícího bridge se má virtuální síťovka připojit.
-
HH (neregistrovaný)
Jasně, nic proti, já speciální startovací/inicializační skripty nemám rád kvůli lidové tvořivosti, zkuste něco takového opravovat po kolegovi který je zrovna v Antarktidě, nebo po sobě po x letech. YMMV. Relativně snesitelné to je v OpenBSD, kde řešení přes skripty má tradici, které pokud se správce drží, tak mají ty skriptíky určitou pevnou strukturu a hlavně jsou extrémně přehledné.
Já mám na serverech většinou RHEL (na pár vývojových Fedoru) a úplně v pohodě jsou všechny vypečenosti nastavené standardním způsobem v konfigurácích typu „klíč=hodnota“, občas xml. Včetně šifrování disků, RAID a LVM, iSCSI a FC iniciátorů s multipathingem, komplexní konfigurace sítě (IPv4 i IPv6, vícero routovacích tabulek, iptables, iptables6, bonding, vlany, brigde, OpenVPN a IPsec tunely), KVM a Xen hypervizory ovládané přes libvirt. Je fakt, že občas jsem musel ty distribuční skripty skripty luštit abych zjistil, jak co nastavit (dokumentace ke speciálnějším věcem moc není), ale mnohokrát se to vyplatilo. Upravit řádek „klíč=hodnota“ zvládne i moje sekretářka, správně zasáhnout do custom skriptu aniž by něco neposr^H^Hkazil většinou nesvede ani „certifikovaný“ specialista …
-
Trident (neregistrovaný)
Ifconfig neumre dokud bude linux mit cosi spolecneho s unixem. ip utils funguji jen v linuxu. Zatimco ifconfig funguje os solarisu,bsd,masox,linux apod.
Popravde receno nechapu tu zapsklost vuci ifconfigu. Na bezne veci ho pouzivam na advanced veci pouzivam tu objektovou blbarnu od kuznetsova. -
Ondřej CaletkaZlatý podporovatelZatímco ifconfig funguje os solarisu,bsd,masox,linux apod.
…ale v každém více, či méně odlišně. ifconfig v Linuxu je jen pro lidi s minimálními konfiguračními nároky. Člověk který chce plně využívat všechny funkce síťového stacku v Linuxu prakticky okamžitě narazí na jeho limity a musí přejít na iproute2
-
e3k (neregistrovaný)
tak ja som to robil uplne inac:
http://kdl.nobugware.com/post/2009/02/17/virtualbox-nat-ssh-guest/
takto som si rozchodil ssh (a podobne aj http):
VBoxManage setextradata Solaris10u6 „VBoxInternal/Devices/e1000/0/LUN#0/Config/ssh/Protocol“ TCP
VBoxManage setextradata Solaris10u6 „VBoxInternal/Devices/e1000/0/LUN#0/Config/ssh/GuestPort“ 22
VBoxManage setextradata Solaris10u6 „VBoxInternal/Devices/e1000/0/LUN#0/Config/ssh/HostPort“ 2222
len treba davat pozor na to ako sa vola sietovka (e1000 v tomto pripade) a premenovat masinu (Solaris…) vypnut zapnut stroj a secko islo jak po masle. -
-
Gagl (neregistrovaný)
Bohuzel qemu je podstatne pomalejsi nez virtualbox.A to jak ve vykonu cpu tak v diskovych io operacich. Virtualbox vychazi z qemu ale ma podstatne pohackovany hypervizor aby se nektere instrukce provadely primo a ne prekladem(podobne to ma vmware). Navic za vyvojem neOSS vetve virtualboxu stoji Sunacle a releasy jsou pomalu kazdy mesic.
Jedna z mala vyhod qemu je ze emuluje jine platformy jako ARMkove boardy,PowerPC,MIPS a podobne. -
Mira (neregistrovaný)
KVM jsem parkrat zkousel. Da se to jednoduse nakonfigurovat a je to svizne. Ale chybi mi tam featury typu „prizpusob rozliseni obrazovky velikosti oknu guesta“ tak jak to umi VMware anebo i VirtualBox. Alespon na Windows XP, co jsem zkousel. Asi je to problem graf. driveru. Takze pouzivam VirtualBox a jsem spokojenej.
