Порада

Для досягнення максимальної продуктивності і стабільності вам настійно рекомендується вибирати відповідний тип ОС.

Закладка CD / DVD

Так як ВМ KVM є повністю вкладеної і емулює фізичну машину, ми можемо тільки виконувати завантаження цієї ВМ або завантажувати операційну систему за допомогою образів ISO, що завантажуються в нашому віртуальному пристрої CD / DVD або з фізичного пристрою, підключеного до вузла хоста Proxmox. В даній закладці ми можемо вибрати чи будемо ми використовувати віртуальне або фізичне пристрій, або ж відібрати образ ISO. Наведений нижче знімок екрана відображає блок діалогу для закладки CD / DVD:

Якщо ми хочемо створити свою ВМ без визначення будь-якого образу диска, нам потрібно буде вибрати опцію Do not use any media.

Закладка Hard Disk

У цій закладці ми визначаємо настройки для нашого першого образу диска створюваної ВМ. Наступний знімок екрана відображає блок діалогу з налаштуванням для нашого прикладу ВМ:

Bus / Device

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

Порада

Для досягнення максимальної продуктивності рекомендується шина VIRTIO.

Для ВМ Windows необхідно вибирати IDE, оскільки Windows не має вбудованого драйвера VIRTIO. У подібному випадку ми можемо скористатися наступними кроками для додавання можливості VIRTIO в ВМ Windows:

1. Створіть ВМ з IDE і встановіть Windows звичайним чином.

2. Додайте другий образ диска з шиною VIRTIO і перезавантажте Windows.

3. Скачайте найостанніший ISO драйвера VIRTIO для Windows зі наступних посилань, а потім завантажте його через віртуальне CD пристрій:

   https://fedorapeople.org/groups/virt/virtio-win/directdownloads/stable-virtio/virtio-win.iso

   http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers

4. Оновлення свій драйвер для нового обладнання знайденого для вашого образу диска VIRTIO.

5. Зупиніть ВМ Windows і зареєструйтеся в інструментальній панелі Proxmox.

6. У закладці Hardware цієї ВМ виберіть образ IDE і натисніть Remove. Відзначимо що це не видалить цей образ диска остаточно. Даний образ диска тепер буде показаний як Unused, як це відображено на наступному малюнку:

   
   

7. Виберіть Unused disk і натисніть Edit. Це відкриє блок діалогу з опціями для вибору типу Bus / Device і іншими параметрами показаними на знімку екрана нижче:

   
   

   У блоці діалогу ми можемо вибрати потрібний тип Bus та інші опції настройки в разі потреби.

8. Натисніть Add для додавання цього образу диска назад до даної ВМ.

   Попередні кроки необхідні для надання ВМ Windows можливості використання образу диска VIRTIO. Коли даний драйвер завантажений, немає необхідності перезавантажуватися для додаткових образів дисків VIRTIO.

Storage

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

Disk size

Це текстовий блок для визначення розміру вашого дискового сховища в ГБ. Значення може бути тільки чисельною. Ми також можемо застосовувати стрілки вгору і вниз для визначення даного розміру.

Format

Це спадаюче меню для вибору типу образу диска. Якщо ми вибираємо сховище, яке підтримує тільки певні типи дисків, то ці опції меню будуть пофарбовані сірим. Наприклад, якщо ми вибираємо сховище Ceph RBD, то дана опція буде прихована сірим (як показано на наступному малюнку), так як RBD підтримує тільки формат .raw.

Якщо ми виберемо хибний формат образу свого диска, або якщо ми пізніше вирішимо використовувати інший формат, ми можемо просто скористатися параметром Move disk в закладці Hardware для зміни формату. Це також можна зробити в CLI застосувавши таку команду:

# Qemu-img convert -O <type> <source_image> <destination_image>

Якщо ми хочемо перетворити образ диска .qcow2 в образ .raw, команда повинна мати такий вигляд:

# Qemu-img convert -O raw vm-101-disk-1.qcow2 vm-101-disk-1.raw

Ця команда добре працює для локальних сховищ, а також для сховищ NFS, ZFS і Gluster, проте не може бути застосована до RBD. Для зміни формату образу диска. зберігається в RBD використовуйте параметр Move на панелі інструментів Proxmox. Щодо зберігається в RBD образу диска, цей параметр Move може бути застосований для переміщення будь-якого образу диска збереженого в будь-якому сховище за допомогою GUI зовсім без якої б то не було необхідності застосування CLI. Цей параметр також корисний при переміщенні образу диска з одного сховища на інше без виключення даної ВМ. Сховище може бути будь-яким від локального до спільно використовуваного і навпаки. Для переміщення або зміни певного формату диска виберіть конкретний образ диска в закладці Hardware і клікніть на Move disk для відкриття блоку діалогу, як це показано на наступному малюнку:

Як показано на попередньому малюнку для нашого прикладу ВМ, ми переміщаємо образ диска в сховище NFS, одночасно перетворюючи в .qcow2 образ з образу .raw. Якщо ми виберемо параметр Delete source, також автоматично буде вилучений файл джерела після закінчення перетворення або переміщення. Якщо ця опція не дозволена, тоді ми повинні будемо вручну видаляти файл джерела. Файл джерела відображається як невикористаний образ диска в закладці Hardware даної ВМ.

Cache

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

No backup

Якщо дана опція включена, образ даного віртуального диска ніколи не буде включатися в резервну копію. За замовчуванням ця опція заборонена.

Discard

Образ диска в Proxmox виряджені в залежності від типу образу. Це означає, що образ певного диска повільно зростає в міру збереження в ньому даних. Згодом дані створюються і видаляються в межах файлової системи даного виду диска. Однак при розрядженому образі диска навіть після видалення даних він ніколи не відновлює вільний простір. ВМ може повідомляти вірне обсяг пам'яті, доступний, проте сховище Proxmox буде показувати більш високе використання простору. Опція скидання (discard) дозволяє вузлу відновити вільний простір, який не використовується якими б то не було даними. Це еквівалентно опції TRIM, яка була введена в пристроях SSD в точності для тих же цілей. Перед тим як ця опція може бути використана, ми повинні переконається, що дана ВМ використовує контролер SCSI VISIO. Ми можемо встановити тип SCSI в закладці Option даної віртуальної машини, як це відображено на наступному малюнку:

За замовчуванням Proxmox налаштовує все ВМ з контролером LSI 53C895A. Опція Discard може не відповідати всім середах, сховищ і операційним системам. Виконайте достатню тестування перед її реалізацією в своєму оточенні.

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

Iothread

Існує дві опції для образів диска KVM:

За замовчуванням Proxmox використовує ionative для всіх образів диска, в той час як опція iothread позначається спеціальним чином для нужденних в ній образах дисків.

Опція iothread дозволяє кожному образу диска мати свій власний потік замість очікування черги з ким небудь ще. Оскільки дисковий вибрати номер / висновок більше не очікує завдяки наявності свого власного тред, він не стримує інші завдання або пов'язані з ним черги, які стосуються цієї ВМ, що в кінцевому підсумку прискорює продуктивність даної ВМ крім збільшення продуктивності дискового обміну. Опція iothread досить нова для Proxmox. Існує кілька повідомлень джерел в яких ВМ були заблоковані через цю опції, тому виконуйте достатню тестування перш ніж реалізуєте цю функціональність в промисловому оточенні.

Закладка CPU

Дана закладка робить можливим налаштування вами необхідних віртуальних WGE для створюваної віртуальної машини. Наступний малюнок відображає блок діалогу з доступними опціями ЦПУ:

Sockets

Ця опція служить визначенням числа сокетов, яке може використовувати створювана ВМ. Ми можемо застосовувати більше 1 сокета для даної ВМ, навіть якщо фізичний вузол не має достатньої кількості роз'ємів. Це може бути корисно в разі, коли будь-яке додаток у вашій ВМ вимагає більш 1 сокета. Однак не буде корисним зовсім для збільшення продуктивності в вузлі Proxmox з єдиним сокетом.

Cores

Ця опція служить визначенням числа ядер, які може використовувати створювана ВМ. Хорошим підходом буде початок застосування ВМ з меншою кількістю ядер з подальшим збільшенням їх числа в міру необхідності, в залежності від навантаження. Виділення великої кількості ядер ВМ викличе непотрібний тиск на доступні ресурси в вашому вузлі. Зазвичай ВМ може надавати хорошу продуктивність з 2 або 4 ядрами тільки якщо вони не знаходяться під високим навантаженням, такий як сервер віддалених робочих місць або сервер SQL / обміну повідомленнями.

Enabling NUMA

