Windows Server na Proxmox działa wolno – checklista VirtIO, ballooning i guest-agent

„Przenieśliśmy Windows Server na Proxmox i wszystko chodzi wolniej niż na VMware." To jedno z najczęstszych zgłoszeń tuż po migracji – i niemal zawsze nie jest to wina Proxmoxa ani sprzętu, tylko domyślnej, „bezpiecznej" konfiguracji maszyny, w której Windows nie ma sterowników do szybkich urządzeń wirtualnych. Dobra wiadomość: to się naprawia w kilkanaście minut, bez reinstalacji.

Poniżej checklista w kolejności od największego wpływu na wydajność. Jeśli świeżo migrowałeś z VMware, przejdź ją w całości – zwykle wąskim gardłem są dwa–trzy z tych punktów naraz.

1. Sterowniki VirtIO – fundament wydajności

Objaw: Windows działa, ale dysk i sieć są wyraźnie wolniejsze niż na VMware.

Dlaczego: żeby maszyna „nie stanęła" po migracji, dysk i karta sieciowa lądują często na emulowanych, zgodnych urządzeniach (IDE/SATA, karta e1000). Emulacja jest wolna – każda operacja I/O przechodzi przez warstwę udającą fizyczny sprzęt. VirtIO to sterowniki paravirtual: gość „wie", że jest maszyną wirtualną i rozmawia z hostem wprost, bez udawania sprzętu.

Rozwiązanie: podłącz do VM obraz virtio-win.iso (oficjalne sterowniki VirtIO dla Windows) i zainstaluj paczkę virtio-win-guest-tools – jednym instalatorem dostajesz sterowniki dysku (VirtIO SCSI), sieci (VirtIO Net), balonu pamięci oraz qemu-guest-agent. To pojedyncza czynność, która daje największy skok wydajności.

2. Kontroler dysku: VirtIO SCSI single + discard

Objaw: wolne operacje dyskowe, wysoki czas odpowiedzi, thin provisioning „puchnie" i nie zwalnia miejsca.

Dlaczego: dysk wisi na IDE/SATA albo na kontrolerze bez włączonego odzyskiwania miejsca.

Rozwiązanie: po zainstalowaniu sterowników VirtIO (punkt 1) przełącz dysk na VirtIO SCSI single (Hardware → Disk → Bus/Device). W ustawieniach dysku włącz Discard i – jeśli storage pod spodem to SSD/NVMe/thin – SSD emulation. Discard sprawia, że skasowane dane realnie zwalniają bloki na warstwie storage. To poprawia i wydajność, i zużycie miejsca.

Kolejność ma znaczenie: najpierw sterowniki (na SATA), potem przełączenie na VirtIO SCSI. Odwrotnie Windows nie zobaczy dysku systemowego i wpadnie w niebieski ekran. Opisaliśmy to szerzej w tekście o pułapkach migracji z VMware.

3. Karta sieciowa VirtIO

Objaw: niska przepustowość sieci, wysokie obciążenie CPU przy transferach.

Dlaczego: emulowana karta e1000 albo Realtek obciąża procesor i nie wyciąga pełnej przepustowości.

Rozwiązanie: ustaw model karty na VirtIO (paravirtualized). Wymaga sterownika z paczki VirtIO (punkt 1) – bez niego Windows straci sieć, więc najpierw sterowniki, potem zmiana modelu. Po przełączeniu przepustowość rośnie, a obciążenie CPU spada.

4. Ballooning – pamięć, która potrafi zaszkodzić

Objaw: Windows „zajmuje" całą przydzieloną pamięć i jej nie oddaje, albo – przeciwnie – przy włączonym balonie działa niestabilnie pod obciążeniem.

Dlaczego: memory ballooning pozwala hostowi dynamicznie odbierać i oddawać pamięć maszynom. Działa tylko wtedy, gdy w gościu jest zainstalowany sterownik balonu (część paczki VirtIO). Bez sterownika ustawiony „minimum/maksimum" pamięci nie działa jak trzeba, a monitoring pokazuje mylące wartości zużycia.

