Проект на выходные: Запускаем Windows VM... внутри Kubernetes. Знакомство с KubeVirt

Проблема: Ваша компания перешла на Kubernetes. 90% сервисов — контейнеры. Но у вас остался "старый, добрый" монолит на Windows Server (например, 1С или старый IIS-апп), который нельзя контейнеризировать.

Решение: Не держать "зоопарк" (Kubernetes + Proxmox/VMware). А запустить эту VM внутри Kubernetes.

KubeVirt — это проект CNCF, который позволяет управлять Виртуальными Машинами (VM) так же, как и контейнерами.

Как это работает: Вы пишете YAML-манифест так же, как для Deployment, но с типом VirtualMachineInstance.
YAML

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: my-windows-vm
spec:
  template:
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
        # ...и т.д.

Взгляд архитектора: Это "Единый Оркестратор". У вас ОДИН инструмент (kubectl) и ОДНА "панель управления" (Kubernetes) для всех ваших нагрузок — и современных (контейнеры), и "легаси" (VM). Это упрощает сеть, хранилище и мониторинг.

#linux #kubernetes #kubevirt #devops #virtualization #architect #гайд

🐧 Proxmox: Спасаем виртуалку из состояния «Locked» 🔒

Пятничный кошмар: завис бэкап или отвалилось сетевое хранилище в момент создания снапшота.
Виртуалка переходит в статус locked, её невозможно ни перезагрузить, ни выключить, ни мигрировать.
GUI просто выдает ошибку, и машина превращается в "зомби".

Не нужно перезагружать всю ноду Proxmox! Статус блокировки — это просто текстовый флаг в конфигурационном файле.

Как снять блокировку через консоль:
Сначала проверяем, почему она заблокирована (возможно, бэкап всё еще идет):

cat /etc/pve/qemu-server/100.conf | grep lock

(Где 100 — это ID твоей виртуалки).

Если процесс бэкапа/снапшота точно завис и убит, снимаем лок одной командой:

qm unlock 100

Результат: Машина снова слушается команд. Выдыхаем. 😮‍💨

#proxmox #linux #virtualization #troubleshooting #sysadmin #friday13 #kvm

🐧 Proxmox: Спасаем зависшую виртуалку, когда Web-интерфейс «умер» 🚑

Знакомая ситуация: виртуалка намертво повисла в статусе `Locked` (например, во время бэкапа), кнопка "Stop" в веб-морде Proxmox (PVE) крутится бесконечно, а нагрузка на ноду растет.

Вместо того чтобы судорожно ребутать весь гипервизор и ронять соседние машины, спускаемся в консоль.

Алгоритм реанимации (SSH на ноду PVE):

1. Снимаем лок с ВМ:

# Разблокируем виртуалку с ID 100
qm unlock 100

2. Пытаемся остановить штатно:

qm stop 100

3. Если не помогло — убиваем процесс KVM:

# Ищем PID процесса виртуалки
ps aux | grep "/usr/bin/kvm -id 100"

# Жестко убиваем найденный PID (например, 12345)
kill -9 12345

После этого виртуалка гарантированно потухнет, и её можно будет запустить заново с чистой совестью.

Консоль — наше всё!

#proxmox #linux #virtualization #troubleshooting #cli #sysadmin #admin_future

🎓 Собеседование сисадмина. Выпуск №4: Виртуализация и Хранение данных

Привет, коллеги! Сегодня разберем три вопроса, на которых часто «плывут» даже опытные админы, привыкшие работать по инструкции, а не по логике.

❓ Вопрос 1: «Почему опасно держать снапшот (Snapshot) виртуальной машины дольше пары дней?»
❌ Ответ новичка: «Снапшот занимает много места на диске, и можно просто забыть, что он есть».
✅ Ответ инженера:

1. Производительность: Снапшот — это не копия ВМ, а дельта-файл. При наличии снапшота все новые записи идут в этот файл, а при чтении системе приходится проверять и основной диск, и все файлы цепочки снапшотов. Это создает огромную нагрузку на I/O.
2. Риск повреждения: Чем длиннее «цепочка» снапшотов, тем выше шанс, что при консолидации (удалении снапшота) произойдет ошибка, которая «убьет» файловую систему виртуалки.
3. Место: Снапшот растет непредсказуемо. Если внутри ВМ идет активная запись (например, обновление базы), снапшот может мгновенно забить всё свободное место на хранилище (LUN/Datastore), что приведет к остановке всех машин на этой полке.

