Глава 3. Под капотом Proxmox

Proxmox является гипервизором на основе кластера. Это означает, что он будет использоваться на различных серверных узлах. Применяя множество узлов в кластере мы предоставляем избыточность или высокую доступность (HA, High Availability) своей платформе поскольку увеличиваем время непрерывной работы. Промышленная виртуальная среда может иметь от десятков до нескольких сотен узлов в кластере. Для администратора может оказаться нереальным изменение файлов настройки в его кластере на каждом узле за раз. В зависимости от числа узлов в этом кластере, замена одного небольшого параметра в файле настройки может занять несколько часов для всех узлов. Для сохранения драгоценного времени Proxmox реализует кластерную файловую систему для поддержания всех файлов настройки или любых других общих файлов, совместно используемых всеми узлами в данном кластере в синхронном состоянии. Официально она именуется как Proxmox Cluster file system (pmxcfs). pmxcfs является движимой базой данных файловой системой, используемой для хранения файлов настроек. Любые изменения сделанные в любых файлах или копирование/ удаление файлов в этой файловой системе получает репликацию в реальном времени на все узлы с применением Corosync. Механизм кластера Corosync является системой взаимодействия групп, применяемой для реализации высокой доступности (HA) в пределах приложения. Вы можете получить дополнительную информацию о Corosync посетив http://corosync.github.io/corosync/.

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

Файловая система pmxcfs монтируется в следующем пути:

# /etc/pve
 	   

Все относящиеся к кластеру файлы хранятся в этой папке пути.

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

Путь каталога	тип данных
/etc/pve/datacenter.cfg	Файл настройки Proxmox VE datacenter. Применяется для изменения таких параметров как язык по умолчанию, раскладка клавиатуры, консоль по умолчанию и т.п.
/etc/pve/corosync.conf	Главный файл настройки кластера. В более ранних версиях до Proxmox VE 4.0 назывался cluster.conf и также применялся для изменения права голоса определённого узла.
/etc/pve/storage.cfg	Файл настройки хранилища PVE. Содержит всю информацию по локальным или совместно используемым хранилищам данных.
/etc/pve/user.cfg	Перечень пользователей и настройки прав доступа для всех пользователей и групп в кластере.
/etc/pve/authkey.pub	Общедоступные ключи для системы квитанций.
/etc/pve/ceph.conf	Если кластер Ceph встроен в Proxmox, для Ceph сздаётся этот файл настроек.
/etc/pve/vzdump.cron	Задачи резервного копирования по всему кластеру, которые не являются специфичными для отдельного узла. Это файл нельзя изменять вручную. Все его элементы автоматически создаются в меню вашего GUI Backup.
/etc/pve/priv/shadow.cfg	Теневой файл паролей для пользователей.
/etc/pve/priv/authkey.key	Частные ключи авторизации применяемые для системы квитанций.
/etc/pve/priv/ceph/<storage_id>.keyring	Кольцо ключей используемое для подключения хранилищ Ceph RBD. Мы рассмотрим Ceph в Главе 4. Системы хранения.
/etc/pve/firewall/<vmid>.fw	Правила межсетевого экрана для всех ВМ.
/etc/pve/nodes/<name>/pve-ssl.pem	Общедоступные (public) ключи SSL для веб- сервера кластера. Применяются для доступа к Proxmox WebGUI.
/etc/pve/nodes/<name>/priv/pve-ssl.key	Частный (private) ключ SSL.
/etc/pve/nodes/<name>/host.fw	Правила межсетевого экрана для хоста Proxmox.
/etc/pve/nodes/<name>/qemu-server/<vmid>.conf	Данные настроек виртуальных машин для ВМ KVM.
/etc/pve/nodes/<name>/lxc/<vmid>.conf	Данные настроек виртуальных машин для контейнеров LXC.
/etc/pve/.version	Файл данных версии для определения изменений файла.
/etc/pve/.members	Информация об узлах, которые являются членами данного кластера.
/etc/pve/.vmlist	Список всех ВМ в данном кластере.
/etc/pve/.clusterlog	Последние 50 записей в журнале кластера.
/etc/pve/.rrd	Самые последние записи в данных RRD.

Все изменения сделанные в этих файлах или любых других файлах внутри pmxcfs смонтированные в каталоге /etc/pve получают репликации автоматически. По этой причине мы должны быть особенно аккуратными с тем, что мы делаем с данными файлами. Например, мы удалили файл .conf на одном из узлов по ошибке. он также будет удалён со всех остальных узлов в кластере Proxmox.

При обычной ежедневной работе у системных администраторов нет необходимости доступа к этим файлам из командной строки поскольку почти все они редактируются из GUI Proxmox. Однако знание местоположения этих файлов и того, что они содержат может сохранить ваш день когда GUI становится недоступным по какой- либо причине.

Теперь мы знаем где хранятся все важные файлы, которые сохраняют кластер Proxmox единым целым. Мы рассмотрим подробности некоторых из этих файлов для лучшего понимания того что они делают и какие параметры команд используют. Вы можете использовать любой редактор Linux для просмотра/ изменения этих файлов настроек. В данной книге мы применяем для просмотра и внесения изменений #nano.

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

