Windows Server 2012 в KVM: хороша ли идея?

Привет.
Я — админ-самоучка с вытекающими.
Для того, чтобы не восстанавливать контроллер домена (из резервного к.д.) придумал такую схему: кручу КД в kvm-виртуалке, регулярно делаю снапшоты (на отдельный диск). В случае, если серверное железо полетит, достаточно просто поднимаю КД на другом железе.

Сомневаюсь, потому что это усложнение системы и как бы снижение надёжности.

Сервер: IBM, Xeon, 4 ядра, 4 гига.
Задачи КД: файловый сервер, служба каталогов, dhcp.

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

Виртуалки это хорошо и удобно, только ЕМНИП откат из снапшота не поможет, в данном случае. Погугли про починку КД.

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

Почему? Переносил старый 2003 простым dd с железа в виртуалку, брат жив. Ну скорее жив, ЕВПОЧЯ.

Плохая идея, на таких мощностях сам 2012 то стартует?

Не помню с какого винда стала заморачиваться на фикс драйвера диска. Я 2008 с бубном переносил из квм прокмокса в квм овирта. Просто так не взлетает и падает в синеву.

Так ты поди нормально погасил и перенес. А вот если в процессе работы были какие-то изменения, а потом оно упало, то восстановление из бекапа/снапшота все ломает.

DC в виртуалке — плохая идея, насколько я помню.

Не помню с какого винда стала заморачиваться на фикс драйвера диска.

А, было что-то такое, не грузилось. Починил за пять минут по какому-то руководству. Вроде с реестром надо было что-то делать. Это в любом случае бесконечно проще, чем заново ставить и настраивать.

Главное синхронизацию времени с хостом отключить, в остальном никаких проблем.

Компы виндового домена периодически обновляют свой GID в АД, если это произойдет между снэпшотом и восстановлением, то данные компы будут исключены из домена. Т.е. снэпшоты КД не являются бэкапом. Если надо точнее, то лучше на винфак или где там виндоадмины кучкуются.

А почему KVM а не Hyper-V?

В случае, если серверное железо полетит, достаточно просто поднимаю КД на другом железе.

На самом деле исходя из таких вводы — тебе нужен veeam backup, можно бесплатный. С ним КД безопаснее ресторить. А он хорошо работает с хип-в.

у меня основной КД чистый на отдельном серваке а резервные в квм .. но я каждую ноч делаю клон на бекап сервер. а не снапшот.. также и почтовик на дебиане . каждую ночь клон .. хранится 3 дня .. не подводило никогда

На хосте? Или гостю? Если даже гостю, имхо 4гб для офтопик 2012 маловато будет. Таже спермерка x64 в kvm норм работать начинает только с 4гб озу, да — это «особенность» kvm, но что делать.

регулярно делаю снапшоты (на отдельный диск)

Вопрос: как и чем?

Да вы очень рисковый товарищ

А восстанавливали хоть раз?

На хосте. Гостю дал 2Гб оперативки, немного тормозит, но работает.

Через virsh хотел.
Но исходя из того, что здесь говорят, лучше каждую ночь полный бэкап диска делать.

На хосте. Гостю дал 2Гб оперативки, немного тормозит, но работает.

Забейте на идею. Серьезно. 2gb для офтопика 2012 это не о чем.

Агент в гостевом офтопике установлен? Если да, то «говорят» фриз гостевой фс должен робить. Но сам не пробовал на 2012. Без тестирования на «кошках» не рекомендую внедрять.

Но исходя из того, что здесь говорят, лучше каждую ночь полный бэкап диска делать.

Если такая возможность есть (останавливать vm), то я бы тоже по такому пути пошел. Меньше промежуточных вариантов факапа.

Думаю норм будет, если накрутить политику перегенарции GID компов в домене, по дефолту это 90суток. Я нафиг выключил эту полиси и моя samba AD, с бекапа норм поднималась.

Установка Windows на KVM

Установка Windows на KVM для опытных системных администраторов не составит труда. Тем не менее, в процессе развертывания ОС и создания под неё виртуальной машины могут встретиться ряд нетривиальных проблем , связанных с особенностями KVM. О них я и расскажу.

Если вам интересна тематика Debian и связанных с ним приложений, рекомендую обратиться к тегу Debian на моем блоге

