1. Сховище даних [ правити ]
2. Підключення загального сховища iSCSI (Multipath) з використанням LVM [ правити ]
3. Мережева підсистема [ правити ]
4. Налаштування мережевої підсистеми [ правити ]
5. Налаштування взаємодії компонентів PVE [ правити ]
6. Запуск служб кластера [ правити ]
7. VM: віртуальні машини kvm [ правити ]
8. Сховища даних [ правити ]
9. Створення віртуальної машини [ правити ]
10. Налаштування мережевих підключень [ правити ]
11. VirtIO [ правити ]
12. Віддалений доступ до віртуальної машини [ правити ]
13. Міграція віртуальних машин з VMware в ALT PVE [ правити ]
14. Обслуговування віртуальних оточень [ правити ]
15. Статистика [ правити ]
16. Управління доступом [ правити ]
17. Резервне копіювання [ правити ]
18. снапшоти [ правити ]

Proxmox Virtual Environment (PVE) - засіб управління віртуальними оточеннями на базі гипервизора KVM і системи контейнерної ізоляції LXC . Строго кажучи, PVE це не система віртуалізації, а інструментарій управління середовищем, в якій виконуються віртуальні оточення KVM і LXC. Основними компонентами середовища є:

• фізичні сервери, на яких виконуються процеси гипервизора KVM, і процеси, що працюють в контейнерах LXC;
• сховища даних, в яких зберігаються образи настановних дисків, образи дисків віртуальних машин KVM і файли, доступні з контейнерів LXC;
• віртуальні мережеві комутатори, до яких підключаються мережеві інтерфейси віртуальних оточень.

Власне PVE складається з веб-інтерфейсу, розподіленого сховища даних конфігурації віртуальних оточень, а також утиліт конфігурації, які працюють в командному рядку. Всі ці інструменти призначені тільки для управління середовищем виконання віртуальних оточень. За формування середовища відповідають компоненти системи, що не входять безпосередньо до складу PVE. В першу чергу це мережева і дискова підсистеми, а також механізми аутентифікації.

Веб-інтерфейс користувача PVE призначений для вирішення наступних завдань:

• створення, видалення, налаштування віртуальних оточень;
• управління фізичними серверами;
• моніторинг активності віртуальних оточень і використання ресурсів середовища;
• фіксація станів (snapshot-и), створення резервних копій і шаблонів віртуальних оточень, відновлення віртуальних оточень з резервних копій.

Крім вирішення користувальницьких задач, веб-інтерфейс PVE можна використовувати ще і для вбудовування в інтегровані системи управління - наприклад, в панелі управління хостингом. Для цього він має розвинений RESTful API з JSON в якості основного формату даних.

Для аутентифікації користувачів веб-інтерфейсу можна використовувати як власні механізми PVE, так і PAM. Використання PAM дає можливість, наприклад, інтегрувати PVE в домен аутентифікації.

Сховище даних [ правити ]

У разі локальної установки PVE для розміщення даних віртуальних оточень можна додатково нічого не налаштовувати і використовувати локальну файлову систему сервера. Але в разі кластера з декількох серверів має сенс налаштувати мережеву або розподілену мережеву файлову систему, що забезпечує паралельний доступ до файлів з усіх серверів, на яких виконуються процеси віртуальних оточень. В якості таких файлових систем можуть виступати, наприклад, NFS або CEPH .

Підключення загального сховища iSCSI (Multipath) з використанням LVM [ правити ]

Налаштування iSCSI-target на базі ALT докладно описана в цієї статті .

Увага! iSCSI initiator налаштовується засобами ALT PVE.
Сервіс iscsid запускається засобами ALT PVE і не повинен бути присутнім в атозагрузке

Вихідні дані:

• Налаштований кластер ALT PVE
• Налаштований iSCSI target

Для додавання iSCSI пристрою треба зайти в web-інтерфейс ALT PVE в розділ Datacenter -> Storage -> Add -> iSCSI:

• ID: Ім'я додається пристрої, може бути будь-яким, але змінити його пізніше не можна
• Portal: Адреса iSCSI сервера
• Target: Список, що випадає ресурсів, що віддаються iSCSI сервером
• Nodes: Яким Нодаме буде доступно дане сховище
• Enable: вмикання / вимикання сховище
• Use LUNs directly: Використання LUN безпосередньо, галочку треба зняти