# cp /etc/pve/<config_file> /home/<any_folder>
 	   

Также мы можем применить команду SCP для резервного копирования файлов на другой узел:

# scp /etc/pve/<config_file> <user>@<ip_or_hostname>:/<folder>
 	   

Файл настройки corosync.conf хранит параметры, необходимые для работы кластера. Любая пустая строка, или строка, начинающаяся с символа # полностью игнорируется. Следующий код является тем, как наш файл corosync.conf в настоящее время выглядит в нашем примере кластера с двумя узлами Proxmox. Файл настройки кластера Proxmox расположен в /etc/pve/corosync.conf.

logging { 
  debug: off 
  to_syslog: yes 
}

nodelist { 
  node { 
    nodeid: 2 
    quorun_votes: 1 
    ring0_addr: pm4-2 
  }
  node {
    nodeid: 1 
    guorun_votes: 1  
    ring0_addr: pm4-1
  }	

}

quorum { 
  provider: corosyne_votequorum 
}

totem {
  cluster_name: MasterPmx2ndEd 
  config_version: 2 
  ip_version: ipv4 
  secauth: on 
  version: 2 
  interface {
  bindnetaddr: 172.16.0.171 
  ringnumber: 0 
} 
 	   

Теперь вы собираетесь углубиться в corosync.conf для отображения функций его параметров. Этот файл настройки автоматически создаётся при создании нового кластера Proxmox. В этом файле имеется четыре сегмента, а именно:

 

logging { }

Этот раздел содержит параметры настройки для протоколирования. Согласно параметрам в нашем примере, отладка выключена и журнальные записи передаются в в syslog. Если мы хотим включить отладку и передавать журнальные записи в logfile вместо syslog, наши параметры будут выглядеть следующим образом. Мы также можем присоединять ко всем элементам протокола timestamp:

logging {
  debug: on
  to_logfile : yes
  to_syslog : no
  timestamp : on
}
/var/log/<filename>.log {
  daily
  rotate 5
  copytruncate
}
 	   

Отметим, что мы хотим если мы хотим передавать ведение журнала в logfile, нам необходим дополнительный сегмент logfile { } наряду с параметрами logrotate и copytruncate.

 

nodelist { }

Как и подразумевает его назввание, этот сегмент является местом, где перечисляются все узлы участники кластера Proxmox. Каждый узел подразделяется отдельным подразделом node { }. Далее следуют три главных параметра в том порядке, как они идут в файле настроек нашего кластера.

 

nodeid

Этот параметр показывает порядковый номер узла- участника по мере его добавления в общий кластер. Он факультативен для IPv4, однако обязателен при применении IPv6. Каждый nodeid должен быть уникальным в вашем файле настроек кластера. Если не используется никакой параметр nodeid при применении IPv4, кластер автоматически вычисляет этот ID из 32-битного адреса IPv4. При применении IPv6 такое вычисление не производится, так как IPv6 содержит более 32 бит.

 

quorum_votes

Данная опция отображает число голосов, которое этот узел должен подавать для формирования quorum. В кластере Proxmox не существует более одного голоса на узел. Раз уж это число присутствует, оно должно быть одинаковым для всех узлов. Просто не существует причины использовать что- то отличное от 1.

 

ring0_addr

Эта строка в основном описывает IP адрес или имя хоста данного узла. Действительный формат этой опции выглядит как ringX_addr, где X является номером кольца. Когда для целей избыточности применяется множество сетевых интерфейсов, в corosync реализуется протокол избыточных колец. Каждому из этих интерфейсов назначается уникальный ringnumber. Этот уникальный ringnumber просит интерфейс соединиться с соответствующим протоколом кольца. Например, в нашем примере кластера, если мы применяем второй интерфейс для избыточности, сегмент node { } будет выглядеть следующим образом:

node {
  nodeid: 2
  quorum_votes: 1
  ring0_addr: 172.16.0.71
  ring1_addr: 192.168.0.71
}
 	   

 

quorum { }

Этот сегмент сообщает кластеру какой алгоритм кворума применять для формирования quorum. Для версии corosync 2.3.5 существует только один доступный поставщик, а именно, votequorum. Этот алгоритм гарантирует что не существует ситуации раздвоения сознания и quorum формируется только когда подаётся большинство голосов. Не существует никаких дополнительных параметров для этого сегмента.

 

totem { }

Этот сегмент определяет параметры для протокола totem. Corosync состоит из Totem Single Ring Protocol (SRP) и Totem Redundant Ring Protocol(RRP). Этот сегмент также содержит интерфейс подраздела { } для определения адреса сцепления (bind) и номера кольца.

В процессе создания нашего примера кластера proxmox вырабатывает следующие параметры:

cluster_name: MasterPmx2ndEd
 	   

Этот параметр определяет имя кластера, которое вводится при создании нами кластера Proxmox с применением следующей команды:

# pvecm create <cluster_name>

config_version: 2
 	   

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

ip_version: IPv4
 	   

Этот параметр определяет используемую версию IP. По умолчанию применяется IPv4. Чтобы использовать версию 6 для IP, просто воспользуйтесь параметром IPv6.

secauth: on
 	   

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

Отметим, что параметр secauth для corosync не рекомендуется. Для поддержки corosync рекомендуется применять crypto_hash и crypto_cipher. Однако в Proxmox 4.1 secauth всё-таки используется по умолчанию. Ниже приводится пример того, как рекомендуемые установки должны выглядеть в сегменте totem:

totem {
  crypto_hash: sha1
  crypto_cipher: aes256
}
 	   

На момент написания этой книги разработчики Proxmox не подтвердили можно ли будет безопасно применять crypto_hash и crypto_cipher вместо secauth.

version: 2
 	   

Этот параметр определяет вашу версию настроек. В настоящий момент единственной версией для данного параметра является 2. Она не является инкрементальной версией файла настройки, которая изменяется при каждом изменении.

Помимо упомянутых ранее параметров существуют некоторые другие параметры, доступные в сегменте totem для различных целей. Следующая таблица отображает некоторые из этих параметров и их функции:

Параметр	Описание
rrp_mode	Доступные значения:none, active и passive. Этот параметр определяет режим избыточности протокола. Когда существует только один интерфейс, corosync автоматически выбирает none. При множестве интерфейсов мы можем установить его в active, что предложит меньшую латентность за счёт меньшей производительности. Мы также можем установить этот режим в passive, что предложит значительное улучшение производительности за счёт использования ЦПУ.
netmtu	Доступные значения: от 1500, до 8982. Определяет MTU интерфейса. Полезен в случае применения кадров jumbo. Linux добавляет 18-байтовый заголовок к пакетам сетевых данных. Поэтому даже несмотря на то, что аппаратура может поддерживать MTU 9000, будет предусмотрительным устанавливать MTU в значение 8982. Таким образом, после добавления Linux дополнительных заголовков, общее значение MTU не превысит 9000 и оборудование будет вести себя как следует. Эти советы MTU применимы всякий раз, когда применяются кадры jumbo.
transport	Доступные значения:udp, udpu и iba. Определяет транспортный протокол. По умолчанию corosync применяет udp. Если используется сетевая среда на основе Infiniband с применением RDMA, то вы можете определить iba вместо udp.

 

interface { }

Это подраздел сегмента totem, в котором определяется информация, относящаяся к сетевому интерфейсу. По умолчанию Proxmox вводит в этом подразделе только параметры bindnetaddr и ringnumber:

bindnetaddr : <ip/network_address>
 	   

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

ringnumber: 0
 	   

Это параметр, определяющий отдельный номер кольца для каждого сетевого интерфейса. Уникальный ringnumber для каждого интерфейса позволяет определять какое кольцо должно применяться для какого интерфейса. Например, в одиночном интерфейсе, в котором определён Totem RRP, существует только одно кольцо с ringnumber 0. При дуальном интерфейсе существуют два кольца с ringnumber 0 и ringnumber 1. Отметим, что нумерация колец должна начинаться с 0.

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

Параметр	Описание
mcastaddr	Определяет адрес группового обмена, используемый corosync. Адрес может быть IPv4 или IPv6 при применении IPv6. Этот параметр обычно необходим если параметр cluster_name уже применён в файле настроек corosync. Однако когда применяются оба, mcastaddr будет иметь более высокий приоритет, чем cluster_name. По умолчанию настройка кластера Proxmox не использует mcastaddr.
mcastport	Определяет номер порта udp для группового обмена данными. Corosync использует для группового обмена два порта: один для приёма и другой для передачи. Нам требуется определить только принимающий порт, так как передающий порт автоматически вычисляется с использованием формулы (mcastport - 1. Например, мы определяем номер принимающего порта, 5405, тогда corosync для отправки будет применять 5404. Это очень важно помнить в средах с групповым обменом в одной и той же сетевой среде.

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

totem {
  cluster_name: MasterPmx2ndEd
  config_version: 4
  ip_version: ipv4
  crypto_hash: sha1
  crypto_cipher: aes256
  version: 2
  rrp_mode: passive
  interface {
    bindnetaddr: 172.16.0.71
    ringnumber: 0
    mcastaddr: 224.1.1.1
    mcastport: 5405
  }
  Interface {
    bindnetaddr: 172.16.1.71
    ringnumber: 1
    mcastaddr: 224.1.1.2
    mcastport: 5408
  }
}
 	   

Это файл настройки, в котором определяется система хранения, которая будет применяться в Proxmox. Файл настройки расположен в /etc/pve/storage.cfg. Мы рассмотрим различные системы хранения в Главе 4. Системы хранения. Ниже приводится содержимое нашего файла настройки хранилища в нашем примере кластера. В настоящее время у нас есть совместно используемые хранилища local, nfs, iscsi и lvm, а также хранилище ZFS, подключённые к нашему кластеру Proxmox:

dir: local
  path /var/lib/vz
  content images,iso,vztmpl,rootdir
  maxfiles 0

nfs: ISO-nfs-01
  path /mnt/pve/ISO-nfs-01
  server 192.165.145.11
  export /mnt/pmxnas01
  options vers=3
  content iso,vztmpl
  maxfiles 1

iscsi: nas-iscsi-01
  target iqn.2015-12.org.example.istgt:pmxtgt01
  portal 192.165.145.11
  content none

lvm: nas-lvm-01
  vgname nas-lvm-01
  base nas-iscsi-01:0.0.0.scsi-330000000391132dd
  shared
  content images

nfs: vm-nfs-01
  path /mnt/pve/vm-nfs-01
  server 192.165.145.11
  export /mnt/pmxnas01
  options vers=3
  content images,vztmpl,backup,rootdir
  maxfiles 1

zfspool: zfs-01
  enable
  pool zfs_pool
  content images, rootdir
 	   

Почти все настройки в storage.cfg могут быть изменены в GUI Proxmox без использования каких- либо средств CLI.

Подключаемые хранилища соблюдают следующий общий формат в storage.cfg:

storage_type : storage_name
    path </путь к папке>
    target <имя файла таргета> (for iSCSI)
    portal <адрес IP сервера> (for iSCSI)
    vgname <имя группы томов> (for LVM)
    base <база группы томов> (for LVM)
    server <IP адрес сервера хранения>
    export </совместный ресурс на сервере NFS>
    content <тип файлов, которые может размещать данное хранилище>
    maxfile <макс. число подлежащих хранению старых резервных копий>>
 	   

Файл user.cfg содержит полную информацию о пользователях, группах, а также управлении доступом в вашем кластере и размещается в /etc/pve/user.cfg. Он следует приводимому ниже формату для хранения всей информации о пользователях:

Основываясь на этом формате, следующий снимок экрана показывает как выглядит наш файл user.cfg для нашего примера кластера:

user:demo1@pve:1:0:Demo:User 1:demouser1@symmcom.com::: 
user:root@pam:1:0:::wahmed@symmcom.com::: 
user:wahmed@pve:1:0:Wasim:Ahmed:wahmed@symmcom.com::: 

poo1:Win_VMs:All Windows VMs::: 
poo1:Lab_1:VMs used in Lab environment:110,100:local: 
pool:Linux_VMs:All Linux VMs::: 

acl:1:/pool/Lab_1:wahmed@pve:PVEPoolAdmin: 
acl:1:/vms/110:wahmed@pve:PVEVMAdmin: 
acl:1:/vms/110:demo1@pve:PVEVMUser: 
 	   

Отметим, что файл user.cfg не содержит никакие пароли пользователей. Эта информация хранится в /etc/pve/priv/shadow.cfg в зашифрованном виде. Всё содержимое в этом файле настроек может управляться через GUI Proxmox. Всякий раз, когда мы создаём новых пользователя/ группу или назначаем роль, обновляется данный файл настроек. Если GUI становится недоступным, данный файл можно изменять вручную.

Файл настроек паролей размещается в /etc/pve/priv/shadow.cfg и хранит все пароли для пользователей в вашем кластере. Его формат достаточно прост, однако функция этого файла очень критична. Формат хранения информации о пароле таков:

<user_name>:<encrypted_password>
 	   

Отметим, что файл паролей размещается в каталоге /priv внутри /etc/pve. Чувствительная информация, такая как пароли, частные ключи авторизации и известные хосты хранятся в папке /etc/pve/priv. При создании нового пользователя в GUI Proxmox сюда добавляется новая запись.

Файл vmid.conf хранит информацию о настройке для каждой виртуальной машины и расположен в /etc/pve/nodes/<name>/qemu-server/<vmid>.conf. Структура каталога подразделяет все файлы настройки ВМ на категории на основе узлов. Например, файл настройки для нашей ВМ с ID#110 хранится в следующем местоположении:

# /etc/pve/nodes/pm4-1/qemu-server/110.conf
 	   

При миграции ВМ с одного узла на другой Proxmox просто перемещает файл настройки на узел назначения. Если данная ВМ включена в процессе миграции, то всё содержимое памяти этой ВМ также мигрирует на указанный узел назначения. Для нашей ВМ 110 если мы перемещаем её на pm4-2, второй узел в кластере, то местоположение файла 110.conf станет следующим:

# /etc/pve/nodes/pm4-2/qemu-server/110.conf
 	   

Теперь мы рассмотрим файл <vmid>.conf сам по себе, чтобы рассмотреть что формирует виртуальную машину за пределами сцены. данный файл настройки следует простому формату OPTION: value. Ниже приводится файл настройки для нашей ВМ 110:

balloon: 128 
bootdisk: virtio0 
cores: 1 
ide2: none,media=cdrom 
kvm: 0 
memory: 512 
name: Ubuntu-1 
net0: virtio=06:4B:8B:5C:B5:3D,bridge=vmbr0,firewall=1
numa: 0 
ostype: l26 
parent: Clean_Install 
smbios1: uuid=a80ce6f7-9f21-4ab2-b5ac-6daacade3199 
sockets: 1 
virtio0: local:110/vm-110-disk-1.qcow2,size=5G  
 	   

Почти все параметры в этом файле могут быть установлены посредством GUI Proxmox в меню закладки параметров виртуальной машины KVM. Некоторые значения опций, такие как аргументы, должны быть добавления с применением CLI. Следующая таблица показывает некоторые из таких возможных опций. Эти значения могут применяться в качестве настроек виртуальной машины:

Параметр	Описание	Возможные значения
acpi:	Разрешает/ запрещает ACPI для ВМ.	1 0
args:	Предоставляет вам возможность передавать аргументы в ВМ. При помощи аргументов KVM может быть активирована функциональность подобная звуку. Отсылаем к разделу Параметры в файле настройки KVM за подробностями по используемым в KVM параметрам.	см. раздел Параметры в файле настройки KVM
autostart:	Автоматически повторно запускает виртуальную машину после её крушения. Значение по умолчанию 0.	1 0
ballon:	Назначение ОЗУ для ВМ в МБ.	Целое число
boot:	Загрузочное устройство по умолчанию.	с | d | n: c = hdd; d = cd-rom; n = network
bootdisk:	Делает возможной загрузку со специфического диска.	ide | sata | scsi | virtio
core:	Число ядер на сокет. Значение по умолчанию равно 1.	Целое число
cpu:	Типы эмулируемых ЦПУ. Значение по умолчанию равно kvm64.	486 | kvm32 | kvm64 | qemu32 | qemu64 | conroe | haswell | nehalem | opteron_G1/G2/G3/G4/G5 | penryn | sandybridge | westmere | athlon | core2duo | coreduo | host | pentium | pentium2 | pentium3 | phenom
cpuunits:	Это весовое значение вашего ЦПУ для данной ВМ. Данное значение применяется планировщиком равноправия ядра. Чем больше это значение, тем больше времени ЦПУ будет получено ВМ. Отметим, что это значение является относительным к весам всех остальных работающих в кластере ВМ. Значение по умолчанию равно 1000.	Целое число от 0 до 500000
description:	Описание данной ВМ.	Простой текст
freeze:	Приостанавливать ЦПУ при запуске.	1 | 0
hostpci(n):	Эта опция делает возможным прямой доступ к оборудованию хоста для ВМ. Когда применяется эта опция, миграция данной ВМ не возможна. Данную опцию следует применять с предосторожностью, поскольку она пока находится в экспериментальном режиме. Не рекомендуется к применению в промышленных средах.	HOSTPCIDEVICE Синтаксис для HOSTPCIDEVICE следующий: bus: <pci_device_number> Получите pci_device_number из команды #lspci
hotplug:	Делает возможной горячую замену для диска или сетевого устройства. Значение по умолчанию равно 0.	1 | 0
ide(n):	Делает возможным использование тома в качестве IDE диска или CD-ROM. N в ide(n) ограничено диапазоном 0-3.	[volume=image_name], [media=cdrom|disk], [cyls=c,heads=h,secs=s,[trans=t]], [snapshot=on|off], [cache=none|writethrough|writeback|unsafe|directsync], [format=f], [backup=yes|no], [rerror=ignore|report|stop], [werror=enospc|ignore|report|stop], [aio=native|threads]
kvm:	Разрешает/ запрещает аппаратную виртуализацию KVM. Этот параметр запрещает любое аппаратное ускорение в пределах ВМ. Возможным сценарием применения может быть случай когда вы настраиваете встроенный кластер виртуализации. Значение по умолчанию равно 1.	1 | 0
lock:	Включает/ выключает блокировку ВМ.	backup | migrate rollback | snapshot
memory:	Выделенный объём ОЗУ для ВМ.	Целое число от 16 до N {Прим. пер.: так в тексте книги.}
migrate_downtime:	Значение в секундах для допускаемого максимума простоя при миграции. Значение по умолчанию равно 0.1 {Прим. пер.: так в тексте книги.}	Число от 0 до N
migrate_speed:	Значение для максимальной скорости в МБ/с для миграции ВМ. Установка в значение 0 снимает ограничение. Значение по умолчанию равно 0.	Целое число от 0 до N
name:	Имя ВМ.	Текст
net(n):	Определённое сетевое устройство. MODEL=XX:XX:XX:XX:XX:XX, [bridge=<dev>],[rate=<mbps>],[tag=<vlanid>]	MODEL = e1000 | i82551 | i82557b | i82559er | ne2k_isa | ne2k_pci | pcnet | rtl8139 | virtio
onboot:	Разрешает/ запрещает автоматический запуск ВМ в процессе перезагрузки узла хоста.	1 | 0
sata(n):	Делает возможным использование тома в качестве SATA диска или CD-ROM. N в sata(n) ограничено диапазоном 0-5.	[volume=]volume], [media=cdrom|disk], [cyls=c,heads=h,secs=s,[trans=t]], [snapshot=on|off], [cache=none|writethrough|writeback|unsafe|directsync], [format=f], [backup=yes|no], [rerror=ignore|report|stop], [werror=enospc|ignore|report|stop], [aio=native|threads]
scsi(n):	Делает возможным использование тома в качестве SCSI диска или CD-ROM. N в scsi(n) ограничено диапазоном 0-13.	[volume=]volume], [media=cdrom|disk], [cyls=c,heads=h,secs=s,[trans=t]], [snapshot=on|off], [cache=none|writethrough|writeback|unsafe|directsync], [format=f], [backup=yes|no], [rerror=ignore|report|stop], [werror=enospc|ignore|report|stop], [aio=native|threads]
scsihw:	Тип контроллера SCSI. Значение по умолчанию равно lsi.	lsi | megasas | virtio-scsi-pci
shares:	Это значение стоимости ОЗУ для автоматического расширения. Чем больше это значение, тем больше ОЗУ получит данная ВМ. Значение 0 запрещает этот параметр. Значение по умолчанию равно 1000.	Целое число от 0 до 50000
sockets:	Число сокетов ЦПУ. Значение по умолчанию равно 1.	Целое число от 1 до N
startdate:	Опция устанавливает начальную дату в реальном значении времени.	now | YYYY-MM-DD | YYYY-MM-DDTHH:MM:SS
startup:	Эта опция устанавливает поведение для запуска и останова ВМ. Очерёдность устанавливается положительным целым числом, которое устанавливает порядок, в котором будут запускаться ВМ. Отключение следует этим значениям очерёдности в обратном порядке. Через значения up и down можно устанавливать задержки для запуска и останова в секундах.	[order=+ Int], [up=+ Int] [down=+ Int]
tablet:	Разрешает/ запрещает устройства USB в ВМ. Когда на одном хосте выполняется большое число ВМ только с консолью, запрет этого свойства может экономить переключения контекста. Значение по умолчанию равно 1.	1 | 0
unused(n):	Неиспользуемые тома в ВМ. при удалении виртуальных дисков в ВМ, тома не удаляются немедленно. Вместо этого их состояние изменяется на неиспользуемое (	unused:<volume_name>). Позже, если этот том потребуется, он может быть повторно подключён к данной ВМ с изменением этой опции на ide(n): | scsi(n): | sata(n):.	1 | 0
usb(n):	Эта опция делает возможным проброс (pass-through) прямого доступа к устройству USB. N может быть установлено в диапазоне от 0 до 4. При применении этой опции миграция данной ВМ больше не возможна.	HOSTUSBDEVICE Синтаксис для HOSTUSBDEVICE следующий: <vendor_id:product_id> Получите usb_device_number из команды #lsusb -t
vga:	Тип дисплея ВМ.	cirrus | std | vmware | qxl
vga:
virtio(n):	Делает возможным использование тома в качестве диска virtio. N в virtio(n) ограничено диапазоном 0-15.	[volume=]volume], [media=cdrom|disk], [cyls=c,heads=h,secs=s,[trans=t]], [snapshot=on|off], [cache=none|writethrough|writeback|unsafe|directsync], [format=f], [backup=yes|no], [rerror=ignore|report|stop], [werror=enospc|ignore|report|stop], [aio=native|threads]

