Что касается установки — то в нашем образе Xubuntu VirtualBox уже есть. Можно установить его либо через репозиторий, либо через deb пекет (рассматриваю семейство ubuntu).

Добавляем репозиторий:

sudo wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add —
sudo wget -q https://www.virtualbox.org/download/oracle_vbox.asc -O- | sudo apt-key add —
sudo add-apt-repository «deb http://download.virtualbox.org/virtualbox/debian bionic contrib»
sudo apt-get update

Теперь собственно установка:

#Установка VirtualBox
sudo apt install virtualbox-6.0 -y

Теперь нужно кое что настроить у пользователя, добавить его в группы:

#Добавляем нашего пользователя хостовой машины в группу vboxusers, что бы он мог их запускать
sudo adduser user vboxusers

#Добавляем нашего пользователя хостовой машины в группу disk, что бы пользователь мог подключать реальные диски системы к виртуальной машине
sudo adduser user disk

#А это нужно уже в виртуальной машине, если она основана на linux, пользователя user добавить в группу vboxsf, что бы он мог работать с передаваемыми папками из хостовой машины в виртуальную
sudo adduser user vboxsf

Теперь рассмотрим вопрос о том как подключить реальные диски к виртуальной машине. Начиная с версии Ubuntu 16.04 стала наблюдаться проблема изменения имен дисков при перезагрузке системы, т.е. раньше диск был, например sdb, после перезагрузки он мог поменять свое имя, скажем на sdc. Поэтому создавать ссылку на диск по его имени я думаю лучше не делать. В linux существует обозначение дисков по uuid, но так обозначаются только партиции диска, а нам нужен диск полностью. Для дисков (и для партиций то же) существует определение по id, для того что бы получить полный список этой нумерации, нужно ввести команду:

ls /dev/disk/by-id/

и мы получим список (что-то вроде):

ata-Samsung_SSD_850_PRO_256GB_S1SUNWAFA00295J
ata-Samsung_SSD_850_PRO_256GB_S1SUNWAFA00295J-part1
ata-Samsung_SSD_850_PRO_256GB_S1SUNWAFA00295J-part2
ata-Samsung_SSD_850_PRO_256GB_S1SUNWAFA00295J-part5
ata-Samsung_SSD_850_PRO_256GB_S1SUNWAFA00295J-part6
ata-Samsung_SSD_850_PRO_256GB_S1SUNWAFA00295J-part7
ata-ST3000DM001-9YN166_W1F15WWL
ata-ST3000DM001-9YN166_W1F15WWL-part1
ata-ST31500541AS_9XW0A8B7
ata-ST31500541AS_9XW0A8B7-part1
ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N1LX74T3
ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N1LX74T3-part1
nvme-eui.0025385471b1e089
nvme-eui.0025385471b1e089-part1
nvme-Samsung_SSD_960_EVO_500GB_S3EUNX0J407558P
nvme-Samsung_SSD_960_EVO_500GB_S3EUNX0J407558P-part1
wwn-0x5000c5001fd80852
wwn-0x5000c5001fd80852-part1
wwn-0x5000c5005363aac7
wwn-0x5000c5005363aac7-part1
wwn-0x50014ee261bc91d0
wwn-0x50014ee261bc91d0-part1
wwn-0x500253887003d196
wwn-0x500253887003d196-part1
wwn-0x500253887003d196-part2
wwn-0x500253887003d196-part5
wwn-0x500253887003d196-part6
wwn-0x500253887003d196-part7

для создания диска, указывающего на физический, даём команду:

VBoxManage internalcommands createrawvmdk -filename drive.vmdk -rawdisk /dev/disk/by-id/nvme-Samsung_SSD_960_EVO_500GB_S3EUNX0J407558P

и получаем файл drive.vmdk, который затем можно будет использовать в виртуальной машине.

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

выбираем нужный нам диск и дважды по нему щелкаем мышью

