--- title: Snolla Recovery VM (VirtualBox) — active prod type: entity tags: [vm, virtualbox, windows, iis, cms, recovery, active] 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-19 --- # Snolla Recovery VM VirtualBox-VM на [[windows-recovery-host]], в которой работает CMS-стек (IIS + .NET + код CMS). Импортирован из OVA-снапшота 2024-10-27, который лежал в Hyper Backup репо. **Статус (вечер 2026-05-19 после revert):** VM **снова active prod**. Был attempt мигрировать на host-IIS в течение дня, через ~10 минут после "done"-объявления пользователь увидел `502 Bad Gateway` → `TOO_MANY_REDIRECTS` → revert (см. [[iis-migration-2026-05-19-postmortem]]). VM поднята из savestate командой `VBoxManage startvm "snolla-recovery"`, потребовался `ipconfig /release /renew` через guestcontrol для оживления network adapter (recipe из [[vbox-windows-stability-tuning]]). Traefik backends восстановлены из `*.bak-phase3-2026-05-19` → trafic снова идёт через VM. Всё, что наработано на хосте для миграции, осталось inert на хосте для следующей попытки. ## Параметры - **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) — нужна ротация.