Параметры в файле настроек виртуальной машины являются способом расширить возможности этой ВМ за пределы только того, что установлено по умолчанию. Например, по умолчанию звук не доступен для ВМ. Чтобы дать возможность для ВМ проигрывать аудио/ видео, в файле настроек этой ВМ должны быть проброшены (pass through) параметры (arguments). Ниже приводятся примеры некоторых параметров, которые могут применяться в файле настроек ВМ Proxmox. Параметры можно добавить в следующем формате:

args: -<device_arguments_1> -<device_arguments_2> . . . .
ballon: 512
bootdisk: virtio0
cores: 1
ide2: none,media=cdrom
. . . .
. . . .
 	   

Чтобы сделать доступным последовательное устройство в ВМ примените следующий код:

args: -serial /dev/ttyS0
 	   

Чтобы сделать доступным звук в ВМ Windows XP примените следующий код:

args: -device AC97,addr=0x18
 	   

Чтобы сделать доступным звук в ВМ Windows 7 примените следующий код:

args -device intel-hda,id=sound5,bus=pci.0,addr=0x18 –device had-micro,id=sound5-codec0,bus=sound5.0,cad=0 –device had-duplex,id=sound5-codec1,bus=sound5.0,cad=1
 	   

Чтобы сделать доступным UUID в ВМ примените следующий код:

