Как перенести физический сервер в виртуалку

MAATRIX

Стоит старый физический сервер, который работает годами и никто не хочет его трогать — но железо стареет, комплектующие снимают с производства, а держать под одну задачу целый корпус с блоком питания и вентиляторами становится дорого. Перенос такой системы в виртуальную машину (P2V, physical-to-virtual) решает эту проблему: сама система и всё её содержимое переезжают на новый хост без переустановки. Но у P2V есть одна ловушка, в которую попадают почти все, кто делает это впервые — и разбираться с ней лучше до переноса, а не после того как сервер не загрузился.

Зачем вообще переносить физический сервер в виртуалку

Причины на практике сводятся к двум сценариям.

Консолидация железа. Если у вас несколько старых физических серверов — например, один под 1С, второй под файловую шару, третий под внутренний сайт — держать их как отдельные физические машины избыточно. Современный сервер с приличным количеством ядер и памяти легко тянет 3-5 таких нагрузок одновременно в виде виртуальных машин на одном гипервизоре (Proxmox VE, голый KVM, Hyper-V). Экономия считается не абстрактно: меньше физических корпусов — меньше электричества на само железо и охлаждение, меньше единиц оборудования на обслуживании и в SLA, меньше UPS и сетевых портов. Вместо трёх серверов в стойке — один мощный хост и три VM на нём.

Списание устаревающего сервера. Второй сценарий чаще встречается на практике: физический сервер работает нормально, но ему 7-10 лет, гарантии на комплектующие давно нет, а замена вышедшего из строя диска или блока питания становится квестом — деталей под этот форм-фактор либо не найти, либо они стоят как новый сервер. При этом сама система на нём настроена, обкатана и трогать её конфигурацию никто не хочет. P2V позволяет снять именно то, что работает, и перенести это на современное железо гипервизора, не переустанавливая и не перенастраивая ничего внутри самой системы.

Отдельно стоит понимать, чем P2V отличается от миграции между гипервизорами: там источник — уже виртуальная машина, и формат диска совместим или почти совместим. При P2V источник — реальное железо, и именно поэтому возникает проблема с драйверами, о которой ниже.

Базовый подход: снимаем образ диска и подключаем его как виртуальный

Есть два рабочих способа получить образ диска с физического сервера.

Специализированные инструменты клонирования. Это самый предсказуемый путь. Для Linux и в целом для образов дисков — Clonezilla (загрузочный live-образ, снимает диск целиком или посекторно, умеет писать сразу в разные форматы). Для Windows — Acronis True Image, Macrium Reflect или встроенный wbadmin для полного образа системы. Эти инструменты умеют снимать образ "на горячую" через снапшот тома (VSS в Windows), не останавливая сервис, что критично для production-машины, которую нельзя выключить на несколько часов.

Посекторное копирование при остановленной системе. Более грубый, но универсальный вариант — загрузиться с live-USB (например, с тем же SystemRescue или любым Linux live-образом) и снять образ диска целиком:

dd if=/dev/sda of=/mnt/backup/server-disk.img bs=4M status=progress conv=sync,noerror

Плюс этого способа — он не зависит от файловой системы и типа ОС внутри, снимает диск байт в байт. Минус — система должна быть остановлена на время снятия образа, и итоговый файл занимает столько же места, сколько занят диск целиком (если не сжимать на лету, например через gzip в пайп).

После снятия образ нужно привести к формату, понятному вашему гипервизору, и подключить как виртуальный диск новой VM:

# перегонка raw-образа в qcow2 для KVM/Proxmox
qemu-img convert -f raw -O qcow2 server-disk.img server-disk.qcow2

# посмотреть, что получилось
qemu-img info server-disk.qcow2

Дальше образ подключается к новой VM как обычный диск — через virsh, конфиг Proxmox или веб-интерфейс. На этом этапе многие ожидают, что систему можно просто загрузить — и здесь начинается основная часть проблемы P2V.