После чего задаем тип — «сквозной», и применить.

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

нажимаем кнопку создать и получаем новую виртуальную сеть:

Можно настроить параметры сети, если это нужно. Таких сетей при необходимости можно создать несколько, тем самым можно сервера разграничить друг относительно друга.

Далее в виртуальной машине заходим на вкладку сеть и

в качестве типа подключения выбираем «Виртуальный адаптер хоста», а в имени выбираем ту сеть к которой мы собрались цеплять наш сервер.

Теперь только осталось настроить файервол на хостовой машине, но это позже.

Что касается автозапуска виртуальных машин (как сервиса), то тут начиная с версии ubuntu 16.04 была большая проблема, которая в основном была связана с правильным выключением. Дело в том, что начиная с версии ubuntu 16.04 система стала использовать systemd для запуска служб. Раньше эта часть работала проще и была полностью отработана. А вот с новой системой systemd возникла проблема, которая связана просто с тем, что ни кто пока её не освоил полностью. И только совсем недавно я нашел в итернете статью , где человек наконец-то справился с проблемой корректной остановки виртуальных серверов.

Вот в общем-то суть:

Создаем файл запуска наших виртуальных машин как сервиса:

sudo mousepad /etc/systemd/system/vm_autostart@.service

[Unit]
Description=VM %I
After=network.target vboxdrv.service
Before=runlevel2.target shutdown.target

[Service]
User=user
Group=vboxusers
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes

ExecStart=/usr/bin/VBoxManage startvm %I —type headless
ExecStop=/usr/bin/VBoxManage controlvm %I savestate

[Install]
WantedBy=multi-user.target

нужно заменить пользователя user на Вашего пользователя. Затем обновляем сервис systemd

#Обновляем сервис systemd
sudo systemctl daemon-reload

Теперь можно добавлять или удалять виртуальную машину в автозагрузку:

# Для добавления виртуальной машины в автозагрузку (в место vm_name подставляем имя нашей виртуальной машины)
sudo systemctl enable vm_autostart@vm_name

# Для удаления виртуальной машины из автозагрузки (в место vm_name подставляем имя нашей виртуальной машины)
sudo systemctl disable vm_autostart@vm_name

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

# Для проверки статуса виртуальной машины vm_name
sudo systemctl status vm_autostart@vm_name

# Для старта виртуальной машины vm_name
sudo systemctl start vm_autostart@vm_name

# Для остановки виртуальной машины vm_name
sudo systemctl stop vm_autostart@vm_name

Тут есть особенность, если виртуальная машина была запущена, как сервис и вы, зашли на пример на нее через RDP и дали команду на выключение, то хоть виртуальная машина и выключится, но непосредственно сервис, который ее стартовал будет продолжать работать. И если Вы дадите команду на запуск сервиса для этой машины, то он не как не отработает, ведь для системы он все еще работает. Так что в этом случае приходится сначала дать команду на останов сервиса, а уж потом давать команду на запуск виртуальной машины. Ну в общем то это не проблема.

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

Файл старта виртуальной машины (vm_start.sh):

#Сначала на всякий случай останавливаем сервис
sudo systemctl stop vm_autostart@vm_name
#А теперь стартуем
sudo systemctl start vm_autostart@vm_name

Файл остановки сервиса виртуальной машина (vm_stop.sh):

#Останавливаем сервис виртуальной машины
sudo systemctl stop vm_autostart@vm_name

И наконец мне иногда, для создания копии данных с дисков виртуальной машины, нужно именно корректно выключить ее, а не сохранять состояние. Для этого есть файл (vm_stop_acpi.sh):

#Даем команду на выключение виртуальной машины
sudo -H -u user /usr/bin/VBoxManage controlvm «vm_name» acpipowerbutton

Здесь не забываем менять user на имя пользователя от которого виртуальная машина запускается, ну и конечно имя виртаульной машины vm_name, на нашу.