неділя, 5 лютого 2017 р.

Міграція віртуальних машин з Oracle VirtualBox до KVM з оболонкою virt-manager

Задача

Віртуальна машина під гіпервізором KVM, який використовується сумісно з демоном libvirtd, утворюється образом диску (або декількома образами дисків) та конфігураційним файлом в форматі XML. Для того, щоб перенести (мігрувати) віртуальну машину з середовища VirtualBox до KVM+libvirtd необхідно виконати дві дії:
1) перенести образ диску
2) створити конфігураційний XML-файл


Перенесення образу диску


На всякий випадок створюємо резервну копію вмісту підкаталога, який містить образи дисків віртуальних машин в VirtualBox (зрозуміло, всі віртуальні машини і сам VirtualBox мають бути вимкнені):

$ cd
$ mkdir -p backup
$ cd backup
$ tar czvf vbox_vms.tgz -C ~ 'VirtualBox VMs'
Образи дисків в VirtualBox зберігаються в форматі VDI. Libvirt підтримує формат VDI, втім є сенс під час міграції перетворити образи дисків в "сирий" (raw) формат. Певною перевагою формату raw є те, що він характеризується найменшими накладними витратами серед всіх форматів. Втім, формат raw не підтримує створення миттєвих знімків (snapshots) диску і стискання з метою економії простору для розміщення образів дисків.


Конвертація образу диску з формату VDI в формат raw:

$ mkdir VMs
$ cd VMs
$ qemu-img convert -f vdi -O raw  \
   ../VirtualBox\ VMs/C7-BASE/C7-BASE.vdi C7-BASE.img
$ ls -lh
total 2,0G
-rw-r--r-- 1 chd chd 8,0G січ  5 21:10 C7-BASE.img


Конфігурація віртуальної машини

Запускаємо оболонку virt-manager. Виконуємо команду 'File' -- 'Create a new virtual machine'. У вікні, що з'явилося, обираємо 'Import existing disk image' та натискаємо 'Forward'.

За допомогою кнопки 'Browse' знаходимо створений образ диску, в даному випадку -- C7-BASE.img. Також обираємо тип операційної системи віртуальної машини та її версію, наприклад, 'Linux', 'Red Hat Enterprise Linux 7.0'. Натискаємо 'Forward'.

Визначаємо потрібний обсяг оперативної пам'яті (RAM) та кількість процесорних ядер (CPU). Натискаємо 'Forward'.

Встановлюємо ім'я нової віртуальної машини, наприклад 'C7-BASE', та відмічаємо опцію 'Customize configuration before install'. Вказуємо конфігурацію мережі, наприклад 'Virtual network default: NAT'. Натискаємо 'Finish'.

У вікні, що з'явилося, є можливість детально визначити всі параметри віртуальної машини, та, у разі потреби додати компоненти.

Машина готова і може бути стартована.

понеділок, 9 січня 2017 р.

Налаштування середовища для віртуалізації на основі KVM в Ubuntu

Мета

На персональному комп’ютері під операційною системою Ubuntu налаштувати середовище для роботи з віртуальними машинами на основі гіпервізора Kernel Virtual Machine (KVM). Здійснити міграцію до KVM віртуальних машин, раніше створених в гіпервізорі Oracle VirtualBox. В даній публікації розглядається початкове налаштування KVM під Ubuntu 16.04.

Перевірка підтримки віртуалізації процесором


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

# egrep -c ‘(vmx|svm)’ /proc/cpuinfo
8

Результат виконання команди -- кількість ядер процесора, які апаратно підтримують віртуалізацію. Прапорець vmx присутній в процесорах Intel, svm -- в процесорах AMD. Вочевидь, отримана кількість ядер процесора дорівнюватиме загальній кількості ядер процесора, адже всі вони однакові. Також ця кількість буде вдвічі більшою за кількість апаратних ядер процесора у разі ввімкнення гіпертрідінгу (hyper-threading), який зазвичай ввімкнено (можливою причиною для вимкнення гіпертрідінгу може бути бажання оптимізувати продуктивність процесору для виконання одно-трідових (single-threaded) процесів, але це не типовий випадок).

Інший метод для перевірки підтримки процесором віртуалізації -- виконання команди lscpu, приклад виводу якої наведено нижче:

# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 58
Model name:            Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz
Stepping:              9
CPU MHz:               1301.179
CPU max MHz:           3200,0000
CPU min MHz:           1200,0000
BogoMIPS:              4390.05
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              6144K
NUMA node0 CPU(s):     0-7
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts

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

Ще однією альтернативою перевірки спроможності процесора апаратно підтримувати віртуалізацію на основі KVM є виконання команди kvm-ok (для цього може бути потрібним встановлення пакунку cpu-checker). Вивід команди у разі підтримки розширень, які використовує KVM:

$ kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used


Для системи з віртуалізацією доречно використовувати 64-бітну операційну систему (ОС). Пересвідчитися, що використовувана ОС є 64-бітною можна командами arch або uname -a, у виводі яких має бути наявним ідентифікатор 64-бітної архітектури -- x86_64:

$ arch x86_64

Також ознакою 64-бітної архітектури ОС є наявність флагу lm в інформації з /proc/cpuinfo:

$ egrep -c ' lm ' /proc/cpuinfo
8

У разі відсутності апаратної підтримки віртуалізації процесором продуктивність системи буде низькою, а у разі використання 32-бітової ОС максимальний обсяг пам’яті створюваних віртуальних машин не зможе перевищувати 2 Гбайти.

Встановлення пакунків для віртуалізації на основі KVM


Для віртуалізації на основі KVM необхідно встановити додаткові пакунки, якщо вони не були встановлені раніше:

$ sudo apt install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils
Встановлення вказаних пакунків призведе до автоматичного встановлення додаткових необхідних пакунків.

У разі, якщо на комп’ютері встановлено сервер графічного інтерфейсу користувача X- Window, доречно додатково встановити графічну утіліту роботи з віртуалізацією virt-manager:

$ sudo apt install virt-manager

Додаткові корисні утіліти:

$ sudo apt install virt-top

Після встановлення необхідних пакунків комп’ютер доречно перезавантажити. Під час завантаження системи можна помітити повідомлення: Starting Virtualization Daemon. Після завантаження перевірити стан гіпервізора для віртуалізації libvirtd можна командою:

$ sudo systemctl status libvirtd
● libvirt-bin.service - Virtualization daemon
  Loaded: loaded (/lib/systemd/system/libvirt-bin.service; enabled; vendor preset: enabled)
  Active: active (running) since пн 2017-01-02 22:46:19 EET; 6min ago
    Docs: man:libvirtd(8)
          http://libvirt.org
Main PID: 1428 (libvirtd)
  CGroup: /system.slice/libvirt-bin.service
          ├─1428 /usr/sbin/libvirtd

творення та керування віртуальними машинами
          ├─1708 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/
          └─1709 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/lib/libvirt/

Команда для огляду стану існуючих віртуальних машин повертає пустий список:

# virsh list --all
Id    Name                           State
----------------------------------------------------

Створення та керування віртуальними машинами

Для створення та керування віртуальними машинами зручно скористатися графічною утілітою virt-manager. Утіліта надає можливість виконання всіх необхідних дій з віртуальними машинами:
  • створення нової віртуальної машини
  • імпорт віртуальної машини, створеної в іншому гіпервізорі
  • запуск (start), зупинення (shut down), призупинка (pause) віртуальної машини
  • створення миттєвих знімків (snapshots)
  • створення нової віртуальної машини шляхом клонування існуючої

Джерела

  • https://help.ubuntu.com/community/KVM/Installation
  • https://help.ubuntu.com/community/KVM/CreateGuests

пʼятниця, 1 квітня 2016 р.

Налаштування зв'язки інтерфейсів EtherChannel за допомогою OpenVSwitch

Попередня публікація на тему використання OpenVSwitch: OpenVSwitch в системі CentOS7: базові налаштування

Вступ

Зв'язка (bundle) інтерфейсів EtherChannel являє собою сумісне використання Ethernet інтерфейсів з метою отримання нового віртуального інтерфейсу, який має наступні ознаки:

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

Для динамічного конфігурування інтерфейсу EtherChannel пристрої, з'єднані через інтерфейси зв'язки, взаємодіють за протоколом Link Aggregation Control Protocol (LACP).

Задача

Розглянемо налаштування інтерфейсу EtherChannel в системі, в якій встановлено віртуальний комутатор OpenVSwitch. Для прикладу уявимо систему CentOS Linux з двома інтерфейсами GigabitEthernet -- ge0, ge1, та двома інтерфейсами 10GigabitEthernet -- te0, te1:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: te0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP qlen 1000
    link/ether 14:18:77:30:64:fe brd ff:ff:ff:ff:ff:ff
    inet6 fe80::1618:77ff:fe30:64fe/64 scope link
       valid_lft forever preferred_lft forever
3: te1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP qlen 1000
    link/ether 14:18:77:30:65:00 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::1618:77ff:fe30:6500/64 scope link
       valid_lft forever preferred_lft forever
4: ge0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 14:18:77:30:65:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global ge0
       valid_lft forever preferred_lft forever
    inet6 fe80::1618:77ff:fe30:6502/64 scope link
       valid_lft forever preferred_lft forever
