VirtualBox 4.3.6

 ( trey | 2013. december 19., csütörtök - 14:53 )

Az Oracle részéről Frank Mehnert bejelentette, hogy elérhető a VirtualBox 4.3.6-os kiadása, amely egy karbantartási kiadás a 4.3-as sorozathoz. Karbantartási kiadáshoz illően benne egy rakás hibajavítás érkezett.

Részletek a bejelentésben.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Tegnap raktam fel a 4.3.4-et... Kétszer. Mert az első install után közölt, hogy valamilyen kernel modult nem talál, ezért egyetlen guest sem indult el. :(
Ha megint előadja, áttérek vmware-re! :D

Ha Linux a host, akkor sokkal jobb a KVM+QEMU egy akármilyen forntenddel (van a libvrites, de van számos natív qt gtk, meg még webes is), mint a vmware.

Bevallom, engem meglep, hogy egy kereskedelmi termék életben tud maradni a nyílt forrás mellet, miközben rosszabb nála. Szóval kifejtenéd, hogy miben jobb a KVM+QEMU? (Hozzáteszem, hogy körülbelül 15 éve láttam utoljára VMWare-t és akkor kiválónak tűnt. Mondjuk nem is volt alternatívája.)

---
Science for fun...

most sincs alternativaja, ha barmi komolyabbrol van szo. (SRM pl)

Ki mondta hogy jobb? Én azt mondtam, hogy ha Linux host, akkor alapból benne van, nem kell semmivel hülyéskedni, minden disztro szállítja. Ezt a kereskedelmi dolgot nem értem. Mi a kereskedelmi? Melyikre mondod?

Amúgy sokan keverik a wmvare esx-et, a vmware-t, a quemi+kvm és az RHEV-t. Te most melyikre gondoltál, hogy kereskedelmi és rosszabb?

A vmware a legjobb abban, hogy infrastruktúrát rittyentett a virtualizációs rétege fölé, ami kétség kívül verhetetlenné teszi nagyvállalati környezetben. Az RHEV halad erre fele, de azért még messze van (lásd állandó vesszőparipámat a distributed virtual switch-et, ami végre megjön az openvswitch-el valamikor). De a magjáról én nem tudnék ítéletet mondani melyik a jobb. Volt egyszer egy nagyszerű összehasonlítás, ami szinte fej-fej mellé hozta ki a 3 elterjedt virtualizációs platformot (esx, kvm, hyperv) a belüket tekintve. A platform ami köréjük van építve meg megint más tészta, mert abban verhetetlen a vmware.

A 15 évet kissé soknak tartom, hogy már akkor vmware-t láttál, és hogy milyet, de lehet Te jobban bent voltál ebben a technológiában akkor.

Ismét hangsúlyozom. Egyiket sem tartom sokkal jobbnak a másiknál. De ha Linux, akkor én a qemu+kvm párost használnám virtualizációra. Ha nagyvállalati környezet, akkor egy talpas esx és egy qemu+kvm sem rúghat labdába, csak az RHEV és a vSphere.

De később itt írják, hogy winről van szó. Így tulajdonképpen tárgytalan is volt a sok pofázásom. :D

Idézet:
Ki mondta hogy jobb? Én azt mondtam, hogy ha Linux host, akkor alapból benne van, nem kell semmivel hülyéskedni

Idézet:
Ha Linux a host, akkor sokkal jobb a KVM+QEMU

Szóval azért én értem, miért kérdeztek vissza :)

Oké, de akkor melyik magyar szót használnád a jobb helyett. Itt nem a minőségről beszéltem. Azt mondtam, hogy az jobb hogy nem kell semmti hegyezsteni, mert benne van.

Kérlek javasolj egy szót és akkor leírom azt a mondatot csak a Te megnyugtatásodra! Hajlandó vagyok azzal a szóval leírni a mondatot, hogy megnyugodjon mindenki kicsi lelke, ha már nem volt elég a kimerítő válaszom.

Légy oly' kedves és konstruktív tehát, hogy egyetlen egy szóval kisegítesz. Előre is köszönöm.

Ne szívd mellre, egyszerűen csak felhívtam a figyelmed rá, hogy dehogynem mondtad. :) Értem, hogy nem ezt gondoltad, meg ki is fejtetted feljebb, ami rendben is van, csak elsőre valóban nem volt egyértelmű, hogy szerinted hogyan jobb.

Egyébként konstruktívan tudnám pl. javasolni az "egyszerűbb" szót, ha esetleg kettővel is megelégszel akkor a "könnyebben telepíthető" (bár gyanús, hogy van vbox repokban is, ha már van belőle openszósz edition)

Na látod így már mingyárt más :D

"Ha Linux a host, akkor sokkal egyszerűbb és könnyebben telepíthető a KVM+QEMU"

