Виртуальный linux сервер для windows

Создаем виртуальный сервер на базе KVM

Краткое содержание: С помощью трех сравнительно простых шагов вы можете с помощью технологии полной виртуализации создать виртуальный сервер на Linux-гипервизоре KVM.

Виртуальная машина, созданная на базе ядра Linux (KVM), является бесплатным программным обеспечением для Linux, имеющим открытый код и предназначенным для использовании технологии виртуализации. KVM основывается на расширенных возможностях, реализованных аппаратно (Intel VT-X и AMD-V), и на модифицированной версии QEMU. KVM является загружаемым модулем ядра kvm.ko, с помощью которого реализуется основная инфраструктура виртуализации серверов, а модули, реализованные под конкретные процессоры — kvm-intel.ko и kvm-amd.ko, разработаны для обеспечения полной аппаратной эмуляции, что требуется для загрузки большого количества операционных систем в немодифицированном виде.

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

В настоящей статье используется сервер IBM® Blade Server HS21 с SUSE 11 в качестве операционной системы. В сервере HS21 поддерживается расширенная технология Intel VT, а версия ядра, используемая в SUSE 11, — 2.6.27.13, в котором уже есть гипервизор KVM (гипервизор KVM входит в ядро начиная с версии 2.6.20).

Для того, чтобы создать виртуальных сервер, нужно выполнить следующие три шага:

1. Установить операционную систему и необходимое программное обеспечение
2. Создать виртуальный сервер
3. Сконфигурировать сеть виртуального сервера

Шаг 1. Устанавливаем ОС и необходимое программное обеспечение

В этой части рассматриваются следующие вопросы:

1. Установка операционной системы и требуемого программного обеспечения
2. Определение, поддерживает ли процессор работу с KVM
3. Проверка правильности установки программного обеспечения

Установка операционной системы и программного обеспечения

После того, как вы установите операционную систему, вы можете с помощью следующей команды проверить установленную версию ядра Linux:

Затем выберите и установите пакеты kvm и kvm-kmp-default (в состав которых уже входит модифицированный QEMU для эмуляции аппаратных средств ввода/вывода). Смотрите рис.1, выберите эти пакеты и щелкните по Accept для того, чтобы их установить:

Рис.1. Поиск модулей установленного ядра

Версия kvm-kmp-default — 78_2.6.27.13_1-11.3 (78 — это версия KVM , а остальная часть указывает версию ядра).

Типичный вариант гипервизора KVM содержит следующие компоненты:

• Драйвер устройств для управления виртуальным аппаратным обеспечением; этот драйвер предоставляет свои возможности через символьное устройство /dev/kvm
• Компонента пользовательского пространства для эмуляции аппаратного обеспечения персонального компьютера; в настоящий момент она обрабатывается в пользовательском пространстве и является слегка модифицированным процессом QEMU
• Модель ввода/вывода, которая непосредственно следует из модели QEMU с поддержкой образов копирования и записи на диск и других особенностей QEMU

Определяем, поддерживает ли процессор работу с KVM

KVM зависит от наличия расширенных команд виртуализации x86. Для того, чтобы проверить совместимость, запустите команду grep vmx /proc/cpuinfo (на AMD, запустите команду grep svm /proc/cpuinfo ). Если результат выдачи будет похож на листинг 1, то это означает, что ваш процессор поддерживает использование KVM; в противном случае ваш процессор не поддерживает работу KVM.

Листинг 1. Проверка процессора на предмет поддержки KVM

Проверяем правильность установки программного обеспечения

Запустите команду lsmod | grep kvm для того, чтобы проверить, что модуль KVM установлен успешно. Если результат аналогичен тому, что показан ниже, то модуль KVM установлен успешно:

Шаг 2. Создаем виртуальный сервер

В этой части рассматриваются следующие вопросы:

1. Создаем образ диска в формате raw
2. Устанавливаем ОС на этот образ
3. Запускаем виртуальный сервер

Создаем образ диска в формате raw

Для того, чтобы создать образ диска, используйте следующую команду:

С помощью этой команды вы создаете образ размером 10 Гбайт и с именем kvmtest.img.

Устанавливаем операционную систему на образ диска

Для того, чтобы получить операционную систему, установленную на этом образе, используйте следующую команду:

Поскольку вы устанавливаете пакет KVM, а не создаете модуль KVM из исходного кода самостоятельно, вы должны использовать команду qemu-kvm , а не команду qemu-system-x86_64 .

