После переезда с Windows Hyper-V Server 2012 R2 на Hyper-V 2016 одна из виртуальных машин после переноса бэкапилась в Veeam с предупреждением. Текст предупреждения — Changed block tracking will not be used for this VM until you upgrade VM hardware version to 8.0 or later. Ниже расскажу, в чем тут дело и как избавиться от этого сообщения.
https://serveradmin.ru/changed-block-tracking-will-not-be-used-for-this-vm-until-you-upgrade-vm-hardware-version-to-8-0-or-later/
#ошибка #hyperv
https://serveradmin.ru/changed-block-tracking-will-not-be-used-for-this-vm-until-you-upgrade-vm-hardware-version-to-8-0-or-later/
#ошибка #hyperv
Server Admin
Changed block tracking will not be used for this VM until you...
После переезда с Windows Hyper-V Server 2012 R2 на Hyper-V 2016 одна из виртуальных машин после переноса бэкапилась в Veeam с предупреждением. Текст предупреждения - Changed block tracking will...
Наконец-то в июне в открытом доступе появилась финальная версия бесплатного гипервизора от Microsoft. Я расскажу, как установить и настроить Microsoft Hyper-V Server 2019 для удобного создания и управления виртуальными машинами. Традиционно, там не так все просто и удобно, как могло бы быть. Обязательно требуется первоначальная подготовка к комфортной работе.
https://serveradmin.ru/ustanovka-i-nastrojka-windows-hyper-v-server-2019/
#статья #hyperv
https://serveradmin.ru/ustanovka-i-nastrojka-windows-hyper-v-server-2019/
#статья #hyperv
Server Admin
Установка и настройка Windows Hyper-V Server 2019 | serveradmin.ru
Я расскажу, как установить и настроить Microsoft Hyper-V Server 2019 для удобного создания и управления виртуальными машинами.
Написал небольшую заметку про установку неподписанных драйверов на бесплатный Microsoft Hyper-V Server 2019. Будет актуальна для любой Core версии Windows Server.
https://serveradmin.ru/ustanovka-nepodpisannogo-drajvera-v-windows-hyper-v-server/
#статья #hyperv #windows
https://serveradmin.ru/ustanovka-nepodpisannogo-drajvera-v-windows-hyper-v-server/
#статья #hyperv #windows
Server Admin
Установка неподписанного драйвера в Windows Hyper-V Server
Ранее я уже рассказывал про установку и настройку apcupsd - утилиты для работы с UPS. В этот раз мне понадобилось подключить UPS непосредственно к серверу с Windows Hyper-V Server 2019. Сходу не...
Один из читателей сайта к статье о настройке proxmox написал комментарий по переносу виндовых виртуалок с hyperv на proxmox. Мне показалась информация полезной, поэтому оформляю в заметку и делюсь с вами. Самому тоже приходилось делать такие переносы, но инструкцию не составлял.
Для начала надо перенести vhdx образы на proxmox и сконвертировать в нужный вам формат. Например в qcow2:
qemu-img convert -O qcow2 /path/to/vhdx/VM.vhdx /path/to/qcow2/vm.qcow2
Далее создаём новую виртуалку, добавляем ей диск минимального размера (VirtIO SCSI). Он нужен будет позже, чтобы установить virtio драйвера на диск в систему. Добавляем к этой виртуалке сконвертированный диск как ide и делаем его загрузочным. Так же добавляем cd-rom и подключаем к нему virtio-win.iso последней версии. В настройках Hardware -> Bios меняем с дефолтного SeaBios на OVMF (UEFI).
Запускаем виртуалку. Должна загрузиться. Ставим все драйвера, в том числе на диск, а так же qemu-guest-agent. Выключаем.
Далее либо через правку конфига vm в консоли меняете путь от virtio диска минимального размера на рабочий, либо через веб интерфейс отцепляете оба диска и обратно подключаете системный диск как VirtIO SCSI. На этом всё.
Скорее всего прямо сейчас вам эта инструкция нее нужна, но если в будущем может пригодиться, не забудьте сохранить.
#hyperv #proxmox
Для начала надо перенести vhdx образы на proxmox и сконвертировать в нужный вам формат. Например в qcow2:
qemu-img convert -O qcow2 /path/to/vhdx/VM.vhdx /path/to/qcow2/vm.qcow2
Далее создаём новую виртуалку, добавляем ей диск минимального размера (VirtIO SCSI). Он нужен будет позже, чтобы установить virtio драйвера на диск в систему. Добавляем к этой виртуалке сконвертированный диск как ide и делаем его загрузочным. Так же добавляем cd-rom и подключаем к нему virtio-win.iso последней версии. В настройках Hardware -> Bios меняем с дефолтного SeaBios на OVMF (UEFI).
Запускаем виртуалку. Должна загрузиться. Ставим все драйвера, в том числе на диск, а так же qemu-guest-agent. Выключаем.
Далее либо через правку конфига vm в консоли меняете путь от virtio диска минимального размера на рабочий, либо через веб интерфейс отцепляете оба диска и обратно подключаете системный диск как VirtIO SCSI. На этом всё.
Скорее всего прямо сейчас вам эта инструкция нее нужна, но если в будущем может пригодиться, не забудьте сохранить.
#hyperv #proxmox
Технический пост, который уже давно нужно было сделать, но всё руки не доходили. На канале много содержательных заметок по различным темам. Иногда сам через поиск ищу то, о чём писал. Ниже набор наиболее популярных тэгов по которым можно найти что-то полезное (и не очень).
#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала
Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow
#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала
Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow
Одной из существенных проблем гипервизора HyperV является невозможность пробросить USB устройство в виртуальную машину.
Есть решение этой проблемы — open source проект usbipd-win. С его помощью можно пробросить USB устройство, подключенное к машине под управлением Windows в любую другую по сети, либо в локальный Linux, работающий по WSL2 (инструкция от microsoft).
На базе проекта usbip существует много различных продуктов. Конкретно usbipd-win это только сервер под Windows. Я начал с него, потому что он максимально просто устанавливается и настраивается. Можно через winget поставить:
Либо скачать msi пакет из репы. Далее смотрим список подключенных устройств и публикуем одно из них:
Опубликованный с помощью этого сервера ключ можно подключить к Linux или Windows машине. Под Linux достаточно установить соответствующие пакеты с утилитой и модулем ядра. Для Debian вот эти:
После этого можно смотреть список опубликованных ключей и подключать один из них:
Для подключения этих ключей в Windows, нужно установить Windows Agent. Взять его можно из другого репозитория usbip-win. Там есть инструкция по установке агента. Она немного замороченная, по сравнению с установкой сервера, но ничего особо сложного нет. Вопрос решаемый.
Точно так же можно публиковать USB устройства с Linux по сети на другие машины. Есть пакет сервера и под OpenWRT. Таким простым и бесплатным способом можно решить вопрос проброса USB ключей. Для HASP работает отлично. Заметку имеет смысл сохранить.
#windows #hyperv
Есть решение этой проблемы — open source проект usbipd-win. С его помощью можно пробросить USB устройство, подключенное к машине под управлением Windows в любую другую по сети, либо в локальный Linux, работающий по WSL2 (инструкция от microsoft).
На базе проекта usbip существует много различных продуктов. Конкретно usbipd-win это только сервер под Windows. Я начал с него, потому что он максимально просто устанавливается и настраивается. Можно через winget поставить:
> winget install usbipd
Либо скачать msi пакет из репы. Далее смотрим список подключенных устройств и публикуем одно из них:
> usbipd list
> usbipd bind --busid=4-3
Опубликованный с помощью этого сервера ключ можно подключить к Linux или Windows машине. Под Linux достаточно установить соответствующие пакеты с утилитой и модулем ядра. Для Debian вот эти:
# apt install usbip hwdata usbutils
После этого можно смотреть список опубликованных ключей и подключать один из них:
# usbip list --remote=10.20.1.56
# usbip attach -remote=10.20.1.56 --busid=4-3
Для подключения этих ключей в Windows, нужно установить Windows Agent. Взять его можно из другого репозитория usbip-win. Там есть инструкция по установке агента. Она немного замороченная, по сравнению с установкой сервера, но ничего особо сложного нет. Вопрос решаемый.
Точно так же можно публиковать USB устройства с Linux по сети на другие машины. Есть пакет сервера и под OpenWRT. Таким простым и бесплатным способом можно решить вопрос проброса USB ключей. Для HASP работает отлично. Заметку имеет смысл сохранить.
#windows #hyperv
Перенос VM с Hyper-V на Proxmox
На днях стояла задача перенести виртуальные машины Linux (Debian 11) с Hyper-V на KVM (Proxmox). Помучался изрядно, но в итоге всё получилось. Если VM первого поколения без EFI раздела, то проблем вообще никаких. Просто переносим диск виртуальной машины, конвертируем и подключаем к VM. Вообще ничего перенастраивать не надо, все имена дисков и сетевых адаптеров будут те же, что и на Hyper-V. А вот если машины второго поколения с загрузкой по EFI, то начинаются танцы с бубном. Причём у каждого свои, судя по информации из интернета.
Рассказываю, как в итоге сделал я, чтобы всё заработало. Перенос делал следующим образом:
1️⃣ Завершаю работу VM на Hyper-V.
2️⃣ Копирую файл диска vhdx на хост Proxmox.
3️⃣ Создаю в Proxmox новую виртуальную машину и обязательно указываю Bios: OVMF (UEFI), SCSI Controller: VirtIO SCSI. Остальное не принципиально. Диски можно никакие не добавлять. Но при этом у вас будет автоматически подключен EFI Disk, с какими-то своими параметрами, из которых я выбрал только формат - qcow2.
4️⃣ В консоли Proxmox конвертируем vhdx диск в диск виртуальной машины:
Формат команды следующий:
5️⃣ После импорта диск цепляется к VM в отключенном виде. Подключаем его как SCSI и настраиваем с него загрузку.
6️⃣ Загружаем VM с этого диска. Тут по многим руководствам из инета виртуалка уже запускается и нормально работает. Но не у меня. Я проваливался в uefi interactive shell v2.2 proxmox.
7️⃣ Заходим в bios этой виртуалки и отключаем там Secure Boot. Делается это в разделе Device Manager ⇨ Secure Boot Configuration. После этого у некоторых VM начинает загружаться, но опять не у меня.
8️⃣ Опять иду в bios, в раздел Boot Maintenance Manager ⇨ Boot Options ⇨ Add Boot Option. Выбираю импортированный диск VM. Там кроме него будет только CD-ROM, так что легко понять, что надо выбрать. Открывается обзор файловой системы EFI раздела от нашей системы. Перемещаемся там по директориям
А я сначала пробовал разные настройки VM, загружался с LiveCD и проверял разделы диска, загрузчик. Там всё ОК, данные нормально переезжают. Проблема именно в настройке загрузки через EFI раздел. Почему-то автоматом он не подхватывался. Может это была особенность Debian 11. Я переносил именно их.
❗️Сразу добавлю полезную информацию по поводу Centos 7. Может это будет актуально и для каких-то других система. Когда я переносил виртуалки с этой системой между гипервизорами, они не загружались, пока не пересоберёшь initramfs под конкретным гипервизором. Если просто перенести, то загрузка не ехала дальше из-за проблем с определением дисков на этапе загрузки. Пересборка initramfs решала эту проблему.
❗️И ещё один нюанс с переездами между гипервизорами, с которым сталкивался. Иногда система не грузится, потому что в fstab были прописаны имена дисков, которые на новом гипервизоре получили другие названия. Тогда грузимся с LiveCD и меняем диски в fstab и возможно в grub.
Тема переезда между разными типами гипервизоров непростая. Иногда проще воспользоваться какой-то системой, типа Veeam Agent For Linux или Rescuezilla. Так как я более ли менее теорию понимаю по этой теме, то переношу обычно вручную.
#linux #hyperv #виртуализация
На днях стояла задача перенести виртуальные машины Linux (Debian 11) с Hyper-V на KVM (Proxmox). Помучался изрядно, но в итоге всё получилось. Если VM первого поколения без EFI раздела, то проблем вообще никаких. Просто переносим диск виртуальной машины, конвертируем и подключаем к VM. Вообще ничего перенастраивать не надо, все имена дисков и сетевых адаптеров будут те же, что и на Hyper-V. А вот если машины второго поколения с загрузкой по EFI, то начинаются танцы с бубном. Причём у каждого свои, судя по информации из интернета.
Рассказываю, как в итоге сделал я, чтобы всё заработало. Перенос делал следующим образом:
1️⃣ Завершаю работу VM на Hyper-V.
2️⃣ Копирую файл диска vhdx на хост Proxmox.
3️⃣ Создаю в Proxmox новую виртуальную машину и обязательно указываю Bios: OVMF (UEFI), SCSI Controller: VirtIO SCSI. Остальное не принципиально. Диски можно никакие не добавлять. Но при этом у вас будет автоматически подключен EFI Disk, с какими-то своими параметрами, из которых я выбрал только формат - qcow2.
4️⃣ В консоли Proxmox конвертируем vhdx диск в диск виртуальной машины:
# qm importdisk 102 /mnt/500G/Debian11.vhdx local-500G
Формат команды следующий:
# qm importdisk <vmid> <source> <storage>
5️⃣ После импорта диск цепляется к VM в отключенном виде. Подключаем его как SCSI и настраиваем с него загрузку.
6️⃣ Загружаем VM с этого диска. Тут по многим руководствам из инета виртуалка уже запускается и нормально работает. Но не у меня. Я проваливался в uefi interactive shell v2.2 proxmox.
7️⃣ Заходим в bios этой виртуалки и отключаем там Secure Boot. Делается это в разделе Device Manager ⇨ Secure Boot Configuration. После этого у некоторых VM начинает загружаться, но опять не у меня.
8️⃣ Опять иду в bios, в раздел Boot Maintenance Manager ⇨ Boot Options ⇨ Add Boot Option. Выбираю импортированный диск VM. Там кроме него будет только CD-ROM, так что легко понять, что надо выбрать. Открывается обзор файловой системы EFI раздела от нашей системы. Перемещаемся там по директориям
/EFI/debian
, выбираем файл grubx64.efi
. То есть мы создаём новый вариант загрузки системы, выбрав этот файл. Там же пишем какое-то название для этой загрузки, чтобы отличить от остальных вариантов. Далее идём в раздел Boot Maintenance Manager ⇨ Boot Options ⇨ Change Boot Order и назначаем первым номером только что созданный вариант для загрузки. Сохраняем изменения и загружаемся. Теперь всё ОК, система загрузилась. А я сначала пробовал разные настройки VM, загружался с LiveCD и проверял разделы диска, загрузчик. Там всё ОК, данные нормально переезжают. Проблема именно в настройке загрузки через EFI раздел. Почему-то автоматом он не подхватывался. Может это была особенность Debian 11. Я переносил именно их.
❗️Сразу добавлю полезную информацию по поводу Centos 7. Может это будет актуально и для каких-то других система. Когда я переносил виртуалки с этой системой между гипервизорами, они не загружались, пока не пересоберёшь initramfs под конкретным гипервизором. Если просто перенести, то загрузка не ехала дальше из-за проблем с определением дисков на этапе загрузки. Пересборка initramfs решала эту проблему.
❗️И ещё один нюанс с переездами между гипервизорами, с которым сталкивался. Иногда система не грузится, потому что в fstab были прописаны имена дисков, которые на новом гипервизоре получили другие названия. Тогда грузимся с LiveCD и меняем диски в fstab и возможно в grub.
Тема переезда между разными типами гипервизоров непростая. Иногда проще воспользоваться какой-то системой, типа Veeam Agent For Linux или Rescuezilla. Так как я более ли менее теорию понимаю по этой теме, то переношу обычно вручную.
#linux #hyperv #виртуализация
Вчера несколько часов провозился с очень простой задачей, которая неожиданно доставила много хлопот. У меня есть два бесплатных сервера Microsoft Hyper-V Server 2016 и 2019. Решил немного перераспределить на них виртуалки, перенеся парочку с 2016 на 2019.
Задача простая и понятная. Можно использовать какие-то дополнительные инструменты для переноса, но проще всего сделать это в лоб. Останавливаем виртулаку, копируем её диск на другой гипервизор. Там создаём виртуальную машину и подключаем к ней перенесённый диск. Я и раньше постоянно так делал. Поступил подобным образом и в этот раз.
Виртуалка второго поколения с Windows благополучно переехала и запустилась. А вот с Debian 12 возникли неожиданные проблемы. Копирую диск, создаю новую виртуалку, подключаю к ней диск. Машина не стартует, не видит efi раздел. А это странно, так как раздел реально есть, с ним всё в порядке. К тому же винда благополучно переехала. На старом гипервизоре всё работает. Переезд с 2016 на 2019 полностью поддерживается. Это в обратную сторону могут быть проблемы, а с более старой версии на новую проблем быть не должно.
Тут я уже начал закапываться. Стал проверять версии виртуальных машин, менять их, пробовать разные поколения, создавать новые виртуалки с efi разделом и подсовывать им старый диск. Ничего не помогало. Уже понял, что предстоит длинная ночь, так как я не смогу спокойно уснуть, пока не разберусь, в чём проблема. Задача простая, проблем быть не должно.
Решил зайти с другого пути. Делаю штатно экспорт виртуальной машины, переношу на другой сервер, там запускаю импорт. Не работает. Импорт не видит виртуальную машину, говорит, что в директории ничего нет, хотя там всё лежит. С правами всё ОК, файлы читаются. Делаю ход конём. Экспортирую эту машину и пытаюсь сделать импорт на этом же гипервизоре. Это 100% должно работать. Но не работает. Импорт тоже не видит виртуальную машину в директории.
Тут я уже начинаю понимать, что у меня происходит какая-то локальная фигня и поиск мне тут не поможет. Иду в Veeam, делаю восстановление оттуда. Он обычно пишет ошибки совместимости, если перенос невозможен. Ошибок нет, восстановление идёт. Значит совместимость есть. Хранилище Veeam далековато, поэтому восстановление через него долгое, хочу всё же сделать напрямую и разобраться, в чём проблема.
Для управления гипервизорами Hyper-V я привык использовать стандартную оснастку Windows. Выделяю для задач администрирования отдельную виртуалку и туда в консоль подключаю все гипервизоры, чтобы удобно было управлять из одного места. Решил попробовать сделать Экспорт/Импорт через Windows Admin Center, который работает в браузере. Обычно я им не пользуюсь, так как там всё очень тормозит. Времени уходит раз в 5 больше, чем то же самое сделать в оснастке.
И о чудо, в Админ Центре экспорт и импорт прошёл без ошибок, виртуалка запустилась на новом месте, никаких проблем с efi разделом не возникло. Заработало всё сразу же.
Похоже на какой-то то ли локальный, то ли общий баг управления через оснастку, который проявился в таком неожиданном месте. Я даже не знаю, с чем это может быть связано. При подключении диска к виртуальной машине Linux 2-го поколения, созданной через оснастку управления Hyper-V, не видится во время загрузки efi раздел. Соответственно, система не загружается. С Windows машинами таких проблем нет. Как и нет проблем с переносом виртуалок Linux 1-го поколения без efi раздела.
Такая вот история вышла, которая вряд ли для кого-то ещё будет актуальна. Новых версий бесплатного Hyper-V больше не будет, так что пользоваться им большого смысла нет. Бесплатная связка Proxmox VE + PBS полностью закрывает вопросы виртуализации для малого и среднего бизнеса за 0 рублей. По Hyper-V буду скучать только в контексте использования в связке с Veeam. Это было удобно.
#hyperv
Задача простая и понятная. Можно использовать какие-то дополнительные инструменты для переноса, но проще всего сделать это в лоб. Останавливаем виртулаку, копируем её диск на другой гипервизор. Там создаём виртуальную машину и подключаем к ней перенесённый диск. Я и раньше постоянно так делал. Поступил подобным образом и в этот раз.
Виртуалка второго поколения с Windows благополучно переехала и запустилась. А вот с Debian 12 возникли неожиданные проблемы. Копирую диск, создаю новую виртуалку, подключаю к ней диск. Машина не стартует, не видит efi раздел. А это странно, так как раздел реально есть, с ним всё в порядке. К тому же винда благополучно переехала. На старом гипервизоре всё работает. Переезд с 2016 на 2019 полностью поддерживается. Это в обратную сторону могут быть проблемы, а с более старой версии на новую проблем быть не должно.
Тут я уже начал закапываться. Стал проверять версии виртуальных машин, менять их, пробовать разные поколения, создавать новые виртуалки с efi разделом и подсовывать им старый диск. Ничего не помогало. Уже понял, что предстоит длинная ночь, так как я не смогу спокойно уснуть, пока не разберусь, в чём проблема. Задача простая, проблем быть не должно.
Решил зайти с другого пути. Делаю штатно экспорт виртуальной машины, переношу на другой сервер, там запускаю импорт. Не работает. Импорт не видит виртуальную машину, говорит, что в директории ничего нет, хотя там всё лежит. С правами всё ОК, файлы читаются. Делаю ход конём. Экспортирую эту машину и пытаюсь сделать импорт на этом же гипервизоре. Это 100% должно работать. Но не работает. Импорт тоже не видит виртуальную машину в директории.
Тут я уже начинаю понимать, что у меня происходит какая-то локальная фигня и поиск мне тут не поможет. Иду в Veeam, делаю восстановление оттуда. Он обычно пишет ошибки совместимости, если перенос невозможен. Ошибок нет, восстановление идёт. Значит совместимость есть. Хранилище Veeam далековато, поэтому восстановление через него долгое, хочу всё же сделать напрямую и разобраться, в чём проблема.
Для управления гипервизорами Hyper-V я привык использовать стандартную оснастку Windows. Выделяю для задач администрирования отдельную виртуалку и туда в консоль подключаю все гипервизоры, чтобы удобно было управлять из одного места. Решил попробовать сделать Экспорт/Импорт через Windows Admin Center, который работает в браузере. Обычно я им не пользуюсь, так как там всё очень тормозит. Времени уходит раз в 5 больше, чем то же самое сделать в оснастке.
И о чудо, в Админ Центре экспорт и импорт прошёл без ошибок, виртуалка запустилась на новом месте, никаких проблем с efi разделом не возникло. Заработало всё сразу же.
Похоже на какой-то то ли локальный, то ли общий баг управления через оснастку, который проявился в таком неожиданном месте. Я даже не знаю, с чем это может быть связано. При подключении диска к виртуальной машине Linux 2-го поколения, созданной через оснастку управления Hyper-V, не видится во время загрузки efi раздел. Соответственно, система не загружается. С Windows машинами таких проблем нет. Как и нет проблем с переносом виртуалок Linux 1-го поколения без efi раздела.
Такая вот история вышла, которая вряд ли для кого-то ещё будет актуальна. Новых версий бесплатного Hyper-V больше не будет, так что пользоваться им большого смысла нет. Бесплатная связка Proxmox VE + PBS полностью закрывает вопросы виртуализации для малого и среднего бизнеса за 0 рублей. По Hyper-V буду скучать только в контексте использования в связке с Veeam. Это было удобно.
#hyperv
Microsoft
Windows Admin Center | Майкрософт
Используйте Microsoft Windows Admin Center для безопасного и эффективного управления серверами. Windows Admin Center позволяет менее чем за пять минут перейти от установки к управлению сервером.