Ту ж процедуру треба проробити для другого адреси iSCSI сервера.
Після цього на всіх нодах з'являться два блочних пристрої.
Далі необхідно налаштувати Multipath по цій інструкції
Далі переходимо в консоль на будь-який ноді для настройки LVM.
Для коректної роботи LVM і Multipath говоримо LVM не перевіряти наші iSCSI-диски (sd *):
У файл /etc/lvm/lvm.conf додаємо:

devices {... filter = [ "r | / dev / sd |" ] ...}

Ініціалізіруем блокові пристрої для використання в LVM:

# Pvcreate / dev / mapper / mpatha

Створюємо групу томів 'sharedsv':

# Vgcreate sharedsv / dev / mapper / mpatha

Далі переходимо в web-інтерфейс ALT PVE в розділ Datacenter -> Storage -> Add -> LVM:

• ID: Ім'я додається пристрої, може бути будь-яким, але змінити його пізніше не можна
• Base Storage: Вибираємо 'Existing volume groups'
• Volume group: Список, що випадає LVM розділів, вибираємо створений нами 'sharedsv'
• Content: Що дозволено зберігати на даному сховище
• Nodes: Яким Нодаме буде доступно дане сховище
• Enable: вмикання / вимикання сховище
• Shared: Робить сховище доступним для всіх нод

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

Мережева підсистема [ правити ]

На відміну від сховища даних, мережева підсистема вимагає спеціальної установки навіть в разі локальної установки PVE. Це обумовлено тим, що мережеві інтерфейси віртуальних оточень повинні підключатися до якогось віртуального ж пристрою, що забезпечує з'єднання із загальною мережею передачі даних. Зазвичай в якості такого пристрою виступає Ethernet-міст.

Як сервер для розгортання PVE потрібно використовувати серверверний дистрибутив Альт на базі 8-ї платформи і доустановити необхідні пакети штатним способом будь-яким штатним способом (apt-get, aptitude, synaptic) встановити пакет pve-manager. Всі необхідні компоненти при цьому будуть встановлені автоматично. Також слід переконатися в тому, що пакет systemd оновлений до версії, що знаходиться в репозиторії P8.

На всіх нодах: # apt-get install pve-manager

Розглянемо налаштування кластера PVE. Локальну установку будемо вважати окремим випадком кластера з одного вузла.

Налаштування мережевої підсистеми [ правити ]

Якщо у файлі options інтерфейсу не заданий TYPE =, pve-manager завершується з помилкою

Спочатку на всіх вузлах кластера налаштуємо Ethernet-міст відповідно до керівництвом :

#ip = $ (hostname -i) #cat> / etc / net / ifaces / ens18 / options << EOF TYPE = eth EOF #mkdir -p / etc / net / ifaces / vmbr0 #cat> / etc / net / ifaces / vmbr0 / options << EOF BOOTPROTO = static TYPE = bri HOST = 'ens18' CONFIG_WIRELESS = no CONFIG_IPV4 = yes EOF #cat> / etc / net / ifaces / vmbr0 / ipv4address << EOF $ ip / 21 EOF #cat> / etc / net / ifaces / vmbr0 / ipv4route << EOF default via 10.88.8.1 EOF cat> /etc/net/ifaces/vmbr0/resolv.conf << EOF search example.com test.com nameserver 10.0.0.0 EOF # cat < <EOF> / etc / net / ifaces / vmbr0 / brctl stp AUTO off setfd AUTO 0 EOF

Ім'я інтерфейсу, позначеного тут як ens18, слід вказати відповідно до реальної конфігурацією сервера.

При встановлених пакетах alterator-net-eth і alterator-net-bridge замість всього цього можна просто скористатися web-інтерфейсом.

Основна частина розробки PVE ведеться під ОС Debian, і в зв'язку з цим в свіжих версіях PVE іноді виникають кумедні нюанси. Так в поточній версії конфігурація Ethernet-мостів і інформація про тимчасові зонах зчитується зі специфічних для Debian і його похідних конфігураційних файлів / etc / network / interfaces і / etc / timezone. Тому, поки похибка не виправлена, настройки доведеться продублювати:

# Printf "\ nauto vmbr0 \ n \ tiface vmbr0 inet static \ n \ taddress 10.8.8.251 \ n \ tnetmask 255.255.255.0 \ n \ tgateway 10.88.8.1 \ n \ tbridge_ports ens18 \ n \ tbridge_stp off \ n \ tbridge_fd 0 \ n ">> / etc / network / interfaces #. / Etc / sysconfig / clock # echo $ ZONE> / etc / timezone # ln -sf / usr / share / zoneinfo / $ ZONE / etc / localtime

