Gnuтий блог особливості використання virtualbox в ubuntu
Моє ставлення до VirtualBox в Ubuntu двояке. Наявність вільних компонент і факт, що це тепер власність Oracle, а вони, в останній час, добре подтрудлісь над своєю репутацією кінчений копірастов, змушує мене сумніватися в світле майбутнє даного продукту. З іншого боку, альтернатива у вигляді Qemu, прямо скажемо, сильно відстає: інтеграція з десктопом відсутня, як клас, а Випиляні в версії 0.12 kqemu, робить її непридатною для використання на старих машинах, де не працює KVM.
Виходить, як в анекдоті: "їжачки плакали, кололися, але продовжували жерти кактус.". Далі я постараюся описати свій досвід того, як це робити зручніше. Может кому пригодится.
Установка linux-headers
В Ubuntu можна отримати ситуацію, коли встановлена версія linux-headers не збігається з встановленою версією linux-image. В результаті, VirtualBox перестає працювати і лається на відсутність модуля vboxdrv.
В принципі, ви можете і не зіткнутися з цією проблемою, особисто я, нарвався на неї з власної "зауми". Не пам'ятаю починаючи з якої версії (в 10.04 ця "фіча" вже була), Ubuntu наполегливо пропонує задіяти можливості забезпечення безпеки закладені в процесор. В першу чергу, це стосується можливості забороняти виконання коду в деяких областях пам'яті (Non-Executable Memory). Для цього пропонується замінити ядро linux-image - * - generic використовується за умовчанням, на linux-image - * - generic-pae.
Сама заміна ядра проходить гладко, але VirtualBox магічним чином перестає працювати. Відбувається це тому, що для VirtualBox потрібно зібрати свій модуль ядра vboxdrv. Цим займається пакет dkms. якому необхідна правильна версія linux-headers. Конкретно, збірка модулів для linux-image - * - generic-pae вимагає наявності linux-headers - * - generic-pae. На жаль, залежності між пакетами прописані так, що автоматично потрібні пакети не встановлюються (LP # 673349).
Найпростіший спосіб виправити проблему (подальші оновлення будуть ставитися автоматично):
Робота з фізичними дисками
У розділі Advanced storage configuration керівництва користувача описано, як у віртуальній машині VirtualBox можна працювати з фізичними дисками. Для мене ця можливість відноситься до розряду життєво необхідних: експерименти з завантажувачем і multi-boot віртуалізація без неї практично неможливі.
Команди додавання фізичного диска і запуск VirtualBox в результаті виглядають так:
До речі, перед запуском VirtualBox нешкідливо упевнитися в отсутсвии завантажених модулів KVM, інакше запустити віртуальну машину не вийде.
Зниження навантаження на процесор
Якщо подумати, то проблема погана. Симптомом є те, що VirtualBox на 100% завантажує одне з ядер процесора, навіть коли гостьова ОС показує всього 1-2% завантаження. Я зловив таку проблему в Ubuntu з Windows XP в якості гостьової ОС.
У чому причина такої поведінки, я так і не зрозумів. Ходять чутки, що справа в постійному перенесенні процесу VirtualBox з одного процесора на інший. Якщо так то, мали б працювати інші рішення, типу прив'язки VM до певного процесору / ядру за допомогою taskset. але у мене вони не спрацювали. Чому? Поки, не розбирався.
Налаштування клавіатури
Нарешті, має сенс приділити увагу налаштуванню гарячих клавіш. В общем-то дрібниця, але на зручності позначається помітно.
Перше, що слід зробити це замінити Host Key на щось більш осудна, ніж правий Ctrl. Більш безглузде значення за замовчуванням придумати складно, конфлікт з гарячими плавішамі всередині гостьової машини забезпечений.
Я зазвичай налаштовую Host Key = LWin. Зробити можна це в меню: Файл → Установки → Введення.
Добре б ще налаштувати фільтр, які комбінації клавіш пропускати в віртуальну машину, а які ні. (Скажіть, наприклад, навіщо передавати в гостьову OS команду блокування консолі (Win + L)? Щоб зайвий раз ввести пароль?)
Кожній збірці ядрі в Ubuntu відповідає своя версія версія headers. Наприклад якщо у вас linux-image-2.6.35-31-generic то, для цього ядра потрібні linux-headers-2.6.35-31-generic. Якщо у вас linux-image-2.6.35-31-generic-pae то, вам потрібні linux-image-2.6.35-31-generic-pae. Збіг хвоста після linux-- має бути точним, так як від цього залежать шляхи, куди встановлюються файли. Всі пакети типу linux-headerи-server, linux-headers та інше - це заглушки, які витягують потрібну версію headers, якщо звичайно пощастить.
Наявність "зайвих" headers пакетів, наскільки я знаю, ніяк не відбивається на роботі системи, хіба що місце займають. Однак, для складання модуля через dkms, вам потрібні headers відповідні саме вашої версії ядра. Ніякі інші для цього не підійдуть, хіба що ви візьметеся збирати модуль руками, але тоді вам ще й бубон знадобиться.
Якщо на момент установки virtualbox у вас не було встановлено потрібний варіант пакету linux-headers, ви це швидко помітите. Віртуальні машини не запустяться.
Перевірити, наявність модулів ядра можна командою:
find / lib / modules / `uname -r` -name 'vbox *'
Якщо команда не знаходить файлів, вам необхідно встановити відсутній пакет linux-headers, після чого виконати реконфігурацію пакета virtualbox-dkms.
sudo dkpg-reconfigure virtualbox-dkms
В ході реконфігурації, потрібні модулі будуть зібрані і завантажені в ядро. Попередня команда (find) повинна після цього знайти файли модулів ядра на файлову систему.
А хіба всі правильні headers c хвостами не повинні витягуватися по залежностям встановлюються метапакетом ядра при установці системи?
Як може вийти, що в системі буде невідповідність?
Теоретично повинні, а практично ніфіга не працює.
Ось вам приклад з 11.10:
virtualbox-dkms Depends: dkms (> = 2.1.0.0)
dkms Recommends: linux-headers-686-pae | linux-headers-amd64 | linux-headers-generic | linux-headers
linux-headers-3.0.0-14-generic-pae Provides: linux-headers
Досить встановити будь-який з пакетів linux-headers- * і dpkg буде вважати, що залежність задоволена. Те що dkms при цьому не збирає потрібні модулі, його абсолютно не хвилює.
Якщо мені пам'ять не зраджує, соотвествтующіе баги заводилися ще за часів 10.04, але оскільки проблема існує і в 11.10 виправляти їх, мабуть, нікому.
Потрібно щось типу умовних залежностей. Підозрюю зробити це можна, додавши по віртуальному пакету для кожного з варіантів ядра і прописавши в залежностях dkms, щось типу: Recommends: (linux-image-pae linux-headers-pae) | (Linux-image-amd64 linux-headers-amd64). Але все це припущення. Щоб це перевірити треба вбити багато часу. Підтягнути розробників двох пакетів linux і dkms. Подзреваю, що доведеться довго-довго проїдати їм лисину, щоб вони звернули на проблему хоч якусь увагу. Потім вони скажуть, що проблеми немає, або вона не відтворюється, або ще щось вигадають. Потім треба буде написати тестовий випадок, який буде демонструвати проблему на свіжовстановленому системі. Йому ймовірно не повірять. Тому ви вирішите написати патч хочаб для себе і вистелете його розробникам. Патч осяде в черзі на злиття. Пару раз до вас можливо звернуться з проханням переробити його для усунення якихось недоліків, але потім вийде новий реліз і про патч забудуть. В кінцевому підсумку виправлені версії пакетів осядуть в вашому ppa, де ви і будете їх підтримувати з релізу в реліз.
На даний момент, війна з вітряками в особі спільноти Ubuntu мене трохи стомила, так що я займатися цим зараз нехочу. Може бути трохи пізніше, коли відійду від свят. ;)
І так теж буде працювати і ще десятком інших способів. Причину глюків я вам назвав: dpkg або apt неправильно задовольняє залежності між пакетами, або залежно криві, до кінця не зрозуміло. Як вилікувати вручну теж відомо.
Я мабуть не розумію мету ваших вправ. Якщо вам потрібно просто запустити виртуалку то, за час, що ми листуємося, можна вже кілька разів перевстановити все з нуля. У разі збою після поновлення, ручне виправлення займає 5-10 хвилин.