Воззрения кота Manual’а на Virtualbox

Воззрения кота Manual’а на Virtualbox

О системе виртуализации VirtualBox как-то не очень принято говорить вслух. Тем, кто с ней работает, она представляется настолько простой, что и говорить-то особенно не о чем. А те, кто с ней только начинает знакомиться, наслышавшись о её достоинствах, стесняются спрашивать столь элементарные вещи.

Введение

Правда, некоторые тонкости в VirtualBox’е (далее VB) действительно есть (например, организация обмена данными между хостом и «гостём»). Есть и некоторые шероховатости при установке VB в разных дистрибутивах. Кое о каких таких шероховатостях и тонкостях (тех, о которых мы с котом Мануалом занем, и с которыми приходилось сталкиваться) будет говориться в этих очерках. Но сначала — небольшая оговорка.

Первая версия данного материала сочинялась по просьбе Татьяны Ивановой aka vita — и в первую очередь для постоянных посетителей форума Matuntu. Так что изложение в основном пойдёт с ориентацией на дистрибутивы Ubuntu’йского семейства, в любом из которых всё происходит абсолютно одинаково. В частности, данные строки, принадлежащие второй версии и сопровождающие их скриншоты редактируются, досочиняются и снимаются в нашей любимой системе Cintu. Конкретно — в её релизе 17.10 Artful.

В более иных дистрибутивах (о совсем более иных операционках к ночи поминать не хочется) некоторые детали могут отличаться. Те дистрибутив-специфические отличия, о которых я вспомню, будут оговорены специально.

Первое, что следует сделать для использования VB — это уяснить, для чего он может использоваться.

Сферы применения

Основными сферами применения VB являются кросс-платформенная разработка и тестирование существующих систем и приложений для них. Кроме того, они очень часто используются для первого знакомства с каким-либо дистрибутивом — просто навскидку определить, стоит ли он дальнейшего знакомства, или дивчинка вы… овчинка выделки не стоит. Правда, к полученным впечатлениям следует относиться с осторожностью, ибо работа системы в виртуальной машине отличается от таковой на «реальном железе» так же, как бег в мешках — от просто бега. Это относится и к использованию VB в любых тестировочных целях. Но об этом будет разговор в разделе об особенностях виртуальной инсталляции.

Мы с котом Мануалом используем VB для достижения трёх целей. Первая — ознакомительная: поглядеть на дистрибутив, который нас почему-либо заинтересовал. Правда, задача эта встаёт перед нами всё реже: как я неоднократно говорил, на современном этапе дистроения реализованы не только все возможные разумные идеи, но и большинство неразумных.

Цель вторая — сопоставительная. Время от времени у нас с Мануалом возникает желание (а иногда и необходимость) поглядеть, как та или иная функция реализована в более иных дистрибутивах. Дабы всю физику к… Cintu не сводить. Чем, надо сказать, часто грешат пользователи Ubuntu’идных систем, и даже иногда их применители. С этой целью мы держим несколько виртуальных машин из числа тех, которые нам интересны или, по той или иной причине, нужны. Набор этих дистрибутивов меняется по ситуации, но в нём непременно присутствуют Matuntu и Antergos, а последнее время её и Maui (в причины этого вдаваться не буду).

Наконец, третья, и главная, цель — сборка системы Cintu, создание её образов и их тестирование. Причём первые два действа мы с Мануалом целиком перенесли в виртуальные машины. Там же проводится и первый этап тестирования. Однако, помятуя об отличиях бега и «бега в мешках», финальное тестирование обязательно проводим на «реальном желез» — только после этого образы выкладываются в открытый доступ.

Так что всё написанное далее подчинено достижению трёх указанных целей — и, как уже говорилось, в первую очередь в системе Cintu. Хотя всё сказанное применимо к любому представителю семейства Ubuntu, а большая часть — вообще к любому дистрибутиву Linux. Вопросов разработки в виртуальной среде мы касаться не будем. Как и возможности применения VB в качестве, скажем, виртуальных web-сервером — насколько нам известно, последней цели служат более иные системы виртуализации, более, так сказать, «промышленные».

Установка VB

Определившись со сферами использования VB, можно приступать к его установке. И эта задача может быть решена тремя способами: «простым», «правильным» и штатным, то есть просто «хорошим».

«Простой» способ

Самый простой способ установки VB — не мудрствуя лукаво, заийти на соответствующую страницу официального сайта и просто скачать бинарный пакет для нужного дистрибутива, его релиза и архитектуры. Например, в нашем случае это будет Ubuntu 17.10 («Artful») — > AMD64. После чего полученный пакет устанавливается штатным инструментом, у нас — командой dpkg -i или утилитой gdebi (если последняя, конечно, сработает, что в Artful’е не гарантируется).