args –uuid fl234a93-20d32-2398-129032ds-2322
 	   

Чтобы сделать доступной поддержку для aio=native в ВМ, поступите так:

args: -drive file=/dev/VGGRP/VOL,if=virtio,index=1,cache=none,aio=native
 	   

Начиная с Proxmox VE 4.0, OpenVZ были отброшены в пользу контейнеров LXC. LXC ответвились от OpenVZ в основной поток ядра. Одним из основных преимуществ LXC является то, что их можно применять поверх стандартного ядра Linux без необходимости специального ядра, как это было в случае OpenVZ.

Ниже приводится файл настройки LXC контейнера #100 в нашем примере кластера:

#Ubuntu Demo LXC Container 
arch: amd64 
cpulimit: 1 
cpuunits: 1024 
hostname: Ubuntu-DC 
memory: 284 
nameserver: 208.67.222.222 8.8.8.8 
net0: bridge=vmbr0,firewall=1,gw=172.16.3.254.hwadrr=3A:30:36:38:66:63,ip=172.16.0.186/20,name=eth0,tag=10,type=veth 
ostype: ubuntu 
rootfs: local:100/vm-100-disk-1.raw.size=4G 
serchdomain: symmcom.com 
swap: 256 
 	   

Настройка контейнера LXC намного проще чем OpenVZ. В LXC нет User Bean Counters в отличие от OpenVZ. Следует отметить, что у если существующий у вас кластер имеет версию Proxmox до 4.0 и на нём работают контейнеры OpenVZ, они не могут быть плавно обновлены в процессе обновления Proxmox. Все контейнеры OpenVZ должны быть выключены, для них должна быть зафиксирована полная резервная копия, после чего они должны быть восстановлены в обновлённом Proxmox VE 4. Мы подробно рассмотрим процесс обновления в Главе 11, Обновление/ модернизация Proxmox. {Прим. пер.: см. также наш перевод официального руководства Преобразование OpenVZ в LXC.}