Установка Windows на KVM

К настоящему моменту у меня уже есть сервер с KVM. На нем также сконфигурирована сеть и хранилище гостевых дисков. Все это я подробно расписал в своей предыдущей статье Установка гипервизора KVM.

Для создания виртуальной машины я буду использовать утилиту virt-install.

Конфигурация виртуальной машины

Есть ряд базовых параметров, без указания которых создание виртуальной машины с помощью virt-install невозможно — это имя ВМ, объем оперативной памяти, настройки диска и параметры установки. Тем не менее, для наглядности я укажу и другие опции, которые так или иначе используются не реже обязательных.

Команда для создания виртуальной машины:

• —-os-type windows — Устанавливает более подходящие аппаратные настройки для конкретной ветки ОС;
• —disk pool=guest_images — Создает виртуальные диски в данном хранилище;
• —graphics vnc,listen=0.0.0.0 — Устанавливаем тип графики. Адрес прослушки необходим, чтобы к vnc могли подключаться удаленные админы. По дефолту разрешены только локальные подключения.

Назначение остальных параметров очевидно.

Если в процессе создания виртуальной машины вы получили ошибку:

Windows 2012 guest best practices

Contents

Introduction

This is a set of best practices to follow when installing a Windows Server 2012(R2) guest on a Proxmox VE server 6.x.

Install

Prepare

To obtain a good level of performance, we will install the Windows VirtIO Drivers during the Windows installation.

• Create a new VM, select «Microsoft Windows 8.x/2012/2012r2» as Guest OS and enable the «Qemu Agent» in the System tab. Continue and mount your Windows Server 2012 ISO in the CDROM drive
• For your virtual hard disk select «SCSI» as bus with «VirtIO SCSI» as controller. Set «Write back» as cache option for best performance (the «No cache» default is safer, but slower) and tick «Discard» to optimally use disk space (TRIM).
• Configure your memory settings as needed, continue and set «VirtIO (paravirtualized)» as network device, finish your VM creation.
• For the VirtIO drivers, upload the driver ISO (use the stable VirtIO ISO, download it from here) to your storage, create a new CDROM drive (use «Add -> CD/DVD drive» in the hardware tab) with Bus «IDE» and number 3. Load the Virtio Drivers ISO in the new virtual CDROM drive.
• Now your ready to start the VM, just follow the Windows installer.

Launch Windows install

• After starting your VM launch the noVNC console
• Follow the installer steps until you reach the installation type selection where you need to select «Custom (advanced)»
• Now click «Load driver» to install the VirtIO drivers for hard disk and the network.
  • Hard disk: Browse to the CD drive where you mounted the VirtIO driver and select folder «vioscsi\2k12\amd64» and confirm. Select the «Red Hat VirtIO SCSI pass-through controller» and click next to install it. Now you should see your drive.
  • Network: Repeat the steps from above (click again «Load driver», etc.) and select the folder «NetKVM\2k12\amd64», confirm it and select «Redhat VirtIO Ethernet Adapter» and click next.
  • Memory Ballooning: Again, repeat the steps but this time select the «Balloon\2k12\amd64» folder, then the «VirtIO Balloon Driver» and install it by clicking next. With these three drivers you should be good covered to run a fast virtualized Windows 10 system.
• Choose the drive and continue the Windows installer steps.

HINT: There is a video showing the process for a Windows Server 2016 installation which is the same as for Windows Server 2012.

Install Guest Agent and Services

Guest Agent

If you enabled the Qemu Agent option for the VM the mouse pointer will probably be off after the first boot.

To remedy this install the «Qemu Guest Agent». The installer is located on the driver CD under guest-agent\qemu-ga-x86_64.msi.

Drivers and Services

The easiest way to install missing drivers and services is to use the provided MSI installer. It is available on the driver CD since version «virtio-win-0.1.173-2».

Run the «virtio-win-gt-x64.msi» file located directly on the CD. If you do not plan to use SPICE you can deselect the «Qxl» and «Spice» features. Restart the VM after the installer is done.

After all this the RAM usage and IP configuration should be shown correctly in the summary page of the VM.

For more information and configuration about ballooning, see Dynamic Memory Management

