vSphere на Proxmox: що справді переїжджає

Кожен посібник з відходу від VMware починається з диска, бо диск це та частина, у якої є файл. Сконвертувати VMDK, імпортувати, завантажити, готово.

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

Ось що ми знайшли, будуючи шляхи читання й запису до обох, вимірюючи проти vCenter 6.7.0 build-24323669.

Диск і один виклик, якого немає

У грі дві форми віртуального диска. У запущеної віртуальної машини vSphere є плаский VMDK плюс маленький дескриптор. В OVA чи завантаженого хмарного образу є stream-optimized VMDK: стиснутий, послідовний і в такому вигляді не завантажуваний.

Очевидний шлях конвертації це CopyVirtualDisk_Task зі специфікацією призначення, що називає цільовий формат. Той виклик існує на окремому хості ESXi і не існує на vCenter: він відповідає «The requested operation is not implemented by the server». Це добрий приклад ширшої пастки цього API, де та сама операція існує на одному рівні керування й не існує на іншому.

Дві речі працюють, і їх варто знати саме в такому порядку:

• CopyVirtualDisk_Task без специфікації призначення працює на vCenter 6.7 і копіює диск, зберігаючи його тип. На цьому vCenter він вимагає аргумент datacenter; форму лише зі шляхом до сховища даних відхилено.
• Шлях імпорту OVF (CreateImportSpec → ImportVApp → HttpNfcLease → HTTP POST → HttpNfcLeaseComplete) приймає stream-optimized диск і конвертує його на вході. Йому потрібен лише дескриптор .ovf, а не вся OVA: OVA це tar-архів із дескриптором попереду, який дістається одним запитом діапазону на 128 кБ.

На боці Proxmox еквівалентом є qm disk import, який бере VMDK і пише його в цільове сховище у власному форматі того сховища. Ця частина справді проста.

Провізіювання змодельовано на двох боках по-різному. У vSphere є два прапорці, thinProvisioned і eagerlyScrub, і це не вибір із трьох: thin виключає eager, тож дійсні стани це thin, thick lazy zeroed і thick eager zeroed. Усе, що моделює це як один перелік із чотирьох значень, рано чи пізно надішле неможливу комбінацію.

Ідентичність: ваш ID не є ідентичністю

Ця річ кусає за місяці, а не в день міграції.

Обʼєкт vSphere адресується посиланням на керований обʼєкт, чимось на кшталт vm-101. Воно має вигляд ідентифікатора і ним не є: це ключ у базі даних того конкретного vCenter. Перебудуйте чи відновіть ту базу, і посилання не піде за машиною, а буде роздане знову іншій віртуальній машині. Те, що ви зберегли пів року тому, тепер вказує на чиюсь чужу машину, а операція, яку ви збиралися виконати, це вимкнення живлення.

Тривким ідентифікатором є config.instanceUuid. Зберігайте його, а посилання розвʼязуйте на кожну операцію через FindByUuid.

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

Модель розташування теж інша. З увімкненим DRS хост, на якому працює машина, змінюється, нікого не питаючи, тож клону дають пул ресурсів, а vSphere обирає сама. У Proxmox одиницею є вузол, і переміщення між вузлами явне. Інвентар, що записував «на якому хості» для кластера з DRS, записував те, що змінюється саме собою.

Налаштування гостя це інший механізм

Обидві платформи вміють налаштувати гостя на першому завантаженні. Роблять вони це способами, які не мають спільного коду.

У vSphere шлях, що працює без залежності від гостя, це guestinfo: чотири ключі в extraConfig, які читає джерело даних VMware в cloud-init.

Ключі .encoding не є необовʼязковими. Пропустіть їх, і cloud-init прочитає текст base64 як сам вміст, а машина підніметься з іменем хоста з сорока символів нісенітниці. Жодної помилки, просто неправильна відповідь.

Альтернатива, власний CustomizeVM_Task від VMware, потребує VMware Tools у гостя, а на старших шаблонах Linux ще й робочого perl, і це така вимога, яку виявляють, коли провізіювання зависає на півдорозі.

У Proxmox налаштування це диск cloud-init, приєднаний до машини, з невеликим набором ключів: від ipconfig0 до ipconfig3, nameserver, searchdomain, ciuser, cipassword, sshkeys, citype, ciupgrade.

