--- title: Snolla Recovery VM (VirtualBox) — savestate'нута 2026-05-21 после 36h успешного soak type: entity tags: [vm, virtualbox, windows, iis, cms, recovery, savestate] sources: [../sources/nas-recovery-session-2026-05-18.md, ../sources/iis-host-migration-2026-05-19.md, ../concepts/iis-migration-2026-05-19-postmortem.md] updated: 2026-05-21 --- # Snolla Recovery VM VirtualBox-VM на [[windows-recovery-host]], в которой работает CMS-стек (IIS + .NET + код CMS). Импортирован из OVA-снапшота 2024-10-27, который лежал в Hyper Backup репо. **Статус (2026-05-21 05:13 MSK):** VM **savestate'нута** после ~36h soak attempt 2 миграции (`VBoxManage controlvm snolla-recovery savestate`, 45.6s, VMState=`saved`). Savestate file: `Snapshots\2026-05-21T05-12-43-636491200Z.sav` = 1.73 GB (compressed RAM). VBoxHeadless процессы исчезли — освобождено ~4 GB private memory. Disk usage +1.7 GB. Resume в любой момент через `VBoxManage startvm snolla-recovery --type headless` (~30 сек). После соак ещё одной недели — `unregistervm --delete` (освободит ~95 GB на C: — `snolla-disk1.vmdk` 95.8 GB + .sav). **Предыстория:** все 11 cms hosts мигрированы на host-IIS:8089 ([[iis-host-migration-2026-05-19]] Phase 10), 36h soak passed без rollbacks (Phase 11), 8/8 наших sites зеленые через full traefik HTTPS chain. VM держалась как parallel fallback (recipe-D из [[iis-migration-2026-05-19-postmortem]]) — fallback не понадобился. История: утром 2026-05-19 attempt 1 миграции сломал prod (Docker NAT loop), был revert на VM. Через тот же вечер — attempt 2 по recipe (backend port `:8089` вместо `:80`, smoke `-MaximumRedirection 0`, phone-test не-LAN) — succeeded. Подробности обеих попыток в `iis-host-migration-2026-05-19` Phases 1-10. ## Параметры - **VBox name:** `snolla-recovery` - **UUID:** `66aac8bb-fe70-4ced-87f6-2291cd0e8b74` - **Расположение:** `C:\Users\vitya\VirtualBox VMs\snolla-recovery\` - **OS внутри:** Windows (вероятно Server 2016/2019, hostname `SNOLLA`) - **RAM:** 4096 MB - **vCPU:** 2 (после оптимизации [[vbox-windows-stability-tuning]] — было 4) - **Disk:** `snolla-disk1.vmdk`, max 120 GB, реально ~92 GB на хосте - **Storage controller:** SATA AHCI (после миграции с SCSI LsiLogic, см. [[vbox-windows-stability-tuning]]) - **Network:** NAT (после миграции с bridged WiFi из-за нестабильности) - **Paravirt:** `kvm` (matching исходному гипервизору Synology VMM) - **OS type:** Windows10_64 (исходно был `Other_64`, поправили для оптимальных дефолтов) - **Guest Additions:** 7.2.8 r173730, RunLevel=3 (полностью активны) ## NAT Port Forwards | Host port | VM port | Назначение | |---|---|---| | 13389 | (console) | **VRDE** (VBox Remote Display) — для отладки, не зависит от Windows RDP | | 23389 | 3389 | RDP внутри VM (Windows Remote Desktop) | | 8022 | 22 | SSH (OpenSSH Server в VM) | | 18080 | 80 | IIS Default — основной HTTP CMS | | 18180 | 8080 | IIS site `stostayer` | | 18181 | 8081 | IIS site `stostayer.old` | | 18189 | 8089 | (запасной) | ## Учётка - **Admin:** vitya (домен SNOLLA) - **Default shell для sshd:** PowerShell (зарегистрирован в `HKLM:\SOFTWARE\OpenSSH` → `DefaultShell`) - **Authorized SSH key для admin-users:** `C:\ProgramData\ssh\administrators_authorized_keys` (особое место для admin Windows OpenSSH; permissions через `icacls`, group `Администраторы:F` + `СИСТЕМА:F`) ## IIS-сайты | Site | Path | Bindings | Прим. | |---|---|---|---| | **MoreThenCms.Web** | `C:\inetpub\wwwroot\MoreThenCms.Web` | `*:80` | **active prod** — catch-all для 11 главных доменов; traefik backend `host.docker.internal:18080` | | **Snolla.IdentityManager** | `C:\inetpub\wwwroot\Snolla.IdentityManager` | `*:8089` | публично не используется | | **stostayer** | `C:\stayer\MoreThenCms.Web` | `*:8080` | **active prod** — traefik backend `host.docker.internal:18180`; conn → внешний `89.253.219.2,1433` (но user в session 2026-05-19 поменял на `www.stostayer.ru,1433` для host-копии; **в VM остался старый**) | | **stostayer.old** | `C:\stayer\stostayer.old` | `*:8081` | **active prod** — traefik backend `host.docker.internal:18181` | | **stostayer.old/calc** | `C:\stayer\Mis.StoStayer.Calculator.Web` | (sub-app под `:8081`) | существует, sub-app pool `calc` | | **stostayer.old/price** | `C:\stayer\Mis.StoStayer.Price.Api` | (sub-app под `:8081`) | существует, sub-app pool `price` | | **stostayer.old/price/tireService** | `C:\stayer\Mis.StoStayer.TireService.Api` | (sub-app под `:8081`) | существует, sub-app pool `tireService` | CMS распознаёт клиента по **Host header** — все 11 клиентских доменов идут на `:80` и роутятся внутри CMS-кода. **Важно для следующей попытки миграции:** stostayer Web.config в VM указывает на старый `89.253.219.2,1433`, а на host-копии (`C:\sites\stostayer\Web.config`) уже patched на `www.stostayer.ru,1433` с XML-escape `&` в password. Если когда-то будем сводить эти конфиги — host-копия правильнее (старый сервер мёртв). ## Web.config — критичные настройки (после recovery patch) - **Connection string:** `Data Source=10.0.2.2;Initial Catalog=MoreThenCms;User Id=snolla;Password=fXkH4@8O%3pc;...` - `10.0.2.2` = NAT gateway в VBox = адрес хоста [[windows-recovery-host]] изнутри VM - До патча было `Data Source=192.168.1.10` (старая мёртвая синка) - Тот же пароль `fXkH4@8O%3pc` совпадает с SA-паролем MSSQL контейнера (production password из старого compose) - **Encoding файла:** UTF-8 with BOM (важно — см. [[cms-config-rewrite-pattern]]) - 4 файла пропатчены аналогично: `MoreThenCms.Web/Web.config`, `Snolla.IdentityManager/Web.config`, `stostayer.old/web.config`, и stayer-проектов (если применимо) ## Связь со внешним миром - VM в NAT-режиме → не имеет LAN-IP - Из traefik (на хосте) достижима по `host.docker.internal:18080` → NAT-форвард в Windows → VM:80 - Раньше (когда было bridged) — VM имела IP `192.168.1.15` с MAC `02:11:32:2A:7C:B9`. snolla.yml в traefik/data/custom/ исходно ссылался на `http://192.168.1.15/` — пропатчен на `host.docker.internal:18080/`. ## Стабильность - Нестабильна на bridged-WiFi → переведена в NAT (стало лучше, но всё равно требует осторожности). - Один случай (после нескольких часов uptime): network adapter в VM "повис" — все TCP-handshake проходили, но через них трафик не шёл. Лечится `ipconfig /release && /renew` внутри VM через VBoxManage guestcontrol. - **Долгосрочно**: пора планировать scheduled task внутри VM, который при детекции downtime автоматически перезагружает network adapter / iisreset. Или вообще переезд на Hyper-V — рекомендация Microsoft для Windows-гостей. ## Известные баги в текущей конфигурации - **X-Forwarded-Proto/Host headers** не передаются с traefik в IIS → CMS делает redirect на `http://www.:4443/` (mixing HTTP scheme with HTTPS port). Не критично, но требует фикса. - **Логи в C:\inetpub\logs\** растут (~6 GB на момент recovery) — нужна ротация.