Преимущество «простого» способа очевидно — мы получаем заведомо самую свежую версию VB. Кроме того, при этом автоматически скачивается и помещается куда нужно образ диска с так называемыми «гостевыми дополнениями» — для Ubuntu’идов это пакет virtualbox-guest-additions-iso. Без которого, как мы увидим со временем, в виртуальной машине не жизнь.

Столь же очевиден и недостаток «простого» способа: автоматическое обновление для него после такой упрощённой установки будет невозможно. Но так ли оно нужно? Серьёзное расширение функционала VB бывает достаточно редко, а мелкие косметические обновления для домашнего применителя (в отличие от «промышленного») нет так и важны. К тому же в ряде случаев, особенно на ранних стадиях жизненного цикла очередной ветки системы, это оказывается плюсом: именно при обновлениях иногда нарушается работа системы.

Кроме того, «простой» способ может оказаться единственно возможным для установки VB: в репозиториях дистрибутив круг официально поддерживаемых крайне узок проектом дистрибутивов крайне узок:

А если VB отсутствует и в собственном репозитории применяемого дистрибутива, то только и остаётся, что скачать All distributions для нужной архитектуры, дать полученному run-файлу бит исполнения и на это самое исполнение его запустить.

«Правильный» способ

Тем не менее, для поддерживаемых проектом дистрибутивов «простой» способ — не лучший. Ибо на указанной странице разработчиками VB предлагается «правильный» способ. Для представителей клана Ubuntu (в том числе и для Cuntu) он выглядит так. Первым делом в файл /etc/apt/sources.list добавляется такая строка:

deb http://download.virtualbox.org/virtualbox/ubutnu artful main

Затем вот отсюда скачивается публичный ключ Oracle и активируется командой

$ sudo apt-key add path2/oracle_vbox.asc

Обе операции можно выполнить выполнить в один заход:

$ wget -q https://www.virtualbox.org/download/oracle_vbox.asc -O- | sudo apt-key add -

После чего остаётся обновить локальный кэш пакетов:

$ sudo apt update

И установить его обычным образом:

$ sudo apt install virtualbox-5.2

Однако «идеологически правильный», с точки зрения разработчиков VB, способ его установки оказывается крамольным для правоверных Ubuntu’йцев. Ибо в этом дистрибутиве полагается позорным и преступным заносить в файл /etc/apt/sources.list что-либо, кроме сведений об официальных репозиториях. Любому «левому» репозиторию должен быть посвящён собственный файл в каталоге /etc/apt/sources.list.d.

И потому для сторонников идеологической чистоты марксизма Ubuntu’изма предлагается несколько модифицированный вариант «правильного» способа. Он начинается с создания в каталоге /etc/apt/sources.list.d файла с именем, скажем, virtualbox.list — на самом деле — произвольным, лишь бы было понятно, об чём идёт речь. Например, так:

$ sudo touch /etc/apt/sources.list.d/virtualbox.list

Затем в него вносится указанная ранее строка, например, так:

$ sudo echo 'deb http://download.virtualbox.org/virtualbox/ubutnu artful main' > \
/etc/apt/sources.list.d/virtualbox.list

После чего, как обычно, выполняются команды

$ sudo apt update
$ sudo apt install virtualbox

Установка VB «правильным» способом позволяет не только иметь актуальную на данный момент версию этого виртуализатора, но и обновлять её в автоматическом режиме, как и все прочие приложения. Ну а зло это или благо — решать применителю. Однако в любом случае он имеет возможность запретить автоматическое обновление командой

$ sudo apt-mark hold virtualbox

Или — через Synaptic. За подробностями — к соответствующим «Воззрениям», тем, что о deb-пакетах.

Как и в предыдущем случае, при «правильной» установке образ диска с «гостевыми дополнениями» автоматически появится в каталоге /usr/share/virtualbox, что тоже следует отнести к положительным моментам. А из моментов отрицательных можно отметить только необходимость ручной правки конфига, скачивания и активации публичного ключа.

«Хороший» способ

Конечно, и редактирование конфигурационного файла, и разборки с публичным ключом — труд невеликий. Однако закоренелые лентяи, к коим принадлежим и мы с Мануалом, могут избавиться и от него. Для этого достаточно обратиться к штатным средствами управления пакетами Cintu, как и любого другого представителя семейства Ubunutu, утилите apt или Synaptic’у. Ибо VB входит в официальный репозиторий этого дистрибутива, в чём легко убелиться командой вроде

$ apt search virtualbox G '^vir'

Которая на выходе даст примерно такой (для релиза 17.10) список:

