Образы linux для hyper v

Содержание

Информация о нерекомендованных дистрибутивах
Общие замечания по установке Linux
Установка модулей ядра без Hyper-V
Изменение размера VHD
Рекомендации по ядру Linux
Агент Linux для Azure
Общие системные требования для Linux
Переезд с Ubuntu на Windows 10, Hyper-V и избавление от железного маршрутизатора

Информация о нерекомендованных дистрибутивах

Применимо к: ✔️ виртуальным машинам Linux ✔️ гибким масштабируемым наборам

Соглашение об уровне обслуживания для платформы Azure применяется для виртуальных машин с ОС Linux, только если используется один из рекомендованных дистрибутивов. Для рекомендованных дистрибутивов предоставляются предварительно настроенные образы Linux, представленные в коллекции в Azure Marketplace.

К любым дистрибутивам, выполняющимся в Azure, предъявляются определенные требования. Поскольку каждый дистрибутив имеет свои особенности, привести исчерпывающую информацию в рамках одной статьи невозможно. Даже при соблюдении всех приведенных ниже условий для надлежащей работы может потребоваться масштабная настройка системы Linux.

Мы рекомендуем начать с одного из рекомендованных дистрибутивов Linux в Azure. В следующих статьях описывается подготовка различных рекомендованных дистрибутивов Linux, которые поддерживаются в Azure:

В этой статье приводятся общие рекомендации по работе с дистрибутивом Linux в Azure.

Общие замечания по установке Linux

Azure не поддерживает формат виртуального жесткого диска Hyper-V (VHDX) и может работать только с фиксированными виртуальными жесткими дисками. Можно преобразовать диск в формат VHD с помощью диспетчера Hyper-V или командлета Convert-VHD. Если вы используете VirtualBox, при создании диска нужно выбрать фиксированный размер вместо динамически выделяемого, который используется по умолчанию.
Azure поддерживает виртуальные машины 1-го поколения (загрузка в BIOS) и 2-го поколения (загрузка в UEFI).
Максимально допустимый размер виртуального жесткого диска составляет 1023 ГБ.
При установке системы Linux рекомендуется использовать стандартные разделы, а не диспетчер логических томов (LVM), который часто используется по умолчанию при установке. Это позволит избежать конфликта имен LVM c клонированными виртуальными машинами, особенно если диск с OC может быть подключен к другой идентичной виртуальной машине в целях устранения неполадок. Для дисков данных можно использовать LVM или RAID.
Требуется поддержка ядра для монтирования файловых систем UDF. При первой загрузке в Azure конфигурация подготовки передается в виртуальную машину Linux через UDF-носитель, подключенный к гостевой машине. Агент Azure Linux должен подключить файловую систему UDF для считывания конфигурации и подготовки виртуальной машины.
Версии ядра 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.
Не настраивайте раздел подкачки на диске с ОС. Можно настроить агент Linux для создания файла подкачки на временном диске ресурсов, как описывается на следующих шагах.
Размер виртуальной памяти всех виртуальных жестких дисков в Azure должен быть округлен до 1 МБ. Перед конвертацией диска RAW в формат VHD убедитесь, что размер диска RAW в несколько раз превышает 1 МБ, как описывается на следующих шагах.

Установка модулей ядра без Hyper-V

Так как Azure запускается на гипервизоре Hyper-V, Linux требует определенные модули ядра для запуска в Azure. При наличии виртуальной машины, созданной вне Hyper-V, установщики Linux могут не включать драйверы для Hyper-V в начальный электронный диск (initrd или initramfs), если только виртуальная машина не обнаружит, что он работает в среде Hyper-V. Если для подготовки образа Linux используется другая система виртуализации (например, Virtualbox или KVM), вам может потребоваться выполнить повторную сборку initrd, чтобы на начальном электронном диске были доступны по крайней мере модули ядра hv_vmbus и hv_storvsc. Это известная проблема встречается по крайней мере в системах на основе предшествующего дистрибутива Red Hat. Также она может встречаться в других версиях.

Механизм повторной сборки образа initrd или initramfs может отличаться в зависимости от дистрибутива. Чтобы узнать правильную процедуру для вашего дистрибутива, см. документацию по дистрибутиву или раздел поддержки. Ниже приведен пример выполнения повторной сборки initrd с помощью служебной программы mkinitrd :

Создайте резервную копию существующего образа initrd:

Выполните повторную сборку initrd с использованием модулей ядра hv_vmbus и hv_storvsc:

Изменение размера VHD

Размер виртуальной памяти образов VHD в Azure должен быть округлен до 1 МБ. Как правило, размер VHD, созданных с помощью Hyper-V, настроен правильно. Если виртуальный жесткий диск (VHD) настроен неправильно, при попытке создать образ из VHD-файла может появиться следующее сообщение об ошибке.

