22 июня 2010 в 11:56

Hyper-V и сети

Это будет, наверное, заключительная статья из серии, посвященной архитектуре Hyper-V. На одном форуме мне посоветовали написать продолжение – «Hyper-V и невидимая виртуалка», «Hyper-V и Орден Линукса», я обязательно об этом подумаю, и возможно даже – напишу.

Итак, в этой статье речь пойдет о том, как виртуальные машины в среде Hyper-V работают с сетевыми интерфейсами. Как я уже говорил в предыдущих статьях – сетевые интерфейсы – это единственный способ взаимодействия виртуальных машин как между собой, так и со «внешним миром». Поэтому понимать особенности сетевого взаимодействия в среде Hyper-V необходимо.

Сетевые адаптеры


Как можно увидеть в Hyper-V Manager, есть два типа виртуальных сетевых адаптеров: Network Adapter и Legacy Network Adapter. Отличаются между собой они тем, что первый из них является синтетическим устройством, а второй – эмулируемым. Чем отличаются синтетические устройства от эмулируемых – можно почитать в первой статье, «Архитектура Hyper-V». Если кому-то это будет интересно – Legacy Network Adapter эмулирует многопортовую сетевую карту DEC 21140 10/100TX 100 MB (и поэтому поддерживает только 10/100Мбит/с) и не поддерживается ОС Windows XP и Windows Server 2003 в 64-битной версии.
Думается, не стоит объяснять, что использование синтетических устройств всегда предпочтительнее, и именно поэтому при создании новой виртуальной машины по умолчанию добавляется именно Network Adapter. Использовать Legacy Network Adapter рекомендуется только в двух случаях:
  • Когда гостевая ОС не поддерживает установку компонент интеграции;
  • Когда необходим доступ к сети до загрузки ОС, к примеру – загрузка по PXE для установки ОС с сервера WDS.

Для этого при создании виртуальной машины необходимо убрать галочку «Start virtual machine automatically», а затем, зайдя в конфигурацию виртуальной машины, вручную удалить Network Adapter и добавить Legacy Network Adapter.
Стоит еще упомянуть о назначении MAC-адресов виртуальным адаптерам. Он может назначаться как автоматически при создании виртуальной машины (причем диапазон выдачи MAC-адресов можно изменять в настройках сервера Hyper-V), либо же вручную через конфигурацию виртуальной машины.

Виртуальные сети


Разумеется, если есть сетевые адаптеры – они должны куда-то подключаться. И для этого в Hyper-V существуют виртуальные сети (Virtual Networks), которые по сути представляют собой самые обычные виртуальные коммутаторы. К каждому виртуальному коммутатору могут присоединяться как сетевые интерфейсы виртуальных машин, так и физические сетевые интерфейсы сервера. Виртуальные сети бывают трех типов, и чтобы проще было их понять – взглянем на схему.

У нашего сервера имеется два сетевых интерфейса. Когда хостовая ОС только что была установлена, и интерфейсы сконфигурированы – к каждому из них привзяывается протокол TCP/IP, некоторые другие протоколы и соответственно – назначаются сетевые настройки (IP-адрес, маска подсети, адреса шлюзов и DNS) – статически или динамически, в данном случае – не суть важно.

Виртуальные сети (то есть виртуальные коммутаторы) бывают трех типов: External, Internal и Private. External – виртуальная сеть, имеющая выход «во внешний мир». При создании сети типа External необходимо указать сетевой интерфейс, через который будет осуществляться выход наружу (Физический адаптер 2). При этом физический интерфейс теряет все сетевые настройки, и создается виртуальный адаптер в хостовой ОС (Виртуальный адаптер 1), к которому привязываются все необходимые протоколы и настройки. Физический же интерфейс остается всего с одним протоколом: Virtual Network Switching Protocol. Кроме этого, в Windows Server 2008 R2 появилась возможность создавать сети типа External, но при этом все равно изолировать их от хостовой ОС. Делается это снятием галочки «Allow management operating system to share this network adapter»:

ATTENTION: При создании виртуальной сети типа External происходит кратковременный разрыв сетевого соединения, и все настройки переносятся на новый, виртуальный адаптер. Об этом необходимо помнить во-первых, если настройка осуществляется удаленно – соединение может прерваться, и во-вторых – возможно придется заново настраивать Windows Firewall, чтобы привязать правила к новому виртуальному интерфейсу.
Internal – внутренняя виртуальная сеть, к которой могут подключаться только виртуальные интерфейсы – виртуальных машин и хостовой ОС. К физическому интерфейсу сеть типа Internal не привязывается, и, соответственно, выхода «вовне» не имеет.
Private – то же самое, что и Internal, за исключением того, что к такой сети могут подключаться только виртуальные машины. Сеть типа Private не имеет доступа ни ко «внешнему миру», ни к хостовой ОС.
Для лучшего понимания – нарисую таблицу, в которой будет указано, какие интерфейсы будут подключены к виртуальному коммутатору, а какие – нет при разных настройках:


Работа с VLAN


Hyper-V поддерживает работу с VLAN (IEEE 802.1Q). Для этого в свойствах виртуальных сетевых интерфейсов имеется галочка «Enable VLAN Identification», после активации которой можно ввести VLAN ID. Предварительно, разумеется, необходимо настроить коммутаторы, чтобы трафик тегировался соответствующими ID, и, разумеется, установить в хостовой ОС драйверы сетевого адаптера с поддержкой необходимых функций.

Более подробно о настройке виртуальных машин для работы с VLAN можно почитать в статье Дмитрия Макарова.

VMQ


Не могу закончить статью, не упомянув о новой фиче, появившейся в Windows Server 2008 R2 – поддержке виртуальных очередей, VMQ.
Поддержка VMQ позволяет перенести большую часть затрат на обработку сетевых пакетов, адресованных виртуальным машинам с хостовой ОС на плечи процессора сетевого адаптера. Разумеется, при условии, что сетевой адаптер это поддерживает, и в гостевых ОС установлены компоненты интеграции.
Если не используется VMQ, то обработка сетевых пакетов происходит следующим образом:

Распределением трафика по виртуальным машинам и фильтрацией по тегам VLAN при этом занимается виртуальный коммутатор, действующий в пространстве родительской ОС. При большом количестве виртуальных машин и при больших объемах трафика это может привести к некоторому снижению производительности, так как у процессора сервера есть и другие задачи, помимо обработки сетевых пакетов. Использование VMQ позволяет переложить обработку пакетов на плечи процессора сетевого адаптера:

Сетевой адаптер, поддерживающий VMQ, способен самостоятельно осуществлять необходимую обработку сетевых пакетов, а затем записать данные непосредственно в область памяти соответствующей виртуальной машины.
Передача же данных, что с VMQ, что без оной – идет как и обычно: Виртуальный сетевой адаптер – VMBus – Виртуальный коммутатор – Физический сетевой адаптер.

Вместо заключения


На этом хотелось бы закончить статью, и заодно – рассказ об архитектуре Hyper-V. В заключение – хотелось бы спросить: у меня есть желание написать статью о Live Migration. Будет ли это интересно аудитории, или же все об этом слышали и все об этом знают?
Александр Косивченко @System32
карма
–126,0
рейтинг 0,0
Похожие публикации
Самое читаемое Администрирование