virtualbox/artful 5.1.30-dfsg-1 amd64
virtualbox-5.2/now 5.2.2-119230~Ubuntu~zesty amd64 [установлен, локальный]
virtualbox-dkms/artful,artful 5.1.30-dfsg-1 all
virtualbox-ext-pack/artful,artful 5.1.30-2 all
virtualbox-guest-additions-iso/artful,artful 5.1.30-1 all
virtualbox-guest-dkms/artful,artful 5.1.30-dfsg-1 all
virtualbox-guest-source/artful,artful 5.1.30-dfsg-1 all
virtualbox-guest-utils/artful 5.1.30-dfsg-1 amd64
virtualbox-guest-x11/artful 5.1.30-dfsg-1 amd64
virtualbox-qt/artful 5.1.30-dfsg-1 amd64
virtualbox-source/artful,artful 5.1.30-dfsg-1 all

Полюбовавшись которым, достаточно дать команду

$ sudo apt installvirtualbox

чтобы сразу получить VB, полностью готовый к употреблению. Правда, как видно из приведённого списка, версия его будет «второй свежести» — версия с официального сайта достигла уже отметки 5.2.6. Каковая, между прочим, обнаруживается в репозитории будущего Bionic’а. Однако важно, что в любом случае версия VB, установленная сейчас, будет существовать до конца жизненного цикла релиза. Так, во всех ныне поддерживаемых LTS-релизах по прежнему содержатся версии, актуальные на момент их выхода:

И примеров официального бэкпортирования VB я не знаю.

Так что поклонникам творчества Михал Афанасьича, не признающим никакой иной свежести, кроме первой, могут прибегнуть к «очень хорошему» способу. Правда, для этого им придётся немножко потрудиться и подключить PPA-репозиторий LocutusOfBorg’а, в котором имеются пакеты наисвежайшей версии VB для последнего LTS и текущего релиза (в данный момент — для Xenial’а и Artful’а), и, как обычно, обновить кеш:

$ sudo add-apt-repository ppa:costamagnagianfranco/virtualbox-ppa
$ sudo apt update

Теперь командой apt policy можно убедиться в том, что кандидатом на установку будет VB последней версии:

apt policy virtualbox
virtualbox:
  Установлен: (отсутствует)
  Кандидат:   5.2.6-dfsg-2~ubuntu17.10.1~ppa1
  Таблица версий:
     5.2.6-dfsg-2~ubuntu17.10.1~ppa1 500
        500 http://ppa.launchpad.net/costamagnagianfranco/virtualbox-ppa/ubuntu artful/main amd64 Packages
     5.1.30-dfsg-1 500
        500 http://ru.archive.ubuntu.com/ubuntu artful/multiverse amd64 Packages

И, разумеется, установить её:

$ sudo apt install virtualbox

Таким образом, «очень хороший» способ установки обеспечивает нас последней версией VB, которая будет регулярно обновляться (по крайней мере, пока товарищ LocutusOfBorg будет обновлять свой репозиторий). Однако и «хороший», и «очень хороший» способы не обеспечивают автоматической установки образа «гостевых дополнений». Так что настало время поговорить о нём (и о других дополнительных компонентах VB).

Установка дополнений

Вернёмся к списку пакетов, имеющих отношение к VB, который выдаётся командой типа

$ apt search virtualbox G '^vir'

В актуализированном виде этот список будет выглядеть так:

virtualbox/artful,now 5.2.6-dfsg-2~ubuntu17.10.1~ppa1 amd64 [установлен]
virtualbox-dkms/artful,artful,now 5.2.6-dfsg-2~ubuntu17.10.1~ppa1 all [установлен, автоматически]
virtualbox-ext-pack/artful,artful 5.2.6-1~ubuntu17.10.1~ppa1 all
virtualbox-guest-additions-iso/artful,artful 5.2.6-1~ubuntu17.10.1~ppa1 all
virtualbox-guest-dkms/artful,artful 5.2.6-dfsg-2~ubuntu17.10.1~ppa1 all
virtualbox-guest-source/artful,artful 5.2.6-dfsg-2~ubuntu17.10.1~ppa1 all
virtualbox-guest-utils/artful 5.2.6-dfsg-2~ubuntu17.10.1~ppa1 amd64
virtualbox-guest-x11/artful 5.2.6-dfsg-2~ubuntu17.10.1~ppa1 amd64
virtualbox-qt/artful,now 5.2.6-dfsg-2~ubuntu17.10.1~ppa1 amd64 [установлен, автоматически]
virtualbox-source/artful,artful 5.2.6-dfsg-2~ubuntu17.10.1~ppa1 all

Первый кандидат на установку в этом списке — пакет virtualbox-ext-pack. Это — тот самый образ диска с «гостевыми дополнениями», о котором неоднократно упоминалось выше. Они обеспечивают произвольное изменение разрешения экрана гостевой системы, поддержку каталогов, разделяемых между гостевой и хост-машиной, а также общий буфер обмена для них. Правда, в ряде дистрибутивов разрешение экрана можно менять «из коробки», без всяких «гостевых дополнений»: среди таких «счастливчиков» все Ubuntu’иды, Antergos, Fedora, возможно, и другие — но, как ни странно, не Oracle Linux. Да и остальные функции не всегда востребованы. Однако — часто таки нужны, так что пакет этот не помешает и потому подлежит установке:

$ sudo apt install virtualbox-guest-additions-iso

Далее, пакет virtualbox-ext-pack содержит проприетарные дополнения (ранее они входили в отдельную коммерческую версию), бесплатные для персонального использования. В их числе поддержка USB, удалённого доступа к десктопу (VRDP), сетевой загрузки по Intel PXE. По нашим с Мануалом наблюдениям, поддержка USB нормально работает через версию, а всё остальное нам не нужно. Однако при необходимости этот пакет также легко установить:

$ sudo apt install virtualbox-ext-pack

Согласившись в процессе инсталляции с лицензией PUEL (Personal Use and Evaluation License).

Прочие неустановленные пакеты вида virtualbox-guest-* предназначены для установки в гостевые системы и нас (пока) не интересуют.

Итоги установки

Каким бы способом VB ни инсталлировался, по окончании процедуры установки в главном меню используемой среды появится соответствующий пункт — в среде Cinnamon он под именем Oracle VM Virtualbox или просто Virtualbox обнаружится в секции Администрирование. Иногда, чтобы его там увидеть, нужно сначала нажать волшебную комбинацию клавиш Alt+Control+Escape.

Теоретически VB установлен со всеми потребными ему модулями, включая абсолютно необходимые для него dkms-модули ядра, которые, опять же теоретически, должны подключиться сами собой. И нынче так оно почти всегда и бывает. Однако, как говорил дед Щукарь, теоретически она лошадь, а практически она падает. И стопроцентную гарантию этому может дать только страховой полис рестарт системы, который лучше сейчас и выполнить. После чего VB будет уже точно готов к работе, и его можно запустить через главное меню среды, что даст такую картину:

Картина эта провоцирует немедленно приступить к созданию нужной здесь и сейчас виртуальной машины. Однако с этим делом лучше обождать, затратив предварительно чуток времени на общую настройку VB, не зависимую от будущих виртуальных машин, но оказывающую на них влияние. Это будет предметом следующего очерка.

Настройка окружения

Настройка окружения, общего для всех будущих виртуальных машин выполняется через главное меню — Файл -> Настройки, вызывающее к жизни такую панельку:

Здесь самое главное — в секции Общее определиться с каталогом для виртуальных машин, каковым по умолчанию выступает ~/VirtualBox VMs. Но по жизни это далеко не всегда лучший выбор — по понятным причинам, обсуждать которые здесь неуместно (хотя некоторые резоны будут приведены позднее, в заметке про создание виртуальных машин). Лучше под это дело выделить самостоятельный раздел.

Вообще, как оказалось, производительность дискового устройства, на котором размещается каталог для виртуальных машин — самый критический фактор их быстродействия. Я долгое время держал виртуалки на внешнем диске, подключённом через USB, хоть и трёшку. И всегда меня удручало их быстродействие — точнее, отсутствие оного, вплоть до полного ступора. От чего не спасали никакие манипуляции с процессорами и памятью (об этом будет сказано в очерке о настройке конкретной машины). А вот когда смог себе позволить перетащить каталог для виртуальных машин на раздел SSD (тогда ещё одиночного) — был просто потрясён ростом скорости. А апофеоз восторга наступил после размещения этого каталога на softRAID Level0 из двух SSD.

В секции Ввод можно переопределить хоткеи для управления системой VB и её машинами. Я этого не делаю, довольствуясь умолчальными. Здесь стоит напомнить только, что по умолчанию в качестве главной управляющей клавиши в VB выступает правый Control — например, для переключения из виртуальных Иксов в любую доступную текстовую консоль (виртуальную, так сказать, в квадрате) служит Control+F#.

Касаемо проверки обновлений также говорить особо нечего — кое-какие соображения по этому поводу были высказаны ранее. Касаемо языка: по умолчанию он определяется текущей локалью. Разрешение виртуального дисплея проще всего оставить умолчальным, то есть автоматическим:

Ибо, если конкретный дистрибутив, устанавливаемый в виртуалку, поддерживается «гостевыми дополнениями», то потом для него можно будет менять разрешения в (почти) произвольных пределах. Если же нет — как повезёт: разрешение может быть одним из стандартных, типа 1024×768 или 1152×864. А не исключено, что оно вообще сведётся к чему-то типа 800×600 или даже 640×480 — и никакие настройки это не изменят.

Про остальные секции панели настроек сказать вообще нечего, так что с этим вопросом можно закончить. И перейти собственно к созданию виртуальной машины. Но уже — в следующем очерке, который предваряется небольшой интермедией.

Создание виртуальной машины

Ну вот и настало время для создания первой виртуальной машины. В качестве объекта для установки в неё, в соответствие с целевой аудиторией этого материала, был выбран дистрибутив Matuntu — его последняя сборка с именем Matuntu-B64, дабы и на неё заодно поглядеть. Прочитать о нём можно здесь. Там же есть и ссылки на образы для скачивания.

