% cbsd bconstruct-tui
			% cbsd cloudinit
			% cbsd bcreate
		

Описание:

FYI: Cloud-init было продемонстрировано в демо:

• Bhyve unattended installation with CBSD: PXE and cloud-init
• NetBSD cloud image for bhyve demo
• Microsoft Windows Server 2016 cloud image via CBSD/cloudbase demo

Команда bconfig, bconstruct-tui, cloudinit

Использование cloud-init в настоящее время является методом де-факто по быстрому разворачиванию виртуальных инстансов в различных облачных окружениях (OpenNebula, OpenStack, Amazon AWS, Microsoft Azure, Digital Ocean ..)

Начиная с версии 12.0.6, CBSD поддерживает конфигурирование cloud-образов посредством функциональности cloud-init.

Как это работает:

На данный момент CBSD способна конфигурировать инстанс cloud-init методом NoCloud data source. Это означает, что виртуальная машина получает все настройки через файловую систему fat32/msdos_fs или cd9660 подключенного локального носителя. Задача CBSD - сгенерировать и подключить образ к виртуальной машине в момент ее старта.

В качестве признака, что CBSD должна активировать функции cloud-init является факт наличия каталога cloud-init в системном каталоге индивидуальной виртуальной машины: ${jailsysdir}/${jname}/cloud-init/. Помимо признака активации cloud-init, этот каталог выступает хранилищем конфигурации в формате и иерархии cloud-init, которое будет предоставлено виртуальной машине. Т.е, если рабочий каталог CBSD (cbsd_workdir) инициализирован в /usr/jails каталог, для виртуальной машины с именем vm1 признак включения и настройки для конфигурирования cloud-init должны быть расположены в каталоге /usr/jails/jails-system/vm1/cloud-init.

За форматом конфигурации и возможностями конфигуририрования cloud-init обратитесь к соответствующей официальной информацией проекта.

Кроме этого, в дистрибутив CBSD входит пример простой конфигурации, которую вы можете посмотреть в каталоге /usr/local/cbsd/share/examples/cloud-init и использовать в качестве старта к построению своих облачных инсталляций.

Дополнительно, в конфигуратор виртуальной машины CBSD через bconstruct-tui добавлен хелпер для cloud-init, реализующий конфигурирование минимально необходимой конфигурации для получения рабочей виртуальной машины из cloud образа. Для этого, можете использовать несколько преднастроенных профилей с префиксом cloud-

Их количество со временем будет увеличиваться. Кроме этого, вы можете самостоятельно собрать и выслать профиль через публичный GitHub репозиторий: https://github.com/cbsd/cbsd-vmprofile. Это профили, которые использует CBSD.