Как и файл настройки KVM, LXC также использует варианты: конкретные значения компонуют определённую настройку в его файле. Добавляемые по умолчанию в процессе создания LXC параметры в основном не требуют объяснений. Большинство этих параметров для LXC могут быть изменены с применением GUI Proxmox. LXC сам по себе имеет немало параметров настройки, которые не могут управляться в GUI, однако они могут добавляться вручную с применением CLI, в зависимости от потребностей. Исчерпывающий перечень всех возможных параметров настройки для LXC можно найти по ссылке http://man7.org/linux/man-pages/man5/lxc.container.conf.5.html

{
"starttime": 1450035295, 
"clinfo": 4, 
"vmlist": 21, 
"corosync.conf": 2, 
"corosync.conf.new": 2, 
"storage.cfg": 3, 
"user.cfg": 10, 
"domains.cfg": 3, 
"priv/shadow.cfg": 4, 
"datacenter.cfg": 2, 
"vzdump.cron": 2, 
"ha/crm_commands": 2, 
"ha/manager_status": 2, 
"ha/resources.cfg": 2, 
"ha/groups.cfg": 2, 
"ha/fence.cfg": 2, 
"status.cfg": 2, 
"kvstore": { 
  "pm4-2": {
    "tasklist": 90257} 
  ,
  "pm4-1": { 
	"tasklist": 89511} 
  }
}
 	   