Как нетрудно догадаться, для создания виртуальной машины предназначена кнопка Создать в инструментальной панели VB. После чего в появившейся панели следует указать имя ОС для машины, изменить тип с умолчальной Windows на нужный нам Linux, после чего версия её также станет Linux 2.6/3.4.X/X.4.X:

Надо заметить, что раньше она, версия, с этот момент сама собой становилась Ubuntu (64-bit). Но, видимо, в сознание широких масс разработчиков наконец проникло мнение, что Ubuntu — не единственный Linux на этом свете.

Впрочем, на самом деле и имя, и тип ОС никакой роли не играют, и служат только для расчёта предлагаемых далее по умолчанию объёмов памяти машины и её диска. Объёмы эти определяются по правилам, ведомым только самому VB, и в дальнейшем мы их проигнорируем. Однако всё-таки для порядку лучше тип и версию ОС указать максимально близкими к реальным — тем более что список вариантов достаточно обширен, и включает даже дистрибутивы, давно не существующие:

Задать объём памяти нужно будет на следующем этапе. По умолчанию для большинства дистрибутивов Linux будет предложено 1024 МБ (а вот для BSD-систем, как почему-то считает VB, и 128 МБ будет вдоволь). Ясное дело, что памяти столько не бывает — даже у распроледнего недобука её обычно от 2 ГБ и выше. Так что мы с Мануалом при 16 «хостовых» гигабайтах почти для всех гостевых систем задаём 4 ГБ. Тем более, что они отъедаются от хоста по требованию, а не про запас:

Следующий этап — создание виртуального диска. От чего, впрочем, можно отказаться (например, если виртуальная машина создаётся для Live-системы) или использовать виртуальный диск, созданный ранее. У нас пока такового не имеется, и выбранный дистрибутив планируется установить, так что останавливаемся на умолчальном варианте:

В некоторых случаях в тестировочных целях на стадии установки системы может потребоваться конфигурация — например, при использовании softRAID, LVM или ZFS. И в одном из последующих очерков будет рассказано, как это делается.

А пока определяется формат файла, играющего роль образа виртуального диска. Поскольку ни с какими другими системами виртуализации я его использовать не планирую — останавливаюсь на родном формате VDI:

Следующий шаг — определение, должен ли размер файла образа быть динамическим или фиксированным. Никаких резонов в пользу второго варианта я не придумал, так что останавливаюсь на первом:

В этом случае, кстати, можно не жмотничать с указанием размера диска — это просто предел, выше которого не прыгнешь, размер же образа будет соответствовать его реальному заполнению. Я обычно ограничиваю размер образа величиной 32 ГБ. Имя для диска резонно оставить тем же, что и имя машины. А с помощью кнопки справа от поля имени можно было бы выбрать существующий файл образа, если бы таковой имелся:

На этом создание виртуальной машины заканчивается и, в принципе, её можно было бы запустить с помощью соответствующей кнопки. Однако и здесь торопиться не надо, как говорил товарищ Саахов: лучше сначала выполнить кое-какие настройки.

Настройка машины

Как подсказывает солдатская смекалка, к настройке созданной виртуальной машины можно приступить, нажав на кнопку Настроить в панели инструментов.

Общие настройки

Кнопка Настроить вызывает вот такое окно:

Описывать все возможные настройки я не буду — в большинстве случаев умолчальные параметры машины вполне подходят. Так что рассмотрю только те, которые представляются мне важными или неоднозначными. И первые из них — во вкладке Дополнительно общей секции окна из предыдущего скриншота. Здесь место для помещения снапшотов данной виртуалки зависит от определения каталога для неё самой — и менять его нет резонов. А вот включить Общий буфер обмена и Функцию Drag’n’Drop, причём в двунаправленном варианте, будет не лишним:

Ни та, ни другая функция сама собой не заработают, ибо они требуют подключения «гостевых дополнений» (о которых, повторяю, будет разговор после установки виртуальной системы). Но раз уж мы оказались рядом — почему бы это не сделать сразу? Просто чтобы не забыть. После чего можно перейти к разделу Система. Где во вкладке Материнская плата главный вопрос — включать или не включать EFI:

Во вкладке Процессор на хост-машине с более чем одним ядром и (или) гипертрейдингом появляется искушение отвести под виртуалку более одного процессора. И если в ней предполагается собирать образы дисков — есть прямой резон это сделать: при включении XZ-сжатия файловой системы многопроцессорность поддерживается на всю катушку:

В настройках экрана я оставляю всё без изменений, хотя для каких-то специальных задач, возможно, не помешает увеличить объём видеопамяти (виртуальной, к видеопамяти хост-машины она не имеет никакого отношения). А вот 3D-ускорение — включай, не включай, всё едино. По крайней мере, Cinnamon в любом случае будет запускаться в режиме программного рендеринга:

Раздел Носители — достаточно важен. Именно здесь следует подключить iso-образ, с которого планируется запуск виртуальной машины. И, если предполагается работа в Live-режиме, включить соответствующую опцию, дабы не повторять процедуру после рестарта:

Здесь же, создав второе устройство на IDE-контроллере, можно подключить и образ диска с гостевыми дополнениями:

Чтобы потом не повторяться, пользуясь случаем, скажу: вопреки не вполне членораздельным сообщениям на официальном сайте VB, скачивать этот образ специально не нужно: при установке VB с официального сайта (как «простым», так и «правильным») он автоматически появится в каталоге /usr/share/virtualbox/VBoxGuestAdditions.iso. А если использовать способ «хороший» — достаточно установить соответствующий пакет.

Если бы у нас имелся заблаговременно созданный VDI-образ — его можно было бы посадить на SATA-контроллер в дополнение к образовавшемуся при создании машины. Но и при отсутствии его можно создать мультидисковую конфигурацию.

Мультидисковые конфигурации

Стандартная процедура создания виртуальной машины в Virtualbox’е предполагает только однодисковую конфигурацию. Правда, в последующем, при её настройке, можно подключить и какой-либо существующий диск. Однако нередко многодисковая конфигурация машины требуется и на стадии инсталляции — например, при тестировании установки системы на softRAID, LVM или ZFS.

Сконфигурировать и многодисковую виртуальную машину также не сложно (как, впрочем, и всё в Virtualbox’е). Для этого надо зайти (через контекстное или главное меню) в пункт Настройки, там переместиться в секцию Носители и, щёлкнув мышью на строке Контроллер SATA, нажать на сине-зелёненькиую кнопочку с плюсом:

Следующий шаг очевиден — надо нажать кнопку Создать новый диск:

Далее второй диск создаётся точно как и первый — только с другим именем:

После чего можно полюбоваться результатом:

И даже заняться установкой системы — эта процедура в виртуалке ничем не отличается от реальной инсталляции, и потому описывать её здесь мы не будем. Заметим только, что, кроме обычной установки с iso-образа, виртуальную машину можно окучить и другими способами, о которых будет сказано несколько позже. А пока предположим, что некий дистрибутив в ней уже появился волшебным образом, и посмотрим, что можно настроить в нём.

«Гостевые дополнения»

Сразу после первого запуска виртуальная Matuntu представляет собой душераздирающее зрелище, ибо втиснута в окошко размером 640×480. Что, впрочем, не является её уникальной особенностью: именно с таким разрешением запускаются все Ubuntu’иды «в законе» (сама Ubuntu, Kubuntu, Xubuntu, Lubuntu). Почему — одному Ахурамазде ведомо: свежеустановленный Linux Mint, скажем, запускается в нормальном таком окошке, вроде 1280×1024. А вот виртуальная Ubuntu и сородичи запускаются в виде такого безобразия:

При умолчальном разрешении в такой виртуальной системе не то что работать не можется — смотреть не хочется. Поэтому первое действие после установки — подключение к виртуальной машине так называемых «гостевых дополнений» (Guest Additions).

Подготовительные действия

«Гостевые дополнения» — это ни что иное, как модули ядра гостевой конкретной машины, которые, прежде чем установиться, должны быть собраны. И, следовательно, для их установки потребуется сборочный инструментарий. В таких системах, как Matuntu и Cintu, полный его комплект имеется «из коробки». В более иных дистрибутивах, возможно, потребуется установка соответствующих пакетов.

В Ubuntu’идах (и, кажется, вообще в deb based дистрибутивах) самый простой способ добиться нужного результата — установка метапакета build-essential:

$ sudo apt install build-essential

Нечто аналогичное, насколько я помню, имеется и в rpm based дистрибутивах.

Установка дополнений

«Гостевые дополнения» пребывают внутри образа VBoxGuestAdditions.iso, который, как уже говорилось, устанавливается автоматически вместе с полной системой VB и находится в каталоге /usr/share/virtualbox/. О чём, впрочем, помнить не обязательно — достаточно зайти в меню окна запущенной виртуальной машины и выбрать там пункт Подключить образ диска Дополнений гостевой ОС:

На это последует предложение автоматического запуска, которое следует принять:

Как и согласиться с повторным предложением того же самого, после чего ввести пароль — и наблюдать сборку дополнительных модулей для ядра гостевой системы:

По завершении чего будет предложено закрыть терминальное окно нажатием Enter‘а. Затем следует перезагрузить виртуальную машину и заняться настройками экрана штатными средствами применяемого десктопа.

Сказанное выше относится ко всем Ubuntu’идам (в том числе и к Cintu с Matuntu), а также ко многим другим популярным дистрибутивам. Однако в общем случае образ с «гостевыми дополнениями» автоматически подключаться не обязан. И что делать, если «автоматика» не сработает? А на попытку запустить подключение «гостевого» диска последует сообщение, что сделать это не получилось. Или, паче того, никакого сообщения не будет вовсе, такое тоже случается…

