Сервіс віртуалізації Hyper-V і особливості роботи з віртуальними машинами Linux

5 (100%) 1 vote [s]

Hyper-V з'явився в Windows 2008 значно розширивши функціонал Windows сервер. Ще б пак - засіб віртуалізації, що використовує апаратні ресурси, та ще й безкоштовне (якщо Ви звичайно купили windows сервер для інших потреб) змогло згодом скласти гідну конкуренцію лідеру систем віртуалізації VMware.

І за ці 8 років з'явилася маса корисних функцій і поліпшень. Найбільш значимі з них, на думку автора - це:

• Підтримка віртуальних машин Linux
• Жива міграція віртуальних машин між вузлами кластера.
• Реплікація віртуальних машин
• Керовані віртуальні свічі
• Поява віртуальних машин другого покоління
• загальні VHD
• контейнери Windows

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

Сьогодні ми поговоримо про роботу віртуальних машин linux в середовищі віртуалізації Hyper-V . Давайте почнемо з конкретного завдання. Для автоматизації розгортання деякої середовища мені знадобилося створити кілька машин з операційною системою CentOS (була використана версія 7.3)

Був викачаний необхідний дистрибутив, створена віртуальна машина другого покоління. І .. Віртуальна машина не запустилася. Про що говорить цей приклад? Про те, що потрібно не забувати читати інструкції і Best Practices при вивченні і розгортанні нових продуктів. У моєму випадку проблема була з некоректним настроюванням Secure Boot віртуальної машини. (Малюнок і пояснення Secure boot)

Secure boot дозволяє бути впевненим, що ПО виконує старт ОС не скомпрометовано. Це ефективно захищає від впроваджень шкідливого софту в завантажувач системи.

Процес завантаження сервера відбувається наступним чином:

1. Запускається апаратна частина.
2. Контроль передається BIOS, яка перевіряє основні компоненти CPU, пам'ять, диски та інше обладнання.
3. BIOS читає настройки завантаження і перебирає всі отримані в списку пристрою в пошуках завантажувача в нульовому секторі.
4. Якщо завантажувач ОС знайдений BIOS завантаженні його в пам'ять і передає CPU для обробки.
5. Завантажувач запускає систему.

Це дуже спрощена, але зрозуміла для розуміння схема. Уразливість з'являється на 4ом кроці, коли BIOS завершує свою роботу. У цей момент ніхто не піклується про те, що буде далі. І цим користуються різні руткіти - це програмні прокладки, зазвичай шкідливі, які знаходяться між BIOS і операційною системою. ОС не може на них впливати, тому що вони знаходяться поза зоною її контролю, однак вони можуть перехоплювати будь-які натискання клавіш і звернення до пристроїв.

З появою UEFI ситуація змінилася. UEFI шукає не просто код в секторі 0, він шукає певні файли і має можливість виконувати деяку їх обробку, а не просто передавати їх на виконання CPU.

Secure Boot поєднує розширені можливості завантаження і обробки з криптографічними можливостями UEFI. Ключі шифрування зберігаються в прошивці. Коли UEFI запускає завантажувач ОС, він може перевірити криптографічний підпис цього завантажувача ОС, якщо така є, ключами підписала, про які він знає. Якщо образ був підписаний довіреною ключем, UEFI дозволить його запуск. В іншому випадку він зупиняє весь процес завантаження і повідомляє про це.

Розмноження віртуальних машин не складає великих труднощів, якщо використовувати команду PowerShell New-VM, однак тут є кілька підходів:

1. Створити образ CentOS з «тихою» установкою.
2. Встановити і підготувати ОС на диску VHD і використовувати диск при створенні нових віртуальних машин.

Оскільки автор (в силу обставин, що склалися) вважає за краще платформу Windows всім іншим рішенням, другий варіант був прийнятий як основний. І наступним завданням була підготовка правильного способу-шаблону. В процесі установки ОС використовувався режим Minimal Install, був створений розділ 20 ГБ, заданий пароль для користувача root і створений користувач з правами root. Інші налаштування, в тому числі конфігурація безпеки, планувалося виконувати в процесі подальшої конфігурації машини. Для створення шаблону було виконано кілька кроків:

1. У файл / etc / sysconfig / network доданий наступний текст:

NETWORKING = yes

HOSTNAME = localhost. localdomain

1. У файл конфігурації мережевого інтерфейсу / etc / sysconfig / network-scripts / ifcfg-eth0 доданий наступний текст:

DEVICE = eth0

ONBOOT = yes

BOOTPROTO = dhcp

TYPE = Ethernet

USERCTL = no

PEERDNS = yes