Далі необхідно забезпечити взаємно однозначне пряме і зворотне перетворення імен для всіх вузлів кластера. Вкрай бажано використовувати DNS, але в крайньому випадку можна обійтися відповідними записами в локальних файлах / etc / hosts:

# Echo "10.88.8.251 pve1.localdomain pve1" >> / etc / hosts # echo "10.88.8.252 pve2.localdomain pve2" >> / etc / hosts # echo "10.88.8.253 pve3.localdomain pve3" >> / etc / hosts

При цьому ім'я машини НЕ повинно бути присутнім у файлі / etc / hosts, дозволяється в 127.0.0.1!

Налаштування взаємодії компонентів PVE [ правити ]

В якості транспорту для передачі команд між вузлами кластера застосовується протокол SSH. Якщо ми налаштовуємо локальну установку PVE, нічого спеціального робити не потрібно, а якщо вузлів в кластері буде кілька, необхідно на кожному вузлі дозволити передачу змінної оточення LC_PVE_TICKET:

# N = $ (($ (sed -n '/ ^ AcceptEnv / {=}' / etc / openssh / sshd_config | tail -1) + 1)); sed -i "$ {N} i AcceptEnv LC_PVE_TICKET \ n" / etc / openssh / sshd_config # N = $ (($ (sed -n '/ ^ [[: space:]] * SendEnv / {=}' / etc / openssh / ssh_config | tail -1) + 1)); sed -i "$ {N} i \ \ \ \ SendEnv LC_PVE_TICKET \ n" / etc / openssh / ssh_config # systemctl restart sshd

Крім того, для передачі команд між вузлами кластера необхідно забезпечити взаємну беспарольному аутентифікацію користувача root. Це можна зробити вручну, а можна при додаванні нового вузла в кластер PVE дозволити на «провідному» вузлі вхід користувача root за паролем і ввести пароль. Після цього взаємна беспарольному аутентифікація root буде налаштована автоматично утилітами PVE, і вхід root по паролю можна буде знову відключити.

Важливо розуміти, що в сконфігурованої кластері PVE всі вузли рівноправні. «Провідним», «головним» і так далі один з вузлів стає тільки в момент додавання в кластер нового вузла. Після додавання новий вузол може стати таким же ведучим при проведенні такої процедури додавання чергового вузла в кластер.

Тепер залишилося налаштувати ще два компонента системи, які утиліти PVE поки не можуть повністю автоматично налаштувати при запуску кластера. Це демон rrdcached, що відповідає за зберігання даних моніторингу активності підсистем кластера, і corosync - комплекс ПО, що забезпечує в межах кластера елементи високої доступності.

Виконати на всіх нодах: # sh / usr / share / doc / pve-cluster / pve-firsttime # cp /usr/share/doc/pve-cluster/rrdcached.sysconfig / etc / sysconfig / rrdcached # mkdir -p / var / lib / rrdcached / {db, journal} # rm -f /etc/corosync/corosync.conf

Конфігураційний файл corosync після цього буде створено автоматично при ініціалізації кластера PVE.

Запуск служб кластера [ правити ]

Запускаємо служби кластера і налаштовуємо їх автоматичний запуск при старті вузла:

# Systemctl start ntpd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target # systemctl enable ntpd rrdcached ksmtuned crond lxcfs openvswitch nfs-client.target

Далі, на «головному» (див. Вище) вузлі кластера виконуємо команди власне ініціалізації конкретного кластера PVE, в даному випадку - «mypve»:

Увага! Якщо після переустановлення pve неможливо форматувати кластер: cluster config '/etc/pve/corosync.conf' already exists видаліть файл /etc/pve/corosync.conf

# Systemctl start pve-cluster # ip = $ (hostname -i) # pvecm create pve --ring0_addr $ ip

На «підлеглих» (див. Вище) вузлах:

Увага! Якщо при додаванні вузла виникає помилка: * cluster config '/etc/pve/corosync.conf' already exists необхідно додати опцію -force

ip = $ (hostname -i) systemctl start pve-cluster pvecm add 10.88.10.251 --ring0_addr $ ip