Комментарии (79)

  • +18
    есть заглавная каринка с большим разрешением? хочется рассмотреть этот аццкий ад поближе
    • 0
      google «nag.ru ужас»
      Раньше на nag.ru был целый раздел «ужасы», где публиковали фотки подобного ада, а теперь nag стал унылым техническим провайдерским ресурсом, так что только гуглить.
      • НЛО прилетело и опубликовало эту надпись здесь
        • –1
          Технет изначально был узкоспециализированным именно техническим ресурсом. А наг превратился в то же самое, во что превратится sysadmins.ru без хумора и курилки ;)
          • НЛО прилетело и опубликовало эту надпись здесь
            • –1
              Ну да, можно и так сказать. То есть из полутехнического-полуразвлекательного ресурса он превратился в чисто-технический.
              • НЛО прилетело и опубликовало эту надпись здесь
                • –1
                  Ну да, не с чего поржать теперь :)
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • +1
                      На фишках юмор по большей части не-айтишный.
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • 0
                          Белко, ну это уже придирки, ей-богу :) Думаю, оффтоп пора заканчивать ;)
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • –5
                              Та зашибись — вон, видишь, евангелирую тут потихоньку)
                              • НЛО прилетело и опубликовало эту надпись здесь
                                • –7
                                  Да уже более-менее без трости хожу, но на улицу без нее пока ссыкотно выходить.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • –5
                                      Every user lies ;)
    • +5
  • 0
    На этом хотелось бы закончить статью, и заодно – рассказ об архитектуре Hyper-V. В заключение – хотелось бы спросить: у меня есть желание написать статью о Live Migration. Будет ли это интересно аудитории, или же все об этом слышали и все об этом знают?

    Давно мечтал, чтобы кто-нибудь написал простенькую статью про пошаговую настройку PRO Tips с Management Pack'ами, которые могли бы как-нибудь экзотически ВМ'ку перезагружать, например, если служба какая-нить внутри ВМ зависала. Нэ? :-)
    • –2
      Дык в PRO задействуются и SCOM и VMM, да еще и про кластеры и live migration рассказывать… «Простенькой» статья никак не получится, потянет на уровень «300» по майкрософтовской шкале. Вопрос только, многим ли тут будут интересны такие статьи — ведь это не обзор нового айпада или андроида…
      • +1
        Добавьте побольше «интриг, скандалов, расследований», напишите что-нибудь вроде: «PRO Tips предоставляет больший функционал, чем VMware DRS и DPM.» и люди к вам «потянутся». «:-)»
        • –2
          Это уж точно — один Антон чего стоит ;)
      • –1
        А если на ITBand публиковать?
        • –1
          Как вариант — можно и там :) А здесь — топик-ссылку.
  • +2
    Как там у Hyper-V с множественными аплинками на виртуальном коммутаторе, с политиками active/standby для разных виртуальных сетей?
    • +2
      Антон, вы знаете, о чем спрашивать. Туше.
    • –3
      Да собственно никак — к виртуальному коммутатору можно присоединить только один физический адаптер.
      Посмотрим, что придумают в следующей версии — Live Migration же придумали, «по просьбам трудящихся».
      • +4
        Перед этим очень долго рассказывали, что Live Migration почти никому не нужно.
        • –4
          Ну собственно он и правда очень мало кому нужен… Очень хорошая и полезная фича, но заказчиков, реально в ней нуждающихся — не так много.
          • +6
            И именно поэтому MS так ее рекламирует как технологический прорыв и суперфичу.
            • –2
              Маркетинг, фигли. Поэтому же и VMware со своим Memory Overcommit носится как с писаной торбой.
              • +2
                Я похож на сотрудника отдела маркетинга VMware?

                Вот мои реальные цифры: blog.vadmin.ru/2010/02/transparent-page-sharing.html

                Кроме того, Dynamic Memory в Hyper-V R2 SP1 и есть Memory Overcommit: blog.vadmin.ru/2010/06/hyper-v-r2-sp1-dynamic-memory.html
                • –2
                  Я похож на сотрудника отдела маркетинга VMware?
                  Не больше, чем я — на сотрудника отдела маркетинга Microsoft :)

                  TPS очень хорошо работает, когда используются 4-килобайтные страницы памяти, с большими страницами оно уже почти не работает.

                  Кроме того, Dynamic Memory в Hyper-V R2 SP1 и есть Memory Overcommit:
                  Вообще вопрос спорный, и на эту тему можно даже отдельный топик написать :)
                  • +1
                    В memory bound среде разница в производительности процессора с 4к и 2М страницами будет практически незаметна, а вот «дополнительная» память очень нужна. К слову, TPS можно отключить. Или включить, но у VMware эта технология есть и бесплатно, даже в Free ESXi. И плюс нормальный, уже годами отшлифованный balloon.

                    • –3
                      При нынешних ценах на память — мне думается, что лучше заранее закупить памяти с запасом, чем рассчитывать на overcommit.
                      К тому же некоторые ОС, такие, к примеру, как Windows 7 стараются занять всю имеющуюся память — под кэш и superfetch. И тут TPS опять не рулит.
                      • +3
                        При каких нынешних ценах на память? Открываю HP Product Bulletin, смотрю текущие цены на память для своих блейдов.

                        HP 8GB 2Rx4 PC3-10600R-9 Kit — 509$
                        HP 8GB 2Rx4 PC3L-10600R-9 Kit — 609$
                        HP 16GB PC3-8500R-7 4Rx4 Kit — 1549$

                        Предположим, 12 модулей по 8 ГБ (три канала по два модуля, два процессора) — это 96ГБ, 6100$ или 7300$. При скромном и консервативном коэффициенте оверкоммита 1.2 «дополнительная» память стоила бы 1220-1450$.
                        Далее я открываю один из своих продуктивных ESX — 42 GB Granted, 30 Consumed. Итого оверкоммит уже 1,4 при нулевом свопе и нулевом балунинге. Соответственно, сохраняя коэффициент получаем, что экономия уже 2500-3000$. На хосте 27 виртуальных машин, средняя загрузка процессоров (2 * Xeon 5570) составляет 15%.

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

                        16 GB FBD PC2-5300 2 x 8 GB Dual Rank Kit — 2069$
                        16 GB FBD PC2-5300 (2 x 8 GB) Kit — 2069$

                        Смотрим дальше. У меня есть отличные, очень мощные BL460c G1 с некогда топовыми Xeon 5365, но у них минус — мало слотов под память, всего 8. К сожалению, 8ГБ модулей с 5365 может быть всего 6 из-за тепловыделения процессоров, аж по 120 Вт. Итого я ограничен даже не финансово, а физически, я просто не могу добавить памяти. Т.е. без memory overcommit и TPS нужно было бы купить новую железку, и добавить на нее лицензий на все, а не только на vSphere. 48 GB физической памяти превращаются в 56-64 GB, смотря с каким коэффициентом ужмутся машины.

                        Кстати, забавный расчет я на этом основывал, и даже графики построил: blog.vadmin.ru/2009/12/hyper-v-vsphere.html
                        • –1
                          12 слотов 4 гиговым планками по пару сотен $ за штуку, и получаем 48ГБ на сервер. или ставим блейд с 18 слотами, как рекомендует вендор под виртуализацию.
                          много у вас двухпроцовых серверов с 48+ оперативки?
                          • 0
                            Весь продуктивный кластер с 64ГБ и судя по всему будет позже добиваться памятью. Поскольку для целей HA 5 хостов вполне достаточно, а загрузка процессоров низкая.

                            Дешевые мелкие модули памяти имеют реальный смысл только в CPU bound среде.
                  • 0
                    TPS очень хорошо работает, когда используются 4-килобайтные страницы памяти, с большими страницами оно уже почти не работает.

                    Как сказать. Какие области памяти чаще всего шарятся? Пустые. Которые вроде как выделены виртуалке, но реально не используются. И таких областей будет достаточно хоть с 4КБ, хоть с 2МБ страницами.

                    Шарить непустые страницы — тоже та еще задача, даже с размером каждой в 4КБ.
                    • –1
                      Это да. Но во-первых есть такая штука, как ASLR, которая немного мешает шарингу страниц, а во-вторых некоторые ОС сейчас пытаются утилизировать всю доступную память полностью.
                      • 0
                        ASLR мешает не так сильно, как оказывается. Цифры, которые я привел чуть выше, на смешанной инфраструктуре, в которой достаточная доля машин с 2008 R2 и 7.
        • –3
          Антон, вы пишете этот коммент к каждой статье о фичах, реализуемых в Hyper-V. Не надоело? =)
          • +3
            Андрей, надоело, но еще более надоело, что MS беззастенчиво вешать лапшу на уши. А затем делает резкий разворот и вешает лапшу на уши уже ровно в обратном направлении.
            • –1
              Ну обычно спрос порождает предложение. И вполне нормально, что компании подстраиваются под потребности рынка.
              Было бы хуже, если бы участники рынка не могли менять свое мнение… примером может служить известный мем — lurkmore.ru/640_килобайт
          • –4
            Что интересней всего — в этой статье я ни разу не упомянул VMware. Но тем не менее, Антон не дремлет :))
      • 0
        Настройки безопасности есть для сетей? QoS?
        • 0
          Есть Windows Firewall в хостовой ОС, и на уровне гостевых ОС. В большинстве случаев этого должно хватить.
          • +1
            Хорошо, вопрос поставлю по-другому. Есть аналоги функций безопасности сети ESX:
            1) Forged Transmits — защита от подмены виртуалкой своего MAC
            2) MAC address changes — смена MAC соотв.
            3) Promiscuous mode — зеркалирование трафика всего коммутатора на эту виртуальную сеть

            Есть сетевой QoS?
            • –1
              1) и 2) — есть в R2. 3) — ЕМНИП нет.
  • +1
    1. есть ли проброс влан внутрь виртуалки без разбора на уровне всвитча?

    2. всвитчи глобальные есть или надо на каждом из десятков хостов вручную создавать одинаковые конфигурации?

    3. список сетевух для виртуалок смешной. в вмвари вариантов шесть, есть и совсем старые pcnet32 и известные почти везде e1000.
    • 0
      к первому вопрос в vlan еще дополнение:
      vlan настраивается только на адаптере самой VM? или его можно все таки настроить на виртуальных коммутаторах? куда в последствии будут подключаться VM.
      • –1
        VLAN — на виртуальных сетевухах и можно на сетевухах сервера, если они поддерживают VLAN.
        • 0
          я ничего не понял из вашего ответа.
          и нет ответа на вопросы выше.
          можно как-то подробнее?
          • –1
            1. Проброс VLAN внутрь — ну по идее можно завести транк прямо в всвитч, а уже на сетевках виртуалок прописать необходимые ID. Сам всвитч в hyper-v — вещь практически абсолюно ненастраиваемая.
            2. Увы и ах, создавать вручную. Но если хостов очень много — есть SCVMM и Power Shell.
            3. Дык Hyper-V и не заявляет поддержку кучи операционок — официально поддерживаются только винды и два линукса, а остальное — на свой страх и риск.
            • +2
              > Проброс VLAN внутрь — ну по идее можно завести транк прямо в всвитч, а уже на сетевках виртуалок прописать необходимые ID.

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

              > Увы и ах, создавать вручную. Но если хостов очень много — есть SCVMM и Power Shell.

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

              > Дык Hyper-V и не заявляет поддержку кучи операционок

              так это вполне себе сейчас заметный минус при выборе в.платформы.

              PS просто первая статья начиналась в виде сравнения вмварь-гиперв, а остальные просто про гиперв. непонятно. надо уж или тогда сравнивать везде и говорить факты типа «тут вообще нет, а тут есть но дорого». или просто говорить только про гиперв без сравнений.
              по этому тот же антон так яростно вмварь и противопоставляет.
              • –2
                нет, мне надо что бы транк вланов с физ.сетевухи проходил сквось всвичт и попадал на вирт.сетевуху так же транком.

                По идее, если транк с вланами завести в всвитч, а на сетевых у виртуалок прописать vlan id — они сами разберут тегированный трафик.

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


                так это вполне себе сейчас заметный минус при выборе в.платформы.

                На самом деле нужно стремиться к максимально однородной сети, если в сети зоопарк операционок — это скорее плохо. Ну разве что в исключительных случаях — всякие RISC-овые сервера с AIX, Sun'ы с соляркой, и т.д. А так надо стремиться к единой платформе, и Microsoft вполне себе справляется с ролью таковой.

                PS просто первая статья начиналась в виде сравнения вмварь-гиперв, а остальные просто про гиперв. непонятно. надо уж или тогда сравнивать везде и говорить факты типа «тут вообще нет, а тут есть но дорого». или просто говорить только про гиперв без сравнений.

                Да, здесь я решил не сравнивать вообще — каюсь, из-за недостатка опыта с VMware. Я уже пожалел о том, что попытался сравнить вначале.

                по этому тот же антон так яростно вмварь и противопоставляет

                Антон — классический тролль, что впрочем, ничуть не мешает ему быть профессионалом, и ничуть не мешает мне его уважать. Он просто вбрасывает навоз на вентилятор и все. И надо сказать, у него неплохо получается ;)
                • +2
                  > По идее, если транк с вланами завести в всвитч, а на сетевых у виртуалок прописать vlan id

                  прописать несколько vlanid можно? иначе это получается вывод нетегированного трафика в в.сетевуху.

                  > — они сами разберут тегированный трафик.

                  вот в этом и был вопрос.

                  > SCVMM — ни разу не уныло.

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

                  > На самом деле нужно стремиться к максимально однородной сети,

                  нет-нет-нет. это маркетинговый бред, что бы посадить фирму на одного поставщика, даже если часть решений неудобна, монстрообразна, или наоборот еще недостаточно функциональна. в этой фразе нет ничего от здравого смысла, только пространные рассуждения о «низкой стоимости владения и подержки». любой адекватный инженер/админ должен сам оценивать разумность использования средств, и не быть искусственно ограничен одним производителем.

                  > если в сети зоопарк операционок — это скорее плохо.

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

                  >Да, здесь я решил не сравнивать вообще — каюсь, из-за недостатка опыта с VMware. Я уже пожалел о том, что попытался сравнить вначале.

                  может теперь все же сделать сравнение? информации по гипрев уже достаточно. esx/vsphere поставить и изучить не сложно.

                  > Антон — классический тролль,

                  да ладно, все его набросы вполне по делу, ничего трольного там нет.
        • 0
          То есть я правильно понял: если мне нужно вынимать из транка несколько разных vlan, то я это буду делать исключительно на каждой VM, а не на виртуальном коммутаторе?
          • –1
            Как вариант — можно настроить VLAN на «железных» сетевухах, а к ним уже подключить всвитчи. В итоге на каждый влан свой всвитч. Собственно, я в статье дал ссылку — там один товарисч очень подробно рассказывает, как он работал с вланами.
            • 0
              почитал статью… мягко говоря — кошмар.
              на паре-тройке серверов это еще можно сделать… на целом блейдцентре (14 лезвий) — это превратится в пытку. а если нужно вынуть еще один VLAN, то еще десяток действий.

              короче работу с сеткой в Hyper-V пилить и пилить еще. хотя бы удобство работы с ней.
              • 0
                SCVMM вам в помощь — там все можно сделать быстро и автоматизированно. Вы наверняка и если vmware будете туда ставить — то поставите и vcenter?
  • 0
    У меня не совсем про сети вопрос, но про Hyper-V :) Может быть знаете, есть ли какой-нибудь простой management soft для hyper-v, чтобы можно было объединять машины в группы, работать сразу с группой (старт/стоп/снапшоты) и т.п. в целях разработки/тестирования софта — по типу как у VmWare Workstation сделаны Teams. А то Hyper-V MMC console слишком простая, а SCVMM — overhead уже для маленькой компании :)
    • –1
      Если Вы — разработчик, то для Вас самым удобным инструментом будет Power Shell — бо на ней даже GUI нарисовать можно ;)
  • –1
    > сетевые интерфейсы – это единственный способ взаимодействия виртуальных машин как между собой, так и со «внешним миром»

    Как, а прослойка «homo sapiens» забыта? :) Медленный транспорт данных, но зато универсальный.
    • –1
      О, а слона я и не заметил))
  • –1
    Симпатичные графики. Ждем SP1 и динамическую память…
  • 0
    конечно продолжайте
  • 0
    Добрый день, пока титаны бьются, можено нуб задаст простенький вопрос знатокам?
    А как у всех платформ с прерываниями? У Xen, у Vmware и Hyper V?
    Вот у меня задача виртуализировать телефонию, там загвоздка, модуль конференций полюбляет таймер, в конференции в должно быть синхронизированно.
    Какие успехи на этом фронте? (Я пользуюсь астериском Linux и Ко)
    • 0
      Есть инфа, что Cisco Call Manager в наше время — это обычная виртуалка, которая вполне справляется со всякими конференциями, видеозвонками и прочей радостью.

      Вопрос основан на опыте, или чистая синтетика?
      • 0
        У циски свой водоём, я с ними не плавал. Для астериска есть пару сторонних модулей которые не требуют тайминга, это просто супер. Но мой производитель пока не интегрировал их для успешной виртуализации. А опыт он есть, пускаешь нарудо в конференцию в виртуалке, и слив.
        Я ещё чего хотел спросить. А вот если я засуну в сервер 5 карт, а можно каждой виртуалке дать доступ напрямую в одну?
        • 0
          напрямую давать доступ к железу в виртуалках это моветон. что будет когда вмашина мигрирует с одного физ. сервера на другой? что будет, когда физ. сервер, на котором стоит уникальная железка будет выключен для экономии энергии, перезагружен или упадет?
          виртуалки будут работать как и работали.
          по этому смысла делать виртуалку с пробросом какого-либо железа внутрь не очень много.
        • 0
          >а можно каждой виртуалке дать доступ напрямую в одну?

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

          Можно и напрямую пробросить, если процессор новый и поддерживает Intel VT-d, но в этом случае до свидания бэкапы, снапшоты и миграция.
    • –1
      Попробуйте Microsoft OCS ;)
      Потому как софт, любящий железо, прерывания и недокументированные функции — это даже не прошлый век, это палеолит времен DOS'а и Intel 80286.
      • 0
        Для OCS 2007 R2 в виртуальной среде поддерживается крайне ограниченное число ролей. Никаких аудио-, видео- и конференций, если хочется поддержки MS.
        • –1
          Это при том, как MS люто, бешено продвигают виртуализацию, особенно — свою собственную? Странно.
          • 0
            FYI.
            • –1
              Странно. Интересно, почему? Вон у циски с виртуализацией все ОК…
      • +1
        Решние от микрософта не подходят из за нескольких причин.
        1: Мы ставим севера для центров дозвона, там уже есть отчётность и разносторонний софт.
        2: Попробовал как от я раз их решение, оно, ну очень плохое по сравнению с астериском.

        Да телефония это каменный век, вливайтесь.

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