❓ Вопрос 2: «В чем разница между Thin (Тонкими) и Thick (Толстыми) дисками? Что вы выберете для высоконагруженной БД?»
❌ Ответ новичка: «Тонкие диски экономят место, а толстые — нет. Для базы выберу толстые, потому что они надежнее».
✅ Ответ инженера:

Thin Provisioning: Место на физическом носителе выделяется только по мере записи данных. Плюс: экономия пространства. Минус: риск «Overprovisioning» (когда суммарный объем тонких дисков больше физического хранилища) и небольшая потеря производительности на операциях записи.
Thick Provisioning (Eager Zeroed): Весь объем резервируется и зануляется сразу. Плюс: максимальная производительность и отсутствие фрагментации на уровне гипервизора.
Выбор: Для высоконагруженной БД (SQL/Oracle/1С) — только Thick Provisioning Eager Zeroed. Это гарантирует отсутствие задержек при расширении файлов базы и исключает ситуацию, когда база падает из-за того, что на физической полке внезапно кончилось место.

❓ Вопрос 3: «Что такое Split-brain в кластере высокой доступности (HA) и как его предотвратить?»
❌ Ответ новичка: «Это когда два сервера работают одновременно. Предотвратить можно, настроив хороший мониторинг».
✅ Ответ инженера:

Split-brain — это состояние, когда узлы кластера теряют связь друг с другом (по сети Heartbeat), но при этом оба остаются живы. Каждый решает, что напарник «умер», и пытается одновременно захватить общие ресурсы (IP, диски). Это гарантированно ведет к повреждению данных.
Защита:
1. Quorum (Кворум): Использование нечетного количества узлов или «свидетеля» (Witness/Quorum Device). Ресурсы получает тот, кто видит большинство голосов.
2. STONITH / Fencing: Принцип «Пристрели другого в голову» (Shoot The Other Node In The Head). Если узел теряет связь, он через управляемую розетку (PDU) или IPMI физически выключает питание напарника, прежде чем забрать ресурсы.

💡 Золотое правило собеса: Помни, что Снапшот — это не бэкап. Это временная точка отката перед рискованной операцией. Если на вопрос «как вы делаете бэкапы» ты ответишь «делаю снапшоты раз в неделю» — собеседование для тебя закончится мгновенно.

Сохраняйте, коллеги! Это те знания, которые превращают «админа-кнопкотыка» в системного архитектора.

#собеседование_AF #virtualization #storage #snapshot #highavailability #proxmox #vmware #admin_future

Переход на KubeVirt и ARM — это не мода, а экономика. Ты либо управляешь тысячей серверов как одной сущностью, либо тонешь в тикетах на «создание одной маленькой виртуалки». В 2026 году админ — это не «хранитель ключей от серверной», а архитектор автоматизированных фабрик по переработке трафика.

Золотое правило: Если систему нельзя описать одним YAML-файлом — эта система не должна существовать в твоем продакшене.

#собеседование_AF #kubevirt #arm #baremetal #virtualization #kubernetes #admin_future

🧠 Skills: Aurora шифрует ESXi. AI на разведке, но цель сдаёт обычный LDAP-запрос

Коллеги, разбор свежей тактики вымогателей, который напрямую касается каждого, кто держит виртуализацию — будь то VMware ESXi, vCenter или Proxmox.

📌 ФАКТЫ (по свежему отчёту Gambit Security)
Кампания Aurora Ransomware: две волны атак в 2026 году на бизнес в Европе, США и Израиле.

AI в роли Co-pilot злоумышленника: оператор использовал Cursor Agent (на базе Claude Sonnet) для автоматизации рутины — генерации конфигов proxychains/VPN, парсинга выдачи Nmap и NetExec, разведки Active Directory, NTLM relay и атак на AD CS.

Операционная дисциплина: атакующий осознанно выставил агенту жесткие рамки — никаких DCSync, без локаута аккаунтов, без регистрации новых машин в домене. Задача — нулевой шум в SIEM.

Как находили виртуализацию: самописный модуль NetExec (esxi_finder.py) вытягивал список хостов через стандартные LDAP-запросы, опрашивал порты 443 и 902, а затем по TLS-сертификату однозначно детектировал гипервизоры и vCenter.

Удар: Linux-бинарник шифровальщика с флагом -esxi тушит виртуальные машины через штатный esxcli и зашифровывает диски (ChaCha20 + RSA-4096).

