У попередній
1. Борошна вибору
Отже, із чого можна вибрати? У
- Система серверної віртуалізації «Р-віртуалізація» (libvirt, KVM, QEMU)
- Програмний комплекс "Засоби віртуалізації «Брест»» (libvirt, KVM, QEMU)
- Платформа управління та моніторингу середовища віртуалізації "Sharx Stream" (хмарне рішення, яке не підходить для держконтору у 95% випадків (секретність тощо))
- Програмний комплекс віртуалізації серверів, робочих столів та програм «ХОСТ» (KVM x86)
- Система безпечного керування середовищем віртуалізації «Z|virt(він же oVirt+KVM)
- Система управління середовищем віртуалізації «ROSA Virtualization(він же oVirt+KVM)
- Гіпервізор QP VMM (надто схожий на Oracle Virtual Box, щоб бути чимось іншим)
Так само можна брати до уваги гіпервізори, що входять до складу постачання ОС, або що знаходяться в їхній репозиторії. Наприклад, у Astra Linux є підтримка KVM. І оскільки він входить до репозиторії ОС, його можна вважати «легітимним» для встановлення і використання. Про те, «що можна використовувати в рамках імпортозаміщення, а що ні», було зазначено у попередній
Насправді ось
- VirtualBox
- Virt-manager (KVM) Орел current
- лібвірт over KVM
У ROSA Linux такого списку немає, але у wiki можна знайти
- ROSA Virtualization over oVirt over KVM
- QEMU over KVM
- oVirt 3.5 over KVM
У Calculate це
У Альт Лінукс це той самий
1.2. Є одне АЛЕ
При найближчому розгляді, робимо висновок, що мати справу нам доведеться лише з кількома відомими гіпервізорами, а саме:
QEMU — вільна програма з відкритим вихідним кодом для емуляції апаратного забезпечення різних платформ, яка може працювати і без використання KVM, але використання апаратної віртуалізації значно прискорює роботу гостьових систем, тому використання KVM QEMU (-enable-kvm) є кращим варіантом. (с) Тобто QEMU — гіпервізор 2-го типу, що є неприйнятним у продуктовому середовищі. З KVM його можна використовувати, але в цьому випадку QEMU буде використовуватися як засіб управління KVM.
Використання оригінального VirtualBox у комерції є фактично
Разом: у чистому вигляді ми маємо тільки KVM.
2. У залишку: KVM чи KVM?
Якщо вам все ж таки необхідно перейти на «вітчизняний» гіпервізор — вибір у вас, прямо скажемо, невеликий. Це буде KVM у тій чи іншій обгортці, з тими чи іншими доробками, але це буде KVM. Добре це чи погано — питання інше, однак альтернативи немає.
Якщо умови не такі суворі, то, як говорилося в попередній
Ці продукти порівнювали далеко не
Про розгортання та налаштування KVM так само писалося не
Те ж саме і про
Не бачу сенсу повторюватись і описувати ці системи, порівнювати тощо. Можна, звичайно, підсмикувати зі статей ключові моменти, але це буде неповага до авторів, я вважаю. Кому належить вибирати — той прочитає не тільки це, а ще й гору інформації, щоб визначитися.
Єдина відмінність, на якій хочу загострити увагу, — відмовостійка кластеризація. Якщо у Microsoft це вбудовано в ОС і функціонал гіпервізора, то у випадку з KVM доведеться використовувати інше програмне забезпечення, яке має входити в репозиторії ОС. Така ж зв'язка Corosync+Pacemaker, наприклад. (Ця зв'язка є майже у всіх вітчизняних ОС ... може, і у всіх, але всі 100% я перевіряти не став.) Мануали з налаштування кластеризації так само є в надлишку.
3. Висновок
Ну, як завжди, наші Кулібіни не стали морочитися, взяли що було, прикрутили трішки свого і видали «продукт», який за документами є вітчизняним, а насправді — OpenSource. Чи є сенс витрачати гроші з бюджету за «окремі» системи віртуалізації (що не входять до складу ОС)? Не думаю. Так як все одно ви отримаєте той же KVM, тільки за нього потрібно буде заплатити.
Таким чином, вибір заміни для гіпервізора зводиться до того, які серверні ОС ви збираєтеся закуповувати для Підприємства та експлуатувати. Або, як у моєму випадку, залишитеся на тому, що у вас вже є (Hyper-VESXiвписати_потрібне).
Джерело: habr.com