NUMA (Non Uniform Memory Access, доступ до неоднорідною пам'яті) не є новим підходом до обробки пам'яті в середовищах з безліччю ЦПУ, хоча це і є новим додаванням в Proxmox VE. Зазвичай при використанні NUMA, оперативна пам'ять може бути повністю розподілена по ЦПУ, що збільшує продуктивність, оскільки більше немає вузьких місць обумовлених тим, що все ЦПУ намагаються здійснювати доступ до однієї і тієї ж групи блоків пам'яті. У Proxmox опція NUMA також уможливлює підключення оперативної пам'яті і ЦПУ в гарячому режимі. Без цієї опції підключення в гарячому режимі ЦПУ і оперативної пам'яті не працює зовсім.

Будь-вузол з більш ніж одним роз'ємом ЦПУ зазвичай обізнаний про NUMA. Тому включення NUMA для ВМ на такому вузлі надасть перевагу продуктивності створюваної ВМ. NUMA завжди буде намагатися залишати таку ВМ на одному і тому ж пакеті ЦПУ. Ми можемо перевірити стан NUMA в кластері Proxmox скориставшись командою:

# numastat

Ця команда відобразить всі ваші вузли в кластері, які обізнані про NUMA, а також їх стсатістікі продуктивності.

Type

Це спадаюче списочно меню для вибору типу пакета ЦПУ. За замовчуванням для всіх ВМ вибирається тип ЦПУ kvm64.

Порада

Для кращої продуктивності краще застосовувати тип Host. При такому підході ВМ буде мати можливість прямого доступу до ЦПУ без застосування рівня емуляції. Це оптимальний тип для середовища, в якій всі вузли ідентичні. Для максимальної переносимості ВМ краще вибирати тип ЦПУ kvm або qemu.

Закладка Memory

Ця закладка робить можливим налаштування виділення оперативної пам'яті створюваної ВМ. Наступний малюнок відображає блок діалогу для нашого прикладу ВМ:

У Proxmox ми можемо встановлювати для ВМ фіксовану або динамічно виділяється оперативну пам'ять. Автоматичний діапазон також називається надуванням пам'яті (memory ballooning). При фіксованих опціях вся пам'ять виділяється в один і той же час. При опціях динамічного виділення оперативна пам'ять виділяється на підставі запитів ВМ в межах попередньо встановленого діапазону. Автоматичне виділення пам'яті добре працює для гостьових ВМ на основі Linux, однак для ВМ Windows надування пам'яті споживає більш високі значення ресурсів ЦПУ, що викликають уповільнення такої ВМ. Тому для ВМ Windows краще застосовувати фіксовану пам'ять, де це можливо.

Закладка Network

Ця закладка дозволяє налаштовувати необхідні віртуальні мережеві інтерфейси для створюваної ВМ. Наступний малюнок показує блок діалогу для настройки мережевого середовища нашого прикладу ВМ:

Bridged mode

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

Firewall

Щоб включити Брандмауер Proxmox для даного мережевого інтерфейсу, необхідно відзначити цю опцію. без цього параметра ніякі правила брандмауера не застосовуватимуться до даного інтерфейсу. Ми розглянемо Брандмауер Proxmox максимально докладно в Главі 8, Брандмауер Proxmox .

NAT mode

Даний режим надає ВМ прямий доступ до зовнішньої мережевому середовищі. Мережевий обмін не проходить ні через які мости. Якщо в цій мережевому середовищі використовується VLAN, він повинен бути налаштований всередині створюваної ВМ. При використанні режиму NAT опція брандмауера Proxmox недоступна.

No network device

Ця опція створює вашу ВМ без якого б то не було налаштованого мережевого інтерфейсу.

Model

Це спадаюче меню: вибір типу віртуального мережевого інтерфейсу. Для максимальної продуктивності мережевий середовища настійно рекомендується застосовувати VIRTIO. Windows не поставляється з драйвером VIRTIO, тому якщо даний інтерфейс застосовується для ВМ Windows, ми повинні вручну завантажити цей драйвер з ISO, який ми завантажили в розділі закладки Hard Disk даного розділу. Для ВМ Windows ми також можемо застосовувати Intel E1000. Починаючи з Windows 7 цей драйвер Intel входить в комплект поставки.

MAC address

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

Rate limit

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

Multiqueues

Зазвичай ВМ KVM мають єдину чергу в яку потрапляють відправляються і одержуються повідомлення по одному за раз без будь-якої одночасності. Множинні черзі видаляють це вузьке місце роблячи можливими одночасні відсилання і прийом шляхом посилення від віртуальних ядер ЦПУ для паралельних черг. Множинні черзі особливо корисні для ВМ, які проявляють активність для великого числа клієнтів, наприклад, для веб-серверів. У закладці Proxmox Network для блоку діалогу створення ВМ ми можемо ввести числове значення для визначення числа паралельних черг, яке повинна використовувати дана ВМ. Це значення не повинно бути більше ніж число виділених даної ВМ vCPU. Наприклад, якщо дана ВМ має 4 віртуальних ядра, ми можемо встановить значення для множинних черг рівне 4. Множинність черг серйозно збільшує продуктивність мережевий середовища ВМ, так як і відправка, і прийом можуть здійснюватися одночасно.

Порада

Майте на увазі, що включення множинних черг також збільшує використання ЦПУ даної ВМ, так як кожна чергу залежить від свого vCPU.

Disconnect

Якщо дана опція включена, віртуальний мережевий інтерфейс буде створений для даної ВМ, проте не буде активований.

Після того, як ВМ конвертована в шаблон, ця ВМ сама по собі більше не використовується. Однак ми можемо змінювати апаратні ресурси. Інший різницею, яку потрібно відзначити, полягає в тому, що одержувана іконка в панелі інструментів Proxmox унікальна для шаблонів KVM, що відображено на знімку екрана нижче:

Процедура клонування одна і та ж незалежно від того, чи буде це ВМ або шаблон KVM. Щоб створити нову ВМ або розгорнути безліч ВМ з певного шаблону або ВМ, клікніть правою кнопкою по шаблону для відкриття контекстного меню, а потім клацніть на Clone. Це відкриє блок діалогу клонування, що відображено на наступному скріншоті:

Функції блоків введення Target node, VM ID, Name і Resource Pool ідентичні закладці General блоку діалогу створення ВМ KVM.

режим

У Proxmox існує два режими клонування:

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

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

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

Перед тим як може бути застосоване підключення під час роботи, нам спочатку потрібно підготувати ВМ на основі Linux. Для включення підключення під час роботи необхідно завантажити два модуля. Ми можемо завантажити ці модулі, застосувавши наступні команди:

# Modprobe acpiphp # modprobe pci_hotplug

Для завантаження цих модулів в процесі завантаження автоматично ми можемо додати їх в / etc / modules.

Нам також потрібно створити новий файл правил udev в файлі /lib/udev/rules.d/80-hotplugcpu-mem.rules і додати нові рядки:

SUBSYSTEM == "cpu", ACTION == "add", TEST == "online", ATTR {online} == "0", ATTR == {online} = "1" SUBSYSTEM == "memory", ACTION = = "add", TEST == "state", ATTR {state} == "offline", ATTR == {state} = "online"

Для активації модулів і правил даний вузол Proxmox повинен виконати цикл включення.

Як дозволити зв'язок під час роботи для ВМ в GUI необхідно виконати наступні кроки:

1. Увійдіть в GUI Proxmox.

2. Виберіть ВМ для дозволу на ній підключення під час роботи; потім клацніть по меню з закладками Options.

3. Виберіть елемент рядка для підключення в часі роботи і клікніть Edit для відкриття блоку діалогу, як це показано на попередньому знімку екрану.

4. Виберіть одне або більше пристроїв для настройки на підключення під час рботи за допомогою спадаючого меню.

5. Для вирішення клікніть на OK.

Щоб додати новий ресурс в ВМ, перейдіть в закладку Hardware і клікніть на Add. У Proxmox VE 4.1 ми можемо додавати тільки образ Hard Disk, Network Device і CD / DVD Drive за допомогою кнопки Hardware | Add, як це показано на наступному зображенні:

Щоб додати в ВМ vCPU або видалити його з неї, виберіть Processor в закладці VM | Hardware і натисніть Edit для відкриття блоку діалогу ЦПУ. Ми також можемо додати vCPU виконаємо наступну команду в CLI вузла Proxmox:

# Qm set <vm_id> -vcpus 2

Попередня команда додасть в цілому два віртуальних ЦПУ до даної ВМ.

Наступні кроки показують як вирішувати підключення ат час роботи оперативної пам'яті для ВМ:

1. Якщо ще не включена, NUMA повинна бути дозволена для оперативної пам'яті для даних vCPU перед тим як оперативну пам'ять стане можна підключати під час роботи. Перезапустіть цю ВМ після включення NUMA.

2. Визначте нове виділення пам'яті через GUI в закладці Hardware.