💡 В ЧЁМ СУТЬ

ИИ здесь не взламывает квантовым алгоритмом — он просто снимает рутину и ускоряет рекогносцировку. Архитектурная дыра ровно та же, что и 5 лет назад: гипервизоры видны из пользовательского сегмента или привязаны к общему AD. Если порт виден наружу, его найдут и без нейросетей.

🛠 АУДИТ БЕЗОПАСНОСТИ
1. Проверяем хост ESXi (по SSH):

Bash

# Проверить, активен ли Lockdown Mode
vim-cmd -U dcui vimsvc/auth/lockdown_is_enabled

# Ограничение белых списков IP для SSH и веб-морды
esxcli network firewall ruleset allowedip list --ruleset-id sshServer
esxcli network firewall ruleset allowedip list --ruleset-id webAccess

# Блокировка запуска неподписанных бинарников (дропает чужой шифровальщик)
esxcli system settings encryption get

# Ревизия локальных учетных записей
esxcli system account list

2. Сканируем из пользовательского сегмента (быстрый smoke-тест):

Bash

nmap -Pn -p 443,902,8006 <подсеть_гипервизоров>
# Порты должны быть отфильтрованы в глухую! (8006 — для Proxmox VE)

🛡 БАЗОВЫЙ ЧЕКЛИСТ ЗАЩИТЫ ГИПЕРВИЗОРОВ
Изолированный Out-of-Band / Management VLAN: интерфейсы управления ESXi, vCenter и Proxmox VE не должны маршрутизироваться в клиентские подсети. Доступ — строго через выделенный Jump-хост с MFA.

Никакого прямого членства в Active Directory: гипервизорам не место в корпоративном домене. Если ESXi все еще там — срочно проверяйте группу ESX Admins и закрывайте дыру CVE-2024-37085.

Харденинг хостов: флаг execInstalledOnly включен, SSH заглушен на уровне службы и поднимается только под регламентные работы.

Неизменяемые (Immutable) бэкапы: резервные копии должны лежать в изолированном пуле (WORM/S3 Object Lock/air-gapped), к которому нет и не может быть доступа с доменными учетками.

Гипервизор — самая дорогая и желанная точка отказа в инфраструктуре. Одна команда — и ложится всё предприятие разом. Проектируйте доступ к нему так, словно злоумышленник уже захватил доменную рабочую станцию.

#skills #esxi #vmware #proxmox #ransomware #virtualization #sysadmin #admin_future

🖥 Proxmox запускает поддержку 24/7 с 19 октября. Закрыт главный аргумент «против» в корпоративе

Коллеги, четверг. Новость для всех, кто ведёт проекты миграции с VMware vSphere и регулярно слышит от CTO или службы безопасности вопрос: «А кому мы будем звонить в 3 часа ночи, когда упадёт прод?».

📌 ФАКТЫ
Старт круглосуточного SLA: с 19 октября Proxmox Server Solutions официально запускает сервис поддержки 24/7 для всей линейки корпоративных продуктов: Proxmox Virtual Environment (PVE), Proxmox Backup Server (PBS) и Proxmox Datacenter Manager.

Конец австрийскому таймзону: ранее официальный вендорский саппорт работал строго в бизнес-часы по Вене (CET), а для ночных дежурств приходилось искать сторонних локальных интеграторов.

Тарифные уровни:

Premium Subscription: режим 24/7 доступен сразу с 19 октября. Безлимитное число тикетов, первичное время реакции — до 2 часов, прямая эскалация инженерам разработки ядра.

Standard Subscription: поддержка 24/7 появится чуть позже, в Q4 2026.

Basic Subscription: SLA остаётся в прежних рамках (рабочие часы).

Глобальная экспансия: учреждено американское подразделение Proxmox North America Inc., обеспечивающее перекрытие смен по модели follow-the-sun.

🛠 ПРОВЕРКА ГОТОВНОСТИ НОД К ОБРАЩЕНИЮ В TAC
При ночной аварии время идёт на минуты — данные для сервисной заявки должны собираться мгновенно:

Bash

# 1. Проверяем валидность лицензионного ключа и активный уровень подписки
pvesubscription get

# 2. Выгружаем точные версии установленных пакетов ядра и гипервизора
pveversion -v | head -5

# 3. Контролируем репозитории: enterprise-репозиторий должен быть активен без ошибок
ls -la /etc/apt/sources.list.d/