IPV6INIT = no

NM_CONTROLLED = no

Останній рядок відключає NetworkManager. Це необхідно для того, щоб Hyper-V міг виконати статичну настройку мережевого інтерфейсу.

1. Виконана команда для видалення правил udev. Ці правила призводять до появи проблем при клонуванні віртуальної машини в Hyper-V або Microsoft Azure.

sudo ln - s / dev / null / etc / udev / rules. d / 75 - persistent - net - generator. rules

1. Очищені всі поточні метадані yum та встановити всі оновлення за допомогою команд

sudo yum clean all

sudo yum - y update

1. Виконана настройка фаервола

firewall - cmd - zone = public - add - port = 22 / tcp

1. Виконана установка Hyper-V tools.

sudo yum install hyperv - daemons

На останньому пункті варто зупинитися докладніше. Спочатку установка Тулов не планувалася з розрахунку, менше ПО - менше поломок. Але це підхід не правильний. Не дивлячись на те, що CentOS 7 більшість Фітч підтримує без установки додаткового ПЗ, на практиці виявилося, що є проблеми зі створенням snapshot'ов, які до слова починаючи з версії win 2012 називаються Checkpoints. Також в моєму сценарії віртуальні машини отримують IP адреса по DHCP, отже, для подальшого підключення до них потрібно знати адресу, який отримав віртуальний сервер. Отримати його можна засобами PowerShell.

До речі, в останній редакції Windows Hyper-V з'явилася функція PowerShell direct, яка дозволяє управляти віртуальною машиною з Hyper-V хоста через PowerShell. Windows PowerShell Direct працює між хостовой і віртуальною машиною. Це означає, що йому не потрібно мережевих налаштувань або налаштувань фаєрвола, він працює завдяки налаштуванням для віддаленого підключення. Windows PowerShell Direct є альтернативою для інструментів, за допомогою яких адміністратори Hyper-V підключаються до віртуальної машини з Hyper-V хоста:

• Remote PowerShell і Remote Desktop
• Hyper-V Virtual Machine Connection (VMConnect)

Ці утиліти працюють добре, але мають свої недоліки: VMConnect і Remote Desktop складно використовувати при автоматизації. Remote PowerShell складний в установці і обслуговуванні. І значимість цих недоліків зростає з ростом інфраструктури Hyper-V. Windows PowerShell Direct надає потужні можливості скріптованія і автоматизації разом з простотою використання VMConnect.

Отримати IP адреса машини можна використовуючи, наприклад, наступний набір командлетів

Get-VM | ? {$ _. VMName -like "LAB2-CentOS7 *"} | Get-VMNetworkAdapter | ft VMName, IPAddresses, switchName -autosize

При цьому отримаємо такий висновок:

До установки Тулов поле IPAdresses було порожнім (як у віртуальної машини LAB2-CentOS7-Template). Потрібно також відзначити, що це поле заповнюється не відразу після установки, а через деякий час. Тому особливо нетерплячим (таким, як я J) рекомендується попити чаю перед тим, як почати панікувати при відсутності очікуваного результату.

Також я хочу окремо зупинитися на установці ТУЛЗ ще й тому, що у мене це викликало деякі труднощі. Довіряючи Microsoft, 14.03.2017 hyper-v tools були завантажені мною з офіційного сайту Microsoft, розпаковані і встановлені відповідно до наявної інструкції. Однак після перезавантаження CentOS 7.3 вперто і безуспішно намагалася грузиться в emergencyMode. Було виконано ряд дій, описаних в розділі інструкції Known Issues. Однак результат не був досягнутий. Після вивчення проблеми і прикладів її рішення, пофарбованих, м'яко скажемо, безсторонніми епітетами в бік Microsoft, мене відвідала ідея установки hyper-v tools з репозитаріїв CentOS. Одна єдина команда вирішила мою проблему.

yum install hyperv - daemons

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

Ось власне і все. Завдання по налаштуванню Hyper-V і віртуальних машин Linux вирішена.

З віддаленої машини я підключаюся PowerShell скриптом до Hyper-V хосту, виконую створення декількох машин, копіювання та підключення для кожної з них шаблонного VHD, запуск всіх створених машин і отримання їх IP адрес, які потім передаються в Ansible для подальшої конфігурації системи. Але це вже зовсім інша історія.

Звичайно ж, багато про hyper-V залишилося за кадром. Тому ми обов'язково продовжимо в майбутніх публікаціях. А якщо у Вас з'явилися питання - наші фахівці завжди готові відповісти на них.

Ми надаємо послуги впровадження і підтримки систем віртуалізації, [Email protected]