Rozwiązanie: zdecyduj świadomie. Jeśli chcesz korzystać z ballooningu (overcommit pamięci na hoście) – zainstaluj sterownik balonu i ustaw sensowny zakres min/max. Dla maszyn krytycznych na wydajność (bazy danych, terminal server) często lepiej wyłączyć ballooning i przydzielić pamięć na stałe. Nie zostawiaj stanu pośredniego: balon włączony, sterownik nieobecny.

5. Typ CPU – nie zostawaj na `kvm64`

Objaw: aplikacje liczą wolniej niż na VMware, brakuje nowoczesnych instrukcji (AES-NI, AVX).

Dlaczego: domyślny typ CPU `kvm64` jest maksymalnie zgodny, ale ubogi – nie przekazuje gościowi nowoczesnych rozszerzeń procesora.

Rozwiązanie: na pojedynczym hoście lub jednorodnym klastrze ustaw CPU type = host (pełna wydajność). W klastrze z różnymi generacjami procesorów wybierz wspólny mianownik, np. x86-64-v2-AES, żeby zachować działającą live migration. Zmiana wymaga restartu maszyny.

6. qemu-guest-agent – nie tylko dla porządku

Objaw: Proxmox nie pokazuje adresu IP, „Shutdown" twardo ubija maszynę, backupy nie są w pełni spójne.

Dlaczego: brak qemu-guest-agent w gościu. To on odpowiada za czyste zamykanie, raportowanie IP oraz „zamrożenie" systemu plików (fs-freeze) na czas backupu.

Rozwiązanie: agent jest w paczce virtio-win-guest-tools (punkt 1). Po instalacji włącz go w Proxmox: Options → QEMU Guest Agent → Enabled i zrestartuj VM. Przy Windows z bazami danych to warunek spójnych backupów.

7. Drobne, ale realne: zaplanowane zadania i „energooszczędność"

Dwa dodatki, które potrafią zjadać wydajność świeżego Windows Server:

• Plan zasilania ustawiony na „zrównoważony" – zmień na Wysoka wydajność, żeby CPU nie schodził w tryb oszczędzania w środowisku serwerowym.
• Zaległe zadania po VMware – upewnij się, że odinstalowałeś VMware Tools; ich pozostałości bywają źródłem błędów i niepotrzebnych procesów.

Zrobić samemu czy zlecić?

Pojedynczą maszynę dostroisz sam według tej listy – i warto. Przy całej flocie Windows Serverów (kilkadziesiąt VM, terminal serwery, bazy danych, RemoteApp) tuning to już projekt: profil CPU spójny w klastrze, świadoma polityka ballooningu, szablony maszyn z gotowym VirtIO, testy wydajności przed i po. Robimy to po polsku – od migracji, przez tuning, po wsparcie powdrożeniowe.

FAQ

Skąd wziąć sterowniki VirtIO dla Windows?

Z oficjalnego obrazu virtio-win.iso (repozytorium Proxmox/Fedora). Podłączasz go jako CD-ROM i instalujesz paczkę virtio-win-guest-tools, która zawiera komplet sterowników i agenta.

Czy muszę reinstalować Windows, żeby przejść na VirtIO?

Nie. Instalujesz sterowniki na działającym systemie (dysk systemowy tymczasowo na SATA), a potem przełączasz kontroler na VirtIO SCSI. Bez reinstalacji.

Czy ballooning zawsze warto włączać?

Nie. Dla maszyn krytycznych na wydajność (bazy, terminal server) często lepiej przydzielić pamięć na stałe. Ballooning ma sens przy overcommicie pamięci na hoście – ale tylko z zainstalowanym sterownikiem balonu.

CPU „host" czy model zgodny?

Host = maksymalna wydajność, ale przypina maszynę do konkretnego procesora. W klastrze z różnymi CPU wybierz wspólny model (np. x86-64-v2-AES), żeby działała live migration.

Podsumowanie

Wolny Windows na Proxmox to prawie zawsze brak VirtIO, zły kontroler, źle ustawiony balon albo `kvm64` zamiast `host`. Przejdź checklistę od góry – największy skok dają sterowniki VirtIO i kontroler SCSI single – a maszyna dogoni (a często przegoni) to, co miałeś na VMware.

Masz do dostrojenia całe środowisko Windows na Proxmox? Umów konsultację, policz subskrypcje w kalkulatorze, albo napisz na proxmox@polsoft.pl / zadzwoń 32 209 80 39 (pon.–pt. 8:00–16:00).