Далі, запускаємо інші служби і додаємо їх в список служб, що запускаються при старті вузла:

# Systemctl start lxc lxc-net lxc-monitord pvedaemon pve-firewall pvestatd pve-ha-lrm pve-ha-crm spiceproxy pveproxy # systemctl enable corosync lxc lxc-net lxc-monitord pve-cluster pvedaemon pve-firewall pvestatd pve-ha- lrm pve-ha-crm spiceproxy pveproxy pve-guests

Подальші налаштування кластера зручно робити через веб інтерфейс.

В ході роботи з веб-інтерфейсом PVE оператору доводиться мати справу з такими основними об'єктами: фізичними вузлами, віртуальними оточеннями, сховищами даних і суб'єктами авторизації. Так як PVE є засобом управління віртуальними оточеннями, розглядати взаємодію компонентів ми будемо щодо них. Віртуальні оточення під керуванням PVE бувають двох типів: повністю віртуалізовані, керовані гіпервізором kvm, і ізольовані оточення виконуються безпосередньо на основному ядрі ОС фізичного вузла. Перші в термінах PVE називаються VM (віртуальні машини), а другі - CT (контейнери, ConTainers). Почнемо з VM.

VM: віртуальні машини kvm [ правити ]

Віртуальні машини, керовані гіпервізором kvm, з точки зору операційної системи фізичного вузла, на якому вони виконуються, є один процес гипервизора kvm. Вони взаємодіють з фізичним обладнанням не безпосередньо, а тільки через гипервизор. Все обладнання, яке є операційній системі всередині віртуальної машини, включаючи процесор і пам'ять, є віртуальним. Навіть віртуальна мережева карта підключається віртуальним кабелем до віртуального комутатора. Дискові контролери теж є віртуальними, а дискові накопичувачі зазвичай являють собою файли на файлової системі фізичного вузла, на якому виконується процес гипервизора.

Сховища даних [ правити ]

У разі, коли PVE керує не одним фізичним вузлом, а кластером фізичних вузлів, повинна забезпечуватися можливість міграції VM з одного фізичного вузла на інший. Міграція являє собою заморозку стану VM на одному вузлі, перенесення даних і конфігурації на інший вузол, і розмороження стану VM на новому місці. Так як віртуальні дискові накопичувачі VM можуть займати значний обсяг, зручно в межах середовища віртуалізації PVE оперувати локальними файловими системами фізичних вузлів, а сховищами даних, доступними з усіх вузлів кластера. Крім того, дуже зручно, коли образи завантажувальних інсталяційних дисків ОС, які ми розгортається на віртуальних машинах, також були доступні відразу на всіх вузлах кластера. Щоб не доводилося копіювати сотні мегабайт файлів .iso з машини на машину, коли нам захочеться розгорнути кілька однотипних VM на різних фізичних вузлах.

Сховищами даних зручно управляти через веб-інтерфейс. Як бекенд сховищ PVE може використовувати:

• мережеві файлові системи, в тому числі розподілені: NFS, CEPH, GlusterFS;
• локальні системи управління дисковими томами: LVM, ZFS;
• віддалені (iSCSI) і локальні дискові томи;
• локальні дискові каталоги.

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

При створенні кожного сховища даних присвоюється роль або набір ролей. Наприклад, зберігання контейнерів, образів віртуальних дисків, файлів .iso і так далі. Список можливих ролей залежить від бекенд сховища. Наприклад, для NFS або каталогу локальної файлової системи доступні будь-які ролі або набори ролей.

Відразу після ініціалізації кластера в межах кожного з вузлів нам є одне локальне сховище даних. Цього вже цілком достатньо для початку роботи.

Створення віртуальної машини [ правити ]

Перш ніж створити в інтерфейсі PVE віртуальну машину (VM), необхідно визначитися з наступними моментами:

• звідки буде завантажений інсталятор ОС, яку ми будемо встановлювати всередину віртуальної машини;
• на якому фізичному вузлі буде виконуватися процес гипервизора kvm;
• на якому сховище даних будуть розташовуватися образи дисків віртуальної машини.

Всі інші параметри VM відносяться до конфігурації віртуального комп'ютера і можуть бути визначені по ходу процесу створення VM.