# 4. Снятие полного диагностического слепка ноды (базовый артефакт для любого тикета)
pvereport > /root/pvereport-$(hostname).txt

💡 В ЧЁМ СУТЬ

Наличие контракта 24/7 снимает формальный барьер у топ-менеджмента, но не отменяет законов физики: оно не заменяет локальный кворум Corosync, кластерный High Availability и отработанный план Disaster Recovery.

Дежурный инженер вендора в Вене или США в первую очередь запросит вывод

pvereport

и системные журналы. Снимите и сохраните эталонный отчет

pvereport

прямо сейчас на здоровом кластере — в момент боевого падения вам будет с чем сравнить конфигурацию и дисковые подсистемы.

#proxmox #virtualization #support #vmware #enterprise #ha #sysadmin #admin_future

🔬 Google Kage: песочница для драйверов прямо внутри ядра Linux

Коллеги, интереснейший доклад с конференции Linux Plumbers 2026 — архитектурная инициатива, способная в будущем кардинально повысить стабильность и отказоустойчивость серверов.

📌 ФАКТЫ
Архитектура Kage: экспериментальная подсистема ядра Linux от инженеров Google, задача которой — изолировать драйверы аппаратных устройств.

Технологический фундамент: компиляторная изоляция LFI (Lightweight Fault Isolation) на базе LLVM (совместный проект Стэнфорда и Google). Драйвер продолжает исполняться в адресном пространстве ядра, но компилятор жестко ограничивает его доступ только выделенным пулом памяти, предотвращая порчу чужих структур ядра.

Рабочие прототипы: уже реализована изоляция драйверов NVMe, сетевых адаптеров и Wi-Fi стеков в рамках архитектуры VKage (интеграция с подсистемой VirtIO).

Производительность: накладные расходы заявляются значительно более низкими, чем у традиционных виртуальных песочниц и микроядерных выносов в userspace (точные бенчмарки пока не финализированы).

Готовность экосистемы: поддержка LFI для архитектуры AArch64 уже принята в апстрим LLVM, реализация под x86_64 ожидается в релизе LLVM 24. Одним из ключевых полигонов внедрения станет экосистема Android.

💡 ПОЧЕМУ ЭТО ВАЖНО СИСАДМИНУ

Драйверы стороннего оборудования — самый объемный, гетерогенный и наименее надежный пласт кодовой базы ядра.

Сегодня любая ошибка адресации или use-after-free в драйвере сетевой карты либо HBA-адаптера мгновенно приводит к Kernel Panic и падению всей ноды (либо к локальному повышению привилегий). Технология Kage локализует сбой до уровня программного отказа отдельного устройства, сохраняя работу ОС и соседних сервисов.

🛠 ДИАГНОСТИКА: СТОРОННИЙ КОД В ВАШЕМ ЯДРЕ ПРЯМО СЕЙЧАС
Bash

# 1. Считаем общее число загруженных модулей ядра
lsmod | wc -l

# 2. Проверяем статус Tainted (0 = ядро чистое и стабильное, >0 = загружены проприетарные модули/были сбои)
cat /proc/sys/kernel/tainted

# 3. Выявляем модули, собранные вне основного дерева исходников ядра (out-of-tree)
for m in $(lsmod | awk 'NR>1{print $1}'); do
  modinfo -F intree "$m" 2>/dev/null | grep -q Y || echo "Вне дерева ядра: $m"
done

#linux #kernel #drivers #google #security #virtualization #sysadmin #admin_future

🚨 PwnEscape (CVE-2026-99999): побег из ВМ на хост KVM через virtio-net. Proxmox уже выпустил исправленное ядро

Коллеги, понедельник. Если у вас Proxmox или любой KVM — это пост номер один на неделю.

📌 ФАКТЫ
Уязвимость ядра Linux в обработке virtio-net и TAP в KVM

Последствия: утечка памяти хоста, его падение или выполнение кода на хосте из гостевой ВМ

CVSS: Linux CNA/NVD — 9.3, Red Hat — 8.8. Оценки привилегий в госте расходятся: от «любая нагрузка, отправляющая трафик» до «нужен root в госте»

В KEV пока нет, эксплуатация в дикой природе не подтверждена. Утечку памяти показали в продакшене Vercel

Обходного решения нет, только обновление ядра и перезагрузка

Исправлено:

Plaintext