Van openszósz vbox, de az isten kegyelmezzen, én(!!!) legalábbis nem szeretem, hogy felcsesz mindenféle tuntap eszközöket, meg saját szarokat, mikor alapban használhatná a linux-osokat, amik ott vannak kéznél.

Hozzáteszem, hogy én is vbox-al kezdtem, aztán mstanában már csakis qemu+kvm+libvirt. Persze ez csak ízlés kérdése. lehet még az sem igaz, ha azt írom hogy álatalánosan könnyebb. Van akinek valószínűleg a vbox a könnyebb.

Ez valami újdonság?
Úgy tudtam az open source csak annyiban tér el a zárttól, hogy pár feature hiányzik belőle. Pl. usb támogatás.

Melyikre gondolsz, hogy újdonság?

Mikor utoljára vbox-al foglalkoztam mindegyik felrakta a saját szarjait (aopenszósz is). Ugyanúgy, mint amikor egy vmware server vagy player terméket felraktam. Mindegyik saját driverekkel működött. De tényleg egy-két éve néztem rájuk utoljára. Ha saját gépen kell virtualizálni akkor leszoktam róluk. (Nagyvállalati környezetben meg eszembe se jut a vmware vspahere-n kívül más.)

Valahogy az jött le a szavaidból, hogy csak az OS pakol fel mindenféle, neked nem tetsző dolgot.
Ezért érdeklődtem.
A tun/tap mióta nem része a linuxos eszköz készletnek?

+1
VMware Workstation 1999-ben jelent meg. Nincs meg az a 15 év még a legelső release óta sem, csak majdnem. Ráadásul a Workstation kb a 4.x-es verzió (2003) környékén kezdett viszonylag értelmesen használható lenni. 5.x-ben (~2005) kapott csomó új (ma már elég alapvetőnek számító) feature-t, viszont elég lassú lett, amit 6.x-re (kb 2006) javítottak ki. Szóval _jó_ tapasztalat, max 10 évvel ezelőttről lehet.

Másrészt szerintem is KVM+QEMU - mint tisztán virtualizációs core technológia - egyszinten van a vmware-rel*, és stabilabb, gyorsabb a VirtualBox-nál. Ez persze azóta van így, hogy a CPU-kban van virtualizációs támogatás.

(* Persze tudok bizonyos rikta corner-case eket, mint pl fizikai CPU mag exkluzívan VM-hez kötése, amit a KVM nem tud megoldani, de az ESXi is csak közelítő megoldást ad. Talán egyedül a Xen oldja meg jól. De ez nagyon nem desktop környezet, és a userek 99%-a életében nem találkozik olyan helyzettel, hogy szüksége legyen rá.)

A QEMU frontendek viszont usability szempontból valóban csapnivalóak, ennél a VirtualBox is simán jobb, de természetesen itt a VMware a nyerő. A KVM-nél a libvirt körüli - főleg jogosultságkezelési - rendszeres kavarások pedig nagyjából összemérhető szívást jelentenek a virtualbox kernel modul újraforgatás miatti kényelmetlenséggel. Szóval hiába része a KVM a mainline kernelnek, a libvirt hülyeségein elveszted a kényelmet. A vmware-nél pedig az a nagy gond, hogy a hivatalos kernel patch-ek csak bizonyos Player/Workstation verzió és Linux kernel verzió kombinációkhoz vannak meg. Ha ezen kívül esel, akkor sok szerencsét...
---
Régóta vágyok én, az androidok mezonkincsére már!

Tökéletes összefoglalás.

Talán még annyit, hogy a cgroups segítségével nagyon szépen lehet a virtuális gépet CPU maghoz kötni, bár kétség kívül pilótavizsgás a dolog. :D

Igen, ezzel már próbálkoztunk, a CPU affinity KVM-mel valóban működött, de sajnos az is kéne, hogy más process ne kerülhessen arra a magra. (Valami ősrégi legacy hard realtime guest OS-t kellett beüzemelni, ami háklis volt arra, ha tickjei kimaradnak)

Az ESXi-ben beállítható CPU affinity is kb ugyaneddig tudja a dolgot, viszont SMP-re gang scheduling-et használ, és a mi konkrét problémánkra ez is megoldást jelentett.
---
Régóta vágyok én, az androidok mezonkincsére már!

KVM is kényelmes már virt-manager-rel. Meg azért a memória buborékos cucca is nagyon hasznos, szemben VirtualBox-val, amely egyben lenyeli a memóriát, KVM-nél meg apránként csorgadozik, ahogy kell a guest-nek.

A jogosultsági gondok (nem részletezted, de ha egyre gondolunk) egyszerűen megoldhatók:

# create new group for libvirt
groupadd libvirt
# add my user to this group
usermod -G libvirt myuser
# enable groups for libvirt instead of the default root
# http://libvirt.org/auth.html#ACL_server_unix_perms
edit /etc/libvirt/libvirtd.conf
unix_sock_group = "libvirt"
auth_unix_rw = "none"
service libvirtd start
# log out and back on
virt-manager