Виртуальный жесткий диск http:// .blob.core.windows.net/vhds/MyLinuxVM.vhd имеет неподдерживаемый виртуальный размер 21475270656 байт. Размер должен задаваться целым числом (в МБ).

В таком случае вы можете изменить размер виртуальной машины с помощью консоли диспетчера Hyper-V или командлета Powershell Resize-VHD. Если вы работаете не в среде Windows, воспользуйтесь командой qemu-img для преобразования (если необходимо) и изменения размера VHD.

В команде qemu-img версии 2.2.1 и более поздних версиях есть ошибка, которая приводит к созданию неверного формата VHD. Эта проблема устранена в QEMU версии 2.6. Рекомендуется использовать либо версию qemu-img 2.2.0 или более раннюю, либо версию 2.6 или более позднюю.

Изменение размера VHD с непосредственным использованием таких инструментов, как qemu-img или vbox-manage , может привести к сбою загрузки VHD. Мы советуем сначала преобразовать VHD в образ необработанного диска. Если образ виртуальной машины был создан в качестве образа необработанного диска (по умолчанию для некоторых гипервизоров, например, KVM), вы можете пропустить этот шаг.

Рассчитайте необходимый размер образа диска, чтобы округлить размер виртуальной памяти до 1 МБ. Следующий скрипт для оболочки Bash использует qemu-img info для определения виртуального размера образа диска и вычисляет размер с округлением до 1 МБ в большую сторону.

Измените размер необработанного диска с помощью $rounded_size , как показано выше.

А теперь преобразуйте необработанный диск обратно в VHD с фиксированным размером памяти.

Или с помощью qemu версии 2.6 или выше добавьте параметр force_size .

Агент Linux для Azure

Агент Linux для Azure waagent выполняет подготовку виртуальной машины Linux в Azure. Можно получить его последнюю версию, узнать о проблемах с файлами или отправить запрос в репозитории GitHub для агента Linux.

Агент Linux выпускается по лицензии Apache 2.0. Многие дистрибутивы уже предоставляют пакеты RPM или deb для этого агента, поэтому вы легко сможете установить и обновить такие пакеты.
Для работы агента Linux для Azure требуется Python v2.6+.
Для агента также необходим модуль python-pyasn1. В большинстве дистрибутивов он предоставляется в виде отдельно устанавливаемого пакета.
В некоторых случаях агент Linux для Azure может быть несовместим с NetworkManager. Многие предоставляемые в дистрибутивах пакеты RPM или Deb настраивают NetworkManager, в результате чего возникает конфликт с пакетом waagent. В таких случаях при установке пакета агента Linux удаляется NetworkManager.
Версия агента Linux для Azure должна быть выше минимальной поддерживаемой версии.

Общие системные требования для Linux

Измените строку загрузки ядра в GRUB или GRUB2 и включите в нее следующие параметры, задающие отправку всех сообщений консоли в первый последовательный порт. Эти сообщения могут использоваться службой поддержки Azure при отладке возникающих проблем.

Кроме того, мы рекомендуем удалить следующие параметры (если они заданы).

Графическая и «тихая» загрузка бесполезны в облачной среде, в которой требуется, чтобы все журналы отправлялись на последовательный порт. При желании можно настроить параметр crashkernel , однако учитывайте, что он сокращает объем доступной памяти в виртуальной машине на 128 МБ или более, что может оказаться проблемой в виртуальных машинах небольшого размера.

Установите агент Linux для Azure.

Агент Linux для Azure необходим для подготовки образа Linux в Azure. Во многих дистрибутивах агент предоставляется в виде пакета RPM или deb (такой пакет обычно называется WALinuxAgent или walinuxagent). Агент также можно установить вручную, как описано в руководстве по агенту Linux.

Убедитесь, что SSH-сервер установлен и настроен для включения во время загрузки. Как правило, эта конфигурация используется по умолчанию.

Не создавайте пространство подкачки на диске с ОС.

Агент Linux для Azure может автоматически настраивать пространство подкачки с использованием диска на локальном ресурсе, подключенном к виртуальной машине после подготовки для работы в среде Azure. Локальный диск ресурсов является временным и может быть очищен при отмене подготовки виртуальной машины. После установки агента Linux для Azure (см. шаг 2) измените следующие параметры в /etc/waagent.conf соответствующим образом.

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

В Virtualbox после выполнения команды waagent -force -deprovision может появиться следующая ошибка: [Errno 5] Input/output error . Это сообщение об ошибке не является важным и может быть пропущено.

Источник

Переезд с Ubuntu на Windows 10, Hyper-V и избавление от железного маршрутизатора

