Установка и настройка CentOS Linux 5.5 под Hyper-V

    Давайте продолжим серию статей о запуске Unix и Linux систем под Hyper-V R2. Сегодня посмотрим, как устанавливать и настраивать CentOS 5.5 под управлением нашей системы виртуализации. Почему именно CentOS? Все очень просто он является самым популярным среди любителей RedHat подобных дистрибутивов.

    Для тех, кому лень читать могу сказать что CentOS работает под Hyper-V очень хорошо и готов к применению в производственной среде. Кстати, все, что я напишу ниже можно с таким же успехом применять и для RHEL.

    Ну что приступим?


    Создаем виртуальную машину. И добавляем в нее сетевой адаптер Legacy. Он пригодится нам для обновления CentOS и для установки компонентов интеграции Hyper-V.

    Centos_hyperv_network_settings

    Запускаем установку ОС. Для того чтобы сценарий тестирования был наиболее реалистичным будем использовать динамические жесткие диски VHD. Обратите внимание, что гостевая система вполне нормально работает с дисками размера до 2 ТБ. Использование динамических дисков автоматически расширяющихся при необходимости поможет нам реалистичнее посчитать среднюю производительность дисковых операции.

    Centos_2TB_VHD_Disk

    Так же в процессе установки можно настроить сетевой интерфейс Legacy. Centos_legacy_network_dhcp_settings

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

    Centos_legacy_network_test

    Сейчас нам доступен сетевой адаптер со скоростью 100 МБит/c. Для многих задач этого достаточно, но ведь хочется более высоких скоростей? Скоро мы и до этого дойдем.

    Обратите внимание, что даже без сервисов интеграции с Hyper-V система способна работать с несколькими виртуальными процессорами. Максимальное количество виртуальных процессоров 4.

    Centos_SMP_Hyperv

    Как видите базовый функционал работает вполне нормально. Теперь давайте приступим к установке сервисов интеграции Hyper-V. Что это даст нам?

    • Синтетические драйвера для жестких дисков и сетевых контроллеров оптимизированные специально для Hyper-V R2.
    • Fastpath Boot позволяет жестким дискам с которых загружается гостевая ОС работать быстрее. 
    • Синхронизация времени гостевой ОС с часами Hyper-V.
    • Правильно завершение работы гостевой ОС Linux по команде Shutdown из Hyper-V, System Center Virtual Machine Manager или Powershell. 
    • Heartbeat – периодическая проверка сердцебиения гостевой ОС.


    Перед установкой сервисов интеграции Hyper-V обновляем гостевую ОС через графический интерфейс или с помощью команд:

    # yum update
    # reboot


    Centos_system_update

    После перезагрузки неплохо было бы сделать мгновенный снимок (snapshot) средствами Hyper-V, если что-то пойдет не так, всегда сможем откатиться назад.

    Теперь устанавливаем заголовки ядра и инструменты разработчика

    # yum install kernel-devel
    # yum groupinstall "development tools"


    Скачиваем интеграционные сервисы для Hyper-V распаковываем их и подключаем ISO к гостевой CentOS.

    Собираем и устанавливаем модули ядра для синтетических устройств

    # mkdir /opt/linux_is
    # cp -R /media/CDROM/* /opt/linux_is
    # cd /opt/linux_is
    # make
    # make install


    Проверяем что модули загрузились с помощью команды

    # lsmod | grep vsc

    Centos_hyperv_integration_services

    Выключаем гостевую ОС с помощью poweroff. Удаляем из нее сетевой адаптер Legacy и добавляем синтетический адаптер. Запускаем ОС и настраиваем новый сетевой адаптер seth0.

    Centos_hyperv_synthetic_device_netwok

    Теперь можно провести тестирование скорости работы синтетического сетевого адаптера с помощью iperf.

    Centos_synthetic_network_speed

    Как видите скорость на сетевом интерфейсе seth0 в среднем составляет 492,5 Мбит/c. Довольно неплохой результат для виртуальной машины.

    К сожалению, выполнять загрузку гостевой ОС Hyper-V умеет только с IDE дисков поэтому рекомендуется на них располагать только раздел /boot. Для всех остальных разделов рекомендуется в качестве жестких дисков использовать SCSI диски. В этом случае мы сможем добиться гораздо более высокого быстродействия.

    Centos_scsi_disk

    Centos_scsi_disk_benchmark

    Если вам нужно сделать так чтобы, подключаясь через RDP к консоли Hyper-V вы могли управлять CentOS с помощью мыши в графическом режиме ставим драйвера синтетического устройства мыши.

    Скачиваем их со страницы проекта Citrix Satori, присоединяем ISO файл к виртуальной машине, копируем исходники и устанавливаем скомпилированный драйвер.

    # mkdir /opt/mouse_is
    # cp -R /media/CDROM/* /opt/mouse_is
    # cd /opt/mouse_is
    # ./setup.pl inputdriver


    На этом установку всех компонентов интеграции можно считать законченной.

    Давайте посмотрим, как CentOS чувствует себя в настоящих больших производственных средах. Для этого я дал ему те ресурсы, что были в наличии на тестовом сервере — 44 Гб ОЗУ и 4 процессора. К сожалению больше ресурсов у меня не было. Интересно было бы глянуть, как CentOS чувствует себя, если дать ему 2ТБ ОЗУ.

    Centos_45gb_memory_4_cpu Centos_45gb_memory_4_cpu_1

    Затем в течении нескольких дней с помощью скриптов запущенных в несколько потоков создавал командой dd файлы размером до 2ТБ и перекачивал их по ftp и scp на другой сервер. Каких либо проблем и сбоев не обнаружилось.

    Поэтому я делаю вывод, что CentOS может использоваться как виртуальная система под Hyper-V для проектов с довольно большой нагрузкой.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 57

      +1
      Сколько проблем. В www.proxmox.com/ можно то же самое сделать за 5 минут, просто выбрал тип виртуализации и нужный дистрибутив.
        –1
        Вы сравниваете холодное с мягким в данном случае, технологию виртуализации с ПО управления виртуальной инфраструктурой. Можно все необходимые действия автоматизировать при помощи тех же SCVMM+VMMSelfServicePortal. Да и никто не мешает сохранить проделанную работу (с уже интегрированными компонентами) как готовый шаблон и потом использовать его для новых машин.
          +1
          это все конечно понятно, но проще же вставить диск в привод, поставить proxmox, тыкнуть три раза и получить в том же OpenVZ контейнере CentOS или FreeBSD в KVM без траты времени :)
            0
            Эмммм… Запускаем SCVMM -> New VM from Template «CentOS with integrated components» -> Next -> Next -> идем курить пока образ из библиотеки деплоится. Разве много времени потрачено? Поймите, Андрей писал о том как подружить CentOS с Hyper-V, которая вообще говоря официально not supported. И не забываем еще что Hyper-V впринципе Microsoft-oriented. Поэтому у меня встречный вопрос — а proxmox на стадии развертывания машины с Windows сможет в ней автоматом без вмешательства задать пароль админа, вбить серийник, применить всю кастомизацию, и включить в домен, так чтобы когда я докурю — мог под своей доменной учетной записью заходить и работать?
              0
              Думаю да, если в Windows не отстает от современных инсталляторов вроде Anaconda или хотя бы поддерживает как FreeBSD install.cfg. Тут я вам точно не могу сказать, т.к. у нас нет возможности использовать Windows в highload.
          +1
          Проделать процедуру надо один раз а потом просто клонировать машину при необходимости.

          К сожалению с Proxmox работать не доводилось. Он умеет делать Live migration — переносить виртуальную систему без прерывания обслуживания и разрыва TCP соединений между физическими серверами?
            +1
            Online live migration на уровне OpenVZ и KVM поддерживается.
              +1
              А proxmox или что там управляет кластером умеет переносить виртуальные машины на другие физ. узлы автоматом если к примеру от системы мониторинга пришел сигнал о неминуемой аварии аппаратного обеспечения на текущем узле. Или к примеру если нагрузка на компоненты текущего узла превысила заданый предел?

              В обще есть ли аналог SCVMM PRO?
                +1
                не знаю, не сталкивался с данной задачей. Обратитесь к разработчикам Proxmox, думаю они смогут объяснить как это сделать.
              +1
              Ой, в таком ключе если дискутировать, можно вообще быстро запутаться.
              Hyper-V — аналог OpenVZ/KVM, технология виртуализации;
              Live Migration — аналог не знаю чего, но это уже компонент кластерной технологии;
              Proxmox это как я понял SCVMM в нашей MS-вселенной;
              Ну а PRO — это вообще надстройка над мониторингом, уверен что в *nix тоже есть пакеты которые мониторят что надо и могут отдавать команды кластеру в случае войны.
              То есть тут минимум 4 более-менее отдельных аспекта и сравнить это все в комплексе достаточно объективно будет сложно по-моему.
                +1
                Мне вот как раз и интересно насколько сложно сделать аналог связки Hyper-V+SCOM+SCVMM+SCDPM

                Скорее всего что то подобное должно быть и для OpenVZ и KVM.
                  +1
                  Я думаю всё есть, и построить примерно так же по сложности — концептуально технологии не должны сильно отличаться. Просто недостаточное знание «другой стороны силы» порождает отношение «как у вас все криво и сложно выглядит, вот у нааааас...» — а по сути все то же самое наверное, просто другая идеология и методы работы с продуктами.
                  –3
                  Hyper-V это аналог XEN, даже не аналог а перепиленная его инкарнация.
                  OpenVZ это сильно отличающаяся технология виртуализации, имеющая некоторые ограничения (ядро едино для ноды и гостей) но очень сильно сокращающая накладные расходы.
                  KVM это аналог VirtualPC.
                    +1
                    Вот это разрыв шаблона. :)

                    Предоставьте пожалуста факты о том что Hyper-V это одна из версий XEN.

                    А я то думал что это развитие технологий которые Virtual PC и Virtual Server которые Microsoft давным давно приобрела у компании Connectix.
                      –1
                      Ну факты не факты, но резонные подозрения есть —
                      «Картинка архитектуры Hyper-V очень похожа на картинку архитектуры Xen. Говорят, что они, собственно, взяли все части Xen, которые позволила лицензия, а остальные переписали. Прозвучала также фраза „Linux с поддержкой Hyper-V“ — это, собственно, Linux over Xen, то есть ядро, обученное тому, что снизу у него лежит не железо, а гипервизор Xen. То есть гипервизор Hyper-V отдаёт вверх такой же интерфейс, как и Xen. Наводит на мысли.»
                      k001.livejournal.com/676361.html
                      P.S. автор сего поста работает в Parallels над OpenVZ
                        +1
                        Архитектура всех гипервизорных систем включая Hyper-V, XEN и VMWare очень похожа. Разница лишь в том монолитный ли это гипервизор или микроядерный.

                        en.wikipedia.org/wiki/Hypervisor
                        virtualizationreview.com/blogs/everyday-virtualization/2009/06/type-1-and-type-2-hypervisors-explained.aspx
                        www.scribd.com/doc/30063295/Hyper-Visor-Type-Comparison

                        Как я уже писал Hyper-V это новая инкарнация Virtual Server. Технологии виртуализации из которых потом вырос Hyper-V были в 2003 году приобретены Microsoft в процессе поглощения компании Connectix. При этом стоит отметить что линейка продуктов виртуализации Connectix на тот момент была весьма продвинутой.

                        Превая бета версия XEN появилась в конце 2003 года. Это был даже не продукт а пока еще рабочий прототип.

                        Linux с поддержкой Hyper-V это стандартное ядро версии выше чем 2.6.32. В него просто добавлены компоненты драйверов отданные Microsoft сообществу под лицензией GPL.

                        Стоит отметить что этот код драйверов разрабатывался вместе с компанией Xenosource которую впоследствии приобрел Citrix.

                        Поэтому и неудивительно что интерфейс драйверов подходит и к Hyper-V и к XEN. Их изначально делали совместимыми с обеими системами. Microsoft объединилась со своим давним партнером Citrix дабы конкурировать с VMWare было проще.

                        Еще одно доказательство этого тот самый проект Citrix Satori о котором я писал в статье.

                        Так что рассказы про Hyper-V который XEN не состоятельны. :)
                          +1
                          Я нигде не нашел информации о том что Virtual Server является технологией паравиртуализации, зато есть инфорация о том, какое железо эмулирует Virtual Server, что говорит об обратном.

                          Так что Hyper-V и Virtual Server не могут быть родственными технологиями.

                          знакомимся с Virtual Server 2005
                          Паравиртуализация
                            0
                            Hyper-V тоже работает с некоторым оборудованием методом эмуляции. Например с сетевой картой Legacy и IDE дисками.

                            При этом ничто не мешает ему работать про технологии паравиртуализации.

                            Я ведь не сказал что Hyper-V прямой потомок Virtual Server. Я лишь утверждаю что многое из Virtual Server перекочевало в Hyper-V. :)
                              0
                              А на основании чего вы утверждаете:
                              «Я лишь утверждаю что многое из Virtual Server перекочевало в Hyper-V. :)»

                              Вы участвовали в разработке этого продукта, или исходники смотрели?

                              И хочется услышать больше конкретики — что общего у Hyper-V и Virtual Server кроме фирмы производителя, назначения и того что один продукт пришел на смену другому?
                                0
                                Я таки работаю в MS, имею доступ к внутренним источникам и вижу что происходит с продуктами на ранних стадиях. :)

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

                                  А мне, за не имением доступа к подобным сведениям, остаётся поверить вам на слово.
                                    –1
                                    Как закончу с описыванием запуска всех распространенных Linux/Unix под Hyper-V, наверно возьмусь за статью об эволюции наших продуктов виртуализации.
                        0
                        Вы правы только в том что Hyper-V является родственником XEN, потому как они — паравиртуализация.
                        OpenVZ как я понял — это технология изоляции пользовательских пространств над ядром. Получается что скажем тот же Windows мы на нем не запустим? Опыта общения с ней не было, если неправильно понял — поправьте меня.
                        А KVM вроде как технология полной виртуализации вообще, какой же это тогда VirtualPC, который без основной ОС жить не хочет?
                          0
                          Про Hyper-V ответил чуть выше.
                          А OpenVZ по сути это продвинутый chroot/jail повышающий удобство безопастность и контроль над ресурсами, да эта технология доступна только под Linux, да гостями могут быть только Linux машины и на гостях не удастся загружать дополнительные модули ядра. Но накладные расходы на такую виртуализацию составляют всего порядка 3%, что во многих случаях является очень важным аргументом.

                          Да и OpenVZ не запрещает использовать параллельно тот же KVM на той же железной ноде, для виртуализации того что не взлетит под OpenVZ.
                            0
                            Ну в таком случае аналог OpenVZ у Microsoft складывается из нескольких технологий — это Terminal Services плюс разделение контекстов выполнения для приложений, например SQL Server instances или те же Application Pools у служб IIS. То есть добиться того же эффекта можно, но комбинируя по кускам. И тут я согласен что в OpenVZ это видимо удобнее реализовано.
                              +1
                              Нет, ничего общего.
                              OpenVZ предоставляет полностью независимое окружение, со своим (произвольным) дистрибутивом на выбор, набором ПО и системных библиотек.
                              Которыми администратор контейнера может распоряжаться полностью по своему усмотрению (обновлять, устанавливать, удалять).
                              Так же нет никакой возможности узнать что происходит за пределами контейнера.
                              Все ограничения связаны только с ядром, всё остальное как в реальной системе.
                                0
                                Спасибо вам за разъяснение, немного не так представлял, теперь ясно.
                                  –1
                                  В общем OpenVZ очень похоже на Solaris Containers (Zones). Или на Virtuozo Windows Containers.
                                    0
                                    Да,
                                    Причем Virtuozo Windows Containers и OpenVZ являются продуктами компании Parallels.

                                    Правда признаюсь, что наличие решения под MS Windows я упустил из виду.
                    0
                    Не ради холивара, а из интереса: оно в сравнении с Xen как по производительности получается?
                      +1
                      К сожалению сравнений производительности с результатами которых согласились бы все стороны я не видел.

                      Мне кажется что Hyper-V лучше подходит для компаний в которых есть специалисты по Windows за счет интеграции с продуктами Microsoft и легкости в освоении для людей привычных к Windows.
                      0
                      Установка и настройка %НазваниеОС% под Hyper-V.
                        +1
                        Такой заголовок специально сделан для поисковиков. Это позволяет быстрее помочь людям которые ищут сведений по данной теме.
                          0
                          Для этого изобрели теги.
                            +1
                            Для поискового робота тег Title выставляемый в начале страницы из названия топика имеет гораздо больший вес чем абстрактные надписи на странице которые мы считаем тегами записи.

                            Посему писать название топика с оглядкой на поисковики выгоднее чем усердствовать с доморощеными тегами если конечно хочешь помочь людям быстро найти твою статью.
                              0
                              Или нафармить пэйдж ранк в поисковой системе :)
                                –1
                                Ну за игры с поисковым рейтингом и фармингом можно и бан получить. Да и смысла особого нет т.к денег я на этом все равно не зарабатываю. :)
                          +1
                          Недавно читал, что обмен данными между виртуалками на Hyper-V проходит не «внутри машины», а используя коммутатор, к которому подключена хост-машина. Якобы пакеты не могут роутиться внутри машины, и попадают на коммутатор, а потом опять в виртуалку. Сказано было, что это специфика Windows. Это правда? ;)
                            0
                            Это отчасти правда, только тут надо понимать что имеется ввиду виртуальный коммутатор, а не та физическая циска, к которой ваш сервер подключен. При установке роли Hyper-V ваш физический адаптер превращается волшебным образом в виртуальный коммутатор с единственным протоколом собственно самой этой коммутации. А в хосте появляется новый адаптер (по сути виртуальный), который подключен к этому самому виртуальному коммутатору (по сути физический адаптер — точка выхода во внешний мир из хоста). Далее все виртуальные адаптеры виртуальных машин общаются уже через этот виртуальный коммутатор.
                            Как видите, тут просто несколько сложная терминология. Так что ответ — правда, через коммутатор. Но он у вас внутри сервера и если общение только между хостом и его гостями — никуда пакеты дальше не побегут.
                              +1
                              Все зависит от того как вы подключили виртуальные машины друг к другу. Весь обмен идет через виртуальные коммутаторы. Их три типа:

                              External — связь с внешними системами через реалную сетевую карту
                              Internal — виртуальный коммутатор в ОЗУ для обмена данными между хостовой ОС и гостевыми машинами
                              Private — виртуальный коммутатор в ОЗУ для обмена данными только между гостевыми машинами

                              Подробнее написано тут itband.ru/2009/04/%D0%B2%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5-%D0%BC%D0%B0%D1%88%D0%B8%D0%BD%D1%8B-%D0%B8-%D1%81%D0%B5%D1%82%D0%B8/
                              +1
                              Интересно было бы глянуть, как CentOS чувствует себя, если дать ему 2ТБ ОЗУ.

                              Мне тоже интересно глянуть, как в Hyper-V можно дать виртуалке больше 64Гб. :-)
                                0
                                В новых прототипах Hyper-V гостевой можно дать гораздо больше ОЗУ чем в текущей версии и процессоров больше 4-х.

                                Коллега Кибкало в своем блоге публиковал скриншоты. :)

                              0
                              Самое главное не забыть про то, что после обновления ядра надо не сразу перезагружаться, а сначала собрать модули под новое ядро, иначе ребута не произойдёт скорее всего :) Т.е. всё вывалится в kernel panic.
                              Инструкция по таким манипуляциям — тут. Мне уже пришлось ею воспользоваться :)
                                0
                                Скоро и эта проблема уйдет в прошлое. В ядрах выше 2.6.32 уже встроены компоненты Hyper-V их не нужно ставить отдельно.

                                А пока что можно чинить вот так
                                www.devplace.nl/.../updating-hyper-v-drivers-after-kernel-upgrade-on-centos

                                Уже сейчас SLES 11 SP1 и Ubuntu 10.10 работают под Hyper-V с синтетическими устройствами на стандартном ядре сразу после установки. Обновления ядер им не страшны.
                                  0
                                  Ссылка поломалась, а хотелось бы глянуть, может есть проще способ, чем я нашёл.
                                  А ubuntu надо потестить — как раз хотел себе поднять такую виртуалку.
                                    0
                                    www.devplace.nl/blog/updating-hyper-v-drivers-after-kernel-upgrade-on-centos

                                    На странице куда ведет ссылка справа надпись «Updating Hyper-V drivers after a kernel upgrade on CentOS» кликнете в нее.

                                    Не знаю почему ссылка так стала работать. :(
                                      0
                                      А, глянул, тоже самое, что я делал :) Проще никак. С другой стороны, и так всё просто :)
                                        0
                                        В сети натыкался на инструкцию с применением ksplice для обновления ядра CentOS. К сожалению ссылку потерял.
                                    0
                                    А драйвер для мышки в них тоже встроили?
                                      0
                                      Драйвер мыши пока в подвешеном статусе он вроде GPL но не ясно когда его в ядро добавят.
                                  +1
                                  чтобы время не «убегало» в гостевой CentOS в /boot/grub/grub.conf добавляю divider=10 notsc в строку kernel
                                    0
                                    Рекомендуумый официально способ синхронизации времени гостевой Linux системы — установка пакета adjtimex.

                                    Забыл об этом написать. :(
                                      0
                                      но этот способ не работает, увы.
                                    –1
                                    Благодаря коллегам нашлась ссылка про обновление ядра и не отваливающиеся драйвера

                                    support.microsoft.com/kb/2387594/en-us

                                    Only users with full accounts can post comments. Log in, please.