5: ge1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 14:18:77:30:65:04 brd ff:ff:ff:ff:ff:ff

Дану систему планується використовувати як носій для віртуальних машин (ВМ). Інтерфейс ge0 використовуватиметься виключно для керування носієм. Інтерфейс ge1 залишається резервним, його можна використовувати, наприклад, для аналізу трафіку на портах комутатора за технологією віддзеркалювання портів (port mirroring). Інтерфейси te0 та te1 використовуватимуться для передачі трафіку ВМ. Для отримання великої пропускної здатності та відмовостійкості інтерфейсів (оптичні з'єзнання 10GigabitEthernet характеризуються нижчою механічною надійністю ніж мідні з'єднання GigabitEthernet) інтерфейси te0 та te1 об'єднуються у зв'язку EtherChannel.

Налаштування EtherChannel

Для використання OpenVSwitch створюється базовий міст ovsbridge0, що, фактично, є віртуальним аналогом звичайного комутатора:

# ovs-vsctl --may-exist add-br ovsbridge0
# ip link set ovsbridge0 up
# ip addr show ovsbridge0
7: ovsbridge0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 96:34:45:9c:6e:4e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::9434:45ff:fe9c:6e4e/64 scope link
       valid_lft forever preferred_lft forever

Створюємо віртуальний інтерфейс EtherChannel -- bond0, з яким пов'язуємо фізичні інтерфейси te0 та te1:

# ovs-vsctl --may-exist add-bond ovsbridge0 bond0 te0 te1

Слід зазначити, що інтерфейс bond0 не з'являється поруч з іншими інтерфейсами, які можна побачити, наприклад, за допомогою команди "ip addr show". З інтерфейсом bond0 оперує OpenVSwitch:

# ovs-vsctl show
8f777f14-8698-4e0e-b48c-38aed81a1a76
    Bridge "ovsbridge0"
        Port "bond0"
            Interface "te0"
            Interface "te1"

На EtherChannel інтерфейсі налаштовується протокол LACP та метод балансування трафіку типу TCP:

# ovs-vsctl set port bond0 bond_mode=balance-tcp \
    other-config={bond-detect-mode=miimon bond-miimon-interval=100} \
    lacp=active

Взагалі, OpenVSwitch підтримує три можливі типи балансування трафіку через з'єднання EtherChannel:

  • balance−slb -- балансування по MAC-адресах і номерах VLAN джерела (source) з періодичним коригуванням розподілу потоків (flows) між фізичними з'єднаннями на випадок зміни характеру трафіку
  • active−backup -- передача всіх потоків через основне (active) фізичних з'єднань та у випадку виходу цього з'єднання з ладу перенесення потоків на резервне (backup) з'єднання
  • balance−tcp -- балансування по інформації з L2, L3 та L4 протоколів, зокрема, по MAC- та IP-адресах та номеру порту TCP призначення (destination)

Метод balance−slb використовується за замовченням. Метод active−backup єдиний дозоляє під'єднувати фізичні інтерфейси, що пов'язані в EtherChannel, до різних комутаторів. Метод balance−tcp вимагає підтримки LACP відповідно стандарту IEEE 802.3ad на комутаторі, з яким створюється з'єднання EtherChannel.

Примітка: я не знайшов чіткої розшифровки скорочення SLB. Найбільш вірогідною мені здається "Switch-assisted Load Balancing".

Як було зазначено раніше, окрім збільшення пропускної здатності технологія EtherChannel дозволяє забезпечити відмовостійкість на випадок виходу з ладу окремих фізичних з'єднань. Налаштування відмовостійкості здійснюється наступними основними параметрами:

  • other_config : bond-detect-mode -- спосіб визначення відмови фізичного з'єднання, можливі значення:
    • carrier -- покладання на наявність сигнал з частотою носія (carrier) в інтерфейсі, використовується за замовченням
    • miimon -- опитування модуля інтерфейсу незалежного від середовища, Media Independent Interface (MII)
  • other_config : bond-miimon-interval -- інтервал в мілісекундах між успішними опитуваннями інтерфейсу MII; умісний лише у випадку використання способу визначення відмови фізичного з'єднання miimon
Для включення протоколу LACP на з'єднання EtherChannel використову'ється параметр lacp -- режим функціювання EtherChannel згідно LACP. Можливі значення параметру:
    • active -- ініціювання та підтримка LACP взаємодії
    • passive -- підтримка LACP взаємодії, якщо її ініціює пристрій-партнер
    • off -- вимкнення LACP взаємодії

Примітка: окрім зазначених параметрів для тонкого налаштування EtherChannel та протоколу LACP можуть бути використана низка додаткових параметрів.