В этом файле не требуется настраивать вручную или править.

Размещаемый в /etc/pve/.members, файл узлов- участников отображает все узлы- участники, которые являются частью кластера Proxmox. Это прекрасный способ просмотра состояния кластера, если по какой- либо причине GUI Proxmox становится недоступным. Ниже приводится файл .members нашего базового кластера:

{
"nodename" "pm4-2", 
"version": 4 , 
"cluster": {"name" : "MasterPmx2ndEd", "version" : 2, "nodes": 2, "quorate": 1 }, 
"nodelist" { 
  "pm4-2": { "id": 2, "online": 1, "ip": "172.16.0.172"}, 
  "pm4-1": { "id": 1, "online": 1, "ip": "172.16.0.171"}
  }
}
 	   

Предыдущий снимок экрана показывает текущий узел, с которого был осуществлён доступ к файлу .members.

"version": 4
 	   

Файл .members имеет свою собственную систему нумерации версий. Как и для файла .version, при всяком изменении .members текущая версия инкрементально увеличивается. Например, когда добавляется или удаляется узел из кластера, текущий номер версии продвигается вперёд:

"cluster": { "name": "MasterPmx2ndEd", "version": 2, "nodes": 2, "quorate": 1 },
 	   

Предыдущий код показывает информацию о нашем кластере такую как имя кластера, версия кластера, число узлов- участников и число голосов (quorate), необходимое для получения кворума.

