- Рекомендации по запуску Linux в Hyper-V
- Настройка файловых систем Linux в динамических VHDX-файлах
- Время ожидания меню GRUB на виртуальных машинах поколения 2
- Загрузка PxE на виртуальных машинах поколения 2
- Использование статических MAC-адресов с отказоустойчивой кластеризацией
- Использование сетевых адаптеров, относящихся к Hyper-V, а не устаревших сетевых адаптеров
- Для повышения производительности дискового ввода-вывода используйте планировщик заданий (NOOP/None)
- Зарезервируйте больше памяти для кдумп
- Сжатие VHDX-файлов или расширения VHD и VHDX может привести к ошибочным таблицам разделов GPT
- Установка и настройка Debian Linux под Hyper-V
- Установка и настройка Linux Ubuntu 10.04 LTS под Hyper-V в Windows Server 2008 R2
Рекомендации по запуску Linux в Hyper-V
область применения: Windows Server 2022, Azure Stack хЦи, версия 20H2; Windows сервер 2019, Windows Server 2016, Hyper-V Server 2016, Windows Server 2012 r2, Hyper-V Server 2012 R2, Windows Server 2012, Hyper-V Server 2012, Windows Server 2008 R2, Windows 10, Windows 8.1, Windows 8, Windows 7,1, Windows 7
Этот раздел содержит список рекомендаций по запуску виртуальной машины Linux в Hyper-V.
Настройка файловых систем Linux в динамических VHDX-файлах
Некоторые файловые системы Linux могут потреблять значительный объем свободного места на диске, даже если файловая система в основном пуста. Чтобы уменьшить объем используемого дискового пространства в динамических VHDX-файлах, учитывайте следующие рекомендации.
- При создании VHDX используйте 1 МБ Блокксизебитес (из 32 МБ по умолчанию) в PowerShell, например:
Формат ext4 является предпочтительным для ext3, так как ext4 больше пространства, чем ext3 при использовании с динамическими VHDX-файлами.
При создании файловой системы укажите число групп 4096, например:
Время ожидания меню GRUB на виртуальных машинах поколения 2
Из-за того, что устаревшее оборудование удаляется из эмуляции на виртуальных машинах поколения 2, для отображения меню GRUB слишком быстро вычисляется таймер обратного отсчета, и сразу же загружается запись по умолчанию. Пока GRUB не будет использоваться для использования таймера, поддерживаемого EFI, измените /Бут/груб/груб.конф,/т.п./default/grub или эквивалентным параметром «Timeout = 100000» вместо значения по умолчанию «timeout = 5».
Загрузка PxE на виртуальных машинах поколения 2
Так как в виртуальных машинах поколения 2 отсутствует таймер «СМОЛой», сетевые подключения к PxE-серверу TFTP можно преждевременно завершить и предотвратить считывание конфигурации GRUB и загрузку ядра с сервера.
В дистрибутивах Linux, отличных от RHEL 6. x, можно выполнить аналогичные действия, чтобы настроить GRUB v 0.97 для загрузки ядер Linux с PxE-сервера.
Кроме того, при вводе с помощью клавиатуры и мыши RHEL/CentOS 6,6 не будет работать с предварительно установленным ядром, что не позволит указать параметры установки в меню. Чтобы разрешить выбор параметров установки, должна быть настроена последовательная консоль.
В файле ефидефаулт на PxE-сервере добавьте следующий параметр ядра «console = ttyS1» .
На виртуальной машине в Hyper-V настройте COM-порт с помощью этого командлета PowerShell:
Указание файла Kickstart для предварительно установленного ядра также позволит избежать необходимости ввода с клавиатуры и мыши во время установки.
Использование статических MAC-адресов с отказоустойчивой кластеризацией
Виртуальные машины Linux, которые будут развернуты с помощью отказоустойчивой кластеризации, должны быть настроены со статическим MAC-адресом для каждого виртуального сетевого адаптера. В некоторых версиях Linux сетевая конфигурация может быть потеряна после отработки отказа, поскольку виртуальному сетевому адаптеру назначается новый MAC-адрес. Чтобы избежать потери конфигурации сети, убедитесь, что у каждого виртуального сетевого адаптера есть статический MAC-адрес. Вы можете настроить MAC-адрес, изменив параметры виртуальной машины в диспетчере Hyper-V или диспетчер отказоустойчивости кластеров.
Использование сетевых адаптеров, относящихся к Hyper-V, а не устаревших сетевых адаптеров
Настройте и используйте виртуальный адаптер Ethernet, который является сетевой картой Hyper-V с повышенной производительностью. Если к виртуальной машине подключены как устаревшие, так и сетевые адаптеры, относящиеся к Hyper-V, сетевые имена в выходных данных команды ifconfig-a могут показывать случайные значения, такие как _tmp12000801310. Чтобы избежать этой проблемы, удалите все устаревшие сетевые адаптеры при использовании сетевых адаптеров, связанных с Hyper-V, в виртуальной машине Linux.
Для повышения производительности дискового ввода-вывода используйте планировщик заданий (NOOP/None)
Ядро Linux предлагает два набора планировщиков дискового ввода-вывода для переупорядочивания запросов. Один набор предназначен для более старой подсистемы «BLK», а один — для новой подсистемы «BLK-MQ». В любом случае с современными твердотельными дисками рекомендуется использовать планировщик, который передает решения о планировании в базовый гипервизор Hyper-V. Для ядер Linux, использующих подсистему «BLK», это планировщик «NOOP». Для ядер Linux, использующих подсистему «BLK-MQ», это планировщик «None».
Для конкретного диска доступные планировщики могут отображаться в этой папке файловой системы:/СИС/класс/блокк/ /куеуе/счедулер с выбранным планировщиком в квадратных скобках. Планировщик можно изменить, записав в это расположение файловой системы. Чтобы сохранить изменения между перезагрузками, необходимо добавить это изменение в скрипт инициализации. Дополнительные сведения см. в документации по дистрибутив Linux.
Версии ядра Linux ниже 2.6.37 не поддерживают NUMA в Hyper-V с виртуальными машинами большего размера. Эта проблема влияет в основном на дистрибутивы более ранних версий, в которых используется исходное ядро Red Hat 2.6.32, и была исправлена в Red Hat Enterprise Linux (RHEL) 6.6 (kernel-2.6.32-504). В системах под управлением модифицированных ядер старше версии 2.6.37 или ядер RHEL старше 2.6.32-504 в командной строке ядра необходимо задать параметр загрузки numa=off в файле grub.conf. Дополнительные сведения см. в статье базы знаний Red Hat 436883.
Зарезервируйте больше памяти для кдумп
Если ядро записи дампа завершается с тревогой при загрузке, зарезервируйте больше памяти для ядра. Например, измените параметр crashkernel = 384M-: 128M на crashkernel = 384M-: 256M в файле конфигурации Ubuntu GRUB.
Сжатие VHDX-файлов или расширения VHD и VHDX может привести к ошибочным таблицам разделов GPT
Hyper-V позволяет сжимать файлы виртуального диска (VHDX) без учета разделов, томов или структур данных файловой системы, которые могут существовать на диске. Если VHDX-файл сжимается до конца раздела, то данные могут быть потеряны, при этом Секция может быть повреждена, а при чтении секции могут возвращаться недопустимые данные.
После изменения размера VHD или VHDX администраторы должны использовать служебную программу, например fdisk, или частично обновить структуру разделов, томов и файловой системы, чтобы отразить изменение размера диска. Сжатие или увеличение размера VHD или VHDX с таблицей разделов GUID (GPT) вызовет предупреждение, если для проверки макета раздела используется средство управления секциями, и администратору будет выведено предупреждение об исправлении первого и дополнительного заголовков GPT. Этот ручной этап можно выполнить без потери данных.
Источник
Установка и настройка Debian Linux под Hyper-V
Давайте продолжим наши упражнения в виртуализации Linux систем под Hyper-V. Сегодня мы займемся установкой и настройкой Debian 6 под Hyper-V. Все что я буду писать ниже можно применять не только к Debian 6, но и к Debian 5 и к остальным дистрибутивам основанным на Debian таким как Ubuntu, Kubuntu, Xubuntu, Ebuntu.
Debian не входит в список официально поддерживаемых Microsoft систем Linux для запуска под Hyper-V. Не смотря на это он работает в виртуальном окружении очень даже хорошо. В связи с тем, что официального пакета компонентов интеграции Hyper-V для Debian нет, мы воспользуемся драйверами Hyper-V встроенными в новейшие ядра Linux.
Установка Debian 6 под Hyper-V довольно банальна. Единственное что нужно сделать на этапе создания виртуальной машины это добавить в систему эмулируемый сетевой интерфейс Legacy. Он нам понадобится для первоначального обновления системы и установки новейшего ядра Linux.
После завершения установки Debian 6 у нас будет ядро 2.6.32 конечно оно не блещет новизной, но в тоже время вполне нормально с многопроцессорными виртуальными машинами.
Для того чтобы виртуальная машина смогла работать быстрее и воспользоваться всеми преимуществами Hyper-V нужно обновить ядро как минимум до 2.6.36. Перед сборкой нового ядра обновляем систему, устанавливаем исходные тексты текущего ядра и все необходимые инструменты для компиляции нового.
# apt-get update
# apt-get install build-essential ncurses-dev kernel-package fakeroot install linux-headers-2.6 linux-source-2.6.32
Теперь приступим к сборке нового ядра 2.6.36 взятого с kernel.org
# cd /usr/src
# wget -c www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.36.tar.bz2
# bzip2 -d linux-2.6.36.tar.bz2
# tar xf linux-2.6.36.tar
# cd linux-2.6.36
# cp /boot/config* ./.config
# make menuconfig
В меню выбираем Device Drivers -> Stagging Drivers –> Microsoft Hyper-V Client Drivers
На этом этапе так же можно удалить лишние драйвера для устройств, которых никогда не будет в виртуальной машине, таких как wi-fi, звуковые карты, USB, PCI. Впрочем, это не обязательно, если не желаете, можете не делать.
После этого можем начать сборку deb пакетов ядра. Для того чтобы лучше отличать ядра добавляем в название символы hyper-v.
# make-kpkg clean
# fakeroot make-kpkg —initrd —append-to-version=-hyper-v kernel_image kernel_headers
Компиляция ядра занимает довольно продолжительное время. После этого в /usr/src появятся два deb пакета которые можно установить в систему командой dpkg –i.
Так же эти пакеты можно будет перенести и установить в другие виртуальные машины с Debian дабы не повторять процесс компиляции.
Редактируем /etc/initramfs-tools/modules и добавляем следующие строки указывающие загружать нужные модули при старте системы:
hv_vmbus
hv_storvsc
hv_blkvsc
hv_netvsc
# update-initramfs –u –k 2.6.36-hyper-v
Выключаем виртуальную машину, удаляем сетевой адаптер Legacy, добавляем синтетический сетевой адаптер и загружаем машину с новым ядром.
После этого проверяем с помощью lsmod | grep hv что все нужные для работы Hyper-V модули загрузились.
Обратите внимание, в новых версиях ядер Linux сетевой синтетический интерфейс Hyper-V переименован из seth в eth. Это может вводить в заблуждение.
Как обычно я протестировал устойчивость виртуальной машины прокачав через нее в течении нескольких дней с помощью scp почти сотню гигабайт трафика. Виртуальные жесткие диски работают также достаточно быстро.
Виртуальная машина работает стабильно в 4-х процессорной конфигурации с 44 гигабайтами ОЗУ. В общем можно сделать вывод, что Debian и основанные на нем дистрибутивы способны отлично работать под Hyper-V и применяться для реализации инфраструктурных элементов работающих с большой нагрузкой.
Источник
Установка и настройка Linux Ubuntu 10.04 LTS под Hyper-V в Windows Server 2008 R2
Выдалось немного свободного времени, поэтому сегодня я решил написать, как обстоят дела с работой Ubuntu 10.04 под Hyper-V.
Не смотря на то, что Ubuntu не входит в список официально поддерживаемых Linux дистрибутивов работает он под Hyper-V отлично. Более того никаких дополнительных компонентов интеграции ставить не пришлось. Все что нужно для работы с Hyper-V давно находится в свежих ядрах Linux.
Ну что, приступим?
Берем Linux Ubuntu 10.04 LTS. Подойдет как 64-х битная, так и 32-x битная версия. Создаем стандартную виртуальную машину, подключаем DVD с ОС и начинаем установку. Обратите внимание, что мы оставляем синтетический сетевой интерфейс, созданный по умолчанию внутри виртуальной машины. Больше нет необходимости использовать устаревший и более медленный сетевой интерфейс Legacy. Рекомендуется использовать статический Mac адрес сетевого интерфейса, если эта виртуальная машина будет мигрировать между физическими узлами кластера с помощью механизма Live migration.
Выполнять установку можно в текстовом или в графическом режиме. Я рекомендую делать это с помощью графики т.к в текстовом режиме перерисовка каждого меню занимает секунд 20-30. Это довольно сильно раздражает, хотя и не мешает завершить установку удачно.
Сразу же после старта установки в течение минуты, другой можно наблюдать ворох предупредительны сообщений о нестандартном BIOS. Смело игнорируем их и продолжаем установку до тех пор пока не увидим следующее лаконичное сообщение.
После первой перезагрузки смотрим с помощью lsmod список загруженных модулей. Обнаруживаем, что загружен лишь модуль шины Hyper-V под названием hv_vmbus.
Этого недостаточно, поэтому редактируем файл /etc/initramfs—tools/modules и добавляем в него строки разрешающие загрузку остальных необходимых нам модулей.
hv_vmbus
hv_storvsc
hv_blkvsc
hv_netvsc
hv_utils
Сохраняем файл и выполняем команду:
$ sudo update-initramfs -u
Прописываем в /etc/network/interfaces ваш новый синтетический сетевой интерфейс seth0. Если бы у вас использовался устаревший сетевой интерфейс Legacy, то он назывался бы eth0.
Для статической адресации:
Auto seth0
iface seth0 inet static
address x.x.x.x
netmask x.x.x.x
Gateway x.x.x.x
Для получения адреса по DHCP:
Auto seth0
iface seth0 inet dhcp
Я проверял оба способа сетевой адресации, они работают.
Перезагружаемся и в процессе видим вот такие сообщения о том что устройства связанные с vmbus найдены.
После загрузки с помощью lsmod проверяем загруженные модули и смотрим, какие сетевые интерфейсы у нас есть в системе.
Как видите, сетевой интерфейс seth0 работает вполне нормально.
Так же стоит отметить, что Ubuntu нормально работает как в однопроцессорной, так и в многопроцессорной конфигурации. Система без проблем масштабируется до 4-х процессоров.
К сожалению, ресурсы ОЗУ моего тестового сервера ограниченны, поэтому дать более 14 ГБ ОЗУ виртуальным машинам с Ubuntu я не смог. Впрочем, для большинства задач такого объема вполне достаточно.
Стоит отметить, что поддержки синтетической мыши в Ubuntu нет, а проект Satori пока что не портирован под этот дистрибутив, поэтому для удаленного управления в графическом режиме я использовал VNC.
На всякий случай внутри виртуальных машин с Ubuntu я настроил веб сервер и FTP сервер. В течение нескольких дней с помощью скриптов периодически скачивал с них довольно большие объемы данных. Деградации быстродействия, каких либо проблем и сбоев замечено не было.
Вывод – несмотря на то, что официально о поддержке Ubuntu не заявлено этот дистрибутив работает под Hyper-V весьма надежно и, по моему мнению, может использоваться в производственной среде.
Источник