Кроме этого, если вы заметили что скорость получения образов медленная (CBSD использует свои собственные зеркала для дублирования образов, на которые ссылаются профили CBSD) и вы имеете желание помочь проекту, ознакомьтесь с информацией как поднять свое собственное зеркало: fetch_iso. Вы можете прислать нам ссылку на ваше зеркало (или добавить его самостоятельно через https://github.com/cbsd/cbsd-vmprofile и вы повысите качество для своего региона.

Примечение: в CBSD версии 12.0.8, параметр ci_user_pubkey_user может принимать не только сам ssh pubkey, но и путь к authorized_keys. Кроме этого, если он установлен в значение .ssh/authorized_keys (значение по-умолчанию с 12.0.8+), это означает что будет использоваться ssh ключ вашей ноды ( ~cbsd/.ssh ). Обратите внимание на то, как выглядит blogin.conf: если виртуальная машина создана через cloud-init, при команде cbsd blogin будет использоваться кастомная команда с использованием ключа ноды и пользователя, который вы укажете в качестве ci_user_add. Таким образом, запуская виртуальную машину из cloud-init, вы можете сразу же заходить в нее через ssh используя команду cbsd blogin.

bcreate from args

Если вы не любите диалоговые окна, запустить виртуальную машину из cloud-образа можно максимально быстрым способом через bcreate, указав соответствующие параметры конфигурации, например:

		cbsd bcreate jname=centos1 imgsize=20g vm_cpus=1 vm_ram=4g vm_os_type=linux vm_os_profile=cloud-CentOS-7-x86_64 ci_jname=centos1 ci_fqdn=centos1.my.domain ci_ip4_addr=DHCP ci_gw4=10.0.0.1 runasap=1

		cbsd bcreate jname=centos2 imgsize=40g vm_cpus=4 vm_ram=8g vm_os_type=linux vm_os_profile=cloud-CentOS-8-x86_64 ci_jname=centos2 ci_fqdn=centos2.my.domain ci_ip4_addr=192.168.0.10/24 ci_gw4=192.168.0.1 runasap=1
		

обратите внимание на ci_ip4_addr и ci_gw4 - при использовании значения DHCP, убедитесь что вы выбрали корректный nodeippool диапазон адресов, а также что ci_gw4 указывает на рабочий IP шлюза в этой подсети.

Пример использования

Профили cloud-образов находятся в меню vm_os_profile. Выберете этот пункт в основном меню:

Внизу списка вы увидите область с Cloud images, если эти профили созданы в CBSD для выбранного семейства ОС:

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

Дальнейшая настройка и запуск cloud-based виртуальной машины ничем не отличается от основного метода. Желаем удачи!

			% cbsd bconfig
			% cbsd bset
		

Описание:

Конфигурирование параметров виртуальной машины

Каждая виртуальная машина CBSD хранит настройки в SQLite3 базе. Для изменения настроек виртуальной машины может служить команда cbsd bconfig, запускающая TUI меню для изменения основных параметров.

Описание соответствующих параметров вы можете прочитать на странице Создание VM через dialog меню

Вы можете написать собственные сценарии, которые будут выполняться внутри клетки и в мастер-хосте при запуске и останове клетки. Для этого, в системном каталоге клетки ( $workdir/jails-system/$jname/ ) имеются следующие каталоги:

• master_poststart.d - скрипты для отработки в мастер-хосте после того, как jail запустится (будьте аккуратны, поскольку скрипты выполняются не в окружении)
• master_poststop.d - скрипты для отработки в мастер-хосте после того, как jail остановится (будьте аккуратны, поскольку скрипты выполняются не в окружении)
• master_prestart.d - скрипты для отработки в мастер-хосте до того, как jail запустится (будьте аккуратны, поскольку скрипты выполняются не в окружении)
• master_prestop.d - скрипты для отработки в мастер-хосте после того, как jail остановится (будьте аккуратны, поскольку скрипты выполняются не в окружении)
• start.d - скрипты для отработки внутри клетки при ее запуске. Аналог параметра exec.start оригинального jail.conf
• stop.d - скрипты для отработки внутри клетки при ее останове. Аналог параметра exec.stop оригинального jail.conf
• remove.d - (с версии CBSD 11.0.10) скрипты отработают при удалении окружения

Писать скрипты для master_\* каталогов может быть полезно, если при старте-останове клеток вам необходимо выполнить какой-то действие не связанное с самим окружением в клетке - например, создать ZFS снапшот, поставить счетчики в IPFW и тп

В скриптах вы можете использовать переменные CBSD, такие как $jname, $path, $data, $ip4_addr, например, поместив такой скрипт (с правами на выполнение) в /usr/jails/jails-system/jail1/master_poststart.d/notify.sh:

		#!/bin/sh
		echo "Jail $jname started with $ip4_addr IP and placed on $path path" | mail -s "$jname started" root@example.net
		

Вы будете получать уведомление по факту запуска клетки на email: root@example.net

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

В качестве примера использования, посмотрите статью Пример использования CBSD/bhyve и ISC-DHCPD (посредством pre/post хуков, обслуживаем IP адреса в bhyve)

			% cbsd bconfig
			% cbsd bset
			% cbsd bconstruct-tui
		

Описание:

Конфигурирование поведения виртуальной машины по exit codes

В CBSD начиная с версии 12.0.4 добавлен регулятор поведения, зависимый от кода завершения гипервизора виртуальной машины

Вы можете переназначить это поведение как через глобальный профиль (bhyve-default-default.conf), так и индивидуально для каждой виртуальной машины

Для редактирования, вы можете использовать bset или соответствующий пункт в меню bconstruct-tui или bconfig

Возможные exit codes, которые вы можете использовать:

• on_poweroff: the content of this element specifies the action to take when the guest requests a poweroff
• on_reboot: the content of this element specifies the action to take when the guest requests a reboot
• on_crash: the content of this element specifies the action to take when the guest crashes

Возможные поведения, которые вы можете переназначить для каждого кода:

• destroy: the domain will be terminated completely and all resources released
• restart: the domain will be terminated and then restarted with the same configuration
• preserve: the domain will be terminated and its resource preserved to allow analysis (WIP, at the moment: XEN only)
• rename-restart: the domain will be terminated and then restarted with a new name (WIP, at the moment: XEN only)

			% cbsd bhyve-dsk mode=modify dsk_sectorsize=512/4096 jname='*'
		

Описание:

Для работы с виртуальными дисками bhyve служит команда cbsd bhyve-dsk, либо вы можете воспользоваться диалоговым интерфейсом cbsd bconfig с подменю bhyvedsk

список дисков

Для вывода списка виртуальных дисков используйте:

		% cbsd bhyve-dsk mode=list
		

Вы можете регулировать объем информации через аргументы header=0 и display=

добавление дисков

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

		% cbsd bhyve-dsk mode=attach dsk_controller=XXX dsk_size=YYY
		

, где:

• XXX - тип контроллера: virtio-blk или ahci-hd
• YYY - желаемый объем диска, например: 10g. Пример команды, которая создаст и подключит новый виртуальный диск к виртуальной машине freebsd1:

  				% cbsd bhyve-dsk mode=attach jname=freebsd1 dsk_controller=virtio-blk dsk_size=10g
  			

отключение и удаление дисков

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

		% cbsd bhyve-dsk mode=detach dsk_controller=XXX dsk_path=YYY
		

, где:

• XXX - тип контроллера диска, который отключаете. Должен совпадать с тем, что вы видите по mode=list
• YYY - имя диска, который отключаете. Должен совпадать с тем, что вы видите по mode=list

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

Если же вы хотите отключить и при этом уничтожить виртуальный диск, используйте команду:

		% cbsd bhyve-dsk mode=remove dsk_controller=XXX dsk_path=YYY
		

, где:

• XXX - тип контроллера диска, который удаляете. Должен совпадать с тем, что вы видите по mode=list
• YYY - имя диска, который удаляете. Должен совпадать с тем, что вы видите по mode=list

модификация свойств/параметров виртуальных дисков

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

		% cbsd bhyve-dsk mode=modify jname=ZZZ dsk_controller=XXX dsk_path_YYY [param=value]
		

, где:

• ZZZ - имя виртуальной машины
• XXX - тип контроллера диска, который модифицируете. Должен совпадать с тем, что вы видите по mode=list
• YYY - имя диска, который модифицируете. Должен совпадать с тем, что вы видите по mode=list

В зависимости от версии CBSD, типа инсталляции и используемой файловой системы, набор параметров которыми вы можете оперировать может отличаться.

Основные параметры, которые доступны на любой файловой системе:

• bootable - установить диск в качестве загрузочного, например: 1
• dsk_sectorsize - изменить размер сектора диска, например: 512,512/4096,4096 [*]
• dsk_size - увеличить объем виртуального диска, например: 30g (установить объем в 30Гб ),+10g (увеличить существующий объем диска на 10 Гб) [**]

___

[*]
- выбирайте корректный sectorsize до форматирования диска, поскольку данные, записанные при одном значении sectorsize будут недоступны при другом.
- если вы указываете значение через '/', цифра слева означает логический sectorsize, значение справа - физический. Наиболее предпочительное значение: 512/4096 или 4096.
- вы можете переназначить значение по-умолчанию в CBSD глобально через bhyve-default-default.conf или в индивидуальном профиле виртуальной машины.

[**]
- виртуальные машины, использующие cloud-init, выполнят resize/увеличение диска в госте автоматически. Если вы не используете cloud-init, помимо увеличения физического носителя, вам необходимо будет расширить файловую систему в госте самостоятельно через соответствующие утилиты.

кастомизация ZFS/zvol properties

Файловая система ZFS имеет богатый выбор возможностей по настройке и оптимизации. Поскольку CBSD интенсивно работает с автоматическим созданием ZFS файловых систем и ZVOL томов в большом количестве и самых различных инсталляциях, вы можете захотеть изменять настройки, которые будут использованы CBSD при этих операциях.

Вы можете изменять параметры по-умолчанию для ZFS датасетов и ZVOL томов через конфигурационный файл zfs.conf. Например, вы можете включить компрессию для GOLD-образов cloud-init, изменить recordsize, volblockmodesize и тд.

			% cbsd cpu-topology
			% cbsd vm-cpu-topology vm-cpu-topology-tui
			% cbsd vm-cpu-topology-tui
		

Описание:

Конфигурирование и просмотр топологии CPU виртуальной машины bhyve.

Регулировка топологии CPU виртуальных машин может производится для повышения производительности и оптимизации вычислительных операций, так и в различных задачах, связанных с тестированием.

При исполнении виртуальных машин важно понимать, что с точки зрения хостера, виртуальные процессоры виртуальной машины являются обычными процессами (в случае с bhyve, отдельный vcpu является тредом в хостер системе).

Предполагается, что пользователь имеет минимальное представление об устройстве CPU, памяти и NUMA-доменов. Кроме того, для эффективной настройки важно понимать тип деятельности и сервисов ОС конкретного гостя. Наиболее важным является понимание работы L1,L2 и L3 кешей и работа процессора с определенными блоками памяти.

Напомним, что L1,L2 кеш - это кеш для одного ядра, тогда как L3 и выше - это кеш на весь процессор (сокет).

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

К примеру, имея 8 ядер, вы можете их сконфигурировать как:

• 1 сокет (виртуальный микропроцессор) по 8 ядер, без гипертрединга ( FreeBSD/SMP: 1 package(s) x 8 core(s) )
• 1 сокет по 4 ядра, но с гипертредингом ( FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads)
• 2 сокета по 2 ядра и гипертредингом ( FreeBSD/SMP: 2 package(s) x 2 core(s) x 2 hardware threads)
• 4 сокета по 2 ядра каждый ( FreeBSD/SMP: 4 package(s) x 2 core(s) )
• и т.д.

Как таковая конфигурация топологии виртуальной машины никак не сказывается быстродействии самой виртуальной машины:

Данные конфигурации становятся важными, совместно с настройками привязывания ядер виртуальной машины к конкретной группе ядер физического сервера ( set_affinity, cpu-pinning ), о чем будет рассказано отдельно. Цель же данной статьи - рассмотреть возможности bhyve и работа с его конфигурацией через CBSD.

Для просмотра текущей топологии со стороны хостера, служит команда cbsd cpu-topology. Помимо информации о текущей системе, вы сможете увидеть схематическое представление сокетов и ядер, которые обслуживают виртуальные окружения

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

Сокет - это непосредственно физический процессор (package) на вашей материнской плате. Если процессор поддерживат гипер-трединг (и он включен), виртуальные ядра будут помечены как THR

Вы можете создать любое количество профилей для топологии. Просмотреть их список можно по команде vm-cpu-topology:

Удалять или добавлять новые вы можете через TUI интерфейс команды vm-cpu-topology-tui

Имена профилей должны быть уникальные и применение той или иной топологии выполняется через команду bset, bconfig. А также, выбор топологий будет доступен при создании виртуальной машины в bconstruct-tui:

			% cbsd bstart jname=vm1
			% cbsd bstart vm1 vm2 ... vmX

			% cbsd bstop jname=vm1
			% cbsd bstop vm1 vm2 ... vmX
		

команда bstop шлет SIGTERM сигнал виртуальной машины для мягкого завершения работы. В случае, если виртуальная машина не перезагрузится в течении hard_timeout (по-умолчанию: 30) секунд, CBSD завершит процесс принудительно. Используйте аргументы noacpi=1 для моментального выключения (без посылки SIGTERM) виртуального окружения или hard_timeout=X для изменения интервала ожидания мягкого выключения

Запуск виртуальных машин происходит при запуске cbsd/сервера автоматически, если параметр astart (auto-start) соответствующей VM установлен в 1. Изменить этот параметр можно через cbsd bconfig или cbsd bset. При остановке сервера или сервиса cbsdd, автоматически останавливаются все запущенные виртуальные машины. Запуск VM вручную производится командой:

			% cbsd bstart jname=vm1
		

либо

			% cbsd bstart vm1
		

либо

			% cbsd bstart vm1 vm2 vm3 ..
		

(для запуска нескольких виртуальных машин одной командой)

Если команда bstart/bstop запускается без аргументов, будет выведен список всех неактивных/активных машин для интерактивного выбора

Если у вас соответствующая сборка FreeBSD и CBSD не ниже 11.2.0, вы можете воспользоваться мгновенным запуском виртуальной машины из чекпоинта, минуя стадию загрузки. Для этого, используйте аргумент checkpoint= с именем чекпоинта

			% cbsd bhyve-ppt
		

Описание:

CBSD позволяет сконфигурировать аргументы bhyve для пробрасывания устройств внутрь гостя, если ваше оборудование это поддерживает

Внимание! Ознакомьтесь с информацией на странице FreeBSD Wiki: bhyve pci_passthru

Для того, чтобы пометить устройство как пробрасываемое, вы должны поместить в /boot/loader.conf параметр, как написано в странице wiki, например:

		pptdevs="2/0/0"
		

Если необходимо указать несколько устройств:

		pptdevs="2/0/0 1/2/6 4/9/0"
		

Обратите внимание, что при использовании pptdevs, vmm модуль должен быть проинициализирован на этапе /boot/loader.conf, чтобы подхватить эти записи.

Если вы загружаете vmm уже после загрузки ядра, например через kldload, то pptdevs не сработает.

Далее, после загрузки системы убедитесь, что CBSD видит маркированные устройства. По команде 'cbsd bhyve-ppt mode=list' вы должны увидете ваши устройства:

% cbsd bhyve-ppt mode=list
5/1/0 :  DGE-528T Gigabit Ethernet Adapter :  D-Link System Inc : -
0/31/3 :  7 Series/C216 Chipset Family SMBus Controller :  Intel Corporation : -
		

Теперь, используя ppt устройство ( 5/1/0 или 0/31/3 в этом примере) вы можете подключить или отключить это устройство к определенной виртуальной машине:

		cbsd bhyve-ppt mode=attach jname=vmname
		

		cbsd bhyve-ppt mode=detach jname=vmname
		

Работа bhyve/CBSD протестирована в том числе с технологией SR-IOV

В этом случае, устройства ppt ничем не отличаются от тех, которые вы конфигурируете с помощью pptdevs

% cbsd bhyve-ppt mode=list
1/0/131 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/133 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/135 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/137 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/139 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/141 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/143 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/145 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/147 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/149 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/151 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/153 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/155 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/157 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/159 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/161 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/163 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/165 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
1/0/167 : X540 Ethernet Controller Virtual Function : Intel Corporation : -
		

Каждую VF (Virtual Function) вы можете подключить к любой виртуальной машине через описанную выше: cbsd bhyve-ppt mode=attach

			% cbsd bhyve-p9shares
		

Описание:

Эта возможность доступна в CBSD версии 11.1.7 и выше.

Общие папки служат для обмена файлами между виртуальными машинами или между виртуальной машиной и хост системой.

Данная возможность работает только если ваша система поддерживает VirtFS/P9 и bhyve поддерживает virtio-p9.

На момент написания этой статьи (2017-10-01), такой системой является TrueOS, тогда как для FreeBSD подготовлен патч и загружен в Phabricator: D10335

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

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

Для просмотра существующих shared folders, используется команда:

% cbsd bhyve-p9shares mode=list

JNAME    P9PATH       P9DEVICE
f111     /root        root
debian1  /tmp/share1  share1
debian1  /tmp/share2  share2
		

Или для индивидуальной виртуальной машины:

% cbsd bhyve-p9shares mode=list jname=XXX
		

Для включения shared folders для конкретной виртуальной машины, используйте mode=attach и аргументы p9path,p9device для задания каталога и наименования shared, например:

% cbsd bhyve-p9shares mode=attach p9device=share1 p9path=/tmp/share1 jname=debian1
		

Для отключения shared folders для конкретной виртуальной машины, используйте mode=detach и аргумент p9device.

После запуска виртуальной машины, подключить shared folders можно разными способами, в зависимости от конкретного дистрибутива. Например в Debian-based дистрибутиве Linux это осуществляется через пакет 9mount и эту команду:

% mount -t 9p -o trans=virtio sharename /mnt
		

или:

% 9mount -i 'virtio!sharename' /mnt
		

bhyve shared folders via VirtFS/virtio-p9:

% cbsd jls display=jname,b_order
		

Описание:

Может возникнуть ситуации, когда запуск одного из jail/vm желателен до запуска остальных. Например таковыми могут быть клетки с критичными сервисами как базы данных SQL или LDAP сервера.

В этом случае, вы можете отредактировать Boot Order (b_order в настройках окружений)

По-умолчанию, все окружения создаются с индексом b_order равным 10 (задается в профиле, что вы можете изменить)

Если вам необходимо, чтобы jail2 стартовал раньше jail1, его индекс b_order должен быть ниже чем у второй клетки.

Вы можете сделать выборку по текущей настройке через команду jls:

% cbsd jls display=jname,b_order
JNAME    B_ORDER
firefly  3
jail1    10
kde4     1
kdeold   9
spicy2   2
test     2
	

Данный вывод изначает, что клетка с именем kde4 запустится самой первой. Самой последней будет запущена клетка jail1

Также, вы можете просмотреть очередность запуска клеток через команду jorder

% cbsd jorder
	

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

Для редактирования очередности используейте комаду jset или TUI-редактор jorder-tui

Для редактирования bhyve очередности, используйте команды: border, border-tui

			% cbsd bremove jail1 jail2 ..
		

Описание:

Удаление виртуальной машины затрагивает все файлы, так или иначе связанные с виртуальной машиной:

• a) каталог или ZFS файловую систему с образами виртуальной машины
• b) статистику и описание виртуальной машины
• c) снапшоты, если были