Check for missing drivers

Go to the Device Manager to see if there are any drivers missing. For any unknown device:

• Right click an select «Update driver».
• Select «Browse my computer for driver software».
• Select the Driver CD. Make sure that «Include subfolders» is checked.
• Once a driver has been found you might be prompted with a security warning asking if you «Would like to install this device software». Click «Install».

Further Information

RAW vs QCOW2

The RAW file format provides slightly better performance WHILE qcow2 offers advanced features such as copy on write and Live_Snapshots independent of the backing storage. Since Proxmox VE version 2.3, qcow2 is the default format.

VirtIO Drivers

Make it really easy:Build your ISO with drivers already included: Windows guests — build ISOs including VirtIO drivers

Виртуализацией по тарифам. Настраиваем Windows в KVM

Содержание статьи

Плюсы и минусы KVM

Проект KVM (Kernel-based Virtual Machine) в этом году празднует десятилетие. Официально он включен в ядро с версии 2.6.20, выложенное на kernel.org 4 февраля 2007 года. Изначально разрабатывался компанией Qumranet, выкупленной Red Hat в 2008 году. После сделки KVM и библиотека управления виртуализацией oVirt стала основой платформы виртуализации RHEV, поэтому Red Hat на сегодня ключевой разработчик KVM.

Технология предоставляет полную виртуализацию на аппаратном уровне. Поэтому, в отличие от популярных LXC и OpenVZ, KVM может запускать в принципе любую ОС, не только Linux (Windows, FreeBSD. ), и Linux, отличающийся от конфигурации основной системы. Если нужна виртуальная машина, не совпадающая параметрами с основным хостом, то выбора особо нет. Включение в ядро было большим прорывом. Теперь поддержка виртуализации в ОС не требовала установки гипервизора (как Xen) и могла быть реализована в любом дистрибутиве, включая настольный. Из коробки доступен VNC, дающий возможность управлять виртуальным сервером с момента загрузки (то есть когда еще не работает SSH), как будто из локальной консоли. Проект активно сотрудничает с другим подобным решением QEMU, задействованы некоторые утилиты и общий формат файла образа Qcow2.

Минусы, конечно, тоже есть. Куда же без них. Главный — процессор должен иметь аппаратную поддержку виртуализации Intel VT-x или AMD-V. Проверить их наличие можно вручную или при помощи утилит:

Также о поддержке технологий говорят флаги в CPU:

В зависимости от производителя процессора будет загружен свой модуль ядра (kvm-amd.ko либо kvm-intel.ko).

Проверяем поддержку KVM

Xakep #216. Копаем BitLocker

Накладные расходы чуть выше, чем при использовании LXC и OpenVZ. Причин тому две.

KVM-контейнер запускает свою копию ядра и окружения, и под них требуется память. LXC и OpenVZ же используют ядро и системные вызовы сервера. Поэтому при одинаковых характеристиках на хостинге у них совершенно разные возможности. При создании KVM-контейнера под него сразу резервируются все ресурсы согласно установкам. Это хорошо видно в htop. Стоит добавить ОЗУ в KVM, как сразу на это значение увеличивается объем занятой памяти. Выйти за лимиты VM не может, они устанавливаются жестко. В этом даже и плюс, можно сразу рассчитать будущую нагрузку на своем сервере, а ресурсы никто не позаимствует.

И VM работают относительно стабильно в плане производительности. В то время как при OpenVZ-виртуализации ресурсы выделяются динамически по мере надобности и каждый виртуальный сервер использует ровно столько ресурсов, сколько ему сейчас нужно. Незанятые ресурсы остаются свободными. Поэтому он и популярен у хостеров, ведь можно всегда напихать чуть больше VM, и именно поэтому виртуальные машины, созданные с запасом, могут работать то быстрее, то медленнее. Иногда оптимизация VM под OpenVZ — настоящая мука: непонятно, почему сервер стал работать по-другому — из-за новых настроек или внешних факторов.