-boot d означает, что мы будем создавать виртуальный сервер, загружая его с CDROM. -m 1024 означает, что мы выделяем для виртуального сервера 1 Гбайт памяти.

После того, как эта команда будет запущена, появится экран установки операционной системы, такой как показано на рис.2:

Рис.2. Экран установки ОС

Далее установите операционную систему так, как вы это обычно делаете.

Теперь запустите ваш виртуальный сервер

После того, как операционная система будет успешно установлена, вы сможете запустить виртуальный сервер с помощью следующей команды:

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

Шаг 3: Конфигурирование сетевых настроек виртуального сервера

Теперь вы знаете, как правильно создавать виртуальный сервер, но не сетевое соединение для виртуального сервера. Рассмотрим, как создать виртуальное соединение типа «мост»:

1. Устанавливаем пакет bridge-util
2. Создаем сетевой интерфейс типа «мост»
3. Создаем скрипт для управления сетью
4. Запускаем сеть гостевой операционной системы
5. Конфигурируем сеть гостевой операционной системы

Установка пакета bridge-util

Нам нужно создать сетевое соединение типа «мост», поэтому нам нужно в операционной системе в разделе управления программным обеспечением выбрать для установки пакет bridge-util.

Рис.3. Установка пакета bridge-util

Создание сетевого интерфейса типа «мост»

На экране настройки сетевых соединений щелкните по ссылке Add a new network interface (Добавить новый сетевой интерфейс) (см.рис.4):

Рис.4. Добавление нового сетевого интерфейса

Должно появиться диалоговое окно настройки аппаратного обеспечения, такое как изображено на рис.5:

Рис.5. Диалог настройки аппаратного обеспечения, используемого для нового сетевого интерфейса

Выберите Bridge («Мост») в качестве типа устройства; щелкните по ссылке Next («Далее») для того, чтобы продолжить конфигурирование сети. Вы должны увидеть экран конфигурирования такой, как изображено на рис. 6:

Рис.6. Экран конфигурирования сети

В разделе «Bridged Devices» выберите вариант eth0 и укажите статический IP адрес для интерфейса типа «мост», который должен быть такой же, как и у eth0 (см. рис. 7).

Рис.7. Конфигурирование статического IP адреса для интерфейса типа «мост»

После того, как вы это сделаете, конфигурация для eth0 должна быть сброшена, поэтому щелкните по ссылке Next («Далее») для того, чтобы продолжить, и вы вернетесь в экран конфигурирования сетевых настроек. Вы увидите, что был создан новый сетевой интерфейс типа «мост» и что интерфейс eth0 был очищен.

Создание скрипта управления сетью

Содержимое скрипта управления сетью должно выглядеть приблизительно так, как показано на листинге 2:

Листинг 2. Скрипт управления сетью

Запуск гостевой операционной системы

Запустите гостевую операционную систему с сетевым интерфейсом с помощью следующей команды:

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

Конфигурирование сетевых настроек гостевой операционной системы

После того, как гостевая операционная система будет загружена, сконфигурируйте ее сетевые настройки так, как вы это делаете обычно.

Поздравляем! Вы успешно создали виртуальный сервер, построенный на основе KVM.

Ссылки на другие статьи по теме виртуализации вы найдете в разделе «Технологии и средства виртуализации» нашей Библиотеки.

Источник

От сложного к простому: запускаем виртуальный сервер Windows/Linux

Сегодня рассказываем про услугу «Виртуальный сервер Windows/Linux», с недавних пор доступную в сервисе CloudLITE. Ее запуск мы анонсировали в ноябре, когда рассказывали о переходе на новую платформу биллинга и провижининга на базе BILLManager, и вот теперь готовы поделиться подробностями.

Что у нас получилось?

Как показала практика, для большинства пользователей CloudLITE простота сервиса важнее кастомизации и функциональных изысков: готовые шаблоны ВМ с предустановленной ОС на порядок популярнее «индивидуальных» сборок, а желающих самостоятельно настраивать сеть или углубляться в администрирование облачной инфраструктуры и вовсе днем с огнем. Мы решили сделать личико попроще и в дополнение к виртуальному дата-центру (IaaS) запустили услугу «Виртуальный сервер (VDS)».

Для того, чтобы начать работу с сервером, нужно всего лишь выбрать тариф, шаблон ОС и объем диска.

Сразу после активации сервер готов к работе без каких-либо лишних настроек. Вам на почту придет письмо с явками и паролями сервера и краткими инструкциями по удаленному подключению через RDP/SSH или через веб-консоль в Личном кабинете.