В случае, если bremove запускается на работающую виртуальную машину, работа гостевой ОС будет автоматически прервана.

Пример:

			% cbsd bremove redhat1
		

			% cbsd brename
		

Описание:

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

• old — старое имя VM
• new — новое имя VM

Пример (переименовывание виртуальной машины debian1 в debian50:

			% cbsd brename old=debian1 new=debian50
		

			% cbsd bls
		

Выводит список виртуальных машин на локальной ноде или всех добавленных нодах. Через аргумент display можно указать конкретные поля для выборки данных. Если display не указан, используется значение, заданное в файле $workdir/etc/defaults/jls.conf, которое вы можете изменить на свое усмотрение через $workdir/etc/bls.conf

Все возможные параметры для выборок описаны в файле $workdir/share/local-bhyve.schema

• JNAME — Имя виртуальной машины
• VM_RAM — объем выделенной оперативной памяти, в Мб
• VM_CPUS — Количество виртуальных ядер CPU
• VM_OS_TYPE — тип гостевой ОС
• PATH — каталог, в котором расположены образы жестких дисков виртуальной машины
• STATUS — состояние виртуальной машины

В случае, если к локальному серверу добавлены RSA/DSA ключи удаленных нод, можно вывести все виртуальные машины в ферме через

			% cbsd bls alljails=1
		

или

			% cbsd bls alljails=1 shownode=1
		

для вывода имени ноды, где размещается данная виртуальная машина.

Пример:

			% cbsd bls
		

			% cbsd bconfig
			% cbsd bconstruct-tui
		

Описание:

На данный момент, VNC возможно только при запуске виртуальных машин через UEFI режим

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

значение vm_efi установлено в uefi:

Если вы хотите зафиксировать VNC порт, используете пункт меню vm_vnc_port

Если vm_vnc_port принимает значение 0 - CBSD автоматически найдет первый свободный порт для VNC соединения

Если vm_vnc_port принимает значение 1 - CBSD не будет открывать порт для VNC

Если vm_vnc_port любое другое числовое значение, например 5905 - CBSD будет использовать данный порт VNC для виртуальной машины всегда

Начиная с версии CBSD 11.1.0, соединение по VNC требует пароля, который задан в конфигурационном файле vnc.conf (~cbsd/etc/defaults/vnc.conf):

Для того, чтобы изменить (или убрать) пароль, продублируйте собственное значение default_vnc_password через файл ~cbsd/etc/vnc.conf:

			% echo default_vnc_password='test' > ~cbsd/etc/vnc.conf
		

Если default_vnc_password принимает пустое значение, пароль на VNC задан не будет.

Обратите внимание, что по-умолчанию, порт VNC открывается на loopback адресе 127.0.0.1

Это сделано из соображений безопасности, иначе любой пользователь сможет подсоединиться на VNC вывод вашей виртуальной машины

Для соединения с VNC на удаленном сервере, используйте SSH туннели, либо прокси, которые защищены сертификатом или паролем

Если же вы хотите работать с VNC напрямую, изменить параметр bhyve_vnc_tcp_bind с 127.0.0.1 на 0.0.0.0 в меню vnc_options. В этом случае, порт для соединения будет открыт всем

			% cbsd blogin
		

Описание:

Запускает tmux сессию, подключаясь к консольному выводу виртуальной машины

Для отключения от терминала (и выключения tmux сессии), нажмите комбинацию клавиш: Ctrl+b, d (удерживая Ctrl нажмите b, отпустите обе клавиши и нажмите d)

Пример:

			% cbsd blogin debian1
		

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

Достигается это через конфигурационный файл blogin.conf и параметр login_cmd.

Файл вы можете разместить как для индивидуального окружения в каталоге $workdir/jails-system/$jname/etc (например, виртуальные машины принадлежат разным системным администратором и вы можете захотеть использовать разные login при соединении через ssh), так и глобально, перезаписав значение из $workdir/etc/defaults/blogin.conf. Для этого, создайте файл с вашей конфигурацией в каталоге $workdir/etc/

При кастомном вызове, вы можете использовать CBSD variables - переменные CBSD для того или иного окружения

Например, если вы хотите, чтобы вместо стандартного поведения, при blogin запустился VNC клиент, файл $workdir/etc/blogin.conf может выглядеть так:

		login_cmd="su -m user -c \"vncviewer ${bhyve_vnc_tcp_ipconnect}:${vm_vnc_port}\""
		

Если вы хотите, чтобы происходило соединение по ssh, этот файл может выглядеть так:

		login_cmd="/usr/bin/ssh your_user@${ipv4_first}"
		

			% cbsd bclone
		

			% cbsd brclone
		

Описание:

Выполняет клонирование виртуальной машины в новую. В качестве обязательных аргументов, указывается источник/оригинал VM через old и новое имя через аргумент new

ZFS клонирование, это мгновенная операция независимо от объемов (спасибо Copy-on-write), но накладывает некоторые ограничения - вы будете записимы от наличия родительского снапшота. Если вы попробуете удалить родительское окружение,, CBSD автоматически выполнит команду zfs promote, однако если вы работаете со снапшотами независимо от CBSD - имейте это ввиду

Вы можете контроллировать это поведение через аргумент clone_method=. Либо можете выставить его глобально через rclone.conf и bclone.conf, переопределив настройку с 'auto' на 'rsync':

		% echo 'clone_method="rsync"' > ~cbsd/etc/rclone.conf
		% echo 'clone_method="rsync"' > ~cbsd/etc/bclone.conf
		
		
Когда ~cbsd/etc/bclone.conf (для bclone) и ~cbsd/etc/rclone.conf содержат:
		
		clone_method="rsync"
		
		
клон не будет использовать zfs clone, даже если вы работаете на ZFS
		
Пример: клонирование виртуальной машины debian1 в debian2:
		
			% cbsd bclone old=debian1 new=debian2
		
	

			% cbsd bexport
		

Описание:

Экспортировать VM в файл (*.img). В качестве аргумента jname указывается имя виртуальной машины. img-файл сохраняется в каталоге $workdir/export. Оригинальная VM после экспорта остается без изменений.

Пример (экспортировать VM debian1 в $workdir/export/debian1.img):

			% cbsd bexport jname=debian1
		

			% cbsd bimport
		

Импортировать из имиджа (*.img) виртуальную машины. В качестве аргумента jname указывается полный путь к файлу или имя имиджа (без расширения .img), который должен находится в соответствующем каталоге ($workdir/import). img-файл после импорта остается на месте. Дополнительно, вы можете импортировать виртуальную машину из образа в альтернативное имя (например, вы хотите развернуть VM debian1 из образа debian1.img, однако в вашей системе уже имеется VM с таким именем). В этом случае, используйте аргумент newjname

Пример:

Импортировать VM из файла /tmp/debian1.img:

			% cbsd bimport jname=/tmp/debian1.img
		

Пример:

Импортировать образ debian2.img находящийся в $workdir/import под новым именем debian5:

			% cbsd bimport jname=debian2 newjname=debian5 
		

Для использования этой особенности, ядро (модуль vmm.ko) и userland утилиты ( bhyve и bhyvectl ) должны быть пересобраны с флагом BHYVE_SNAPSHOT. Добавьте в /etc/src.conf строчку:

WITH_BHYVE_SNAPSHOT=yes

И в конфигурационный файл ядра опцию:

options         BHYVE_SNAPSHOT

Функциональность чекпоинтов (checkpoint) и спящий режим (suspend) виртуальной машины - это заморозка виртуального окружения с сохранением всего состояния на диск, из которого вы можете вновь вернуть систему в прежнее состояние без необходимости перезагрузки окружения.

Чекпоинты

В CBSD для работы с чекпоинтами служит команда bcheckpoint, имеющая следующий синтаксис:

	cbsd bcheckpoint [jname=] [mode=] [name=] [poweroff=]
	

где:

• - jname: (обязательно) имя окружения, например: freebsd1
• - mode: (обязательно) действие относительно окружения: create (создать чекпоинт), list (список созданных чекпоинтов), destroyall (уничтожить все чекпоинты)
• - name: (опционально) указать альтернативное имя чекпоинту, по-умолчанию: checkpoint
• - poweroff: (опционально). Если poweroff=1, CBSD автоматически выключит виртуальную машину моментально (через bstop noacpi=1) по факту создания чекпоинта.

		% cbsd bls
		JNAME     JID    VM_RAM  VM_CURMEM  VM_CPUS  PCPU  VM_OS_TYPE  IP4_ADDR  STATUS  VNC_PORT
		freebsd1  21923  1024    24         1        0     freebsd     DHCP      On      127.0.0.1:5900  
		
		% cbsd bcheckpoint mode=create jname=freebsd1
		Waiting and sure that the info is written on the disk: 1/5
		Waiting and sure that the info is written on the disk: 2/5
		Waiting and sure that the info is written on the disk: 3/5
		Waiting and sure that the info is written on the disk: 4/5
		Waiting and sure that the info is written on the disk: 5/5
		Checkpoint was created!: /usr/jails/jails-system/freebsd1/checkpoints/checkpoint.ckp
		
		% cbsd bcheckpoint mode=create jname=freebsd1 name=after_update
		Waiting and sure that the info is written on the disk: 1/5
		Waiting and sure that the info is written on the disk: 2/5
		Waiting and sure that the info is written on the disk: 3/5
		Waiting and sure that the info is written on the disk: 4/5
		Waiting and sure that the info is written on the disk: 5/5
		Checkpoint was created!: /usr/jails/jails-system/freebsd1/checkpoints/after_update.ckp
		
		% cbsd bcheckpoint mode=list jname=freebsd1
		Created checkpoint for freebsd1:
		after_update
		checkpoint
	

Имея созданные чекпоинты, вы можете возвращаться в нужное состояние через команду bstart с аргументом checkpoint

Небольшое демо на ранней стадии разработки на Youtube

Спящий режим

WIP

Пауза виртуальной машины

WIP

			% cbsd bconstruct-tui
			% cbsd bconfig
		

В процессе эксплуатации bhyve вы можете столкнуться с проблемами, свойственными любому другому программному обеспечению, которое создал человек. А именно - процесс bhyve может внезапно умереть. Это неприятная ситуация и в идеальном мире не должна существовать. Вы можете приблизить идеальный мир путем исправления данной ошибки, если вы являетесь kernel hacker. Но если вы таким не являетесь, вы все равно можете помочь проекту, оформив максимально информативный отчет об ошибке. В этом нам может помочь возможность CBSD запустить bhyve от дебагера gdb (GNU debuger) или lldb (LLVM). Также, эта возможность будет полезна разработчикам bhyve или в каких-либо других исследовательских работах.

В качестве примера, приведем ситуацию с крешем NetBSD guest, когда вы включаете драйвер xhci. В данном случае мы запустили NetBSD виртуальную машину с опцией lldb и получили backtrace, который отправили в список рассылки NetBSD и bugs.freebsd.org

Для запуска bhyve через дебагер, используйте меню debug_engine в 'cbsd bconfig' и 'cbsd bconstruct-tui' диалогах.