Так як сховища даних у нас поки тільки локальні, визначимося з фізичним вузлом на якому буде створено віртуальне оточення. Щоб встановити ОС на віртуальну машину, розташовану на цьому вузлі, потрібно забезпечити можливість завантаження інсталятора на цій віртуальній машині. Для цього завантажимо ISO-образ інсталятора в сховище даних обраного фізичного вузла. Це також зручно робити через веб-інтерфейс.

Тепер, коли все попередні дії виконані, натискаємо в веб-інтерфейсі PVE кнопку «Створити VM» в правому верхньому кутку.

Процес створення VM оформлений у вигляді «майстри», звичного для користувачів систем управління віртуальними машинами. Проходячи по черзі по вкладках, вибираємо, відповідно, унікальне ім'я VM, шаблон налаштувань ОС, файл .iso, з якого буде завантажуватися інсталятор ОС, тип дискового контролера, формат і розмір образу віртуального жорсткого диска, сховище даних, на якому він буде розташовуватися, кількість ядер процесора і об'єм оперативної пам'яті і так далі. Окрему увагу звернемо на настройки типу підключення дискових накопичувачів настройки доступу до мережі.

Налаштування мережевих підключень [ правити ]

Існує два основних способи підключення VM до мережі:

• через трансляцію мережевих адрес;
• через ethernet-міст.

Перший спосіб рекомендується до використання в ситуаціях, коли ми не плануємо використовувати віртуальну машину в якості сервера якихось мережевих протоколів. Наприклад, коли ми просто хочемо протестувати процес інсталяції ОС. Механізм NAT буде налаштований автоматично, без додаткових дій оператора, досить буде просто в процесі створення віртуальної машини поставити радіокнопку на вкладці «Сеть» в положення «NAT mode».

В процесі настройки гостьовий ОС потрібно буде вибрати автоматичний варіант настройки мережевих адрес за протоколом DHCP. З боку гипервизора kvm буде піднято сервер DHCP, який видасть гостьовий системі мережеву адресу і маршрути. Також, з боку гипервизора буде автоматично налаштована трансляція всіх адрес виданих вбудованим сервером DHCP. Таким чином додатки, що працюють в гостьовій ОС, отримають доступ до всіх мереж, до яких має доступ ОС фізичного вузла, причому з боку цих мереж вони будуть маскуватися під адресою самого фізичного вузла.

Другий спосіб підключення рекомендується у всіх інших ситуаціях. У цьому випадку, з огляду на налаштування, зроблені нами при установці PVE, мережевий інтерфейс віртуальної машини буде підключений до того ж самому віртуальному комутатора, що і мережевий інтерфейс фізичного вузла. Тобто, настройки мережної підсистеми віртуальної машини залежать від конфігурації тієї самої мережі, в якій знаходиться фізичний вузол. Наприклад, якщо в цій мережі працює сервер DHCP, який зможе видати потрібну адресу віртуальної машині, можна вказати автоматичний варіант конфігурації. Якщо немає - доведеться налаштовувати вручну. На відміну від першого способу, де ручний варіант налаштувань не передбачається (хоча, і можливий).

VirtIO [ правити ]

Налаштовуючи з'єднання з мережами, звертаємо Рамус такоже и на ті, что в списку мережевих карт, Які может емулюваті гипервизор kvm, є пункт «VirtIO (paravirtualized)». Це Спеціальний інтерфейс, завдання которого є зниженя накладних витрат на емуляцію фізичної мережевої карти и реалізацію драйвера для роботи з нею. Між виробниками сучасних операційних систем і проізоводітелямі сучасних гіпервізора існує домовленість про підтримку єдиного інтерфейсу VirtIO, який з боку гостьової ОС виглядає як дуже проста і продуктивна мережева карта, а з боку гипервизора - як прямий інтерфейс до мережевого драйверу гостьовий ОС. Таким чином, продуктивність істотно зростає за рахунок того, що не потрібно більше емулювати неіснуюче залізо. Якщо про гостьову ОС точно відомо, що вона підтримує VirtIO, має сенс використовувати саме цю «мережеву карту».

До речі, реалізація VirtIO існує також і для іншого інтерфейсу між віртуальною ОС і гіпервізором, критичного до швидкості передачі даних - для дискових накопичувачів. Там рекомендації точно такі ж - якщо впевненість у підтримці з боку гостьової ОС є, включаємо.

Віддалений доступ до віртуальної машини [ правити ]