"pm4-2": { "id": 2, "online": 1, "ip": "172.16.0.172"}
 	   

Узлы, перечисляемые в разделе списка узлов предоставляют относящуюся к каждому узлу информацию, например, идентификатор, состояние включён/ выключен и IP адрес.

Размещающийся в /etc/pve/.vmlist, файл списка виртуальных машин хранит перечень всех наших виртуальных машин в пределах кластера Proxmox. Файл .vmlist для хранения списка применяет следующий формат:

"<vmid>": { "node": "<nodename>", "type": "<vm_type>", "version":<int> }
 	   

В нашем базовом кластере у нас есть две виртуальные машины и один шаблон. Показанный ниже экранный снимок отображает информацию, хранящуюся в файле .vmlist:

{
"version": 21, 
"ids": {
"100": { "node": "pm4-1", "type": "lxc", "version": 23 }, 
"110": { "node": "pm4-1", "type": "gemu", "version": 11 }} 

}
 	   

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

Для саого по себе кластера существует файл журнала и он располагается в /etc/pve/.clusterlog. В основном он сопровождает аутентификацию регистраций пользователей. Ниже приводится часть нашего файла .clusterlog:

{
"data" {
("uid": 322, "time": 1450316440, "pri": 6, "tag": "pvedaemon", "pid": 15540, "node": "pm4-1", "user": "root@pam", "msg": "successfu1 auth for user 'root@p 
("uid": 321, "time": 1450315540, "pri": 6, "tag": "pvedaemon", "pid": 21688, "node": "pm4-1", "user": "root@pam", "msg": "successfu1 auth for user 'root@p 
("uid": 320, "time": 1450314639, "pri": 6, "tag": "pvedaemon", "pid": 19540, "node": "pm4-1", "user": "root@pam", "msg": "successfu1 auth for user 'root@p 
("uid": 319, "time": 1450313739, "pri": 6, "tag": "pvedaemon", "pid": 12837, "node": "pm4-1", "user": "root@pam", "msg": "successfu1 auth for user 'root@p 
("uid": 318, "time": 1450312839, "pri": 6, "tag": "pvedaemon", "pid": 12837, "node": "pm4-1", "user": "root@pam", "msg": "successfu1 auth for user 'root@p 
("uid": 317, "time": 1450311939, "pri": 6, "tag": "pvedaemon", "pid": 12837, "node": "pm4-1", "user": "root@pam", "msg": "successfu1 auth for user 'root@p 
("uid": 316, "time": 1450311039, "pri": 6, "tag": "pvedaemon", "pid": 6182, "node": "pm4-1", "user": "root@pam", "msg": "successfu1 auth for user 'root@pa
("uid": 315, "time": 1450310138, "pri": 6, "tag": "pvedaemon", "pid": 6182, "node": "pm4-1", "user": "root@pam", "msg": "successfu1 auth for user 'root@pa
("uid": 314, "time": 1450309238, "pri": 6, "tag": "pvedaemon", "pid": 25841, "node": "pm4-1", "user": "root@pam", "msg": "successfu1 auth for user 'root@p
("uid": 313, "time": 1450308338, "pri": 6, "tag": "pvedaemon", "pid": 24353, "node": "pm4-1", "user": "root@pam", "msg": "successfu1 auth for user 'root@p
("uid": 312, "time": 1450307438, "pri": 6, "tag": "pvedaemon", "pid": 25841, "node": "pm4-1", "user": "root@pam", "msg": "successfu1 auth for user 'root@p
 	   

Ceph является разновидностью распределённой системы хранения объектов и файлов, которая полностью интегрируется с Proxmox. В своей поставке Proxmox приходит с опцией управления кластером Ceph через свой GUI и полным массивом функциональности чтобы сделать интеграцию настолько бесшовной, насколько это возможно. Мы изучим глубже Ceph в Главе 4, Системы хранения. {Прим. пер.: желающих получить более полную информацию по Ceph отсылаем к нашим переводам обеих имеющихся на данный момент книг Карана Сингха Книга рецептов Ceph (март 2016) и Изучаем Ceph (январь 2016). Список дополнительных материалов, посвящённых Ceph вы можете найти по ссылке CloudComputing#Ceph на нашем сайте.} Ceph может быть установлена на своё собственное оборудование с применением операционной системы, например Ubuntu, или сосуществовать с Proxmox на том же самом узле. Вне зависимости от того, будет ли она сосуществовать или будет располагаться в собственном кластере, узлам Proxmox необходимо для соединения осуществлять доступ к файлу настройки этой Ceph. Для сосуществующего узла Proxmox+Ceph файл настройки расположен в /etc/pve/ceph.conf. В случае работающих по отдельности узлов Proxmox, этот файл должен храниться в /etc/ceph/ceph.conf. В случае сосуществующего узла Proxmox создаёт символическую ссылку на файл настройки Ceph в /etc/ceph/ceph.conf.

Помимо файла настройки Ceph также применяет ключи аутентификации, которые хранятся в следующих каталогах:

/etc/pve/priv/ceph.client.admin.keyring
/etc/pve/priv/ceph.mon.keyring
/etc/pve/priv/ceph/<rbd_storage_id>.keyring
 	   

Для соединения с хранилищем Ceph RBD (Rados Block Device), Proxmox нуждается в отдельном кольце ключей. <rbd_storage_id>.keyring является просто скопированной и переименованной версией ceph.client.admin.keyring. Без этого кольца ключей Proxmox не сможет соединиться с Ceph.

Что касается Proxmox 4.1, полностью функциональный межсетевой экран встроен в кластер Proxmox. Он очень мощный и поставляется с гранулированной персонализацией вниз вплоть до отдельной виртуальной машины. Правила межсетевого экрана могут создаваться отдельно для кластера, узла и виртуальной машины. Следующая таблица отображает местоположения файлов правил межсетевого экрана:

Наименование правил	Путь каталога
Правила межсетевого экрана всего кластера	/etc/pve/firewall/cluster.fw
Правила межсетевого экрана узла	/etc/pve/nodes/<node_id>/host.fw
Правила межсетевого экрана VM/CT	/etc/pve/firewall/<vm_id>.fw

Все правила межсетевого экрана могут управляться с помощью меню межсетевого экрана GUI Proxmox/ без их редактирования с применением командной строки. Мы рассмотрим подробнее межсетевой экран в Главе 8, Межсетевой экран Proxmox.

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

В этой главе мы рассмотрели местоположение важных файлов настройки необходимых для работы кластера Proxmox. Мы также заглянули вовнутрь этих файлов настройки для лучшего понимания применяемых параметров и других допустимых значений для различных параметров. Как уже упоминалось ранее, большинство этих файлов настройки могут изменяться из GUI Proxmox. Однако если GUI становится недоступным по какой- либо причине, знание того, где расположены эти файлы может сохранить значительное количество времени для доступа к ним из CLI.

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