Вышел пакет обновлений u4 для ESX3.5.
Expanded Support for Enhanced vmxnet Adapter — This version of ESX Server includes an updated version of the VMXNET driver (VMXNET enhanced) for the following guest operating systems:
Microsoft Windows Server 2003, Standard Edition (32-bit)
Microsoft Windows Server 2003, Standard Edition (64-bit)
Microsoft Windows Server 2003, Web Edition
Microsoft Windows Small Business Server 2003
Microsoft Windows XP Professional (32-bit)
The new VMXNET version improves virtual machine networking performance and requires VMware tools upgrade.
Enablement of Intel Xeon Processor 5500 Series — Support for the Xeon processor 5500 series has been added. Support includes Enhanced VMotion capabilities. For additional information on previous processor families supported by Enhanced VMotion, see Enhanced VMotion Compatibility (EVC) processor support (KB 1003212).
QLogic Fibre Channel Adapter Driver Update — The driver and firmware for the QLogic fibre channel adapters have been updated to version 7.08-vm66 and 4.04.06 respectively. This release provides interoperability fixes for QLogic Management Tools for FC Adapters and enhanced NPIV support.
Emulex Fibre Channel Adapter Driver Update — The driver for Emulex Fibre Channel Adapters has been upgraded to version 7.4.0.40. This release provides support for the HBAnyware 4.0 Emulex management suite.
LSI megaraid_sas and mptscsi Storage Controller Driver Update — The drivers for LSI megaraid_sas and mptscsi storage controllers have been updated to version 3.19vmw and 2.6.48.18 vmw respectively. The upgrade improves performance and enhance event handling capabilities for these two drivers.
Newly Supported Guest Operating Systems — Support for the following guest operating systems has been added specifically for this release:
For more complete information about supported guests included in this release, see the Guest Operating System Installation Guide: http://www.vmware.com/pdf/GuestOS_guide.pdf.
SUSE Linux Enterprise Server 11 (32-bit and 64-bit).
SUSE Linux Enterprise Desktop 11 (32-bit and 64-bit).
Ubuntu 8.10 Desktop Edition and Server Edition (32-bit and 64-bit).
Windows Preinstallation Environment 2.0 (32-bit and 64-bit).
Furthermore, pre-built kernel modules (PBMs) were added in this release for the following guests:
Ubuntu 8.10
Ubuntu 8.04.2
Newly Supported Management Agents — Refer to VMware ESX Server Supported Hardware Lifecycle Management Agents for the most up-to-date information on supported management agents.
Newly Supported I/O Devices — in-box support for the following on-board processors, IO devices, and storage subsystems:
SAS Controllers and SATA Controllers:
The following are newly supported SATA Controllers.
PMC 8011 (for SAS and SATA drives)
Intel ICH9
Intel ICH10
CERC 6/I SATA/SAS Integrated RAID Controller (for SAS and SATA drivers)
HP Smart Array P700m Controller
Notes:
Some limitations apply in terms of support for SATA controllers. For more information, see SATA Controller Support in ESX 3.5 (KB 1008673).
Storing VMFS datastores on native SATA drives is not supported.
Network Cards: The following are newly supported network interface cards:
HP NC375i Integrated Quad Port Multifunction Gigabit Server Adapter
HP NC362i Integrated Dual port Gigabit Server Adapter
Intel 82598EB 10 Gigabit AT Network Connection
HP NC360m Dual 1 Gigabit/NC364m Quad 1 Gigabit
Intel Gigabit CT Desktop Adapter
Intel 82574L Gigabit Network Connection
Intel 10 Gigabit XF SR Dual Port Server Adapter
Intel 10 Gigabit XF SR Server Adapter
Intel 10 Gigabit XF LR Server Adapter
Intel 10 Gigabit CX4 Dual Port Server Adapter
Intel 10 Gigabit AF DA Dual Port Server Adapter
Intel 10 Gigabit AT Server Adapter
Intel 82598EB 10 Gigabit AT CX4 Network Connection
NetXtreme BCM5722 Gigabit Ethernet
NetXtreme BCM5755 Gigabit Ethernet
NetXtreme BCM5755M Gigabit Ethernet
NetXtreme BCM5756 Gigabit Ethernet
Expanded Support: The E1000 Intel network interface card (NIC) is now available for NetWare 5 and NetWare 6 guest operating systems.
Onboard Management Processors:
IBM system management processor (iBMC)
Storage Arrays:
SUN StorageTek 2530 SAS Array
Sun Storage 6580 Array
Sun Storage 6780 Array
вторник, 31 марта 2009 г.
понедельник, 30 марта 2009 г.
"Композитная" виртуальная машина
Один из часто задаваемых вопросов касается "композитной" виртуальной машины. "Можно ли сделать так, чтобы ресурсы двух хостов ESX объединить в одну виртуальную машину?"
Нет, нельзя. Почему?
Кластерные суперкомпьютеры, которые позволяют "объединять" ресурсы множества узлов, строятся под задачи. ПО для работы на этих суперкомпьютерах разрабатывается специально, с учетом всех их особенностей.
Виртуальные машины в общем случае - это универсальное и неспециализированное ПО, которое даже понятия не имеет, что работает не на физическом железе. И ведет себя соответствующим образом.
Даже при использовании специальных высокоскоростных сетей, разработанных для суперкомпьютеров, задержки доступа составляют порядка микросекунды, в то время как задержка доступа к локальной памяти несколько наносекунд, т.е. объединение памяти физических машин в одну "композитную" выльется в 1000-кратное замедление скорости работы. Про процессорные шины и говорить не приходится. Да, пожалуй, если задаться подобной целью, то мы сможем в конечном итоге реализовать проект, который позволит на железе стоимостью сотни тысяч долларов создать виртуальную машину с производительностью на уровне 386 процессора. Извините, 32-процессорной машины с 386 процессорами.
Почему же все тогда говорят про "облако" и ресурсы по заказу? Все очень просто. Мы действительно может давать ресурсы по заказу и относиться к большому Fully automated DRS кластеру ESX как к облаку. Но при одном условии - каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.
Виртуальные машины могут многое, и избавляют нас от многих забот, но они могут не все. И даже при всей автоматизации управления виртуальной инфраструктурой, не следует забывать то, что в первую очередь виртуальные машины - это консолидация серверов, деление ресурсов очень мощного хоста между виртуальными машинами. Если нам надо больше ресурсов для ВМ, чем есть у хоста, то вывод может быть только один - виртуализация здесь не нужна и проблемы с правильным проектированием, а не с недостатком возможностей платформы виртуализации.
Нет, нельзя. Почему?
Кластерные суперкомпьютеры, которые позволяют "объединять" ресурсы множества узлов, строятся под задачи. ПО для работы на этих суперкомпьютерах разрабатывается специально, с учетом всех их особенностей.
Виртуальные машины в общем случае - это универсальное и неспециализированное ПО, которое даже понятия не имеет, что работает не на физическом железе. И ведет себя соответствующим образом.
Даже при использовании специальных высокоскоростных сетей, разработанных для суперкомпьютеров, задержки доступа составляют порядка микросекунды, в то время как задержка доступа к локальной памяти несколько наносекунд, т.е. объединение памяти физических машин в одну "композитную" выльется в 1000-кратное замедление скорости работы. Про процессорные шины и говорить не приходится. Да, пожалуй, если задаться подобной целью, то мы сможем в конечном итоге реализовать проект, который позволит на железе стоимостью сотни тысяч долларов создать виртуальную машину с производительностью на уровне 386 процессора. Извините, 32-процессорной машины с 386 процессорами.
Почему же все тогда говорят про "облако" и ресурсы по заказу? Все очень просто. Мы действительно может давать ресурсы по заказу и относиться к большому Fully automated DRS кластеру ESX как к облаку. Но при одном условии - каждая ВМ требует ресурсов, значительно меньших, чем ресурсы одного хоста. Как только уровень ресурсов становится сравним, облако рассеивается на отдельно стоящие хосты.
Виртуальные машины могут многое, и избавляют нас от многих забот, но они могут не все. И даже при всей автоматизации управления виртуальной инфраструктурой, не следует забывать то, что в первую очередь виртуальные машины - это консолидация серверов, деление ресурсов очень мощного хоста между виртуальными машинами. Если нам надо больше ресурсов для ВМ, чем есть у хоста, то вывод может быть только один - виртуализация здесь не нужна и проблемы с правильным проектированием, а не с недостатком возможностей платформы виртуализации.
четверг, 26 марта 2009 г.
Кто такие Евангелисты
Александр Ложечкин, руководитель группы евангелистов Microsoft, прекрасно раскрыл тему.
"Итак, кто же такие евангелисты?
Евангелисты, если отбросить исконное значение этого слова, появились именно в сфере ИТ и это было, по моему мнению, вызвано недостаточной эффективностью работы традиционных методов продвижения продуктов и технологиях на техническую аудиторию. А в те времена в ИТ не было простых пользователей, вся сфера ИТ состояла только из технических профессионалов. Для этой аудитории рекламных листовок и традиционных маркетинговых материалов недостаточно и, чтобы убедить эту аудиторию, нужно без лишней рекламы откровенно рассказывать о достоинствах и недостатках своих продуктов и технологий, быть такими же, как эта аудитория, техническими специалистами, понимать их проблемы и говорить с ними на одном языке. Так и появились евангелисты – люди, работа которых находится на стыке между технологиями и маркетингом. Все технические евангелисты, которых я знаю – люди с большим опытом работы в этой сфере разработчиками, архитекторами, ИТ-профессионалами. Как правило, евангелистами они становятся потому, что им нравится и интересно не только изучать и внедрять современные технологии, но и интересно делиться своими знаниями с другими, выступать на конференциях, писать блоги, публиковать статьи и книги и т.д.
Что делают евангелисты и зачем?
Когда меня спрашивают, что является целью моей работы, то краткий ответ звучит так: моя цель – чтобы каждый разработчик ПО и каждый ИТ-профессионал в России был счастлив. А для достижения этой цели нужно изучать нашу аудиторию, понимать ее проблемы и нужды, нужно придумывать решения проблем и рассказывать о них широким аудиториям. Поскольку я знаю и верю, что технологии Microsoft являются лучшими из того, что сейчас есть на рынке, для достижения своей цели я и мои коллеги продвигаем наши технологии на рынок, но не путем донесения маркетинговых лозунгов, а путем рассказа о возможностях наших продуктов и способах их применения. При этом мы понимаем, что даже если бы у нас работало 100 евангелистов, мы вряд ли бы смогли дотянуться до каждого из сотен тысяч разработчиков и ИТ-профессионалов в России, поэтому помимо перечисленного выше в обязанности евангелиста входит и развитие сообществ пользователей наших продуктов, в которых посредством форумов, блогов, конференций, просто неформальных встреч пользователи наших продуктов могли бы обмениваться опытом их использования, помогать решать проблемы и тем самым, становиться более счастливыми!
Как измеряется успех работы евангелиста?
Для измерения работы евангелиста с учетом перечисленных выше целей используется 2 основных показателя: уровень удовлетворенности целевой аудитории и уровень использования технологий. Для измерения этих показателей используются регулярные социологические исследования. Важно отметить, что продажи не являются способом измерения работы евангелиста. И в Microsoft это сделано совершенно сознательно, чтобы ориентация на продажи не помешала бы евангелисту быть на 100% искренним. Да, возможно, это и негативно влияет на продажи в краткосрочной перспективе, но доверие нашей аудитории, которое мы, надеюсь, завоевываем таким образом, для нас гораздо ценнее. И, что очень важно, доверие пользователей приводит к гораздо большему эффекту в продажах в долгосрочной перспективе. Т.е., конечно евангелисты – не альтруисты."
"Итак, кто же такие евангелисты?
Евангелисты, если отбросить исконное значение этого слова, появились именно в сфере ИТ и это было, по моему мнению, вызвано недостаточной эффективностью работы традиционных методов продвижения продуктов и технологиях на техническую аудиторию. А в те времена в ИТ не было простых пользователей, вся сфера ИТ состояла только из технических профессионалов. Для этой аудитории рекламных листовок и традиционных маркетинговых материалов недостаточно и, чтобы убедить эту аудиторию, нужно без лишней рекламы откровенно рассказывать о достоинствах и недостатках своих продуктов и технологий, быть такими же, как эта аудитория, техническими специалистами, понимать их проблемы и говорить с ними на одном языке. Так и появились евангелисты – люди, работа которых находится на стыке между технологиями и маркетингом. Все технические евангелисты, которых я знаю – люди с большим опытом работы в этой сфере разработчиками, архитекторами, ИТ-профессионалами. Как правило, евангелистами они становятся потому, что им нравится и интересно не только изучать и внедрять современные технологии, но и интересно делиться своими знаниями с другими, выступать на конференциях, писать блоги, публиковать статьи и книги и т.д.
Что делают евангелисты и зачем?
Когда меня спрашивают, что является целью моей работы, то краткий ответ звучит так: моя цель – чтобы каждый разработчик ПО и каждый ИТ-профессионал в России был счастлив. А для достижения этой цели нужно изучать нашу аудиторию, понимать ее проблемы и нужды, нужно придумывать решения проблем и рассказывать о них широким аудиториям. Поскольку я знаю и верю, что технологии Microsoft являются лучшими из того, что сейчас есть на рынке, для достижения своей цели я и мои коллеги продвигаем наши технологии на рынок, но не путем донесения маркетинговых лозунгов, а путем рассказа о возможностях наших продуктов и способах их применения. При этом мы понимаем, что даже если бы у нас работало 100 евангелистов, мы вряд ли бы смогли дотянуться до каждого из сотен тысяч разработчиков и ИТ-профессионалов в России, поэтому помимо перечисленного выше в обязанности евангелиста входит и развитие сообществ пользователей наших продуктов, в которых посредством форумов, блогов, конференций, просто неформальных встреч пользователи наших продуктов могли бы обмениваться опытом их использования, помогать решать проблемы и тем самым, становиться более счастливыми!
Как измеряется успех работы евангелиста?
Для измерения работы евангелиста с учетом перечисленных выше целей используется 2 основных показателя: уровень удовлетворенности целевой аудитории и уровень использования технологий. Для измерения этих показателей используются регулярные социологические исследования. Важно отметить, что продажи не являются способом измерения работы евангелиста. И в Microsoft это сделано совершенно сознательно, чтобы ориентация на продажи не помешала бы евангелисту быть на 100% искренним. Да, возможно, это и негативно влияет на продажи в краткосрочной перспективе, но доверие нашей аудитории, которое мы, надеюсь, завоевываем таким образом, для нас гораздо ценнее. И, что очень важно, доверие пользователей приводит к гораздо большему эффекту в продажах в долгосрочной перспективе. Т.е., конечно евангелисты – не альтруисты."
вторник, 24 марта 2009 г.
Особенности Non-Persistent Pool в View
Исправляю свою старую ошибку относительно Non-Persistent Pool в этом посте.
"Выглядит примерно так же, как и Persistent, только с тем отличием, что все изменения на виртуальных машинах откатываются, а пары логин/машина не запоминаются."
На самом деле изменения никуда не откатываются, это уже дело доменного администратора спланировать архитектуру так, чтобы пользователю было все равно на какой машине работать. Например, за счет использования Roaming Profiles.
Тем не менее, есть опция, которая позволяет гарантировать, что при логине пользователь будет получать девственно чистую машину. Эта опция называется "Delete VM on logoff". При завершении сессии и выходе ВМ удаляется, а на ее место разворачивается новая из шаблона.
"Выглядит примерно так же, как и Persistent, только с тем отличием, что все изменения на виртуальных машинах откатываются, а пары логин/машина не запоминаются."
На самом деле изменения никуда не откатываются, это уже дело доменного администратора спланировать архитектуру так, чтобы пользователю было все равно на какой машине работать. Например, за счет использования Roaming Profiles.
Тем не менее, есть опция, которая позволяет гарантировать, что при логине пользователь будет получать девственно чистую машину. Эта опция называется "Delete VM on logoff". При завершении сессии и выходе ВМ удаляется, а на ее место разворачивается новая из шаблона.
понедельник, 23 марта 2009 г.
Veeam Backup 3
Инженеры компании Veeam зарабатывают на свой хлеб с маслом, выпуская продукты, упрощающие жизнь администратору VMware Virtual Infrastructure. И надо сказать, что очень достойные продукты.
Хочу рассказать об интересных особенностях их нового продукта, Veeam Backup 3.0.
В чем же его отличие от бесплатного VCB?
Прежде всего, это полноценный и удобный GUI, причем совмещен инструмент как резервного копирования, так и восстановления.
Veeam Backup
1) работает с ESXi, включая бесплатный.
2) способен работать как самостоятельно, так и в паре с VCB, снимая дополнительную нагрузку с ESX сервера.
3) поддерживает Microsoft VSS.
4) поддерживается восстановление отдельных файлов для файловых систем FAT & NTFS.
5) Клиент Veeam Backup одновременно является и FastSCP. Или наоборот, кому как нравится :)
Помимо всего прочего, Veeam Backup презентуется как решение с "синтетическим" бэкапом. Чем же синтетический отличается от привычных дифференциального и инкрементального?
Полный бэкап - определение самоочевидно :)
Дифференциальный бэкап - в бэкап записываются данные, измененные со времени последнего полного бэкапа.
Инкрементальный бэкап - в бэкап записываются данные, измененные со времени последнего любого бэкапа.
Преимущества полного бэкапа очевидны - наискорейшее восстановление, но он требует больше всего места. Дифференциальный бэкап требует для восстановления два бэкапа - собственно дифференциальный и полный, что несколько замедляет сам процесс бэкапа, но требует меньше места, чем для полного. Недостаток дифференциального в том, что при нескольких последовательных дифференциальных бэкапах идет расход места под одни и те же изменения, входящие в каждый дифференциальный бэкап. Наименее требователен к месту инкрементальный, но он же самый медленный для восстановления и самый чувствительный к повреждениям резервных копий и вообще их наличию.
Синтетический бэкап, используемый в Veeam Backup - это инкрементальный бэкап наоборот. После первого полного бэкапа остальные идут как инкрементальные, но(!) вместо того, чтобы записывать на диск инкрементальный бэкап, все переворачивается с ног на голову. Инкрементальный бэкап используется для обновления состояния полного бэкапа, а пишутся на диск обратные инкрементальные изменения. Что это дает?
Наиболее востребована только последняя сделанная копия, ибо, что вполне логично, нам требуется наиболее свежее состояние системы. При прямом инкрементальном бэкапе нам надо взять последний полный бэкап и последовательно накатить на него все инкрементальные изменения (или одно дифференциальное). Здесь же, в синтетическом (обратном инкрементальном) бэкапе, последняя актуальная копия всегда является полной. И только если вдруг нам потребуется копия более ранняя, придется накатить на полный бэкап обратные инкременты.
Одно из несомненных достоинств Veeam Backup - дедупликация данных "на лету" при бэкапе, и интегрированный механизм компресии самих файлов бэкапов.
Все это прекрасно, спору нет. Вопрос о цене.
Veeam Backup лицензируется по количеству сокетов обслуживаемой инфраструктуры ESX серверов. Цена лицензии $550 за сокет, поддержка 5*8 на год включена в лицензию, дополнительная поддержка 5*8 стоит 120$ в год за сокет.
Хочу рассказать об интересных особенностях их нового продукта, Veeam Backup 3.0.
В чем же его отличие от бесплатного VCB?
Прежде всего, это полноценный и удобный GUI, причем совмещен инструмент как резервного копирования, так и восстановления.
Veeam Backup
1) работает с ESXi, включая бесплатный.
2) способен работать как самостоятельно, так и в паре с VCB, снимая дополнительную нагрузку с ESX сервера.
3) поддерживает Microsoft VSS.
4) поддерживается восстановление отдельных файлов для файловых систем FAT & NTFS.
5) Клиент Veeam Backup одновременно является и FastSCP. Или наоборот, кому как нравится :)
Помимо всего прочего, Veeam Backup презентуется как решение с "синтетическим" бэкапом. Чем же синтетический отличается от привычных дифференциального и инкрементального?
Полный бэкап - определение самоочевидно :)
Дифференциальный бэкап - в бэкап записываются данные, измененные со времени последнего полного бэкапа.
Инкрементальный бэкап - в бэкап записываются данные, измененные со времени последнего любого бэкапа.
Преимущества полного бэкапа очевидны - наискорейшее восстановление, но он требует больше всего места. Дифференциальный бэкап требует для восстановления два бэкапа - собственно дифференциальный и полный, что несколько замедляет сам процесс бэкапа, но требует меньше места, чем для полного. Недостаток дифференциального в том, что при нескольких последовательных дифференциальных бэкапах идет расход места под одни и те же изменения, входящие в каждый дифференциальный бэкап. Наименее требователен к месту инкрементальный, но он же самый медленный для восстановления и самый чувствительный к повреждениям резервных копий и вообще их наличию.
Синтетический бэкап, используемый в Veeam Backup - это инкрементальный бэкап наоборот. После первого полного бэкапа остальные идут как инкрементальные, но(!) вместо того, чтобы записывать на диск инкрементальный бэкап, все переворачивается с ног на голову. Инкрементальный бэкап используется для обновления состояния полного бэкапа, а пишутся на диск обратные инкрементальные изменения. Что это дает?
Наиболее востребована только последняя сделанная копия, ибо, что вполне логично, нам требуется наиболее свежее состояние системы. При прямом инкрементальном бэкапе нам надо взять последний полный бэкап и последовательно накатить на него все инкрементальные изменения (или одно дифференциальное). Здесь же, в синтетическом (обратном инкрементальном) бэкапе, последняя актуальная копия всегда является полной. И только если вдруг нам потребуется копия более ранняя, придется накатить на полный бэкап обратные инкременты.
Одно из несомненных достоинств Veeam Backup - дедупликация данных "на лету" при бэкапе, и интегрированный механизм компресии самих файлов бэкапов.
Все это прекрасно, спору нет. Вопрос о цене.
Veeam Backup лицензируется по количеству сокетов обслуживаемой инфраструктуры ESX серверов. Цена лицензии $550 за сокет, поддержка 5*8 на год включена в лицензию, дополнительная поддержка 5*8 стоит 120$ в год за сокет.
пятница, 20 марта 2009 г.
Template & Domain
Вопрос: присоединять Windows ВМ к домену перед ее превращением в шаблон или оставить в рабочей группе?
Ответ: Если присоединить ВМ к домену до запуска sysprep, то членство в домене будет потеряно. Если присоединить ВМ к домену после запуска sysprep, то по истечению некоторого срока (30 дней по умолчанию) временные пароли для создания защищенного канала с контроллером домена потеряют актуальность и членство в домене снова будет потеряно.
Поэтому лучше оставить машину в рабочей группе и присоединять к домену во время развертывания из шаблона используя механизм customization.
Ответ: Если присоединить ВМ к домену до запуска sysprep, то членство в домене будет потеряно. Если присоединить ВМ к домену после запуска sysprep, то по истечению некоторого срока (30 дней по умолчанию) временные пароли для создания защищенного канала с контроллером домена потеряют актуальность и членство в домене снова будет потеряно.
Поэтому лучше оставить машину в рабочей группе и присоединять к домену во время развертывания из шаблона используя механизм customization.
четверг, 19 марта 2009 г.
ESX и USB для ВМ
Один из наиболее задаваемых вопросов про ESX(i) - когда VMware сделает возможным использование host USB в ВМ на ESX.
Отвечаю: никогда.
Объясняю: концепция использования ВМ в среде Virtual Infrastructire, т.е. на ESX(i) серверах предполагает, что каждый ESX хост является донором лишь трех возможных ресурсов - времени процессора, мегабайтов оперативной памяти и мегабитов сетевого соединения. Почему только так? Просто потому что VI - это платформа виртуализации, вышедшая из первого поколения (консолидации) довольно давно, и ВМ не привязана к какому-то конкретному хосту. DRS и VMotion + разделяемое хранилище дают прозрачное перемещение ВМ в пределах кластера.
- Где у вас находятся эти виртуальные машины? - (строгий аудит)
- Где-то тут. - (сисадмин обводит рукой стойку с серверами)
- Как, Вы не знаете где они работают?!
- А разве это так важно?
С появлением ESXi Embedded ввод в строй новых хостов еще более упростился и приближается к концепции анонимных хостов. А вся система приближается к модному в этом сезоне термину - "облаку". Нас реально не волнует как там что устроено внутри, оно просто работает.
Почему здесь нет места USB? А просто потому что использование портов хоста жестко привязывает ВМ к хосту. Она больше не может никуда мигрировать. Она даже не перезапустится в HA кластере при смерти хоста, на котором выполнялась - ведь нужный ей порт USB вместе с USB ключом, или что там было подключено, находится на недоступном хосте.
Итог: если Вам действительно нужны USB порты в ВМ, то у Вас есть два возможных варианта при работе с VMware VI. В любом случае Вы добавляете в инфраструктуру отдельный хост и:
1) Устанавливаете на нем VMware Server, который прекрасно работает с хостовым USB, и запускаете серверы лицензий и тому подобные машины с необходимостью наличия USB под VMware Server.
2) Устанавливаете дополнительные USB контроллеры в нужном количестве и запускаете хост-сервис USB-over-IP на этой машине. После чего пробрасываете USB в нужные виртуальные машины по сети. Но в этом случае Вам будет необходимо купить соответствующий продукт, благо их в настоящее время достаточно широкий выбор.
Отвечаю: никогда.
Объясняю: концепция использования ВМ в среде Virtual Infrastructire, т.е. на ESX(i) серверах предполагает, что каждый ESX хост является донором лишь трех возможных ресурсов - времени процессора, мегабайтов оперативной памяти и мегабитов сетевого соединения. Почему только так? Просто потому что VI - это платформа виртуализации, вышедшая из первого поколения (консолидации) довольно давно, и ВМ не привязана к какому-то конкретному хосту. DRS и VMotion + разделяемое хранилище дают прозрачное перемещение ВМ в пределах кластера.
- Где у вас находятся эти виртуальные машины? - (строгий аудит)
- Где-то тут. - (сисадмин обводит рукой стойку с серверами)
- Как, Вы не знаете где они работают?!
- А разве это так важно?
С появлением ESXi Embedded ввод в строй новых хостов еще более упростился и приближается к концепции анонимных хостов. А вся система приближается к модному в этом сезоне термину - "облаку". Нас реально не волнует как там что устроено внутри, оно просто работает.
Почему здесь нет места USB? А просто потому что использование портов хоста жестко привязывает ВМ к хосту. Она больше не может никуда мигрировать. Она даже не перезапустится в HA кластере при смерти хоста, на котором выполнялась - ведь нужный ей порт USB вместе с USB ключом, или что там было подключено, находится на недоступном хосте.
Итог: если Вам действительно нужны USB порты в ВМ, то у Вас есть два возможных варианта при работе с VMware VI. В любом случае Вы добавляете в инфраструктуру отдельный хост и:
1) Устанавливаете на нем VMware Server, который прекрасно работает с хостовым USB, и запускаете серверы лицензий и тому подобные машины с необходимостью наличия USB под VMware Server.
2) Устанавливаете дополнительные USB контроллеры в нужном количестве и запускаете хост-сервис USB-over-IP на этой машине. После чего пробрасываете USB в нужные виртуальные машины по сети. Но в этом случае Вам будет необходимо купить соответствующий продукт, благо их в настоящее время достаточно широкий выбор.
Подписаться на:
Сообщения (Atom)
Сообщения