Купив новый ноутбук, я с сожалением заметил, что моя любимая Ubuntu больше не поддерживает работу сенсоров и вентиляторы постоянно жужжат, делая работу не комфортной. В тоже время, если загрузить предустановленную Windows 10 Pro с оригинального жесткого диска, то наступает приятная для уха тишина. Пока на улице (и дома) было прохладно, было терпимо. Но как наступила жара, терпению пришел конец. Было решено мигрировать на Windows.

В своей работе я использую многочисленные виртуальные машины для сборки, тестирования и отладки разрабатываемого программного обеспечения. Windows 10 Pro включает в себя виртуализацию Hyper-V — раз деньги уплачены, то придеться использовать! В Ubuntu я пользовался libvirt и виртуальными машинами объединенными в одну внутреннюю виртуальную сеть.

Перенеся Windows с оригинального диска на SSD и преобразовав образы виртуальных машин в формат для hyper-v, с болью в сердце, я приступил к осваиванию новой операционной системы.

Оказалось не все так страшно! Виртуальные рабочие столы заменились на рабочие столы windows(к сожалению только горизонтальные), консоль заменила консоль WSL (Windows Subsystem for Linux), для X11 приложений был установлен и добавлен в автозапуск VcXsrv, виртуальные машины заработали в Hyper-V и даже удалось запустить OSX.

Родной терминал оказался не совсем удобным и без вкладок, поэтому был безжалостно заменен на xfce4 терминал, который запускается через ярлык со скрытым окном linux консоли:

Код скрипта для запуска приложения со скрытым окном (скрывается родная консоль, которая открывается при запуске X11 приложений с командной строки), нагугленного на просторах интернета:

В итоге получилось так:

Мне приходится часто ездить, специально для поездок у меня был мелкий маршрутизатор TP-LINK WR703N прошитый OpenWRT:

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

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

Запускаем Диспетчер Hyper-V и выбираем Диспетчер виртуальных коммутаторов. Создаем новый внутренний виртуальный коммутатор, который будет обслуживать нашу виртуальную локальную сеть. Назовем его LAN Internal:

Выходить в интернет мы будем через беспроводной адаптер и езернет кабель. Создаем два внешних виртуальных коммутатора, не забыв убрать галку «Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру» — незачем Windows ходить в интернет напрямую.

Виртуальный коммутатор для WiFi:

Виртуальный коммутатор для езернет кабеля:

Операционной системой виртуальной машины маршрутизатора я выбрал серверную Ubuntu 16.04. Почему 16.04? Потому что в 18.04 простые настройки сети в /etc/network/interfaces заменили на netplan — не хочу! Создаем новую виртуальную машину и добавляем в нее наши виртуальные коммутаторы:

В закладке Безопасность либо отключаем безопасную загрузку, либо выбираем Центр сертификации Microsoft UEFI и ставим операционную систему как обычно.

После установки, заходим в свежеустановленную систему и проверяем сетевые интерфейсы командой ifconfig. Внешние подключения через кабель и WiFi могут получить ip адреса если они подключены и активны. Если адреса не получены, воспользуемся утилитой получения адреса:
dhclient eth0 eth1 eth2

Внутренний будет без адреса, так как в нашей локальной сети еще не работает сервер dhcp.
В моем случае eth0 — внешний езернет, eth1 — локальная сеть, eth2 — внешнее беспроводное подключение (в порядке добавление сетевых карт). Локальная сеть у нас будет 192.168.3.0.

Отредактируем настройки сети в /etc/network/interfaces с помощью, например, редактора nano:

Перезагружаем маршрутизатор и заходим на него опять. Теперь все сетевые интерфейсы должны иметь адреса (внешние если имеют подключение).

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

Устанавливаем необходимые нам приложения:
sudo apt install dnsmasq iptables-persistent netfilter-persistent openvpn

Разрешаем пересылку ip пакетов:

Настраиваем межсетевой экран:

Настраиваем dhcp сервер и сервер имен:

Перезагружаем и получаем работающий маршрутизатор для Windows и других виртуальных машин!

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

Но позвольте, спросите вы, а как же быть с телефоном и другими гаджетами?

Простое решение — использовать встроенный в Windows 10 Мобильный хотспот! Но не все так просто. Мобильный хотспот не хочет активироваться на виртуальном интерфейсе нашей виртуальной локальной сети! Незадача…

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

Помучившись неделю, приложение было написано (и заодно освоен ранее не изведанный зверь — Visual Studio):

Кроме активации точки доступа, приложение может запускаться при входе в систему, активировать точку по запуску и закрывать приложение после активации.

Исходный код доступен на github.
Для тех, кто не может или кому лень собирать из исходных текстов, приложение (бесплатно, без смс и всякой рекламы) доступно в Windows Магазине NoWiFi.

Таким образом, поставленная задача была решена, старый маршрутизатор окончательно отправился на пенсию, а в рюкзаке освободилось место!

На этом у меня все, всем спасибо за внимание и терпение при чтении столь нудного материала!