Proxmox VE : proxmox-kernel-7.0.14-24-pve (PSA-2026-00068-1)
Debian 13  : 6.12.113-1 (DSA-6568-1)
Debian 12  : 6.1.190-1  (DLA-4841-1)
Upstream   : 6.1.190 · 6.6.159 · 6.12.113 · 6.18.57 · 7.2.11

🛠 PROXMOX: ОБНОВЛЕНИЕ БЕЗ ПРОСТОЯ
Bash

# 1. Проверяем текущее ядро и версию PVE
uname -r && pveversion -v | grep -E 'kernel|manager'

# 2. Выкачиваем патчи
apt update && apt full-upgrade

# 3. Уводим ВМ с узла, ребутаем хост, возвращаем — узел за узлом
qm migrate <VMID> <NODE> --online

💡 В ЧЁМ СУТЬ

Граница между ВМ и хостом — главное обещание виртуализации. Если на одном хосте живут ВМ разной степени доверия (клиентские, тестовые, DMZ), обновляйтесь в первую очередь. Live migration делает это без простоя — ради таких дней её и настраивают.

#security #proxmox #kvm #virtualization #linux #cve #sysadmin #admin_future

🖥 Proxmox: с сегодняшнего дня поддержка 24/7, а ветка 8.x уже без обновлений. Чек-лист перехода на 9

Коллеги, два события по Proxmox, которые стоит связать между собой.

📌 ФАКТЫ
С 19 октября Proxmox запускает круглосуточную enterprise-поддержку (Premium — сразу, Standard — в Q4 2026)

Proxmox VE 8 — конец поддержки в августе 2026. Debian 12 продолжает получать патчи через LTS до июня 2028, но pve-manager, qemu-server, pve-qemu-kvm, ядро Proxmox и Ceph обновляться перестали

Значит, свежие исправления вроде PwnEscape приходят в ядро PVE 9. Узлы на 8.x их не получат

🛠 ЧЕК-ЛИСТ 8 → 9
Bash

pveversion                     # сначала до последней 8.4 (pve-manager ≥ 8.4.1)
ceph --version                 # гиперконвергентный Ceph — сначала до Squid 19.2
df -h /                        # минимум 5 ГБ свободно, лучше 10+
pve8to9 --full                 # только проверяет и сообщает, ничего не меняет

Дальше узел за узлом: унести ВМ → репозитории на Trixie → apt dist-upgrade → перезагрузка → проверка → следующий узел. Репозитории переходят на формат deb822, помогает apt modernize-sources.

💡 В ЧЁМ СУТЬ

Поддержка 24/7 появилась, но платить за неё и сидеть на неподдерживаемой 8.x — плохая комбинация. Сначала обновление до 9 и бэкап в PBS, потом подписка.

#proxmox #virtualization #upgrade #debian #sysadmin #admin_future

🛠 Multipass 1.17: Debian и Fedora в одну команду, симуляция «падения зоны» и работа даже на Windows Home

Коллеги, инструмент для быстрых тестовых ВМ — когда нужно проверить скрипт или обновление, не трогая прод.

📌 ФАКТЫ (релиз 19 октября)
Multipass от Canonical — лёгкие ВМ из облачных образов одной командой

В 1.17 добавлены официальные образы Debian и Fedora — раньше была только Ubuntu

Зоны доступности: ВМ раскладываются по трём зонам с отдельными подсетями. Зону можно «выключить» и посмотреть, как сервис переживёт её отказ

Windows: новый драйвер на API HCS — работает на всех редакциях, включая Home. Драйверы Hyper-V и VirtualBox объявлены устаревшими

macOS: превью драйвера на Apple Virtualization framework

🛠 БЫСТРЫЙ СТАРТ
Bash

multipass find                         # доступные образы
multipass launch <образ> --name test1 --cpus 2 --memory 2G --disk 20G
multipass shell test1
multipass transfer ./script.sh test1:/tmp/
multipass delete test1 && multipass purge

Bash

# Симуляция отказа зоны
multipass zones
multipass launch <образ> --name app1 --zone <имя-зоны>
multipass disable-zones <имя-зоны>     # ВМ зоны становятся недоступны
multipass enable-zones <имя-зоны>

💡 В ЧЁМ СУТЬ

Тестовая ВМ за 30 секунд убирает соблазн «проверить прямо на сервере». А зоны позволяют на ноутбуке отрепетировать то, что обычно проверяют только во время настоящей аварии.

#tools #multipass #virtualization #testing #linux #sysadmin #admin_future