Администрировать KVM сложнее, так как прозрачный доступ к файлам, процессам, консолям и сети контейнеров отсутствует, это приходится настраивать самостоятельно. Перестройка параметров VM в KVM (CPU, RAM, HDD) не очень удобна и требует дополнительных действий, включающих перезагрузку ОС. В том же OpenVZ это можно сделать на лету. Сам проект не предлагает удобных графических инструментов для управления виртуальными машинами, только утилиту virsh, реализующую все необходимые функции. Но, поискав в Сети, можно найти несколько интерфейсов, хотя для индивидуального использования одной или нескольких VM их обычно ставить нет смысла. К тому же много open source проектов, активно развивавшихся во время большого интереса к виртуальным машинам, сегодня стали коммерческими, хотя некоторые по-прежнему предлагают обрезанную free-версию. В репозитории пакетов есть virt-manager, предлагающий графический интерфейс для управления KVM и другими типами VM, поддерживающими virtlib, как установленных локально, так и удаленно через SSH.

В качестве веб-интерфейсов можно порекомендовать старенький, но еще рабочий WebVirtMgr, бесплатный UVMM UCS Core Edition, openQRM Free Community Edition и другие. Кроме того, существуют специальные дистрибутивы вроде Proxmox VE, в котором все необходимые инструменты для создания и управления VM на базе KVM и LXC уже есть (правда, он подходит для bare metal установки, а не на удаленный VDS).

Установка KVM

Плюсы KVM в том, что она работает из коробки и что процессоры серверов хостеров однозначно поддерживают эту технологию. Поэтому вполне реально при наличии свободных ресурсов подгрузить в VDS еще одну виртуальную машину (или несколько). Конечно, под фактически двойной виртуализацией они будут работать не так быстро, как на железе, но если большая нагрузка не планируется, то этого вполне должно хватить. Более того, у некоторых хостингов есть rescue-инструменты, дающие возможность подмонтировать другую файловую систему (в hetzner это rescue/LARA ), подменить имеющуюся и даже установить свою ОС. При некотором умении можно по тарифам Linux абсолютно легально использовать Windows.

Наша задача — установить под KVM Win и настроить доступ. KVM работает со всеми версиями Win, включая и последние. Но Win капризней к ресурсам, поэтому тариф следует подбирать с учетом минимальных системных требований и накладных расходов на ОС и виртуализацию. На Digital Ocean, например, Win2012R2 при 4 Гбайт ОЗУ сильно тормозит, а если выделить 6+ Гбайт, то уже вполне нормальный отклик. В различных дистрибутивах и даже версиях процесс немного отличается, но в основном это касается названий пакетов. Мы будем использовать Ubuntu 16.06. Ставим пакеты.

Проверяем поддержку KVM.

Если такой ответ получен, значит, все нормально. Список поддерживаемых ОС и их правильное название можно получить при помощи osinfo-query .

Список поддерживаемых ОС и их названия

Конфигурационные файлы libvirt находятся в каталоге /etc/libvirt , журналы, в которых нужно искать ответы на проблемы, размещаются в /var/log/libvirt . В /var/lib/libvirt несколько каталогов: в boot система, если не указан путь, будет искать образ для установки гостевой системы, а в images размещать жесткие диски.

Управление виртуальными машинами из консоли производится при помощи утилиты virsh . Параметров много, их все можно узнать, введя:

Вначале просто стоит пройтись и познакомиться, чтобы понять суть. Список ОС пока пуст:

Проверяем, что сеть настроена. По умолчанию используется default (подробнее дальше по тексту).

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

И перезагружаем модули:

Еще один момент. Для работы Win потребуются паравиртуальные драйверы virtio, которые реализуют работу основных устройств в виртуальном окружении. Они не обязательны, но их использование позволяет достичь большей производительности и отзывчивости в работе виртуальных окружений. Они должны поддерживаться как хостом, так и гостевой ОС. В ядре Linux драйвер поддерживается с 2.6.25, но модуль по умолчанию не ставится. Если вызов /sbin/lsmod | grep virtio и cat «/boot/config- uname -r » | grep -i virtio ничего не показал, следует установить пакет qemu-guest-agent. Для гостевой ОС ISO-образ доступен на fedoraproject.org.

Далее два варианта. Можно самостоятельно установить операционную систему или взять уже готовый образ с установленной ОС. Первый шаг в общем отличается тем, что нужно подготовить диск, запустить VM и установить ОС стандартным способом. Создадим диск размером 25 Гбайт.