Есть и полуавтоматический путь — утилита virt-v2v из libguestfs, которая умеет забирать образ (в том числе напрямую с VMware или из образа диска) и одновременно готовить его под KVM: подменяет драйверы, чистит специфичные для старого гипервизора/железа службы. Работает не идеально и не на все версии ОС, особенно старые, но для типовых Linux и относительно свежих Windows сильно экономит время по сравнению с ручной подготовкой.

Главная засада P2V: система заточена под конкретное железо

Вот в чём суть проблемы, и её нужно понимать до переноса, а не после первого неудачного запуска. Операционная система, установленная на физическом сервере, не абстрактна — она содержит и использует драйверы под конкретное железо этого сервера: под конкретный контроллер диска (например, аппаратный RAID-контроллер определённого производителя или конкретный SATA/SAS-чипсет), под конкретную сетевую карту.

Когда вы подключаете снятый образ как диск виртуальной машины, виртуальное "железо" — даже эмулированное гипервизором максимально стандартно — почти никогда не совпадает с тем, под что система была настроена изначально. Разница особенно велика, если исходный физический контроллер диска сильно отличается от того, что предлагает гипервизор по умолчанию.

Итог на практике: при первом запуске перенесённого образа как VM система может не загрузиться вообще. Для Windows это классический синий экран INACCESSIBLE_BOOT_DEVICE сразу после логотипа загрузки — система пытается инициализировать драйвер диска, которого просто нет в её загрузочном наборе, потому что виртуальный контроллер (особенно если это virtio-scsi или virtio-blk — самый производительный вариант в KVM) для неё абсолютно незнакомое устройство.

Это не редкий крайний случай, а типичная ситуация почти при каждом первом P2V-переносе, если не подготовиться заранее. Разбор именно этой механики — почему виртуальный диск, который выглядит как обычный SATA/SCSI-диск, на деле требует своего драйвера — подробно разобран в статье про virtio и эмуляцию устройств: вкратце, virtio — это не эмуляция реального физического устройства, а паравиртуализованный интерфейс, специфичный для KVM, и система обязана иметь под него драйвер заранее.

Windows: ставим virtio-драйверы до самого переноса

Практика, которая реально работает и экономит часы разбора синих экранов — установить нужные драйверы в исходную физическую систему заранее, ещё до снятия образа.

Если вы планируете перенос именно в KVM-based гипервизор (Proxmox VE, голый libvirt/KVM), последовательность такая:

1. Скачайте ISO с virtio-драйверами для Windows (виртуальный CD с драйверами под virtio-blk/virtio-scsi, virtio-net и другие устройства — этот образ поддерживается сообществом и распространяется отдельно от самого QEMU).
2. Подключите ISO к физическому серверу как виртуальный привод (или распакуйте нужные .inf-файлы на диск) и установите драйвер контроллера диска (viostor для virtio-blk или vioscsi для virtio-scsi) и сетевой карты (NetKVM) через диспетчер устройств — как обычное добавление драйвера для "неизвестного устройства", даже если сейчас такого устройства физически нет.
3. Убедитесь, что драйвер зарегистрирован как критический для загрузки (boot-critical) — для дискового драйвера это должно происходить автоматически при установке через .inf, но стоит перепроверить в реестре ветку HKLM\SYSTEM\CurrentControlSet\Services\viostor (или vioscsi), значение Start должно быть 0 (загружается на этапе загрузки ядра).
4. Только после этого снимайте образ диска и переносите его в новую VM с диском на virtio-scsi контроллере.

Смысл в том, что нужный драйвер уже присутствует внутри образа системы до того, как железо реально сменилось — Windows находит его в своём драйверном пуле при следующей загрузке, вместо того чтобы упасть в синий экран.