В одного з них є пастка, що лишається невидимою, доки не поскаржиться клієнт. У схемі Proxmox ciupgrade має default = 1, тож пропустити його не означає «не оновлювати пакети на першому завантаженні»; це означає «оновити». Незнята галочка має надсилатися явним ciupgrade=0, інакше галочка бреше. Його також не існує до PVE 8.1, де надіслати його взагалі це жорстка помилка, а не проігнорований ключ.

Ще дві речі йдуть не так однаково на обох боках. Ідентифікатор екземпляра має змінюватися, коли машина отримує нову ідентичність: iid-local01 з більшості прикладів означає, що клонована машина зберігає конфігурацію шаблона. І інтерфейс не матиме тієї назви, на яку ви очікуєте: ens160 на VMware, щось інше на KVM. Netplan із match: {name: "e*"} замість вгаданої назви пристрою це те, що змушує один образ працювати на обох.

Віртуальне залізо, до якого гість має драйвери

vmxnet3 це розсудлива усталена мережева карта на VMware, і в неї є передумова: їй потрібні VMware Tools у гостя. Встановіть шаблон без Tools, дайте йому карту vmxnet3, і операційна система взагалі не побачить мережевої карти.

Це має значення двічі. До, бо шаблонові, який чудово завантажується на ESXi, може знадобитися натомість e1000e. І після, бо високопродуктивний вибір Proxmox це virtio, якому потрібні власні драйвери: наявні в сучасному Linux і геть відсутні в стоковому образі Windows. e1000 це повільний, нудний варіант, що працює скрізь на обох платформах, і це правильне перше завантаження для машини, яку ви переносите.

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

Агент усередині гостя змінює назву

Дивовижно велика частина того, що показує панель, узагалі не приходить від гіпервізора.

У vSphere guest.ipAddress приходить від VMware Tools. Як і справжнє використання диска, через guest.disk: показник summary.storage.committed на рівні сховища даних це цифра провізіювання, і для тонкого диска вона читається неправильно. Tools, що не працюють, означають порожні поля, а порожньо означає «я не знаю», ніколи «у машини немає адреси».

Після переїзду та сама інформація приходить від qemu-guest-agent, іншого пакета з іншою назвою, який треба встановити. Флот, що мігрував без нього, має у вашому власному інвентарі вигляд флоту, який втратив свої адреси.

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

Мережа і зʼєднання, якого тихо немає

У vSphere два види мережевої підкладки, і вони не схожі одне на одного. Стандартна Network адресується назвою; DistributedVirtualPortgroup адресується UUID свого комутатора плюс власним ключем групи портів.

Побудуйте лише першу форму, і в будь-якому середовищі з розподіленим комутатором ви отримаєте карту, приєднану ні до чого. vCenter не відмовляє, бо назва справді існує як мережевий обʼєкт. Машина завантажується без звʼязку, а помилка сидить усередині гостя.

Proxmox простіший: мережева карта називає міст, з необовʼязковою міткою VLAN. Зіставлення писати вам; автоматичного перекладу з групи портів у міст немає. Ще дві речі, які треба вирішити перед першим переїздом:

• MAC-адреси. Перенести їх означає зберегти чинними резервації DHCP і привʼязки ліцензій, і водночас означає, що дві машини ділять MAC, якщо джерело колись увімкнуть назад. Обирайте свідомо.
• Фаєрвол на кожну машину. У vSphere його немає; це NSX, окремий продукт. У Proxmox є. Машини, що приїжджають з VMware, ніколи не мали фаєрвола на рівні гіпервізора, і увімкнути його це проєкт, а не галочка.

Що не їде і чого немає в жодному файлі

У деяких речей немає відповідника, і план, який їх не називає, виявляє їх по одній:

• Знімки. Машина їде як плаский диск; дерево знімків це структура vSphere, і імпортувати його немає в що.
• Відстеження змінених блоків, а з ним і будь-яка історія інкрементальних копій, що на нього спиралася.
• Теги, власні атрибути й теки. Вони живуть у базі даних vCenter, а не на машині.
• Пули ресурсів, правила DRS, резервування й частки. У Proxmox немає еквівалентного планувальника, тож політика розміщення, написана як правила DRS, стає рішеннями про те, на якому вузлі сидить машина.
• Версія віртуального заліза. Поняття vSphere без відповідника в Proxmox, тож усе, що на ньому завʼязано у вашій автоматизації, тепер мертвий код.

Що наш інструмент робить, а чого ні

Скажемо прямо: ми не будували міграцію з vSphere на Proxmox. Наш інструмент міграції покриває сьогодні рівно один маршрут, між двома ігровими панелями, і сидить за прапорцем функції, який вимкнено.

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

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