Після того, як вибір параметрів віртуальної машини закінчений і натиснута кнопка «Завершити», віртуальна машина створена. Тепер потрібно отримати віддалений доступ до її консолі. У PVE для віддалений доступ до «фізичної» консолі віртуальної машини використовується протокол VNC. Як клієнт виступає додаток на Javascript, інтегроване в вікно браузера.

Міграція віртуальних машин з VMware в ALT PVE [ правити ]

Цей розділ описує міграцію віртуальних машин з VMware в ALT PVE, на прикладі віртуальної машини з Windows 7.
Підготовка операційної системи Windows
Необхідно зробити так, щоб система вантажилася з дисків в режимі IDE.
Підготовка образу диска
Припустимо що файл з образом диска називається win7.vmdk
За допомогою vmware-vdiskmanager (утиліта поставляється в комплекті з VMWare Workstation) Вам необхідно перетворити Ваш образ диска в тип "single growable virtual disk". Для цього в перейдіть в папку з образами дисків і виконайте наступну команду:

"C: \ Program Files \ VMware \ VMware Server \ vmware-vdiskmanager" -r win7.vmdk -t 0 win7-pve.vmdk

Підключення образу диска до віртуальної машини на основі Directory Storage
Створіть нову віртуальну машину KVM, використовуючи web-інтерфейс ALT PVE, але не запускайте її. Подивіться VMID, створеної віртуальної машини (наприклад 100).

Скопіюйте перетворений образ win7-pve.vmdk в директорію з образами віртуальних машин

/ Var / lib / vz / images / VMID

(Для цього можна скористатися WinSCP).

Перетворіть файл win7-pve.vmdk в qemu формат:

# Qemu-img convert -f vmdk win7-pve.vmdk -O qcow2 win7-pve.qcow2

Для підключення образу диска до створеної віртуальної машині Вам необхідно додати в конфігураційний файл /etc/pve/nodes/node01/qemu-server/VMID.conf віртуальної машини наступний рядок:

unused0: locald: 100 / win7-pve.qcow2.qcow2

де 100 це VMID, а locald це ім'я сховища в ALT PVE. Далі перейдіть в web-інтерфейс ALT PVE на вкладку Hardware, створеної віртуальної машини. У списку пристроїв ви побачите невикористаний жорсткий диск, клацніть на нього, виберете режим IDE і натисніть кнопку Add:

Підключення образу диска до віртуальної машини на основі LVM Storage
Створіть віртуальну машину використовуючи web-інтерфейс ALT PVE з диском більшого розміру, ніж диск в образі vmdk. Подивитися розмір диска в образі можна командою:

# Qemu-img info win7-pve.vmdk image: win7-pve.vmdk file format: vmdk virtual size: 127G (136365211648 bytes) disk size: 8.5G cluster_size: 65536 Format specific information: cid: 3098509145 parent cid: 4294967295 create type : monolithicSparse extents: [0]: virtual size: 136365211648 filename: win7-pve.vmdk cluster size: 65536 format:

В даному випадку необхідно створити диск в режимі IDE розміром не менше 127GB, не запускайте віртуальну машину.
Скопіюйте перетворений образ win7-pve.vmdk на потрібну ноду кластера.
Перейдіть в консоль Ноди кластера і подивіться як називається LVM диск створеної віртуальної машини (він повинен бути в статусі ACTIVE):

# Lvscan ACTIVE '/ dev / sharedsv / vm-101-disk-1' [130,00 GiB] inherit

Далі необхідно конвертувати образ vdmk в raw формат безпосередньо на LVM-пристрій:

# Qemu-img convert -f vmdk win7-pve.vmdk -O raw / dev / sharedsv / vm-101-disk-1

Підключення образу диска до віртуальної машини на основі CEPH Storage
Створіть віртуальну машину використовуючи web-інтерфейс ALT PVE з диском більшого розміру, ніж диск в образі vmdk.
Скопіюйте перетворений образ win7-pve.vmdk на потрібну ноду кластера.
Перейдіть в консоль Ноди кластера. Ім'я потрібного пулу можна подивитися на вкладці Datacenter-> Storage-> rbd-storage:

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

# Rbd map rbd01 / vm-100-disk-1 / dev / rbd0

Далі необхідно конвертувати образ vdmk в raw формат безпосередньо на відображене пристрій:

# Qemu-img convert -f vmdk win7-pve.vmdk -O raw / dev / rbd0

