Простите, я не очень понял требования.
Есть ВМ на узле с ПО IP телефонии (без устройств)
Есть вторая виртуальная машина для мониторинга.
Миррорить трафик с одной ВМ на другую ВМ, подключенную к тому же виртуальному свичу можно.
Поясните, где я вас недопонял? И что именно не заработало.
Теперь о лицензировании. Лицензия Datacenter (равно как и Standard) позволяет использовать экземпляры 2012 и более старые. Вопросы активации за вами. Для 2008/R2 есть KMS, — ваш KMS (2003, 2008, 2012) сможет активировать любые ОС — был бы нужный ключ. Если у вас нет KMS, а нужно иметь 2008 в ВМ, или нужно активировать 2003, вам требуется обращаться в центр активации Microsoft, дать им подтверждение о покупке, они дадут ключи. Дистрибутивы это ваша ответственность. Их можно приобрести отдельно (Disk Kit) или взять с TechNet/MSDN/rutracker :)
По клиентским ОС все просто. То устройство, с которого вы обращаетесь к виртуальной машине с клиентской ОС *должно* иметь действующую Software Assurance (для Windows устройств) или лицензию VDA (для не Windows). Активация — через KMS. Права downgrade, смены языка и архитектуры у вас есть в рамках SA.
Размещать машину можно и на бесплатном гипервизоре.
Чтобы работал RemoteFX (любой) требуется доставить роль Remote Desktop Virtualization Host (есть и на бесплатном).
Как только вы начинаете пользоваться RemoteFX внутри ВМ, вы потребляете RDS CAL.
Вне виртуальных машин Hyper-V технология RemoteFX не работает.
А этих курсов и нет нигде кроме «Звёзд и С». Они не предполагались на публику вообще, но раз уж я участвовал в подготовке, мне дали право их проведения.
Я уже 5 или 6 раз прочитал Виртуализацию, и по 3-4 раза остальное в УЦ «Звезды и С» — и порядка 60% заказчиков приходили сами, а не со стороны Microsoft.
Уже сейчас, записавшись на курсы в июне, вы получите информацию по новому в R2 — на основе предварительной версии. Если будет публичная бета, то будут и лабораторные. Если нет, то только обсуждение и демо.
Да. Для перенаправления USB технология RemoteFX будет работать с RDP 7.0+ клиента на Win7 SP1 ENT/ULT
А вот для работы синтетического видео требуется уже внутри ВМ ОС Win8/2012
На данный момент внутри Microsoft все разговоры о следующей ОС под очень жестким контролем. Весной 2012 была публичная бета сервера. Тогда и были внутренние курсы. Сейчас нет никаких официальных признаний того, что серверная ОС хоть как-нибудь будет обновлена.
Я планирую в треке в июне уже рассказывать о новых возможностях — по виртуализации и кластерам. Если мы будем проводить подобные треки и в будущем, то наверное будут и новые лабораторные.
Microsoft никогда не отдает учебников по новым версиям продуктов бесплатно тем, кто покупал старые. Но очевидно, что если будут массовые изменения, будут новые курсы, будут новые учебники.
Вебкаст «что нового» я проведу сразу после публичной беты.
Сама шина USB последовательна (serial bus), что означает техническую невозможность разделения портов на одной шине. Ни одно решение не сможет дать порт A для ВМ1 и порт B для ВМ2. Можно отдать лишь всю шину, — одной ВМ (дорого) или нескольким (опасно, ибо это канал между ними в обход TCP/IP). Ни один вендор серверной виртуализации не рискует дать одну шину нескольким ВМ сразу.
Другие решения делают это следующим образом: у X* это реализовано редиректором с клиента на сервер, подобно RemoteFX от Microsoft, но более изящно. V* имеет экспериментальную (читай как неподдерживаемую) возможность отдать всю PCI шину с USB концентратором и всеми портами одной ВМ. При этом пропадает *motion и куча других фишек.
Все вендоры сходятся на том. что лучше закупать 1U многопортовое устройство и отдавать порты по TCP/IP. Я обычно говорю об AnywhereUSB. Есть и софтовые варианты, в том числе под Windows.
Наврядли вы станете использовать USB порты самого хоста (иначе нет миграции ВМ)…
Примерно так.
Для начала напомню теорию: дедупликация работает лишь для выключенных машин. И в релизе 2012 ее нельзя включить на общем томе CSV.
То есть ваш вопрос не о кластерах.
Риск заключается в том, что при высоком уровне дедупликации, сделанной, например в то время, пока машины были выключены, при их включении она не будет дедуплицировать одинаковые блоки, резко закончится место на томе, и все машины будут paused-critical.
Это риск? Безусловно. Практический и срабатывающий, — да.
Через полтора-два месяца я сделаю отдельный вебкаст по дедупликации в 2012R2, там все веселее.
Пока об этом не могу писать публично.
Согласно последнему отчету IDC Virtualization Tracker, количество виртуальных машин, созданных на Hyper-V за последние полгода превысило результаты любых других вендоров, а согласно Gartner, еще без учета SC2012 и WS2012 он находится в лидируещем сегменте. Нельзя говорить о только-только догонящих, особенно в разрезе абстрактных конкурентов.
Про старые гипервизоры речь шла о всем том, что не поддерживает VMGenerationID (например Hyper-V R2 :) ) и всех сторонних гипервизорах, на которых не поддерживается современная ОС Windows Server 2012 (на Hyper-V R2, безусловно поддерживается).
Список поддерживаемых гипервизоров и их версий можно посмотреть на странице каталога: windowsservercatalog.com/results.aspx?&bCatID=1521&cpID=0&avc=0&ava=0&avq=0&OR=1&PGS=100
Если вашего гипервизора там нет, это его проблемы, он не годен для виртуализации WS2012 вообще, не говоря уже о контроллерах домена. Большинство сторонних решений там присутствует. О наличии в них VMGenerationID следует обращаться к вендорам. API открыт уже около года.
Безусловно, слайд условный, — упрощен до предела для облегчения понимания процесса.
Хотя фактически invocationID контроллера это атрибут, содержащий текущий GID, практически это некий «friendly name» используемый для определения версии состоянии базы на контроллере в процессе репликации. Изображать на слайде ситуацию с многоэтажными GUIDами было бы менее интуитивно, — громоздко.
Равно и с конкретными номерами RID/USN — слайд рассказывает архитектуру работы, а не пример из реальной жизни, его цель наглядно показать сложный процесс простым примером. А детально это следует разбирать уже на стадии более глубокого понимания работы архитектуры AD и механизма репликации.
Если есть вопросы по тому, как это работает, готов на ваших примерах более детально рассказать не упрощая картинки.
Есть ли эта схема на русском или английском?
Как стёб — пять баллов в плюс, а вот информативность её на китайском для большинства нас хромает.
Поможите?
Попробую рассказать о причинах, побудивших меня объединить темы.
Описывая технологии терминального доступа и VDI мне хотелось показать, как «правильно» их планировать.
Microsoft RDSH без APP-V довольно неуклюж. Даже в сценарии SMB, если вам требуется иметь десяток приложений, среди них наверняка найдется капризное, которому нужен старый Office. И наверняка вам на терминальных серверах для работы веб-браузера и ряда приложений потребуются ночные кошмары администратора за именем Flash и Java (ну и Silverlight, если уж откровенно). Обновлять терминальные серверы каждые две недели, перезагружать из-за очередной дыры Flash — увольте. А количество версий великой кросплатформенной Джаббы? Которые несовместимы. И ваше верхнеуровневое приложение №1 хочет Java 5.0, новое приложение №2 хочет Java 7.0, а старое №3 хочет Java 3.0… Как вы это решаете сейчас (хинт, две Java установить полноценно на одну ОС нельзя)? Ставите несколько виртуалок с терминалами.
Для SMB хороший вариант иметь один золотой образ чистой ОС, и 3-4 дочерних диска с одинаковыми конфигурациями — вообще без приложений. Весь софт через APP-V, размещение софта на шаре APP-V сервера (может быть локальная шара на сервере виртуализации). В терминальных сценариях всегда было так, что плотность (количество пользователей на xxx GB RAM) на 50% выше если сделать 3-4 виртуалки (это в случае 64ГБ памяти, если меньше, то двух достаточно) — чем если ставить терминалы на само железо. Плюс обеспечивается доступность. Без APP-V фермы неудобны — сложно обновлять, и много места занимает софт. С APP-V все просто и удобно.
Я не вижу сценариев конкурентной борьбы Citrix XenApp без APP-V, а с ним для большинства бизнес сценариев хватает решения Microsoft. Ну и о стоимости… APP-V for RDS это часть RDS CAL, так что бесплатно для терминалов. В случае VDI нужен MDOP, но мало кто вообще говорит о VDI без виртуализации приложений…
VDI вообще не требует System Center. Не использует его никак. Соответственно, можно и без него.
Для APP-V 5.0 есть варианты индивидуального сервера управления и полной инфраструктуры SCCM. Для pool VDI я бы точно не стал ставить SCCM.
По соотношению. Примерно половину курса по времени уделено RDS/VDI, и половину APP-V. В первом больше теории (и простые лабы), во втором больше сложных лаб.
По результатам первого прохода будем принимать решение, насколько аудитории интересно комбинирование тем вместе, и нет ли нужды вынести APP-V в отдельный тренинг (добавить лаб), а к RDS/VDI добавить службы печати, которые не тривиальны в таких сценариях.
Есть ВМ на узле с ПО IP телефонии (без устройств)
Есть вторая виртуальная машина для мониторинга.
Миррорить трафик с одной ВМ на другую ВМ, подключенную к тому же виртуальному свичу можно.
Поясните, где я вас недопонял? И что именно не заработало.
По клиентским ОС все просто. То устройство, с которого вы обращаетесь к виртуальной машине с клиентской ОС *должно* иметь действующую Software Assurance (для Windows устройств) или лицензию VDA (для не Windows). Активация — через KMS. Права downgrade, смены языка и архитектуры у вас есть в рамках SA.
Чтобы работал RemoteFX (любой) требуется доставить роль Remote Desktop Virtualization Host (есть и на бесплатном).
Как только вы начинаете пользоваться RemoteFX внутри ВМ, вы потребляете RDS CAL.
Вне виртуальных машин Hyper-V технология RemoteFX не работает.
Уже сейчас, записавшись на курсы в июне, вы получите информацию по новому в R2 — на основе предварительной версии. Если будет публичная бета, то будут и лабораторные. Если нет, то только обсуждение и демо.
А вот для работы синтетического видео требуется уже внутри ВМ ОС Win8/2012
Я планирую в треке в июне уже рассказывать о новых возможностях — по виртуализации и кластерам. Если мы будем проводить подобные треки и в будущем, то наверное будут и новые лабораторные.
Microsoft никогда не отдает учебников по новым версиям продуктов бесплатно тем, кто покупал старые. Но очевидно, что если будут массовые изменения, будут новые курсы, будут новые учебники.
Вебкаст «что нового» я проведу сразу после публичной беты.
Другие решения делают это следующим образом: у X* это реализовано редиректором с клиента на сервер, подобно RemoteFX от Microsoft, но более изящно. V* имеет экспериментальную (читай как неподдерживаемую) возможность отдать всю PCI шину с USB концентратором и всеми портами одной ВМ. При этом пропадает *motion и куча других фишек.
Все вендоры сходятся на том. что лучше закупать 1U многопортовое устройство и отдавать порты по TCP/IP. Я обычно говорю об AnywhereUSB. Есть и софтовые варианты, в том числе под Windows.
Наврядли вы станете использовать USB порты самого хоста (иначе нет миграции ВМ)…
Примерно так.
То есть ваш вопрос не о кластерах.
Риск заключается в том, что при высоком уровне дедупликации, сделанной, например в то время, пока машины были выключены, при их включении она не будет дедуплицировать одинаковые блоки, резко закончится место на томе, и все машины будут paused-critical.
Это риск? Безусловно. Практический и срабатывающий, — да.
Через полтора-два месяца я сделаю отдельный вебкаст по дедупликации в 2012R2, там все веселее.
Пока об этом не могу писать публично.
Про старые гипервизоры речь шла о всем том, что не поддерживает VMGenerationID (например Hyper-V R2 :) ) и всех сторонних гипервизорах, на которых не поддерживается современная ОС Windows Server 2012 (на Hyper-V R2, безусловно поддерживается).
Список поддерживаемых гипервизоров и их версий можно посмотреть на странице каталога: windowsservercatalog.com/results.aspx?&bCatID=1521&cpID=0&avc=0&ava=0&avq=0&OR=1&PGS=100
Если вашего гипервизора там нет, это его проблемы, он не годен для виртуализации WS2012 вообще, не говоря уже о контроллерах домена. Большинство сторонних решений там присутствует. О наличии в них VMGenerationID следует обращаться к вендорам. API открыт уже около года.
Хотя фактически invocationID контроллера это атрибут, содержащий текущий GID, практически это некий «friendly name» используемый для определения версии состоянии базы на контроллере в процессе репликации. Изображать на слайде ситуацию с многоэтажными GUIDами было бы менее интуитивно, — громоздко.
Равно и с конкретными номерами RID/USN — слайд рассказывает архитектуру работы, а не пример из реальной жизни, его цель наглядно показать сложный процесс простым примером. А детально это следует разбирать уже на стадии более глубокого понимания работы архитектуры AD и механизма репликации.
Если есть вопросы по тому, как это работает, готов на ваших примерах более детально рассказать не упрощая картинки.
Как стёб — пять баллов в плюс, а вот информативность её на китайском для большинства нас хромает.
Поможите?
Описывая технологии терминального доступа и VDI мне хотелось показать, как «правильно» их планировать.
Microsoft RDSH без APP-V довольно неуклюж. Даже в сценарии SMB, если вам требуется иметь десяток приложений, среди них наверняка найдется капризное, которому нужен старый Office. И наверняка вам на терминальных серверах для работы веб-браузера и ряда приложений потребуются ночные кошмары администратора за именем Flash и Java (ну и Silverlight, если уж откровенно). Обновлять терминальные серверы каждые две недели, перезагружать из-за очередной дыры Flash — увольте. А количество версий великой кросплатформенной Джаббы? Которые несовместимы. И ваше верхнеуровневое приложение №1 хочет Java 5.0, новое приложение №2 хочет Java 7.0, а старое №3 хочет Java 3.0… Как вы это решаете сейчас (хинт, две Java установить полноценно на одну ОС нельзя)? Ставите несколько виртуалок с терминалами.
Для SMB хороший вариант иметь один золотой образ чистой ОС, и 3-4 дочерних диска с одинаковыми конфигурациями — вообще без приложений. Весь софт через APP-V, размещение софта на шаре APP-V сервера (может быть локальная шара на сервере виртуализации). В терминальных сценариях всегда было так, что плотность (количество пользователей на xxx GB RAM) на 50% выше если сделать 3-4 виртуалки (это в случае 64ГБ памяти, если меньше, то двух достаточно) — чем если ставить терминалы на само железо. Плюс обеспечивается доступность. Без APP-V фермы неудобны — сложно обновлять, и много места занимает софт. С APP-V все просто и удобно.
Я не вижу сценариев конкурентной борьбы Citrix XenApp без APP-V, а с ним для большинства бизнес сценариев хватает решения Microsoft. Ну и о стоимости… APP-V for RDS это часть RDS CAL, так что бесплатно для терминалов. В случае VDI нужен MDOP, но мало кто вообще говорит о VDI без виртуализации приложений…
В видео, навряд ли будем перемонтировать.
А вот с APP-V — вполне.
И действительно, сейчас Microsoft тяготеет к динамике и весам.
Для APP-V 5.0 есть варианты индивидуального сервера управления и полной инфраструктуры SCCM. Для pool VDI я бы точно не стал ставить SCCM.
По соотношению. Примерно половину курса по времени уделено RDS/VDI, и половину APP-V. В первом больше теории (и простые лабы), во втором больше сложных лаб.
По результатам первого прохода будем принимать решение, насколько аудитории интересно комбинирование тем вместе, и нет ли нужды вынести APP-V в отдельный тренинг (добавить лаб), а к RDS/VDI добавить службы печати, которые не тривиальны в таких сценариях.
Комментарии приветствуются.