… правда, ныне достаточно редко: с момента сочинения первой версии очерка про «гостевые дополнения» я довольно долго ждал момента, когда мне подвернётся дистрибутив, с которым «автоматический номер» не проходит.

И вот, наконец, подфартило: установив как-то в виртуалке очередную версию PCLinuxOS, я при попытке Подключить образ… через меню VirtualBox’а в ответ получил тишину. То есть не последовало даже сообщения о невозможности это сделать. Правда, сам по себе образ «гостевого» диска при этом в виртуалке смонтировался:

Что делать дальше — думаю, солдатская смекалка вам уже подсказала: открыть терминал, перейти в соответствующий каталог (а моём случае — в /media/VBOXADDITIONS_5.0.14_105127/) и, авторизовавшись там root’ом, запустить на исполнение нужный бинарник:

# ./VBoxLinuxAdditions.run

После чего дождаться окончания сборки соответствующих модулей и перезапустить виртуальную машину.

Разрешение виртуального экрана

Первое, что хочется сделать после установки «гостевых дополнений» — это создать комфортную для работы виртуальную среду. А это предполагает для начала подбор разрешения виртуального экрана, адекватного глазам применителя и его монитору.

Как уже говорилось, во многих дистрибутивах это можно сделать и без всякиз «дополнений». Однако общий случай — обращение к штатным средствам используемого десктопа. Например, в Cintu с её Cinnamon для этого вызываются Параметры системы, где в секции Оборудование отыскивается пункт Дисплей. И в нём из всего списка теоретически возможных разрешений выбирается нужное:

Для наших с Мануалом глаз и при нашем мониторе о 27 инчах, комфортным разрешением оказывается 16:9.

От «гостя» к хосту и обратно

Изменением разрешения виртуальной системы функции «гостевых дополнений» не ограничиваются. После этого начинает работать обмен данными между хостом и гостевой системой через буфер. Правда, не «мышиный» — не тот, в который текстовые фрагменты помещаются сразу по факту выделения их мышью. А тот, что условно можно назвать «Иксовым», то есть по комбинациям клавиш Control+C (копирование), Control+X (вырезание) и Control+V (вставка):

Появляется также возможность прямого перетаскивания файлов и каталогов из гостевой системы в «хозяйскую» и обратно:

В обоих случаях обмен может быть односторонним (из хоста к «гостю» и наоборот), или двунаправленным, как показано на скриншотах. Кроме того, соответствующие опции можно было включить и заранее, как говорилось в разделе об общих настройках. Однако заработают они только теперь. Да и то, только после перезапуска виртуальной машины.

Разделяемые каталоги

Наконец, дополнениями обеспечивается ещё один способ обмена данными между хост-машиной и гостевой системой — совместное использование каталогов. По этому вопросу в сети можно найти массу информации, которая… не то что неправильна, а, скажем так, несколько избыточна и часто не вполне членораздельна. Потому что на самом деле всё это дело не простое. А более чем простое.

Настройка разделяемых каталогов, доступных на чтение/запись пользователю как из хост-машины, так и из виртуалки, начинается с создания в первой каталога, которому предстоит стать разделяемым. Например, вот такого:

$ mkdir ~/vbox

Создаём в нём текстовый файл такого, например, содержания:

Это тестовый файл для настройки share-каталога в Virtualbox

После этого переходим в окно гостевой системы и в его меню выбираем Устройства -> Общие папки -> Настроить общие папки, чем вызывается такое окно:

Добавляем папку машины, найдя только что созданный каталог в файловой иерархии хоста и включив для него нужные опции:

Он появляется в списке папок машины:

Штатными средствами используемого в виртуалке десктопа добавляем пользователя в группу vboxsf. Или проделываем то же самое командой

$ sudo usermod -G vboxsf -a username

Перезагружаем гостевую систему, заходим в каталог /media/sf_vbox/, видим в нём наш текстовый файл и читаем его содержимое:

Забываем навсегда про те турусы на колёсах, которые выдали нам Гоша и Яша по поводу разделяемых каталогов в Virtualbox’е. Всё.

Внутри виртуалки

А теперь можно вернуться к вопросу — а откуда же взялось содержимое виртуальной машины, которое подвергалось всяческим настройкам? Первый ответ — напрашивающийся: это некий инсталлированный обычным образом дистрибутив, о чём и говорить-то скучно. Но есть и два других способа обретения системы в виртуальной машине. Первый из них — воспользоваться одним из готовых образов.

Готовые VDI-образы

