VBoxManage controlvm snolla-recovery savestate — 45.6s, VMState=saved. Savestate file 1.73 GB (compressed 4096 MB RAM). VBoxHeadless процессы освободили ~4 GB private memory. Resume в 30 сек через startvm --type headless. unregistervm --delete (~95 GB disk reclaim) запланирован на +неделю uptime. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
8.4 KiB
title, type, tags, sources, updated
| title | type | tags | sources | updated | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Snolla Recovery VM (VirtualBox) — savestate'нута 2026-05-21 после 36h успешного soak | entity |
|
|
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с MAC02: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) — нужна ротация.