Створений інтерфейс EtherChannel переводимо в режим VLAN транку (trunk) та додаємо список VLAN, які дозволено передавати:

# ovs-vsctl set port bond0 vlan_mode=trunk trunks=10,20,30

Для перегляду стану сформованого з'єднання EtherChannel використовуємо наступні команди:

# ovs-vsctl list port bond0
_uuid               : 50620062-c457-4c70-b3c7-66de0d27fb0c
bond_active_slave   : "14:18:77:30:65:00"
bond_downdelay      : 0
bond_fake_iface     : false
bond_mode           : balance-tcp
bond_updelay        : 0
external_ids        : {}
fake_bridge         : false
interfaces          : [741f5d85-bafc-4add-b3bc-580f90f27b2e, 78d25b6b-7a42-4b76-be60-04aed46b8555]
lacp                : active
mac                 : []
name                : "bond0"
other_config        : {bond-detect-mode=miimon, bond-miimon-interval="100"}
qos                 : []
rstp_statistics     : {}
rstp_status         : {}
statistics          : {}
status              : {}
tag                 : []
trunks              : [10, 20, 30]
vlan_mode           : trunk

# ovs-appctl bond/show
---- bond0 ----
bond_mode: balance-tcp
bond may use recirculation: yes, Recirc-ID : 2
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
next rebalance: 9565 ms
lacp_status: negotiated
active slave mac: 14:18:77:30:65:00(te1)

slave te0: enabled
        may_enable: true

slave te1: enabled
        active slave
        may_enable: true

# ovs-appctl lacp/show
---- bond0 ----
        status: active negotiated
        sys_id: 14:18:77:30:64:fe
        sys_priority: 65534
        aggregation key: 1
        lacp_time: slow

slave: te0: current attached
        port_id: 2
        port_priority: 65535
        may_enable: true

        actor sys_id: 14:18:77:30:64:fe
        actor sys_priority: 65534
        actor port_id: 2
        actor port_priority: 65535
        actor key: 1
        actor state: activity aggregation synchronized collecting distributing

        partner sys_id: f8:b1:56:83:8a:81
        partner sys_priority: 1
        partner port_id: 49
        partner port_priority: 1
        partner key: 210
        partner state: activity aggregation synchronized collecting distributing

slave: te1: current attached
        port_id: 1
        port_priority: 65535
        may_enable: true

        actor sys_id: 14:18:77:30:64:fe
        actor sys_priority: 65534
        actor port_id: 1
        actor port_priority: 65535
        actor key: 1
        actor state: activity aggregation synchronized collecting distributing

        partner sys_id: f8:b1:56:83:8a:81
        partner sys_priority: 1
        partner port_id: 50
        partner port_priority: 1
        partner key: 210
        partner state: activity aggregation synchronized collecting distributing

Альтернативним способом налаштування EtherChannel на OpenVSwitch є створення файлу конфигурації інтерфейсу bond0 -- /etc/sysconfig/network-scripts/ifcfg-bond0:

DEVICE=bond0
NAME=bond0
ONBOOT=yes
DEVICETYPE=OVS
TYPE=OVSBond
OVS_BRIDGE=ovsbridge0
BOOTPROTO=none
BOND_IFACES="te0 te1"
TRUNKS="trunks=10,20,30"
OVS_OPTIONS="bond_mode=balance-tcp"
OVS_OPTIONS+=" other-config:bond-detect-mode=miimon"
OVS_OPTIONS+=" other-config:bond-miimon-interval=100"
OVS_OPTIONS+=" lacp=active vlan_mode=trunk $TRUNKS"

Конфігурація інтерфейсів з боку комутатора, до якого під'єднано інтерфейси, які об'єднано в EtherChannel, може виглядати таким чином (комутатор серії Dell Networking N1500):

interface Te1/0/1 
channel-group 1 mode active
description "CR ETH2"
switchport mode trunk
exit              
!                 
interface Te1/0/2 
channel-group 1 mode active
description "CR ETH3"
exit              
!                 
interface port-channel 1
switchport mode trunk
switchport trunk allowed vlan 10,20,30
exit

Зазначимо, що простіше було б на обох транкових інтерфейсах -- port-channel 1 з боку комутатора та bond0 з боку сервера, дозволити передачу фреймів всіх можливих VLAN -- з 1 по 4096. Проте, так робити не слід, оскільки це невиправдано подовжує широкомовні сегменти, якими є VLAN. Детальніше про те, чому не слід спрощувати конфігурації шляхом дозволу всіх VLAN, можна почитати в прекрасній статті Івана Пепельняка VLANS AND FAILURE DOMAINS REVISITED.

Джерела