Если в будущем нужно изменить размер диска, то используется команда resize:

Некоторые параметры очевидны, поэтому кратко:

• name — имя, по которому можно обращаться к VM;
• ram и vcpus — количество памяти и vCPU, выделяемых VM;
• disk — имя диска, формат и драйвер;
• cdrom — виртуальный CD-ROM, здесь указан ISO-образ, с которого будет загружаться система;
• network — сетевое подключение, тип и модель (можно использовать virtio, но бывают проблемы, потом можно сменить);
• os-type и os-variant — тип ОС.

Параметр —vnc имеет смысл только на сервере без GUI, при наличии интерфейса KVM сразу откроет окно через SDL. Также можно подключиться локально при помощи virsh:

Удаленно также можно зайти с использованием любого VNC-клиента, при необходимости используя port forwarding (см. ниже).

Коннектимся к Windows, запущенной под KVM

После установки ОС можно приступать к работе. Второй вариант позволяет использовать уже готовый диск с установленной ОС. Его можно скопировать с готовой системы, сконвертировать при помощи qemu-img convert, которая поддерживает форматы дисков практически всех систем виртуализации. Или взять с сайта проекта Cloudbase.

Запуск почти не отличается от предыдущего, убираем, если не нужен, cdrom и добавляем —import .

В дальнейшем можно управлять поведением VM при помощи virsh start|reboot|shutdown|suspend|resume|destroy|undefine|edit|autostart|info и так далее.

Настройки VM хранятся в отдельных XML-файлах в каталоге /etc/libvirt/qemu , имя соответствует параметру —name . Можно их просмотреть, отредактировать при необходимости, скопировать при помощи virsh. Например, нужно изменить настройки сетевого адаптера.

Скопируем настройки в файл.

Теперь в любом текстовом редакторе правим параметры второй машины, указываем новый виртуальный диск и можем запускать второй экземпляр. Для клонирования есть и другой вариант.

Настройки виртуальной машины

Сеть в KVM

Настройка сети — самый важный момент при работе с KVM. По умолчанию используется Usermode или default, когда базовая система работает как маршрутизатор между внешней и гостевой сетью. Гостевая ОС может получать доступ к внешним сетевым сервисам, но не видна из сети. IP выбирается автоматически при помощи DHCP из диапазона 192.168.122.0/24 , интерфейс основной ОС всегда имеет IP 192.168.122.1 . Для доступа к сервисам нужно самостоятельно настроить маршрутизацию. После установки libvirtd должен создать ряд NAT-правил iptables .

Правила iptables после установки KVM

Второй вариант — Bridged, когда интерфейс гостевой ОС привязывается к физическому интерфейсу и VM доступна извне без допнастроек. Этот вариант чуть сложнее в настройках, так как из-за перестроек можно потерять SSH-подключение. Поэтому при отсутствии локальной консоли (Java/веб-аплета у провайдера) пользоваться им нужно только после тщательного тестирования, и мы его рассматривать не будем.

В первом варианте удобнее настроить KVM так, чтобы она назначала гостевой системе один и тот же IP-адрес. Это можно сделать прямо в конфигурационном файле /etc/libvirt/qemu/networks/default.xml или вызвав

Далее добавляем параметр host в секции dhcp :

Редактируем сетевые настройки для виртуального хоста

И так для каждого узла. После чего перезапускаем сеть.

Теперь можем указать маршрут к сервису в основной системе:

По умолчанию VNC в хостовой машине слушает только локальный порт. Поэтому при подключении с помощью VNC-клиента нужно обязательно пробрасывать порты.

Изменить эту ситуацию можно несколькими способами: добавив параметр —vnc,listen=0.0.0.0 и при необходимости указав другой порт —vncport 5901 .

Аналогичные настройки есть в сетевых установках хоста.

Чтобы не менять установки для каждой VM, проще изменить это поведение глобально:

Заключение

Ну вот, собственно, мы имеем Windows, запущенную внутри Linux. Конечно, рассматривать KVM для локальной установки, где сильны позиции у VirtualBox и VMware Workstation, не стоит, но при наличии свободных ресурсов на VDS можно быстро развернуть еще одну машину. Скорость, конечно, будет невелика, но для небольших тестов вполне достаточная.