Files
admin/snolla-recovery-vm.md
vitya b3f9526bb2 docs(.wiki): ingest iis-host-migration attempt 2 (success) + docker-host-loopback-detect
Phase 10 успех — recipe из post-mortem применён полностью: backend port :8089, bak-pre-attempt2 серия, IIS binding + Stop+Start, loop-detect через docker exec wget, 2 canary phone-tests от мобильного интернета, batch 9 cms; stayer routes user-ом подтверждены internal → .yml.disabled.

Touched:
- sources/iis-host-migration-2026-05-19.md — append Phase 10
- concepts/iis-migration-2026-05-19-postmortem.md — footer attempt-2-succeeded с маппингом recipe A-G
- concepts/recovery-architecture-snapshot.md — major rewrite, chain через host-IIS:8089, VM = parallel fallback
- entities/snolla-recovery-vm.md — status parallel-fallback, 24-48h soak
- entities/windows-recovery-host.md — IIS sites active prod
- NEW concepts/docker-host-loopback-detect.md — recipe loop-detect + WinHTTP-proxy gotcha
- index.md, log.md
2026-05-19 16:01:12 +03:00

7.9 KiB
Raw Blame History

title, type, tags, sources, updated
title type tags sources updated
Snolla Recovery VM (VirtualBox) — parallel fallback после attempt 2 entity
vm
virtualbox
windows
iis
cms
recovery
parallel-fallback
../sources/nas-recovery-session-2026-05-18.md
../sources/iis-host-migration-2026-05-19.md
../concepts/iis-migration-2026-05-19-postmortem.md
2026-05-19

Snolla Recovery VM

VirtualBox-VM на windows-recovery-host, в которой работает CMS-стек (IIS + .NET + код CMS). Импортирован из OVA-снапшота 2024-10-27, который лежал в Hyper Backup репо.

Статус (после attempt 2 на host-IIS, 2026-05-19 вечер): VM running, но больше не на prod-пути — все 11 cms hosts мигрированы на host-IIS:8089 (iis-host-migration-2026-05-19 Phase 10). VM держится как parallel fallback в течение 24-48h soak (recipe-D из iis-migration-2026-05-19-postmortem). VM NAT port forwards :18080/:18180/:18181/:18189 холостые — traefik больше не ходит. После confirmed stability — savestate (освободит ~3 GB RAM), потом unregistervm --delete (освободит ~92 GB на C:).

История: утром 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\OpenSSHDefaultShell)
  • 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.<domain>:4443/ (mixing HTTP scheme with HTTPS port). Не критично, но требует фикса.
  • *Логи в C:\inetpub\logs* растут (~6 GB на момент recovery) — нужна ротация.