Майнтайнеры некоторых дистрибутивов, наряду с iso-образами и, иногда, образами для записи на флешки/карты, изготовляют и образы, предназначенные для прямого запуска в виртуальных машинах — благо, из таковых широко распространены только две, VMWare и VirtualBox (о гипервизорах «ядерного» уровня здесь речь не идёт, перед ними ставятся совсем другие задачи). Да вот беда — дистрибутивы, интересующие нас с Мануалом, почти никогда в их число не попадали.

Однако при изучении вопроса всё оказалось не так уж печально: в процессе поиска «виртуализованных» образов я натолкнулся на сайт OSBoxes, содержащий коллекцию оных для многих популярных и просто интересных дистрибутивов, в форматах как VMWare, так и VirtualBox’а. Правда, в момент сочинения этих строк при заходе на сайта следует сообщение, что

Срок действия его сертификата безопасности истёк 3 дня назад.

Но это, надеюсь, препятствие временное, а пока легко обходится. И никак не помешает нам с Мануалом выпить ознакомиться со списком — разумеется, вторым. Приводить его полностью не буду — заинтересованные лица могут ознакомиться с ним сами. Отмечу только, что из интересующих нас с Манулом там не обнаружилось только Maui. Всё остальное, от Antergos’а до Xubuntu, место быть имело, хотя и не всегда самых последних версий — но зато часто и многих предшествующих.

Большинство образов — в сборках для обеих архитектур, 32- и 64-битной. Разумеется, если первая ещё поддерживается майнтайнерами дистрибутива. Так, Ubuntu 17.10 Artful имеется только в 64-битном исполнении. Тогда как все более ранние релизы, начиная с Ubuntu 12.04 Precise Pangolin, представлены обоими вариантам.

Образы для VirtualBox — стандартные файлы *.vdi, сжатые компрессором 7z. Для VMWare это также 7z-архиавы, объединяющие в себе всё изобилие файлов формата этой виртуальной машины (честно говоря, уже не помню, как он устроен, да и речи о них дальше не будет).

Обращение с образами для VirtualBox’а очень простое. Архив распаковывается в подходящий каталог (тот, что предназначен для хранения виртуальных дисков вообще, у меня — /home/data/vbox). Далее виртуальная машина создаётся обычным образом — задаётся её имя и то, что в VirtualBox’е называют «типом» и «версией», например, так:

На самом деле, говорилось выше, «тип» и «версия» могут быть любыми. Размер памяти задаётся следом — я отвожу под это дело обычно 2 или 4 ГБ. А вот диск у нас уже создан трудами работников OSBoxes, надо только отметить соответствующий пункт и выбрать нужный образ:

После чего новая виртуальная машина оказывается в списке виртуалок в виде, готовм к немедленному использованию. И, поглядев на несколько интересующих нас систем через призму OSBoxes, я и кот Мануал с полной ответственностью можем рекомендовать этот сайт любителям поэкспериментировать с дистрибутивами без риска для своего рабочего окружения и лишних трудозатрат на их установку.

Клонирование виртуальных машин

Второй способ обрести операционный «наполнитель» виртуальной машины без тоскливой инсталляции — это клонирование машины, уже созданной, настроенной и несущей на себе работоспособную ОС, также сконфигурированную должным образом. Это — задача, частая при создании и тестировании собственных индивидуализированных сборок. Благо, в Virtualbox’е она выполняется не просто, а очень просто. Соответствующая функция вызывается либо из главного меню: Машина –> Клонировать, либо из контекстного меню по ПКМ:

Очевидно, что в любом случае клонируемая машина должна быть выключена — в работающей машине указанный пункт активизирован не будет.

В появившемся окне будет предложено задать имя новой машины — по умолчанию это будет Клон [orig-name], однако ясно, что оно может быть любым, кроме совпадающего с исходным:

Нужно ли генерировать новые MAC-адреса для сетевых устройств — зависит от задачи. Для тех целей, в которых я использую Virtualbox (тестирование и модификация собственных образов) — не нужно.

Далее предлагается определить с типом клонирования — полным или связным. Чем они различаются — очевидно из поясняющего текста. Для моих целей подходит только полное клонирование:

Затем начинается процесс клонирования. Длительность его зависит от величины VDI-образа и быстродействия носителя. Здесь, как нигде, сказывается превосходство SSD дан HDD в быстродействии — не на порядок, конечно, во что можно было бы верить (если верить формальным характеристикам), но в разы — точно.

По завершении клонирования никакого сообщения не выводится — просто в списке виртуальных машин появляется имя, соответствующее клону:

В примере можно видеть cintu-ts — собранную «вручную» систему-матку из mini.iso Ubuntu 16.04.1 и Cinnamon из репозитория Tsvetko, без всяких дополнительных компонентов, и два её (пока) точных клона, которым со временем предстоит стать mini- и midi-редакциями Cintu 16.04.2, соответственно. Именно таким способом мы с котом Мануалом собираем все редакции нашей любимой системы, отличные от минимальной.

Добавить комментарий