import: merge .wiki/concepts/ from temp prefix into existing dir (history preserved via merge+rename)
This commit is contained in:
140
.wiki/concepts/vbox-windows-stability-tuning.md
Normal file
140
.wiki/concepts/vbox-windows-stability-tuning.md
Normal file
@@ -0,0 +1,140 @@
|
||||
---
|
||||
title: VirtualBox + Windows-гость — нюансы стабильности при cross-hypervisor миграции
|
||||
type: concept
|
||||
tags: [virtualbox, windows, kvm, migration, troubleshooting]
|
||||
sources: [../sources/nas-recovery-session-2026-05-18.md]
|
||||
updated: 2026-05-19
|
||||
---
|
||||
|
||||
# VirtualBox + Windows-гость: cross-hypervisor migration
|
||||
|
||||
Импорт OVA с Synology VMM (KVM-based) в VirtualBox прошёл через 3 круга проблем. Записано чтобы в следующий раз не танцевать. Касается [[snolla-recovery-vm]].
|
||||
|
||||
## Симптом исходный
|
||||
|
||||
OVA импортируется через `VBoxManage import`, VM стартует, Windows валится в WinRE ("Восстановление при загрузке не удалось восстановить компьютер"). Startup Repair не помогает.
|
||||
|
||||
## Цепочка фиксов (применять по порядку)
|
||||
|
||||
### 1. Storage controller: SCSI LsiLogic → SATA AHCI
|
||||
|
||||
OVA с KVM-источника обычно имеет SCSI LsiLogic. Windows-гость не имеет встроенного boot-driver для VBox's LsiLogic emulation. SATA AHCI — generic, поддерживается любым Windows из коробки.
|
||||
|
||||
```
|
||||
VBoxManage controlvm "<vm>" poweroff
|
||||
VBoxManage storageattach "<vm>" --storagectl "SCSI" --port 0 --device 0 --medium none
|
||||
VBoxManage storagectl "<vm>" --name "SCSI" --remove
|
||||
VBoxManage storagectl "<vm>" --name "SATA" --add sata --controller IntelAhci --portcount 4
|
||||
VBoxManage storageattach "<vm>" --storagectl "SATA" --port 0 --device 0 --type hdd --medium "<vmdk-path>"
|
||||
```
|
||||
|
||||
После этого Windows бутится дальше WinRE → доходит до login screen.
|
||||
|
||||
### 2. Hyper-V Virtualization Infrastructure Driver — disable в Safe Mode
|
||||
|
||||
После login Windows зависает в **чёрный экран после Welcome**. Виновник — Microsoft Hyper-V virtualization infrastructure driver, который остался от Synology VMM/KVM. Под VBox он не находит свой target hypervisor → виснет.
|
||||
|
||||
Доступ: жмёшь power → Shift+Restart → Recovery → Troubleshoot → Advanced Options → Startup Settings → Restart → **4 (Safe Mode)** или **5 (Safe Mode with Networking)**.
|
||||
|
||||
В Safe Mode:
|
||||
- Device Manager → Системные устройства → **Драйвер инфраструктуры виртуализации Microsoft Hyper-V** → правый клик → **Отключить устройство** (Disable, не удалять — потом можно вернуть).
|
||||
- Параллельно почистить "Другие устройства" с жёлтыми треугольниками (audio-controller, base system device) — uninstall, без удаления драйверов.
|
||||
|
||||
Reboot нормально → Windows загружается до desktop.
|
||||
|
||||
### 3. Paravirt provider: default → kvm
|
||||
|
||||
После пары часов uptime VM начинает виснуть рандомно. Корень — несоответствие paravirt-интерфейса между source-гипервизором (Synology VMM = KVM) и VBox default (`default`/`auto`, который пытается подружиться с гостем но не угадывает).
|
||||
|
||||
```
|
||||
VBoxManage modifyvm "<vm>" --paravirtprovider kvm
|
||||
```
|
||||
|
||||
Windows-гость, который изначально загружал KVM paravirt drivers (virtio?), теперь под VBox видит знакомый интерфейс → стабильнее.
|
||||
|
||||
### 4. OS type: Other_64 → Windows10_64
|
||||
|
||||
VBox по умолчанию ставит OS type = `Other/Unknown (64-bit)` при импорте OVA с неузнанной маркировкой. Это означает дефолтные acceleration settings, которые могут не подходить Windows.
|
||||
|
||||
```
|
||||
VBoxManage modifyvm "<vm>" --ostype Windows10_64
|
||||
```
|
||||
|
||||
Включает VBox-внутренние оптимизации для Windows (HPET off, large pages on, и др.).
|
||||
|
||||
### 5. HPET off, vCPU 2 (а не 4), RAM 4 GB
|
||||
|
||||
- HPET (High Precision Event Timer) — для Windows-гостя на VBox чаще создаёт jitter чем помогает. Off:
|
||||
```
|
||||
VBoxManage modifyvm "<vm>" --hpet off
|
||||
```
|
||||
- vCPU: 4 на 2-ядерном/4-ядерном хосте может создавать contention. Снизить до 2:
|
||||
```
|
||||
VBoxManage modifyvm "<vm>" --cpus 2
|
||||
```
|
||||
- RAM: 4 GB достаточно для IIS + CMS + Windows на легкой нагрузке.
|
||||
|
||||
### 6. Установить **VirtualBox Guest Additions**
|
||||
|
||||
Без GA Windows использует generic Microsoft драйверы для VBox-эмулированного железа. С GA — нативные оптимизированные VBox-драйверы для сети/видео/storage/устройств.
|
||||
|
||||
**Установить через VRDE-консоль** (mstsc к `localhost:13389`), а не через сетевой RDP — потому что сеть может умереть до установки GA.
|
||||
|
||||
Шаги:
|
||||
1. На хосте: `VBoxManage storagectl "<vm>" --name "IDE" --add ide --controller PIIX4` (новый контроллер для DVD)
|
||||
2. `VBoxManage storageattach "<vm>" --storagectl "IDE" --port 0 --device 0 --type dvddrive --medium "C:\Program Files\Oracle\VirtualBox\VBoxGuestAdditions.iso"`
|
||||
3. В VM: Win+E → D: drive → запустить `VBoxWindowsAdditions.exe` → Next/Install/доверять Oracle publisher → Restart.
|
||||
|
||||
После: `GuestAdditionsRunLevel=3` (полностью активны). VM существенно стабильнее.
|
||||
|
||||
## Network nuances
|
||||
|
||||
### Bridged WiFi нестабильно
|
||||
|
||||
Если хост-машина подключена по WiFi и VBox NIC = bridged через WiFi adapter — частые проблемы с promiscuous mode. Симптомы:
|
||||
- VM получает IP по DHCP
|
||||
- Работает 10-60 минут
|
||||
- Network "повисает": TCP-handshake проходит, но трафик не идёт
|
||||
- ARP-table показывает MAC, но State=`Stale`
|
||||
|
||||
Решение: **NAT с port forwarding** вместо bridged.
|
||||
|
||||
```
|
||||
VBoxManage modifyvm "<vm>" --nic1 nat
|
||||
VBoxManage controlvm "<vm>" natpf1 "rdp,tcp,127.0.0.1,23389,,3389"
|
||||
VBoxManage controlvm "<vm>" natpf1 "ssh,tcp,127.0.0.1,8022,,22"
|
||||
VBoxManage controlvm "<vm>" natpf1 "http,tcp,127.0.0.1,18080,,80"
|
||||
# ...и так далее на нужные порты
|
||||
```
|
||||
|
||||
VM получает 10.0.2.15 (default NAT subnet). Host достижим из VM по 10.0.2.2 (NAT gateway).
|
||||
|
||||
### Network recovery inside Windows VM
|
||||
|
||||
Если внутри VM network "повис" (бывает даже с GA + NAT):
|
||||
|
||||
```
|
||||
VBoxManage guestcontrol "<vm>" run --exe "C:\Windows\System32\cmd.exe" \
|
||||
--username vitya --password '<pw>' --wait-stdout --wait-stderr \
|
||||
-- cmd.exe /c "ipconfig /release && ipconfig /renew"
|
||||
```
|
||||
|
||||
Через GA это работает не требуя SSH/RDP связи.
|
||||
|
||||
## VRDE backup-доступ
|
||||
|
||||
Всегда включён в нашей конфигурации как fallback:
|
||||
|
||||
```
|
||||
VBoxManage controlvm "<vm>" vrde on
|
||||
VBoxManage controlvm "<vm>" vrdeport 13389
|
||||
```
|
||||
|
||||
`mstsc → localhost:13389` показывает VM-консоль независимо от состояния сети в VM. Полезно для recovery когда RDP в VM умер.
|
||||
|
||||
## Что не сработало
|
||||
|
||||
- Hyper-V на хосте — рассматривался как cleaner альтернатива для Windows-гостя, но требует доустановки Hyper-V Manager и перезагрузки хоста. Отложено как Plan B, не понадобилось.
|
||||
- VMware Workstation Pro 17 — бесплатен с 2024, но та же migration-головная боль на Windows-госте с другого гипервизора.
|
||||
|
||||
Связано: [[snolla-recovery-vm]], [[windows-recovery-host]].
|
||||
Reference in New Issue
Block a user