Если про подготовку заранее забыли (сервер уже перенесён, и он не грузится) — рабочий обходной путь: подключите перенесённый диск к новой VM не через virtio, а через эмулируемый IDE или SATA-контроллер (для них в Windows драйвер универсальный и встроен всегда), дайте системе загрузиться в таком виде, установите внутри уже загруженной системы virtio-драйверы, выключите VM, переключите диск на virtio-scsi и загрузитесь снова. Это на один шаг дольше, но спасает, если про virtio не подумали заранее. Подробный разбор типичных граблей именно на Windows и virtio есть в статье про Windows в KVM и драйверы virtio.

Linux: обычно проще, но initramfs всё равно нужно проверить

С Linux ситуация на практике заметно спокойнее — ядро Linux по умолчанию собирается с широкой встроенной поддержкой самых разных драйверов диска и сети "из коробки", и модуль virtio-blk/virtio-scsi/virtio-net почти всегда уже есть в системе, даже если раньше не использовался.

Тем не менее стоит проверить и, если нужно, пересобрать initramfs с учётом нового набора виртуальных драйверов — потому что initramfs собирается под конкретное железо на момент установки, и если модуль контроллера диска не попал туда явно, при загрузке на новом виртуальном железе ядро может не найти корневой раздел.

Для дистрибутивов с Debian/Ubuntu (initramfs-tools):

# добавить модули явно, если их ещё нет
echo "virtio_blk" >> /etc/initramfs-tools/modules
echo "virtio_scsi" >> /etc/initramfs-tools/modules
echo "virtio_net" >> /etc/initramfs-tools/modules

# пересобрать initramfs для всех установленных ядер
update-initramfs -u -k all

Для RHEL/CentOS/Fedora (dracut):

echo 'add_drivers+=" virtio_blk virtio_scsi virtio_net "' > /etc/dracut.conf.d/virtio.conf
dracut --regenerate-all --force

Отдельно стоит проверить /etc/fstab и загрузчик (/boot/grub/grub.cfg или конфиг GRUB2) на предмет того, как там указан корневой раздел. Если система смонтирована по имени устройства (/dev/sda1), а не по UUID, после переноса на другой контроллер устройство вполне может стать /dev/vda1 вместо /dev/sda1 — и загрузка упадёт с "root device not found", хотя сам диск подключён и виден. Правильная практика — использовать в fstab и grub именно UUID= (посмотреть можно командой blkid), это не зависит от того, как называется контроллер диска на новом железе.

Тестируем в изоляции, не спешим отключать физический сервер

Даже если всё выше сделано правильно, перенесённую VM стоит проверить в изолированном окружении, прежде чем полностью отключать исходный физический сервер. Практический чек-лист:

• Поднимите VM в отдельном VLAN или вообще без сетевого моста наружу (только с NAT или изолированной внутренней сетью), чтобы она не конфликтовала по IP/имени с ещё работающим физическим оригиналом.
• Проверьте, что все сервисы стартуют штатно, а не просто что система загрузилась — специфичные для железа службы (агенты мониторинга оборудования, драйверы конкретных RAID-контроллеров, лицензионные привязки к MAC-адресу или серийному номеру) могут падать даже при успешной загрузке ОС.
• Прогоните реальную нагрузку — тестовые запросы к базе, проверку файловых шар, синтетический трафик — не только "пинг прошёл".
• Сверьте контрольные суммы критичных файлов/таблиц данных с оригиналом, если перенос был не "на горячую", а по образу с работающей системы — гарантии консистентности при снятии образа без остановки сервиса не стопроцентные.
• Держите физический сервер выключенным, но не разобранным и не списанным ещё 1-2 недели после успешного переноса — это стандартная практика на случай, если проблема всплывёт не сразу, а под нагрузкой через несколько дней (например, редкий фоновый job, который не запускался при тестировании).

Как именно проверить, что перенос — не только P2V, но миграция в целом — прошёл успешно с точки зрения данных и сервисов, разобрано отдельно в статье как проверить, что миграция прошла успешно. Если переносите не единичный сервер, а сразу несколько с чёткой очерёдностью и окном на откат, полезно заранее свериться с материалом как составить план миграции на новый сервер.

Частые вопросы