Проблеми з образом VMware
Крім того Ваш образ диска може бути в форматі flat, тоді при спробі конвертувати його ви отримаєте помилку "Operation not permitted". Ви можете подивитися справжній формат вашого .vdmk файлу за допомогою команди "file". Якщо файл у форматі flat то ви отримаєте приблизно такий висновок:

# File myVMwFlatImage-pre.vmdk myVMwFlatImage-pre.vmdk: x86 boot sector; partition 1: ID = 0x83, active, starthead 1, startsector 63, 208 782 sectors; partition 2: ID = 0x8e, starthead 0, startsector 208845, 16563015 sectors, code offset 0x48

Дуже просто конвертувати такий файл з .vdmk в .qcow2 просто прибравши параметр "-f vdmk" з попередньої команди, надавши qemu-img автоматично визначити формат вихідного файлу:

# Qemu-img convert myVMwFlatImage-pve.vmdk -O qcow2 myVMwFlatImage-pve.qcow2

Якщо ваша віртуальна машина KVM стартує, але не вантажиться з помилкою "booting from hard disk ... boot failed: not a bootable disk", то спробуйте при конвертації замість типу диска "single growable virtual disk" тип "preallocated virtual disk". Для цього в командному рядку запустіть vmvare-vdiskmanager без параметрів, Ви побачите довідку по роботі з командою. Тип диска при конвертації задає параметр -t <disk-type>:

Disk types: 0: single growable virtual disk 1: growable virtual disk split in 2GB files 2: preallocated virtual disk 3: preallocated virtual disk split in 2GB files 4: preallocated ESX-type virtual disk 5: compressed disk optimized for streaming

Нам потрібно вибрати тип 2:

vmware-vdiskmanager -r whatever.vmdk -t 2 whatever-pve.vmdk

Майте на увазі, що при цьому vmware-vdiskmanager створить два файли. Перший файл whatever-pve.vmdk дуже маленький, це звичайний текстовий файл з посиланням на образ. Другий файл whatever-pve-flat.vmdk, який має розмір всього Вашого віртуального диска і саме його треба конвертувати в kvm.
Адаптація нової віртуальної машини KVM

• Перевірте режим роботи жорсткого диска для Windows - IDE, для Linux SCSI
• Режим VIRTIO жорсткого диска:
  • Режим VIRTIO також доступний для Windows, але відразу завантажитися в цьому режимі система не може
  • Завантажитеся спочатку в режимі IDE і вимкніть машину, додайте ще один диск в режимі VIRTIO і включіть машину, Windows встановить потрібні драйвера
  • вимкніть машину
  • Змініть режим основного диска з IDE на VIRTIO
  • Завантажте систему, яка повинна застосувати VIRTIO драйвер і видати повідомлення, що драйвер від RedHat
• Увімкніть віртуальну машину
• Перше включення займе якийсь час поки будуть завантажені необхідні драйвера
• Драйвера VIRTIO для Windows можна завантажити тут

На відміну від віртуальної машини, яка з точки зору ОС, запущеної на фізичному вузлі, являє собою один процес гипервизора, процеси контейнера виконуються на тому ж самому ядрі, що і інші процеси ОС. Тобто, якщо ми запустимо VM і CT на одному і тому ж фізичному вузлі PVE, процеси CT будуть виконуватися «поруч» з процесами гипервизора. Різниця буде лише в застосуванні до процесів контейнерів механізмів ізоляції - просторів імен (Namespaces) і груп управління (CGroups) - працюють на рівні ядра Linux.

Існує кілька реалізацій ізольованих контейнерів, які базуються на цих механізмах. например OpenVZ и LXC , Які відрізняються розвиненістю і пропрацьованністю механізмів управління. У PVE версій 4+ використовується реалізація LXC (до 3 версії використовувалася OpenVZ), загорнута додатковим власним призначеним для користувача інтерфейсом, що робить процес створення і обслуговування контейнерів ще більш зручним.

Процес створення контейнера багато в чому схожий з процесом створення віртуальної машини. Різниця в тому, що створення контейнера відповідає створенню VM і одночасно установці туди операційної системи. Еквівалентом інсталяційного диску є шаблон, з якого розгортається контейнер. Це архів, що містить кореневу файлову систему майбутнього контейнера. Приклади шаблонів контейнерів можна знайти на сайті розробників PVE и в колекції шаблонів OpenVZ .