Мы пока остановились на готовых шаблонах самых популярных среди наших клиентов ОС:

• Ubuntu 14.04,
• Centos 6.7,
• русская и английская версии Windows Server 2008/2012.

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

Тарифов по пять штук для каждой группы ОС — немного, по сравнению с виртуальным дата-центром, но внутри тарифа можно гибко управлять размером диска: чем старше тариф, чем больше интервал, из которого можно выбирать.

Каждому серверу выделяется внешний IP-адрес, который теперь прикрепляется напрямую к серверу, а не через NAT, как в виртуальном дата-центре.
Из бонусов: в комплект с VDS Windows уже входит серверная лицензия, а к виртуальному серверу Linux прилагается панель ISPmanager 5 LITE.
Kак и все сервисы CloudLITE, виртуальный сервер Linux/ Windows базируется на VMware. Оборудование размещается в собственном дата-центре NORD 3 на севере Москвы.

Что еще интересного?

Почасовая тарификация. Помимо посуточной оплаты, которая уже доступна для услуги виртуального дата-центра, для VDS будет работать почасовая тарификация. Что это означает на практике? Если виртуальные сервер нужен не все время в течение дня, то можно его выключать и тем самым сэкономить деньги. В неактивном состоянии будет учитывается только стоимость заказанной оперативной памяти, дискового пространства (они же продолжают хранить ваши данные, даже когда сервер выключен :)) и лицензий (в случае с севером Windows). А вот за процессор платить не придется. В течение дня биллинг фиксирует количество часов «бодрствования» сервера и раз в сутки списывает деньги с учетом этой статистики. Информацию о списаниях можно посмотреть в разделе «Расходы» в Личном кабинете.

Более подробные данные по количеству часов, в течение которых сервер работал, нагрузку (%) на процессор и диск можно будет отслеживать во вкладке «Мониторинг» (этот раздел пока находится в стадии бета-тестирования). В дальнейшем здесь появится функция SMS- и email-оповещения о недоступности сервера и/или критической нагрузке на процессор.

Миграция в виртуальный дата-центр. По сравнению с виртуальным дата-центром (IaaS), VDS не требует дополнительных настроек и позволяет сразу начать работу, но и возможностей в этом формате чуть меньше. На случай, если вы почувствуете, что упираетесь в потолок по функционалу и хотите больше контроля над ресурсами, всегда можно проапгрейдиться и перенести свой сервер в виртуальный дата-центр (ВДЦ). Все, что нужно, это создать ВДЦ подходящего размера, выбрать виртуальный сервер для переноса, а все остальное сделает служба техподдержки CloudLITE.

По традиции приглашаем всех на тест-драйв новой услуги. Сейчас можно попробовать виртуальный сервер с Ubuntu/Centos в конфигурации 1 vCPU, 1 GB RAM, 30-80 GB SSD. В комплект входит панель ISPmanager 5 LITE и DNS-хостинг, который мы тоже запустили в начале этого года, как и обещали :).
И как всегда, будем признательны за любой конструктивный фидбек.

Источник

Опыт настройки и использования WSL (подсистемы Linux в Windows 10)

К написанию данной статьи меня побудил вопрос на Тостере, связанный с WSL. Я, после нескольких лет использования систем на ядре Linux, около полугода назад перешел к использованию Windows 10 на домашнем ПК. Зависимость от терминала и Linux окружения в моей работе практически сразу привели меня к вопросу: или ставить виртуалку или попробовать WSL. Я выбрал второе, и остался вполне доволен.

Под катом я расскажу как установить и настроить WSL, на какие я наткнулся проблемы и ограничения, как запускать Linux приложения из Windows и наоборот, а так же как интегрировать элементы окружения Xfce в окружение рабочего стола Windows.

Никогда не думал, что однажды вернусь на Windows, но повод попробовать мне дали стечения обстоятельств: жена, далекая от IT, дергала почти каждый раз, когда у нее возникала необходимость воспользоваться компом; проснулась ностальгия по одной игре, но она никак не хотела адекватно работать под wine; а тут еще мне подарили коробочную Windows 10 Pro. WSL я поставил чуть ли не сразу после установки системы, поигрался несколько вечеров, понял, что продукт для моих задач годный, но хочется более привычный терминал и вообще некоторых удобств.

Установка WSL и дистрибутива