Azért nem részleteztem, mert elég sok különböző problémám volt vele. Amit leírtál az _elvileg_ jó kéne legyen, csak néhány verziónként belekavarnak az egészbe, és olyankor mindig nulláról kell kezdeni a nyomozást, hogy most éppen hogy kéne beállítani. Legutóbb azt hiszem policykittel kellett küzdeni.

Többször van, hogy 1-1 specifikus dolog romlik csak el, pl néha nincs hang, vagy a GUI VNC-vel megy, de SDL-lel már nem stb.

Nyilván ha hostnak egy olyan szinten LTS disztrót használnék, mint RHEL/CentOS akkor ez az egész nem érintene - but then again, ott a vmware kernel moduljaival se lesz probléma.
---
Régóta vágyok én, az androidok mezonkincsére már!

És megint meg kell erősítsem. A policykit-es hibák gyakoriak. Régen csak azt csinálta, hogy nem engedett más felhasználóval virt-managert indítani, mint aki be volt jelentkezve (egyébként lehet hogy ez nem is policykit hanem dbus hoba volt). Aztán ez megoldódott, Következő frissítsnél már csak a root használhatta, amíg bele nem raktad magad valamelyik konfig állományba, már én sem emlékszem melyikbe. Most ott tartunk, hogy tök jó, de nagyon izgoluk a következő frissítésnél mindig. :D

"körülbelül 15 éve láttam utoljára VMWare-t és akkor kiválónak tűnt. Mondjuk nem is volt alternatívája"

most sincs...
--
ne terelj

Windows host, de egyébként sem győzött meg anno a kvm.
Virtualbox is tud hülyeségeket produkálni, de ... szóval rossz emlékeim vannak a kvm-ről.

Nem emlékszem, pontosan milyen szituációban, de nekem is volt hasonló kínom vele. Ilyenkor kézzel le kell futtatni a /etc/init.d/vboxdrv szkriptet és működik.

---
Science for fun...

Sajnos windows-on nincs ilyen :)
De megint előadta. Lusta vagyok kinyomozni, hogy miért.

Ubuntu alatt akkor szoktam így járni, ha új kernel verziót jön le frissítéskor. Bár érdekes, hogy az fglrx kernel moduljaival nincs ilyen probléma.

dkms fenn van?
(bár lehet, hogy keverem a virtualbox drivereket az nvidia-éval)

fent van a dkms (a "/etc/init.d/vboxdrv setup"-hoz szükséges), de valamiért csak az éppen futó kernelre fordítja le a modulokat, míg az fglrx-nél mindegyikre.

Windows 7 alatt 4.3.4 volt eddig, ment, 4.3.6-ra frissítettem, megy. Windows alatt kernel modul hiba?


"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Vicces, igaz? :)

Szerintem ez még semmi, hanem, mind a 4.3.4-ben, mind a 4.3.6-ban a windows 98 guest telepítő hatására merevre fossa magát a gazdarendszer is. A SysRq mágia is hatástalan.

Régebben ki kellett adni egy /etc/init.d/vboxdrv setup -ot, ami lefordította a kernelmodulokat...

... vagy esetleg hiányzik nálad a DKMS

Milyen Linuxon csinálta ezt neked?

---
#include "alairas.h"

Win7 64bites "linuxon" :)

Sziasztok,

Szerintetek mi az oka annak, hogy nem kap ip-t a virtualbox-os szerverem? Brigde üzemmódban használom az eth0 interface-t, és már próbálkoztam mac adress átírással, töröltem a szerveren az udev szabályok 70-persistent-net.rules fájljából a sorokat, töröltem magát a fájlt is, hogy hátha újragenerálja, kapcsolgattam ki/be az interface-t, próbálkoztam dhclient-tel új ip-t kérni, adtam meg újra route-ot az ip route paranccsal, gatewayt is állítottam. Most már vagy 4. napja nem kap ip-t a virtuális szerver, előtte tökéletesen működött, egyik napról a másikra romlott el.

-- Zoli

Mi változott akkoriban?
DHCP szerveren van valami a logokban?
Az eth0 biztosan az első adaptered?
(ip link kimenetében ugyanaz a MAC address szerepel, ami a VB-ban be van állítva? )
Ha MAC address-t cseréltél, a változást átvezetted a DHCP szerveren is?
A rules... file-t nem árt megnézni alaposabban, mert az új udev verziók ignorálják a virtuális hálókártyákat.
Hirtelen ennyi jutott eszembe.

Az adapter eth0 ok, ugyanaz a MAC address.
Nem tudom most megnézni a dhcp szerver logjait.
Most újratelepítem a virtualboxot, remélem megoldódik.

-- Zoli