Важліво пам'ятати, что шаблони, придатні для розгортання CT в PVE , Мають власну нотацію імен, що відрізняється від таких, наприклад, в OpenVZ. Тому перед завантаженням чергового шаблону в сховище PVE не забуваємо перейменувати його відповідним чином.

Майже весь процес «інсталяції» зводиться до розпакуванні шаблону. Частина, що залишилася процесу інсталяції полягає в тому, щоб надати розпакованого образу кореневої файлової системи унікальні риси, які відрізняють його від інших таких же контейнерів, створених, можливо, з цього ж самого шаблону.

Унікальність контейнера забезпечується на двох рівнях: перший рівень це унікальний ідентифікатор контейнера в межах ОС фізичного вузла, в якій розгортаються контейнери. Це число, як правило більше ста. PVE автоматизованим чином веде облік ідентифікаторів і при створенні контейнера не дозволить вибрати вже зайнятий. До речі, в межах кластера PVE ідентифікатори VM і СТ складають єдиний простір ідентифікаторів.

Другий рівень унікальності контейнера - строго кажучи, не обов'язковий - це мережеві настройки: IP-адреса і ім'я вузла. Забезпечувати унікальність на цьому рівні не обов'язково, так як у нас може бути кілька контейнерів з однаковим ім'ям вузла, IP-адресою, і навіть MAC-адресою. Просто вони будуть запускатися в різний час. Але стежити за цим буде вже не PVE, а оператор. PVE тільки забезпечує можливість завдання мережевих налаштувань контейнера при його створенні.

Основне завдання CT, на відміну від VM - НЕ запуск повноцінної ОС у віртуальній машині, а запуск окремого додатка або мережевий служби в ізольованому оточенні. Тому доступ для обслуговування CT, як правило, зручніше здійснювати через звичайний термінал - тобто, вже без участі інтерфейсу PVE. Для цього всередині контейнера налаштовують серверну частину SSH, VNC або навпаки - клієнтську частину X-протоколу. Втім, веб-інтерфейс надає для CT, так само, до речі, як і для фізичних вузлів консоль. Звичайну текстового термінала UNIX.

Обслуговування віртуальних оточень [ правити ]

Крім створення, видалення і отримання доступу до консолі існує ще ряд важливих завдань по роботі з віртуальними оточеннями, які веб-інтерфейс PVE дозволяє успішно вирішувати. Це в першу чергу збір статистики по витрачанню ресурсів кластера PVE, управління доступом до об'єктів віртуальної інфраструктури, і забезпечення безперебійної роботи в разі збоїв.

Статистика [ правити ]

Протягом всього часу роботи кластера PVE збирає статистику по широкому спектру параметрів, що характеризують різні види навантаження на фізичні вузли, сховища даних і віртуальні оточення. Статистична інформація збирається, зберігається, і може бути в будь-який момент представлена ​​у вигляді графіків і діаграм.

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

Управління доступом [ правити ]

Як уже згадувалося в керівництві по установці, PVE може використовувати будь-які бази даних облікових записів користувачів, доступні через механізм PAM. Наприклад, бази локальних користувачів фізичних вузлів кластера. Крім того, у PVE є ще й своя база даних облікових записів користувачів і груп. Всі ці користувачі та групи є повноправними суб'єктами доступу до об'єктів кластера. Об'єктами доступу є фізичні вузли і сховища даних. Повноваження суб'єктів доступу налаштовуються через механізм ролей.

Для спрощення розмежування доступу в PVE існує ще один рівень об'єктів доступу, функціонально аналогічний групам - пули. До складу пулу можуть входити віртуальні оточення і деякі види сховищ даних. Доступ до пулів регулюється так само через механізм призначення ролей.

Резервне копіювання [ правити ]

На радість системним адміністраторам PVE має вбудовану систему резервного копіювання. Додати черговий пункт в розклад зняття резервних копій стану віртуальних оточень і сховищ даних можна буквально «в кілька кліків».

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

Формат і режим зняття резервних копій можуть бути різними. Це можуть бути образи зупинених віртуальних оточень, які перебувають в Консистентне стані, або снапшоти, зроблені «на льоту». В останньому випадку працездатність сервісів, запущених всередині віртуального оточення, після відновлення з резервної копії не гарантується.

снапшоти [ правити ]

Крім зняття резервних копій, снапшоти використовуються і просто для фіксації стану віртуального оточення. Для фіксації снапшотов є спеціальний пункт в меню віртуального оточення в інтерфейсі PVE.