Сразу оговорюсь, в интернете можно найти описание установки с помощью выполнения команды lxrun /install в командной строке или консоли PowerShell. Данный способ больше не работает (после выхода WSL в стабильный релиз). Насколько мне известно, сейчас WSL можно установить только из Microsoft Store вместе с предпочитаемым дистрибутивом.

Так же отмечу, что когда установку производил я, на выбор были доступны дистрибутивы OpenSUSE, SUSE Linux Enterprise и Ubuntu 16.04 — последний я и установил. Сейчас также доступны Ubuntu 18.04, Debian 9 и Kali Linux, возможно появятся и другие дистрибутивы. Действия по установке могут отличаться. Так же, часть проблем описанных в статье может быть уже исправлена.

Находим в магазине желаемый дистрибутив и устанавливаем. Установка пройдет быстро, так как скачает только эмулятор ядра Linux и утилиту для запуска подсистемы, которая окажется в системной папке в трех экземплярах: wsl.exe, bash.exe и ubuntu.exe (вместо ubuntu будет имя Вашего дистрибутива). Все они равнозначны и делают одно и то же — запускают собственный эмулятор терминала, в нем linux’овый bash работающий под эмулятором ядра. При первом же запуске нас попросят придумать логин и пароль для пользователя по умолчанию, а после произойдет непосредственно установка дистрибутива. В качестве пользователя по умолчанию указываем root без пароля — это потребуется для дальнейших шагов. Безопасность не пострадает, кроме того при подготовке материалов к статье, в англоязычном туториале, я наткнулся на информацию, что новые версии WSL теперь делают пользователем по умолчанию root без пароля без лишних вопросов.

Дожидаемся установки. Далее первым делом стоит обновить зеркала apt на ближайшие. Для этого понадобится CLI текстовый редактор. В комплекте только vi, я же больше предпочитаю nano, поэтому ставлю его:

sudo вводить не требуется, так как мы уже под root’ом. Отредактируем файл /etc/apt/sources.list:

У меня лучше всего работают зеркала Яндекса, поэтому мой файл выглядит так:

Нажимаем Ctrl+O для сохранения и Ctrl+X для выхода. Теперь можно обновить систему до актуального состояния:

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

Далее переходим в папку юзера, зайдем под ним, установим пароль и отредактируем файл

Все, подсистема готова к использованию… почти.

Установка X-сервера, Xfce и прочих GUI’шных приложений

Первая же проблема, на которую я натолкнулся — bash-completion в предлагаемом эмуляторе терминала работал, мягко говоря, некорректно. Кроме того, данный эмулятор не умеет вкладки, а каждый его экземпляр запускает все в новом пространстве процессов, с отдельным init’ом (который кстати не заменить). Мне захотелось нормальный эмулятор терминала, некоторых других GUI приложений, а так же панельку, чтоб это все быстро запускать.

Когда я гуглил этот вопрос, я наткнулся на множество проблем, вроде необходимости перевода dbus на tcp протокол. На данный момент всех этих проблем нет. В подсистеме нормально работают unix-domain-socket’ы и все спокойно общается через них.

Первым делом нам понадобится X-сервер, притом установленный в основную систему (в Windows). Лично я использую для этих целей VcXsrv — порт X11 на Windows. Официальный сайт указанный в about самой утилиты его сейчас не предоставляет, поэтому гуглим установщик и устанавливаем все по умолчанию.

Пока идет установка возвращаемся в терминал WSL, командой exit выходим обратно в root’а. Первым делом настроим русские локали:

Далее установим некоторые компоненты Xfce. Можно конечно установить его целиком из мета-пакета, но большинство компонентов нам не понадобится, а модульная архитектура Xfce позволяет нам поставить только необходимое:

Запускать каждый раз окружение руками не очень удобно, поэтому я автоматизировал данный процесс. Для этого в основной системе создадим в удобном для нас месте папку, а в ней 3 файла для запуска:

config.xlaunch — файл настроек для VcXsrv

x-run.vbs — WSL всегда запускается со своим эмулятором терминала, если его закрыть — завершатся все его дочерние процессы. Чтоб данное окно не мозолило глаза, неплохо его запускать скрытым. К счастью в Windows встроен интерпретатор VBScript, который позволяет это сделать в одну строчку:

Поясню, что здесь происходит. Мы говорим VBscript выполнить приложение wsl с параметром cd /home/user1; DISPLAY=:0 LANG=ru_RU.UTF-8 su user1 -c xfce4-session , папка запуска нам не важна, поэтому пустая строка, действие open — запуск, 0 — скрытый режим. Самому wsl мы отдаем команду на выполнение: переход в папку пользователя, затем с установкой переменных окружения DISPLAY (дисплей X-сервера) и LANG (используемая локаль) мы запускаем xfce4-session от имени нашего пользователя user1 (благодаря команде su)

start.bat — batch файл для запуска, по желанию его можно засунуть в автозагрузку

Далее можем запустить наш start.bat и настроить панель Xfce под себя. Замечу, что здесь я наткнулся на еще одну проблему — панель прекрасно отображается поверх всех окон, но вот выделить себе место, как панель на рабочем столе Windows она не может. Если кто знает решение данной проблемы, поделитесь в комментариях.

Ну и под конец данной части, скриншот моего рабочего стола:

Взаимодействие окружения Windows и окружения подсистемы Linux

Запускать Linux приложения напрямую из Windows можно через те же 3 команды — bash, wsl или ubuntu. Не забываем, что по умолчанию запуск идет от root, поэтому стоит понижать привилегии через su , так же нужно не забывать передавать переменную окружения DISPLAY=:0 если приложению требуется X-сервер. Так же нужно менять папку, из которой должно работать приложение, через cd внутри WSL. Пример, посчитаем md5 для file.txt на диске D средствами Linux’овой md5sum:

Доступ к файловой системе Linux так же имеется, лежит она в %localappdata%\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs . Читать таким образом файлы можно, а вот писать — не желательно, можно поломать файловую систему. Думаю проблема в том, что Windows не умеет работать с правами и владельцами файловой системы Linux.

Из Linux так же можно запускать Windows приложения. Просто запускаем exe-шник и он выполнится в основной системе.

Диски Windows монтируются в /mnt в соответствии со своими буквами в нижнем регистре. Например диск D будет смонтирован в /mnt/d . Из Linux можно свободно читать и писать файлы Windows. Можно делать на них симлинки. Права у таких файлов всегда будут 0777, а владельцем будет root.

Сетевой стек у подсистемы общий с Windows. Сервер поднятый в Linux будет доступен на localhost в Windows и наоборот. Однако unix-domain-socket для Windows будет просто пустым файлом, работать с этим можно только внутри Linux. Выход во внешнюю сеть у Linux так же есть, в том числе можно слушать порты, если этого не запрещает фаервол.
ifconfig в Linux и ipconfig в Windows выдают одинаковую информацию о сетевых интерфейсах.

Из диспетчера задач Windows можно спокойно прибить процесс внутри подсистемы Linux. Однако Linux увидит только свои процессы.

Особенности, ограничения и подводные камни

Ядро Linux в WSL не настоящее. Это всего лишь прослойка-эмулятор, которая часть Linux-специфичных задач выполняет сама, а часть проксирует напрямую в ядро winNT. Большая часть api в нем реализована, но не все. Свое ядро собрать не получится, как и не получится подключить модули ядра (.ko, Kernel Object).

Init процесс у WSL тоже свой и заменить его, например, на system.d не выйдет. У меня давно есть желание написать менеджер демонов на go, который бы работал с файлами юнитов system.d и предоставлял бы схожий интерфейс, да все руки не доходят.

Нет поддержки openFUSE, соответственно примонтировать виртуальную или удаленную файловую систему не получится. Так же нельзя сделать mount из файла, mount вообще ничего кроме bind здесь, похоже, не умеет.

Так же нет никакой возможности разбить файловую систему Linux на несколько разделов/дисков.

Прямой доступ к железу практически отсутствует. Все таки мы находимся в песочнице Windows, а не в полноценном Linux. /dev и /sys заметно пустуют, в них лишь проц да виртуальные устройства. Доступ к GPU — только через X-сервер, напрямую — никак, так что нейросети обучать придется в Windows.

В JS разработке столкнулся с тем, что electron.js отказался запускаться в WSL, пришлось дублировать окружение node.js в Windows.

Итоги

Статья получилась довольно длинной, надеюсь, что она окажется еще и полезной.
WSL для меня лично оказался инструментом вполне юзабельным, решающим мои задачи fullstack backend разработчика. Виртуалка с Linux за полгода так и не понадобилась. По общим ощущениям Windows+WSL намного функциональнее, чем Linux+Wine.

Пока писал статью, обнаружил, что в Microsoft Store появилась сборка WSL с Debian 9.3, данный дистрибутив мне более симпатичен, чем Ubuntu, поэтому буду пробовать ставить.

Источник