Oculus Touch обзор — лучшие в мире VR контроллеры. Управляющий интерфейс esx, виртуальный контроллер для service console (vswif)
Переводим... Перевести Китайский (упрощенное письмо) Китайский (традиционное письмо) Английский Французский Немецкий Итальянский Португальский Русский Испанский Турецкий
К сожалению, мы не можем перевести эту информацию прямо сейчас - пожалуйста, повторите попытку позже.
GestureWorks Gameplay - это новый способ взаимодействия с популярными играми на ПК. Программа Gameplay для Windows 8 позволяет игрокам использовать и создавать собственные виртуальные контроллеры для сенсорного управления, которые можно применять в существующих играх. Каждый виртуальный контроллер добавляет кнопки, жесты и прочие элементы управления, которые сопоставляются с поддерживаемыми игрой средствами управления. Кроме того, игроки могут применять сотни индивидуально настраиваемых жестов для взаимодействия с игрой на экране. Сотрудничество компании Ideum с корпорацией Intel позволило получить доступ к технологиям и инженерным ресурсам, чтобы реализовать возможности сенсорного управления в Gameplay.
Посмотрите этот короткий ролик , поясняющий принцип работы Gameplay.
Виртуальные контроллеры
В отличие от традиционных игровых контроллеров виртуальные контроллеры полностью настраиваются, а игроки могут обмениваться ими с друзьями. Программа Gameplay работает на планшетах с Windows 8 , ультрабуках , устройствах 2 в 1 , моноблоках и даже мультисенсорных планшетах с большими экранами.
Рисунок 1 ‒ Программа Gameplay в действии на планшете с процессором Intel Atom
«Виртуальный контроллер реален! Программа Gameplay охватывает сотни игр для ПК, не поддерживающих сенсорное управление, и позволяет играть в них на совершенно новом поколении мобильных устройств, - говорит Джим Спадаччини (Jim Spadaccini), директор компании Ideum, создавшей GestureWorks Gameplay. - Виртуальные контроллеры Gameplay лучше физических контроллеров, поскольку их можно полностью настраивать и изменять. Мы с интересом ожидаем распространения Gameplay среди игроков».
Рисунок 2 ‒ Главная страница Gameplay
Вместе с GestureWorks Gameplay поставляется несколько десятков уже готовых виртуальных контроллеров для популярных игр для Windows (в настоящее время поддерживается свыше 116 уникальных наименований). В программе Gameplay пользователи также могут настраивать существующие контроллеры и изменять их раскладку. Программа также включает удобное в использовании средство создания виртуальных контроллеров: пользователи могут создавать собственные контроллеры для множества популярных игр для Windows, распространяемых с помощью службы Steam.
Рисунок 3 ‒ Раскладка виртуального контроллера
Пользователи могут размещать джойстики, переключатели, колесики прокрутки и кнопки в любых местах экрана, изменять размер и прозрачность элементов управления, добавлять цвета и подписи. Также можно создавать несколько представлений разметки и переключаться между ними в любой момент игры. Благодаря этому пользователь может создавать представления для разных действий в игре, например в ролевой игре можно создать одно представление для боя, а другое - для управления снаряжением.
Рисунок 4 ‒ Глобальное представление жестов виртуального контроллера
Программа Gameplay, в основе которой лежит движок обработки жестов GestureWorks Core, поддерживает свыше 200 глобальных жестов. Простейшие глобальные жесты, такие как касание, перетаскивание, сведение/разведение пальцев и поворот, поддерживаются по умолчанию, но также настраиваются. Это позволяет расширять возможности контроллеров и применять мультисенсорные жесты для дополнительного управления в играх на ПК. Например, определенные действия или боевые приемы в шутерах от первого лица можно активировать одним жестом вместо нажатия нескольких кнопок. Gameplay также включает экспериментальную поддержку акселерометров: в гонках можно поворачивать, наклоняя ультрабук или планшет. Программа обнаруживает переключение устройств 2 в 1 в режим планшета, чтобы при необходимости включить виртуальный контроллер.
Проблемы, возникшие при разработке
Разрабатывать такую удобную программу было непросто. Для воплощения идеи Gameplay в жизнь потребовалось преодолеть ряд технических проблем. Некоторые проблемы удалось решить традиционными методами программирования, для других проблем потребовались более изощренные решения.
Поддержка переключения 2 в 1
Еще в самом начале разработки Gameplay, мы решили добавить поддержку устройств 2 в 1. Идея была в том, что приложение работает постоянно, но отображение контроллеров не происходит в настольном режиме. В случае перехода в режим планшета, контроллер Gameplay начинает отображаться для обеспечения сенсорного управления в приложении. Активируйте поддержку в настройках виртуального контроллера на устройствах 2 в 1.
Рисунок 5 ‒ Настройки виртуального контроллера
Для тех, кто хочет получить дополнительную информацию о переключении режимов в устройствах 2 в 1, в разделе Ресурсы приведена отличная рекомендация с примерами кода.
Внедрение DLL
Внедрение DLL (DLL injection) - это метод, используемый для выполнения кода внутри адресного пространства другого процесса путем загрузки внешней библиотеки динамической компоновки. Внедрение DLL часто используется внешними программами для вредоносных целей, но эту технологию можно использовать и в «мирных целях», чтобы расширить возможности программы так, как это не было предусмотрено ее авторами. В программе Gameplay нам требовался способ вставки данных в поток входных данных процесса (запущенной игры), чтобы сенсорный ввод можно было преобразовать во входные данные, распознаваемые игрой. Из множества методов реализации внедрения DLL программисты Ideum выбрали вызовы подключения к Windows в API SetWindowsHookEx. В конечном итоге выбрали подключения к определенным процессам вместо глобальных подключений по соображениям производительности.
Запуск игр из сторонней оболочки запуска
Мы изучили два метода подключения к адресному пространству целевых процессов. Приложение может подключиться к адресному пространству запущенного процесса, или же приложение может запустить целевой исполняемый файл в качестве дочернего процесса. Оба метода вполне жизнеспособны. Тем не менее на практике оказалось, что намного проще отслеживать и перехватывать процессы или потоки, созданные целевым процессом, если наше приложение является родительским по отношению к этому целевому процессу.
При этом возникает проблема для клиентов приложений, таких как Steam и UPlay, запускаемых при входе пользователя в систему. В Windows не предоставляется гарантированного порядка запуска процессов, а процесс Gameplay должен быть запущен до этих процессов, чтобы получить возможность подключаться к управлению. Gameplay решает эту проблему путем установки компактной системной службы, которая отслеживает запуск приложений при входе пользователя в систему. Если запускается одно из интересующих нас клиентских приложений, Gameplay может подключиться к ней в качестве родительского процесса, и тогда элементы управления будут отображаться нужным образом.
Полученный опыт
Фильтрация данных мыши
При разработке мы столкнулись с тем, что в некоторых игра неверно обрабатывались входные данные виртуальной мыши, полученные с сенсорного экрана. Эта проблема чаще всего возникала в шутерах от первого лица или в ролевых играх, где при помощи мыши выбирается направление взгляда. Проблема состояла в том, что входные данные мыши, полученные с сенсорного экрана, были абсолютными по отношению к какой-либо точке на экране, а значит, и в игровой среде. Изза этого сенсорный экран был практически бесполезным в качестве устройства для управления направлением взгляда с помощью мыши. Решить эту проблему удалось путем фильтрации входных данных мыши, перехватывая поток входных данных игры. Это дало возможность имитировать входные данные мыши для управления направлением взгляда с помощью такого экранного элемента управления, как джойстик. Потребовалось немало времени и усилий, чтобы настроить чувствительность джойстика и зону нечувствительности, чтобы они по ощущениям совпадали с мышью, но когда это было сделано, все прекрасно заработало. Это исправление можно увидеть в действии в таких играх, как Fallout: New Vegas или The Elder Scrolls: Skyrim .
Отбор игр для сенсорного управления
Разработчики Ideum потратили немало времени, настраивая виртуальные контроллеры для оптимального удобства в играх. Различные элементы игр определяют пригодность игры для Gameplay. Ниже приводятся общие правила, определяющие, какие типы игр хорошо работают с Gameplay.
Удобство игры - это важный фактор использования или отказа от использования Gameplay для этой игры, но самый важный фактор - это стабильность. Некоторые игры вообще не работают ни с подключением к управлению, ни с внедрением входных данных, ни с наложением. Это может происходить по разным причинам, но чаще всего сама игра отслеживает свое пространство в памяти или поток входных данных, чтобы избежать подмены данных. Программа Gameplay сама по себе является вполне безопасной и разрешенной, но она использует технологии, которые также применяются для вредоносных целей, поэтому, к сожалению, некоторые игры не будут работать с Gameplay, если в них нет встроенной поддержки сенсорного управления.
Сегодня даже небольшие компании уходят от автономных децентрализованных Wi-Fi-сетей, которые дорого эксплуатировать, сложно защитить от вторжения и еще сложнее масштабировать. Наиболее распространены централизованные сети, управляемые с помощью контроллеров. Затраты на приобретение и эксплуатацию контроллеров составляют значительную часть стоимости такой сети. Для решения этой проблемы сегодня все чаще используются виртуальные контроллеры.
Наиболее распространенные корпоративные Wi-Fi-сети (WLAN) обычно используют проверенную концепцию централизованного контроллера, который управляет другими контроллерами и точками доступа (AP). В таких системах через физический контроллер проходит весь трафик и данные, необходимые для управления сетью.
Новая концепция виртуализации предполагает программный контроллер, через который проходят только данные для управления: аутентификация, координация сессий, предотвращение вторжений, управление радиопокрытием и т. д. Остальной трафик в таких сетях минует контроллер и передается через сеть напрямую. Компания Adtran в своих решениях Bluesocket впервые разделила трафик и управление за счет умных AP, которые самостоятельно осуществляют аутентификацию пользователей и проводят трафик. Виртуальные контроллеры Bluesocket имеют аббревиатуру vWLAN (virtual Wireless LAN), примем это обозначение для всех сетей с виртуальным контроллером, который не проводит трафик.
Рисунок 1. Традиционная схема централизованной сети с контроллером, через который проходит весь трафик
Аппаратный контроллер часто является самым «узким» местом ИТ-системы, поскольку через него проходит весь трафик. Любое резкое увеличение нагрузки может затормозить или даже «утопить» контроллер и привести к сбою в работе всей сети. Часто этим фактом могут воспользоваться злоумышленники - провести успешную DDoS атаку на корпоративную сеть. Также большое количество контроллеров создает множество мобильных доменов, что усложняет эксплуатацию и создает дополнительные риски взлома.
Виртуальный контроллер работает только с данными управления, а трафик идет через сеть на месте подключения, поэтому масштабировать сеть проще. Данные, управляющие сетью, шифруются и могут передаваться через Интернет, но при этом потеря связи означает потерю управления сетью. Правда и в этом случае vWLAN может поддерживать работу внутренней сети в автономном режиме. Если при аутентификации используется удаленный сервер RADIUS, то в случае потери связи с контроллером новые пользователи не смогут подключиться к сети. Для предотвращения подобных ситуаций необходимо заранее настроить дополнительные способы аутентификации на случай недоступности RADIUS.
Рисунок 2. Новая схема централизованной сети с контроллером, через который проходит только трафик для управления
Функционал WLAN и vWLAN в настоящее время не отличается, например, Bluesocket предлагает физические и виртуальные серверы, на которых используется один и тот же программный код и приложения.
WLAN и vWLAN
Популярная сейчас концепция SaaS, при которой сеть Wi-Fi предлагается как услуга, также требует минимум настраиваемых аппаратных решений, потенциально обещает значительную экономию средств в сравнении с традиционными аппаратными системами. Слабым звеном в реализации этой концепции является контроллер, как центр сети.
Небольшим и средним компаниям часто не по карману покупка, резервирование и обслуживание контроллера WLAN с десятками AP. Впрочем, и для крупных организаций покупка мощного контроллера, например, Aruba 7210 (до 512 AP), обойдется в сумму больше $15 тыс., что требует серьезного подхода при планировании сети. Но в любом случае возможности расширения сети ограничены, и при очередном увеличении масштабов нужно закупать новое дорогостоящее оборудование. У сетей vWLAN таких аппаратных ограничений нет, например, виртуальный контроллер Bluesocket на мощной платформе виртуализации VMware может обслуживать до 10 тыс. AP и до 50 тыс. пользователей для Wi-Fi современного стандарта 802.11n.
Рисунок 3. Виртуальный контроллер vWLAN позволяет быстро развернуть надежную сеть с множеством удаленных точек доступа (AP)
Виртуальный контроллер позволяет отказаться от всех трат на аппаратную часть, кроме покупки точек доступа. Например, контроллер Bluesocket для vWLAN может поставляться в виде образа, который размещается в частном или публичном облаке. Обслуживание контроллера может производить владелец облака, управление сетью происходит через гипервизор дата-центра. Масштабирование такой сети очень простое: с помощью покупки лицензий на любое количество точек доступа.
Движение трафика без «протаскивания в бутылочное горлышко» физического контроллера резко снижает нагрузку на контроллер vWLAN и экономит средства за счет использования более «медленного» соединения при подключении контроллера через Интернет. Это означает меньшие требования к производительности оборудования. К тому же на контроллере vWLAN проще выполнить резервирование сети, в том числе разместить запасной контроллер в другом регионе, что повышает надежность и дает возможность бесшовного обновления софта.
У WLAN есть преимущество при модернизации старой и очень крупной сети — обычно проще купить новый более мощный контроллер, чем переделывать сеть под виртуальный контроллер. Но при этом в WLAN необходим канал от AP до контроллера, который позволяет передавать трафик внутри защищенного тоннеля. Это усложняет развертывание сети с центральным контроллером и существенно удорожает ее эксплуатацию.
Рисунок 4. В технологии Aruba Instant роль виртуального контроллера берет на себя точка доступа (AP)
Свой вариант виртуализации предлагает компания HPE. Ее решение Aruba Instant использует уникальный подход к виртуализации контроллера. В сети Aruba Instant виртуальный контроллер размещается на одной из AP. Он обеспечивает обычные функции контроллера, аутентификацию RADIUS, отвечает за автоматическое конфигурирование сети, гостевой доступ и другие сетевые сервисы. Администратор сети может настраивать политики доступа и каналы связи для каждого идентификатора беспроводной сети или пользователя. Фактически, это децентрализованная система, в которой AP, не способная найти контроллер, сама назначает себя контроллером. Преимущество Aruba Instant в простоте и дешевизне развертывания: можно начать с одной AP и постепенно наращивать емкость сети. Поэтому обычно такие сети используются в небольших офисах. Следует учесть, что несмотря на наличие встроенных функций безопасности, например межсетевого экрана, к защищенности сетей Aruba Instant есть вопросы. В частности, в мае 2016 г. инженер Google Свен Блюменштейн (Sven Blumenstein) опубликовал отчет о 22 уязвимостях Aruba Instant, включая «слабый» софт, удаленный запуск программного кода, раскрытие содержания информации и т. д.
Бреши обещают закрыть в третьем квартале 2016 г., но Блюменштейн отметил, что его список уязвимостей явно не исчерпывающий. На этом фоне решения Bluesocket vWLAN выглядят намного более надежными благодаря использованию традиционных проверенных систем безопасности, разработанных для централизованных сетей.
Централизованная сеть — лучшее сегодня
Централизованная сеть с виртуальным контроллером в настоящее время предлагает максимальную гибкость и защищенность. Например, виртуальный контроллер Bluesocket vWLAN может одинаково эффективно использоваться в малом офисе или в транснациональной компании и масштабируется на 90 % больше, чем традиционные решения. При выделении виртуальному контроллеру Bluesocket четырех ядер CPU, 6 Гб ОЗУ и 41 Гб накопителя обеспечивается работа более 1,5 тыс. AP и 48 тыс. пользователей.
Разделение потоков основных данных и информации для управления сетью за счет умных AP освобождает ресурсы контроллера Bluesocket, но при этом сохраняется высокая защищенность сети. Кроме того, виртуальный контроллер может легко мигрировать на новый сервер во время очередной модернизации ИТ-системы компании. Решения Bluesocket обеспечивают развертывание безопасных беспроводных сетей современных стандартов 802.11a/b/g/n/ac и подходят для средних и крупных коммерческих, правительственных организаций с большим количеством пользователей на значительной площади.
Рисунок 5. Контроллеры Edimax и Bluesocket имеют встроенные инструменты, которые обеспечивают быстрое развертывание сети
Аналогичными возможностями обладают контроллеры Edimax, которые также проводят только данные управления, а не весь трафик. При этом, например, контроллер Edimax APC500 сразу имеет встроенную функцию радиопланирования с привязкой к Google Maps, что облегчает развертывание беспроводной сети. Он может использоваться для закрытых корпоративных и открытых общественных сетей (в ресторанах, гостиницах, парках и т. п.). В этом случае возможно подключение новых пользователей через Captive Portal, в том числе и с помощью SMS-аутентификации. Это позволяет выполнить современные требования российского законодательства по обязательной идентификации абонентов беспроводных сетей.
Таким образом, можно констатировать, что проектирование современной сети означает в большинстве случаев использование централизованного управления сетью (с помощью контроллера), но с разделением трафика на данные управления и непосредственно «рабочий» трафик, который циркулирует в сети и не проходит через контроллер. Это в значительной степени разгружает контроллер и каналы связи, устраняя основное узкое место в сети. При этом обеспечивается полный функционал и максимальная защита информации при снижении стоимости эксплуатационных расходов
Мне нужна консультация. Свяжитесь со мной.
Так как виртуальным машинам обычно требуется жесткий диск, то VirtualBox должен предоставлять "реальное хранилище" данных гостю в качестве виртуального жесткого диска. Существует три способа достичь этого:
Чаще всего VirtualBox использует большие файлы на реальном диске и предоставляет его гостю как виртуальный жесткий диск. Они описаны в разделе “Disk image files (VDI, VMDK, VHD, HDD)” .
Если у вас есть сервер iSCSI storage, вы можете подключить VirtualBox к нему, который описывается в разделе “iSCSI servers” .
Наконец, в качестве экспериментальной функции, вы можете разрешить виртуальным машинам непосредственно использовать жесткие диски хоста; эта расширенная функция описывается в разделе “Using a raw host hard disk from a guest” .
Каждое виртуальное устройство хранения (файл образа, iSCSI target или физический жесткий диск) необходимо подключить к виртуальному контроллеру жестких дисков виртуальной машины. Механизм подключения раскрывается в следующем разделе.
Контроллеры жестких дисков: IDE, SATA (AHCI), SCSI, SAS
В настоящем компьютере, жесткие диски и CD/DVD устройства подключаются к устройству, которое называют контроллером жесткого диска и которое управляет дисковыми операциями и передачей данных. VirtualBox может эмулировать четыре наиболее используемых типа контроллеров жестких дисков, которые встечаются в современных ПК: IDE, SATA (AHCI), SCSI и SAS.
IDE (ATA) используются с 1980 года. Вначале, этот тип интерфейса работал только с жесткими дисками, но позднее был расширен также для использования устройств CD-ROM и других типов внешних носителей. В компьютерах данный стандарт используется плоский 40 или 80 жильный кабель (шлейф). С помощью этого кабеля возможно подключить два устройства к контроллеру, которые называют "master" и "slave". К типичному контроллеру жестких дисков подключаются два таких кабеля; то есть, большинство компьютеров поддерживают до 4 устройств.
В VirtualBox по умолчанию, к каждой виртуальной машине подключается один IDE контроллер, который позволяет вам подключить до четырех виртуальных устройств хранения данных. (По умолчанию, один из этих четырех -- secondary master -- настроен на подключение виртуального привода CD/DVD, но эту настройку можно изменить. )
Даже если ваша гостевая ОС не поддерживает SCSI или SATA устройства, она всегда обнаружит IDE контроллер, который по умолчанию всегда подключен.
Вы также можете точно указать тип IDE контроллера, который должен быть предоставлен виртуальной машине (PIIX3, PIIX4 или ICH6). Тип не влияет на производительность, но в случае если вы импортирует виртуальную машину от других виртуальных сред, операционная система в этой машине может не заработать, если ей не предоставить нужный тип контроллера.
После создания новой ВМ в графическом интерфейсе, с помощью визарда "Созать новую виртуальную машину" , вы обнаружите один IDE контроллер к которому будет подключин виртуальный привод CD/DVD.
Serial ATA (SATA) это новый стандарт, появившийся в 2003. По сравнению с IDE, он поддерживает более высокую скорость обмена и позволяет подключить большее количество жестких дисков к контроллеру. Так же как на реальном компьютере, устройства могут быть добавлены и удалены во время работы системы. Стандарт интерфейса для SATA контролеров называется Advanced Host Controller Interface ( AHCI ).
По соображениям совместимости, AHCI контроллеры по умолчанию работают с дисками в режиме называемом IDE совместимом, пока явно не указать использование SATA. Этот режим ("IDE compatibility mode") означает, что устройства будут определяться и управляться через BIOS компюютера. Still, disks assigned to those slots will operate in full-speed AHCI mode once the guest operating system has loaded its AHCI device driver.
Как и реальный SATA, виртуальный SATA контроллер работает быстрее и также меньше нагружает процессор, чем IDE контроллер. Кроме того, возможно подключение до 30 виртуальных жестких дисков к одной ВМ, а не трех как в IDE (плюс уже подключенный DVD привод). Первые четыре слота (с номерами 0-3 в окне настроек) по умолчанию работают в режиме IDE совместимости.
Поэтому, начиная с версии 3.2, в зависимости от вида гостевой операционной системы, VirtualBox использует SATA их по умолчанию для новых создаваемых вириуальных машин. По умолчанию, создается один виртуальный SATA контроллер и новый создаваемый виртуальный жесткий диск подключается к нему.
Предупреждение
SATA контроллер и виртуальные диски подключенные к нему (включая диски в режиме IDE совместимости) будут видны только операционным системам с поддержкой AHCI. Например, AHCI не поддерживается в системах Windows до Windows Vista, т.е. в Windows XP (даже с SP3) вы не увидите диски пока не установите дополнительные драйвера. Возможно сменить IDE на SATA после установки ОС, установив SATA драйвера и изменив тип контроллерв в диалоге настроек ВМ.
Для добавления SATA контроллера к виртуальной машине у которой его нет (возможно по причине создания ее в ранних версиях VirtualBox или потому, что SATA не поддерживается гостевой ОС), перейдите на закладку "Носители" диалога настроек и кликните на кнопке "Добавить контроллер" под списком "Носители информации", выбрав далее "Добавить SATA котроллер". После этого, дополнительный контроллер появится в виртуальной машине как PCI устройство и вы сможете подключать виртуальные диски к нему
Чтобы изменить режим совместимости IDE для SATA контроллера, обратитесь к Разделу, “VBoxManage modifyvm” .
SCSI это другой промышленный стандарт, расшифровывается как "Small Computer System Interface". Он был создан еще в 1986, в качестве универсального интерфейса для передачи данных между различными видами устройств, включая устройства хранения данных. В настоящее время SCSI по прежнему используют для подключения жестких дисков и ленточных устройств. Он до сих пор используется в высокопроизводительных компьютерах и серверах.
Для совместимости с другими программами виртуализации, VirtualBox поддерживает LsiLogic и BusLogic SCSI контроллеры, которые позволяют подключать до 15 виртуальных жестких дисков.
Для добавления SСSI контроллера к виртуальной машине перейдите на закладку "Носители" диалога настроек и кликните на кнопке "Добавить контроллер" под списком "Носители информации", выбрав далее "Добавить SCSI котроллер". После этого, дополнительный контроллер появится в виртуальной машине как PCI устройство.
Предупреждение
Как и в случае с другими типами контроллеров, SCSI контроллер будет видны только операционным системам, которые могут работать с ними. Windows 2003 и позднии версии поставляется с драйвервми для LSI Logic контроллера, а Windows NT 4.0 и Windows 2000 поставляются с драйверами BusLogic контроллера. Windows XP не имет драйверов ни для одного из них.
Serial Attached SCSI (SAS) это другой стандарт, который использует систему комманд SCSI. As opposed to SCSI, however, with physical devices, serial cables are used instead of parallel ones, which simplifies physical device connections. In some ways, therefore, SAS is to SCSI what SATA is to IDE: it allows for more reliable and faster connections.
Для гостевых систем требующих SAS контроллеров, VirtualBox эмулирует LSI Logic SAS контроллер, который может быть подключен тем же путем, что и SCSI контроллер. В настоящее время, можно подключить до 8 устройств к SAS контроллеру.
Предупреждение
Как и SATA, SAS контроллер будет доступен только в ОС которые могут с ним работать. Например, SAS не поддерживается в системах Windows до Windows Vista, т.е. в Windows XP (даже с SP3) вы не увидите диски пока не установите дополнительные драйвера.
Суммируя вышесказанное, VirtualBox предоставляет вам следующие виртуальные устройства хранения:
в режиме IDE совместимости (по умолчанию слоты 0-3) или
четыре слота для подключения к стандарным IDE контроллерам, которые всегда представлены (один из них как виртуальный привод CD/DVD);
30 слотов для подключения к SATA котроллеру, при условии что, что ваша гостевая ОС может работать с ними
15 слотов для подключения к SCSI контроллеру, если гостевая ОС их поддерживает;
8 слодов для подключения к SAS контроллеру, если гостевая ОС их поддерживает;
Учитывая большой выбор контроллеров, перед вами может возникнуть вопрос выбора нужного. Вы должны избегать использование IDE, конечно если он не является единственно поддерживаемым контроллером в вашем госте. Реальной разницы между SATA, SCSI и SAS не существует. Такое разнообразие контроллеров нужно только для совместимости VirtualBox с другими гипервизорами и аппаратными требованиями гостей.
Файлы образа диска (VDI, VMDK, VHD, HDD)
Файлы дисковых образов располагаются на хост системе и определяются гостевыми системами как жесткие диски определенного размера. При чтении или записи данных с диска гостевой ОС, VirtualBox перенаправляет дисковые запросы к файлу образа.
Как и у физического диска, у виртуального диска есть размер (емкость), который должен быть указан при его создании. Но в отличии от физических дисков, VirtualBox позволяет вам увеличивать образ файла после его создания, даже в случае когда он содержит данные; см. подробности в.
VirtualBox поддерживает 4 типа файлов образов диска:
Независимо от формата виртуальных дисков, как упоминается в Разделе, “Создание виртуальных машин” , существует два типа создаваемых образов: фиксированного размера и динамически расширяемые.
Если вы создаете образ фиксированного размера , то файл образа будет создан на хосте с примерно таким же размером как и у виртуального диска. Т.е, для 10G диска, вы получите 10G файл. Заметьте что создание фиксированных образов может занять довольно значительное время, в зависимости от размера образа и производительности дисковых операций вашей системы.
Для более гибкого управления виртуальными носителями, используются динамически расширяемые образы . При создании данный образ будет иметь небольшой размер, за счет неиспользуемого пространства виртуального диска, но по мере использования, файл образа будет увеличиваться. Данный вид файла занимает меньше места на начальном этапе, однако VirtualBox необходимо увеличивать размер образа (пока образ не достигнет максимального размера), что ведет к замедлению дисковых операций по сравнению с дисками фиксированного размера. Однако, после достижения предела расширения динамического диска, потери производительности операций чтения и записи уже не так значительны.
Менеджер виртуальных носителей
VirtualBox хранит данные обо всех жестких дисках, CD/DVD-ROM и образах гибких дисков которые используются в виртуальных машинах. Обычно они упоминаются как "известные носители" и которые могут быть получены из 2 источников:
Список известных носителей можно просмотреть и изменить в Менеджер виртуальных носителей , который можно открыть через меню "Файл" в главном окне VirtualBox:
Носители сгруппированы на трех вкладках по их форматам. Форматы дисков:
Образы жестких дисков, в виде собственного VirtualBox Virtual Disk Image (VDI) или формата стороннего поставщика, которые перечисленны в предыдущем разделе;
CD/DVD образы в ISO стандарте;
образы дискет в стандартном формате RAW (полная копия носителя).
Как вы видите на скриншоте выше, для каждого образа, менеджер виртуальных носителей показывает полный путь к файлу образа и другую информацию: например,подключен ли образ к ВМ, если таковые имеются.
Менеджер виртуальных носителей позволяет вам
удалить образ из хранилища (и при необходимости также удалить образ файла);
"освободить" образ, то есть, отключить его от виртуальной машины, если он подключен к одной из машин.
Начиная с версии 4.0, для создания новых образов дисков, используйте закладку "Носители" в диалоговом окне настроек виртуальной машины (т.к. образы дисков по умолчанию сохраняются в папку виртуальной машины).
Файлы образов жестких дисков можно скопировать на другой хост и импортировать в другие виртуальные машины.
Замечание
Не создавайте копии виртуальных дисков простым копированием. При импорте таких копий в виртуальную машину, VirtualBox будет выдавать ошибку, так как VirtualBox присваивает уникальный идентификатор (UUID) каждому образу, убедитесь что образы используются одновременно только в одной ВМ. Ознакомьтесь с разделом, “Клонирование образов дисков” для получения информации по вопросу клонирования образов. Если вы хотите скопировать виртуальную машину на другую систему, то VirtualBox предоставит вам механиз импорта/эксорта, который лучше всего подойдет для этой задачи; см. раздел “Importing and exporting virtual machines” .
Особые режимы записи образа
Для каждого образа виртуального диска поддерживаемого в VirtualBox, вы можете отдельно установить его поведение в случае выполнения операций записи в виртуальной машине и при работе со снимками состояний. Это относится ко всем форматам образов(VDI, VMDK, VHD or HDD) и не зависит от типа образа - фиксированого размера или динамически расширяемого.
По умолчанию, образ создается в режиме "normal" . Для преобразования режима существующего образа в другой, используйте VBoxManage modifyhd ; см. Раздел, “VBoxManage modifyhd” . Альтернативный метод - используя VBoxManage для подключения образа к ВМ используя аргумент --mtype ; см. .
Для normal образов (по умолчанию) не существует ограничений на операции чтения и записи на диск.
Когда вы делаете снимок состояния вашей виртуальной машины (см. Раздел, “Снимки состояний”), состояние диска в режиме "normal" будет всегда сохранено в снимке и при возврате к снимку, его состояние будет полностью сброшено к состоянию на момент создания снимка.
(Technically, strictly speaking, the image file itself is not "reset". При создании снимка, VirtualBox "замораживает" файл образа и не записывет данные в него. При операциях записи в ВМ, создается другой "разностный" файл образа, в который записываются все изменения.
Когда вы подключаете "normal" образ к более чем одной виртуальной машине, то только одна из этих виртуальных машин может работать с этим файлом образа в одно и то же время, иначе не возможно было бы разрешить конфликты одновременной записи данных в образ.
В отличии от него, на жесткие диски write-through не влияет механизм снимков состояния: их состояние не сохраняется и не восстанавливается при создании и восстановлении снимков.
Жесткие диски Shareable это вариант write-through жестких дисков. Для них также не сохраняется и не востанавливается состояние при работе со снимками. Их различие только в совместной работе с несколькими ВМ. Shareable диски могут быть подключены к нескольким ВМ, которые могут работать одновременно. Это особеность, позволяет использовать их в кластерных файловых системах. Только образы фиксированного размера могут использоваться в этом случае - использование динамических расширяемых дисков запрешено.
Предупреждение
This is an expert feature, and misuse can lead to data loss -- regular filesystems are not prepared to handle simultaneous changes by several parties.
Далее, immutable образы хранят записанные на них данные только при работе виртуальной машины; все изменения будут потерены, когда ВМ будет запущена в следующий раз. В отличие от "normal" образов, immutable образы могут использоваться в нескольких виртуальных машинах без ограничений.
Создание immutable образа не имеет смысла, поскольку изначально он не содержит данных и все данные на нем будут потерены при перезапуске машины (конечно если вы действительно хотите иметь такой диск, то создавайте). Обычно, вначале вы должны создаете "normal" образ и когда вы заполните его нужными данными можете сделать его immutable.
Если вы сделаете снимок виртуальной машины с immutable образом, то при каждом ее включенииэтот образ будет соответствовать последнему состоянию (текущему) снимка (а не состоянию оригинального immutable образа).
Замечание
As a special exception, immutable images are not reset if they are attached to a machine whose last snapshot was taken while the machine was running (a so-called "online" snapshot). As a result, if the machine"s current snapshot is such an "online" snapshot, its immutable images behave exactly like the "normal" images described previously. To re-enable the automatic resetting of such images, delete the current snapshot of the machine.
Фактически VirtualBox никогда не пишет напрямую never в immutable образ. Все операции записи в машине перенаправляются в разностный образ; при следующем включении ВМ, разностный образ очищается. Differencing образ очищается только при включении виртиуальной машины VirtualBox"ом, а не при перзапуске запрошеной внутри виртуальной машины. This is also why immutable images behave as described above when snapshots are also present, which use differencing images as well.
Образ в режиме multiattach может быть подключен одновременно к более чем одной виртуальной машине, даже если эти машины работают одновременно. Для каждой ВМ к которой этот образ подключен, создается разностный образ. В результате, данные которые пишутся на виртуальный диск одной машины не доступны на другой, для каждой машины создается своя собственная история записи данных multiattach образа.
В техническом плане, "multiattach" образ идентичен "immutable" образу за исключением того, что его содержимое не очищается при каждом запуске машины.
Наконец, read-only образ используется для CD/DVD образов, т.к. на CD/DVD нельзя записать.
Для иллюстрации отличий между разными типами образов рассмотрим работу со снимками состояний: предположим вы установили гостевую ОС в виртуальной машине и сделали ее снимок состояния. Представим что ваша ВМ была заражена вирусом и вы хотите вернуться к сохраненному ранее состоянию. Для normal образа диска, вы просто восстанавливаете состояние ВМ и предыдущее состояние вашего диска будет восстановлено (вирус будет удален). Для immutable диска, вне зависимости от снимка, все что нужно сделать так это перезапустить ВМ, изменения сделанные вирусом в файловой системы будут удалены. Для write-through образа однако, вы не можете просто удалить последствия действий вируса средствами виртуализации, вам необходимо будет "вылечить" вашу виртуальную машину как реальный компьютер.
Использование write-though образов удобно, когда вы захотите сохранять важные данные вне зависимости от снимков состояний и вам необходимо использовать образ в нескольких ВМ: вы можете использовать один immutable диск для ОС, а другой write-through диск для файлов с данными.
Differencing образы
В предыдущем разделе упоминались разностные образы, как они мспользуятся в снимках состояний ВМ, immutable образы и диски для множественного подключения. Для любознательных пользователей VirtualBox в этом разделе более подробно описываются детали их работы.
Разностный образ это специальный образ диска, который содержит только изменения/отличия данных из другого образа. Отделное использование его бесполезно, он должен быть всегда ссылаться на другой образ. Разностный образ обычно рассматривается как "дочерний", который хранит изменения для его "родителя".
В активный разностный образ записываются все данные по операциям записи от виртуальной машины. Разностный образ состоит только из секторов виртуального жесткого диска, которые были изменены с момента его создания. Когда машина читает сектор с этого виртуального жеского диска, она вначале ищет его в разностном образе. Если такой сектор найден, то но считывается из него; если нет, то VirtualBox ищет его в образе родителя. Другими словами, родитель это образ "только для чтения"; он никогда не используется для записи, но если сектор на не был изменен то он используется для чтения данных.
Разностыне образы могут образовывать цепочки. Если создается другой разностный образ для виртуального диска, который уже имеет разностный образ, то он становится "внуком" для родительского образа. Первый разностный образ также становится доступным только для чтения, а операции записи выполняются только на разностном образе второго уровня. При чтении с виртуального диска, VirtualBox необходимо сначала обработать второй разностный образ, затем первый и если сектор не будет найден то оригинальный образ.
Возможно создание неограниченого количества разностных образов и любой образ может иметь более одного дочерьнего элемента. В результате, может быть создана сложная древовидная структура с родительскими, "одноуровневыми" и дочерними элементами. Операции записи всегда выполняются на один "активный" разностный образ, а для операций чтения, VirtualBox может потребоваться просмотреть все сектра в цепочке образов, вплоть до родительского. Вы можете посмотреть на такое дерево в менеджере виртуальных ностелей:
 |
In all of these situations, from the point of view of the virtual machine, the virtual hard disk behaves like any other disk. While the virtual machine is running, there is a slight run-time I/O overhead because VirtualBox might need to look up sectors several times. This is not noticeable however since the tables with sector information are always kept in memory and can be looked up quickly.
Разностные образы могут использоваться в следующих ситуациях:
VirtualBox восстановит настройки виртуальной машины, которые были сохранены в снимке состояния. В результате, если вы изменяли настройки машины, то они будут отменены.
If the snapshot was taken while the machine was running, it contains a saved machine state, and that state is restored as well; after restoring the snapshot, the machine will then be in "Saved" state and resume execution from there when it is next started. Otherwise the machine will be in "Powered Off" state and do a full boot.
Для каждого образа диска подключенного к машине, с видом differencing, будут отменены все действия выполненные операциями записи на него и его состояние будет восстановлено из оригинального родительского образа. (If you restored the "root" snapshot, then this will be the root disk image for each attachment; otherwise, some other differencing image descended from it.) This effectively restores the old machine state.
Снимки состояний. Когда вы создаете снимок, как описывалось в предыдущей секции, VirtualBox "замораживает" образы подключенные к виртуальной машине и создает разностный образ для каждого из них (если быть точным: один для каждого образа, который не находится в режиме "write-through"). С точки зрения виртуальной машины, виртуальные диски продолжают работу, но все операции записи передаются в разностные образы. В любое время вы можете создать другой снимок, для каждого подключенного жесткого диска, будет создан и подключен другой разностный образ, формируя цепочку или дерево.
На рисунке выше, вы можете увидеть, что к исходному образу диска теперь подключен снимок состояния, который представляет состояние диска в момент создания снимка.
Если вы теперь восстановите снимок -- т.е. если вы хотите вернуть машину к состоянию сохраненному в снимке, то произойдет следующее:
Если вы позже удаляете снимок для освобождения места на диске хоста, у каждого подключенного диска один из differencing образов становится не нужным. В данном случае, подключенный differencing образ не может быть просто удален. VirtualBox нужно просмотреть каждый сектор в разностном образе и скопировать нужные в родительский; это называется "объединение" образов и эта операция может быть длительным процессом, что зависит от размера разностного образа. Также для этой операции временно может потребоваться большое количество свободного дискового пространства.
Immutable образы. Если образ находится в режиме "immutable", то разностные образы также создаются. Как и в случае снимков, родительский образ переходит в режим только для чтения, а запись производится в разностный образ. Каждый раз при запуске виртуальной машины, все immutable образы отбрасывают свои собственные разностные образы.
Клонирование образов дисков
Вы можете сделать копии образов жестких дисков для того чтобы быстро создать другую виртуальную машину с такой же ОС. Однако, вам необходимо обязательно делать копию виртуального образа диска используя утилиту поставляемую с VirtualBox; см. the section called “VBoxManage clonehd” . Ее необходимо использовать, так как VirtualBox присваивает уникальный идентификационный номер (UUID) каждому образу диска, который хранится внутри файла образа и VirtualBox не будет работать с двумя образами с одинаковыми идентификаторами. В случае если вам нужно повторно импортировать дисковый образ, который вы скопировали обычным методом, вы можете использовать другую утилиту VirtualBox: импортируйте его вместо копирования.
Заметьте что новые дистрибутивы Linux идентифицируют загрузочные диски по ID устройств. ID который VirtualBox предоставляет устройствам получает из UUID образа виртуального диска. Поэтому если вы получили копию диска и попытаетесь загрузиться с него, но так как UID изменился, то гостевая система может не определить свой загрузочный диск и не загрузиться. В данном случае вы должны будете изменить ID диска в настройке загрузчика (например /boot/grub/menu.lst). The disk ID looks like this:
Scsi-SATA_VBOX_HARDDISK_VB5cfdb1e2-c251e503
ID для копии образа можно определить командой
Hdparm -i /dev/sda
Host I/O caching
Начиная с версии 3.2, в VirtualBox можно по желанию отключать кэширование I/O (буферизация ввода/вывода), которое по умолчанию выполняется ОС хоста для файлов виртуальных дисков.
Обычно, VirtualBox открывает файл образа диска как обычный файл, для которого выполняется кэширование операционной системой хоста, как и для всех других файлов системы. Основное преимущество этой операции - скорость: когда гостевая ОС пишет данные на диск хостовая ос использует кэш, приостанавливая физическую запись, а гостевой ОС может быть отослано сообщение об успешном выполнении операции записи. Также, когда вы запускаете ВМ в другой раз и имеется достаточно свободной памяти у ОС для кэширования, то значительные части виртуальных жестких дисков могут быть расположены в системной памяти и поэтому ВМ может получить доступ к данным значительно быстрее.
Заметьте, что это относится только к файловым образам; буферизация вывода никогда не применялась к виртуальным дискам расположенным на удаленных iSCSI хранилищах (см. раздел “iSCSI servers”).
Для виртуализации нескольких на одном хосте - буферизация это полезная настройка, но имеется несколько недостатков в этой технологии:
Отложенная запись, через кэш ОС, менее безопасна. Когда гостевая ОС записывает данные, то считается что данные сохранены, даже если не было физической записи на диск. Если по каким то причинам запись не происходит (сбой питания или ОС хоста), то увеличивается вероятность потери данных.
Образы дисков обычно имеют очень большие размеры. Поэтому, их кэширование может быстро занять весь кэш ОС хоста. Это может привести к замедлению работы хоста, особенно, если одновременно запущено несколько ВМ. Например, на Linux, возможна задержка всех операций записи процессе ожидания заполнения всего кеша и последующей его одновременной записи на диск, что может приводить к приостановке работы ВМ до нескольких минут. Это может привести к ошибкам I/O в гостевой ОС по таймауту.
Физическая память часто тратится впустую, т.к. у гостевых систем есть собственный кэш ввода/вывода, что приводит к дублированию операций буферизации (в кеше гостя и хоста).
Если вы решите отключить кэширование I/O хоста, то VirtualBox будет использовать свой собственный, маленький кеш только для буферизации записи, а для операций нет, т.к. чтение обычно буферизируется в гостевой ОС. Дополнительно, VirtualBox полностью поддерживает асинхронный ввод/вывод для SATA, SCSI и SAS контроллеров, посредством многопоточного ввода/вывода.
Асинхронный I/O не поддерживается для IDE контроллеров, поэтому вы возможно захотите включить кеширование в ваших ВМ с виртуальными IDE контроллерами.
Поэтому, VirtualBox позволяет вам настраивать кеширование операций вводв/вывода для каждого контроллера отдельно. Снимите галку с "кеширование операций ввода/вывода" на вкладке "Носители" или используйте следующую команду VBoxManage, для отключения кеширования виртуального контроллера:
VBoxManage storagectl
По упомянутым выше причинам, VirtualBox теперь использует по умолчанию SATA контроллер для новых виртуальных машин.
Ограничение пропускной способности для дисковых образов
Начиная с версии 4.0, VirtualBox позволяет ограничить максимальную полосу пропускания для асинхронного ввода/вывода. Возможно задание ограничений для нескольких образов, посредством групповых лимитов. Возможно задать более, чем один такой лимит.
Ограничения настраиваются через VBoxManage . В примере ниже создается групповая полоса пропускания названная "Limit" с лимит в 20 MB/s и она привязывается к подключенным дискам ВМ:
VBoxManage bandwidthctl "VM name" --name Limit --add disk --limit 20 VBoxManage storageattach "VM name" --controller "SATA" --port 0 --device 0 --type hdd --medium disk1.vdi --bandwidthgroup Limit VBoxManage storageattach "VM name" --controller "SATA" --port 1 --device 0 --type hdd --medium disk2.vdi --bandwidthgroup Limit
Для всех дисков в группе задан общий лимит, для примера выше это значит, что пропускная общая способность обоих дисков никогда не превысит 20 MB/s. Однако, если одному диску не требуется канал ввода/вывода, то оставшиеся диски в группе используют пропускную способность канала всей группы.
Ограничения для каждой группы может быть изменено при работающей ВМ и эти изменения сразу же вступают в силу. В следующем примере, для группы созданной в примере выше, задается лимит в 10 MB/s:
VBoxManage bandwidthctl "VM name" --name Limit --limit 10
Поддержка CD/DVD
Виртуальные приводы CD/DVD по умолчанию работают только в режиме чтения. Настройки носителей можно изменять во время работы ВМ. Вы можете выбирать тремя настройками:
Host Drive определяет, что гостем будет использоваться носитель в приводе хоста.
Image file (обычно ISO файл) гость будет иметь доступ только для чтения к данным файла образа.
Empty задает состояние отсутствия носителя в приводе.
Переключения описанных выше настройек, изменения носителя в приводе хоста или файла образа сразу передаются гостевой операционной системе, которая может реагировать на эти изменения (например запускать установщик программы).
Смена носителя может быть запрещено гостем и VirtualBox блокирует смену диска в этом случае. Вы можете принудительно удалить носитель в данной ситуации через графическую среду VirtualBox GUI или с помощью командной строки VBoxManage. Фактически это похоже на аварийное извлечение диска, которое обеспечивают многие приводы CD/DVD , но с этим действием связаны побочные эффекты: гостевая ОС может выдать сообщение об ошибке, и как в случае с реальным оборудованием, гостевые приложения могут вызывать сбои в работе. Используйте это метод с осторожностью.
Замечание
Наименование устройства предоставляемого гостю (которое в гостевой системе будет отображаться в утилитах настроек таких как Windows Device Manager) будет всегда "VBOX CD-ROM", независимо от текущей настройки виртуального привода. Это сделано для того, чтобы исключить срабатывания механизма поиска новых устройств в госте при изменении настроек ВМ.
Эмуляция стандартных CD/DVD приводов позволяет читать данные только со стандартных форматов CD и DVD. Гостю можно дать право на запись CD/DVD, посредством прямого доступа к приводу хоста, но данная функция имеет статус экспериментальной: В зависимости от аппаратной части хоста, это позволяет:
Записывать CD/DVD из гостевой системы, если привод CD/DVD хоста пишущий;
В диалоге настроек контроллера для подключенного носителя есть флажок "Разрешить прямой доступ" или вы можете использовать опцию --passthrough в команде VBoxManage storageattach ; см. раздел “VBoxManage storageattach” .
Даже в случае включенного режима прямого доступа, небезопасные команды, такие как прошивка привода. будут заблокированы. Формат Video CD не поддерживается даже в режиме прямого доступа, и поэтому не может быть просмотрен в виртуальной машине.
On Solaris hosts, pass-through requires running VirtualBox with real root permissions due to security measures enforced by the host.
Сервера iSCSI
iSCSI это стандарт для "Internet SCSI", который позволяет использовать протокол SCSI через Internet (TCP/IP) соединения. Подключение устройства iSCSI к компьютерным сетям (лучше с гигабитным Ethernet) позволяет их использовать как удаленный жесткий диск. В терминах iSCSI сервер предоставляющий ресурсы хранилища называется "iSCSI target", а клиент подключенный к серверу и использующий эти ресурсы "iSCSI initiator".
VirtualBox позволяет подключать удаленные хранилища iSCSI к виртуальной машине как виртуальный жесткий диск. Гостевая ОС не "видит" различий между образом виртуального диска (файлом VDI) и iSCSI target. Для этой цели в VirtualBox интегрирован iSCSI initiator.
Поддержка в VirtualBox iSCSI была разработана с соответствии со стандартом iSCSI, что позволяет работать со стандартными устройствами iSCSI targets. Для использования iSCSI с VirtualBox, вы должны использовать командную строку; см. раздел “VBoxManage storageattach” ended ; now they are discarded every time the machine is powered on.
Первое, чем отличаются виртуальные сетевые контроллеры, – это принадлежность. Принадлежать они могут Service Console (для ESX, у ESXi нет Service Console), VMkernel (самому гипервизору) и виртуальным машинам.
Если виртуальный контроллер принадлежит ВМ, то он может быть разных типов – Flexible, vmxnet2, vmxnet3, E1000. Но про них поговорим в разделе, посвященном свойствам и оборудованию виртуальных машин, а здесь сконцентрируем внимание на виртуальных сетевых контроллерах для Service Console и VMkernel.
Управляющий интерфейс ESX, виртуальный контроллер для Service Console (vswif)
Виртуальный сетевой контроллер для Service Console используется для управления сервером ESX. Один такой контроллер создается установщиком сервера ESX, именно ему принадлежит тот IP-адрес, который вы указывали при установке. Именно на IP-адрес Service Console вы подключаетесь клиентом vSphere, через него с сервером работает vCenter, на этот IP подключаются утилиты для работы с ESX. Также через интерфейс Service Console идут сигналы пульса (heartbeat) при работе кластера VMware HA. Наконец, некоторые варианты резервного копирования виртуальных машин осуществляются через интерфейсы Service Console.
Вам следует резервировать управляющий интерфейс, сделать это можно двумя путями, см. рис. 2.6.
В левой части рисунка вы видите дублированную конфигурацию единственного интерфейса Service Console. Она задублирована за счет того, что к вКоммута-
Рис. 2.6. Два варианта дублирования управляющего интерфейса ESX
тору подключены два сетевых контроллера. Таким образом, выход из строя одной физической сетевой карточки (а если они подключены к разным физическим коммутаторам – то и одного из них) не приведет к недоступности управления сервером ESX по сети.
В правой части рисунка вы тоже видите дублированную конфигурацию, но дублированную по-другому – созданы два интерфейса Service Console, на разных вКоммутаторах, следовательно, на разных vmnic. Если выйдет из строя один из каналов во внешнюю сеть (сам vmnic или порт в физическом коммутаторе, к которому он подключен, или сам физический коммутатор), то один из интерфейсов SC станет недоступен, но останется другой.
Первый вариант удобнее в использовании, но если мы не можем себе позволить выделить два vmnic на вКоммутатор с Service Console, то он будет невозможен. Выделить может не получиться, если количество сетевых контроллеров в сервере недостаточно под все наши задачи. Тогда имеет смысл пойти по второму пути. Само собой, на вКоммутаторах интерфейсы Service Console могут соседствовать с любыми другими виртуальными интерфейсами в любых количествах – на рис. 2.6 их нет для простоты.
Однако первый вариант резервирования не защитит от двух дополнительных типов проблем:
Q ошибки настроек интерфейса SC;
Создать еще один интерфейс очень просто: Configuration ? Networking ?
Аdd Networking (для создания нового вКоммутатора – то есть резервирование
по правому варианту с рис. 2.6). Нас спросят, группу портов для чего мы хотим создать на этом вКоммутаторе. Несложно догадаться, что сейчас нас интересует Service Console. Выбираем, жмем Next . Выберем, какие vmnic привязать к создаваемому сейчас вКоммутатору. Next . Указываем имя (Network Label) – это название группы портов.
«Service_Console_2» вполне подойдет.
Однако при чем здесь группа портов, мы ведь создаем виртуальный сетевой интерфейс Service Console? Дело в том, что любой виртуальный сетевой контрол лер числится подключенным именно к группе портов, поэтому при создании интерфейса SC из GUI мы создаем и интерфейс Service Console, и группу портов для него.
На стандартном виртуальном коммутаторе интерфейс Service Console всегда занимает свою группу портов целиком (или, что то же самое, группа портов для Service Console всегда состоит из одного порта). Этот факт не является ограничением – на одном вКоммутаторе могут сосуществовать любые виртуальные интерфейсы в любых комбинациях, просто под каждый интерфейс Serice Console (и, забегая вперед, VMkernel) создается отдельная группа портов.
Затем для виртуального контроллера указываем настройки IP. В принципе,
Единственный, наверное, нюанс – если хотим создать интерфейс SC не на но-
вом, а на уже существующем вКоммутаторе. Тогда делаем так: Configuration ?
Networking ? для нужного вКоммутатора нажимаем Properties ? и на вкладке
Наконец, в случае распределенных виртуальных коммутаторов пройдите Configuration ? Networking ? кнопка Distributed Virtual Switch ? ссылка Manage Virtual Adapters ? Add .
Будьте аккуратны в случае изменения настроек интерфейса SC, когда он один, – в случае ошибки (например, опечатки в IP-адресе) доступ к управлению ESX по сети станет невозможен. Решается такая проблема из командной строки для ESX или из BIOS-подобного локального интерфейса ESXi. В любом случае понадобится доступ к локальной консоли сервера – физически или по iLO и аналогам.
Обратите внимание. Виртуальный сетевой контроллер для Service Console называется vswif – при создании их из GUI им даются имена вида vswif#, в командной строке мы управляем этими объектами с помощью esxcfg-vswif.
Управляющий интерфейс ESXi
Для ESX управление идет через интерфейс Service Console. Но в составе ESXi нет Service Console. Поэтому для ESXi в качестве интерфейсов управления используются виртуальные сетевые контроллеры VMkernel, те из них, в свойствах которых установлен флажок «Management traffic» (рис. 2.7).
Таким образом, организационные соображения здесь те же самые, что и для интерфейсов Service Console в ESX, но в качестве самих интерфейсов выступают интерфейсы VMkernel с соответствующим флажком в свойствах.
Виртуальный сетевой контроллер для VMkernel (vmk)
И в ESX, и в ESXi мы можем создать виртуальные сетевые адаптеры для VMkernel, для гипервизора. Нужны они для:
Q vMotion – по этим интерфейсам будет передаваться содержимое оператив-
ной памяти переносимой ВМ;
Q подключения дисковых ресурсов по iSCSI в случае использования программного инициатора iSCSI;
Q подключения дисковых ресурсов по NFS;
Q Fault Tolerance – по этим интерфейсам будут передаваться процессорные инструкции на резервную ВМ в Fault Tolerance-паре;
Q (только на ESXi) управления сервером (на ESX для этого используется
сеть Service Console).
Рис. 2.7. Управляющий интерфейс ESXi
См. подробности и требования к сети для соответствующих функций в разделах, им посвященных.
Таким образом, работа гипервизора с сетью немного двойственна, потому что происходит на двух уровнях. С одной стороны, гипервизор имеет доступ и управляет физическими контроллерами; с другой – сам для себя, для своего доступа в сеть создает контроллеры виртуальные. Тем не менее такая схема весьма удобна для понимания: физические контроллеры – это всегда «ресурс», всегда только канал во внешнюю сеть. А как источник трафика, как активные объекты сети всегда выступают контроллеры виртуальные, в том числе для трафика гипервизора.
Виртуальные сетевые контроллеры для гипервизора создаются точно так же, как для Service Console (на ESX): Configuration ? Networking ? и затем:
Q либо Аdd Networking для создания нового вКоммутатора и интерфейса VMkernel на нем;
Q либо для существующего вКоммутатора Properties ? Add на закладке
Ports;
Q в случае распределенных виртуальных коммутаторов пройдите Configuration ? Networking ? кнопка Distributed Virtual Switch ? ссылка Manage Virtual Adapters ? Add .
В любом случае как тип добавляемого интерфейса выбираем VMkernel . Укажем имя группы портов и настройки IP для создаваемого интерфейса.
Обратите внимание на то, что для интерфейса VMkernel у нас есть возможность установить три флажка (рис. 2.8).
Каждый из флажков разрешает передачу соответствующего трафика через данный интерфейс. Технически допускается любая комбинация флажков на од-
Рис. 2.8. Настройки интерфейса VMkernel на ESXi
ном виртуальном интерфейсе. Однако рекомендуется трафик разных типов разносить по разным физическим сетевым контроллерам, из чего следует создание отдельного интерфейса VMkernel под разные типы трафика гипервизора. Устанавливать флажки следует только по необходимости.
К тому же в случае использования ESXi через интерфейс с флажком «Management traffic» по умолчанию не пересылается трафик iSCSI и NFS. Если вы планируете использовать один интерфейс для управления и обращения к IP-СХД, то лучше всего создать несколько интерфейсов, пусть даже из одной подсети и на одном и том же виртуальном коммутаторе.
Обратите внимание. Виртуальные сетевые контроллеры этого типа называются vmk – при создании их из GUI им даются имена вида vmk#, в командной строке мы управляем этими объектами с помощью команды esxcfg-vmknic.
Oculus Touch в продаже уже 2 месяца, и пора делать какие-то выводы. Как мы считаем, стал более мощной платформой виртуальной реальности, чем когда-либо прежде.
Touch не так просто стать успешными. Главный конкурент Рифта, на протяжении года был единственной VR гарнитурой для PC, со своими контроллерами для отслеживания движений рук. Теперь, Touch имеет возможность сравнять счет и сделать Oculus наиболее убедительным VR устройством на планете.
Давайте выясним, стали ли контроллеры от Oculus главным провалом компании, или же, наоборот, лучшим их решением.
Настройка
Настройка всегда была областью, в которой Oculus выигрывает. Несколько кликов в меню настроек и вы получаете вариант «добавить Touch» в раскрывающемся меню. После запуска, вам предлагается к просмотру очень полезный, анимированный туториал по настройке. Синхронизация беспроводных контроллеров с ПК очень простая — нужно зажать по кнопке на каждом контроллере менее чем на 30 секунд.
В отличие от гарнитуры Oculus, Touch требует наличия двух датчиков, чтобы нормально функционировать. Это означает, что вам нужно подготовить немного больше места, чем вы делали раньше и быть очень внимательными к размещению датчиков. Например, поставив камеры слишком близко друг к другу или слишком далеко друг от друга, возникнет ошибка во время установки, а для получения правильной конфигурации может потребоваться несколько попыток.
В большинстве случаев вы можете перейти от открытия контроллеров, до их использования, менее чем за пять минут, если сама гарнитура Rift уже готова к работе.
Туториал
После того, как вы закончили установку, вам предложиться туториал для Oculus Touch. Туториал состоит из двух простеньких игрушек, каждая из которых предназначена, чтобы вы привыкли к разнообразным возможностям ваших новых контроллеров.
Первым делом, вы окажетесь в эфирной бело-серой среде, в которой приятный женский голос расскажет вам про основные возможности Touch. Этот невидимый рассказчик покажет как использовать уникальные кнопки, аналоговые стики и так далее. Как только вы доказали вашему всевидящему наставнику, что можете манипулировать каждым контроллером, вы телепортируетесь в следующий туториал, где все становится по-настоящему интересно.
First Contact — это первый VR опыт, в котором можно будет должным образом оценить контроллеры Touch. Он бросает вас в научно-фантастическкую гостиную 80-ых, где находиться ваш собственный робот. Хотя First Contact проходится всего за пять минут, но учит всему необходимому: как бросать, хватать, размахивать, перестреливаться и так далее.
В целом, First Contact — хорошо продуманный туториал, который объяснит все даже самому неопытному новичку в виртуальной реальности. И он делает это со стилем.
Функциональность
Функциональность и эргономичность являются областями, где Oculus Touch заставляет своих конкурентов краснеть. Touch может сделать все, что контроллеры HTC Vive или PlayStation Move, и даже больше.
Так же, как палочки Vive, Touch позволяет подобрать виртуальные объекты с помощью кнопки сбоку, стрелять при помощи триггера, а вместо сенсорной панели палочек Vive, Touch предлагает несколько аналоговых стиков.
Touch является первым коммерчески доступным VR контроллером, включающим средства управления на основе движений пальцев. В основном, управление ограничивается подниманием большого м и указательного пальца, но варианты использования этих естественных жестов в различных игровых и социальных приложениях удивительно разнообразны. Например, вместо того, чтобы протягивать полную руку к кнопке лифта, теперь вы можете сделать это указательным пальцем, чтобы выбрать конкретную кнопку так же, как и в реальной жизни. Или, вы можете показать другу свое удовлетворение, подняв большие пальцы вверх во время перестрелки с зомби в кооперативе.
Возможность выполнять такие простые вещи может не вызвать удивления, но на самом деле это делает Touch очень ценным контроллером в отрасли.
Эргономика
Эргономичный дизайн контроллеров Touch не что иное, как шедевр. Эти маленькие красавицы настолько невероятно легкие и хорошо продуманы, что они просто тают в ваших руках. Они позволяют забыть о внешнем мире, и это именно то, что хочется для VR.
Из-за намеренно созданных формы и дизайна Touch, стрельба чувствуется очень реалистично и естественно. Другие контроллеры VR позволяют почувствовать, как палочки в руках становятся виртуальными объектами, но Touch дает почувствовать, как вы подбираете виртуальный объект сам по себе.
Триггеры, кнопки и аналоговые стики очень приятны. У них достаточно сопротивления, чтобы дать вам хорошую тактильную обратную связь, но не настолько, чтобы утомить ваши пальцы, когда вы стреляете либо совершаете любые другие вещи с контроллерами в течение длительных периодов времени.
Тактильная обратная связь Touch также впечатляет. Вибрация контроллеров способна обеспечить тонкие толчки, когда вы подбираете пулемет, и хорошо поколотить, когда вы начинаете стрелять из него. Единственный недостаток в том, что они являются шокирующе громкими для контроллеров их размера. Это не является проблемой, когда на вас надеты встроенные наушники Oculus, но мешает соседям по комнате.
Поведение
Это хитрая категория для оценки, когда речь идет про Touch. Поведение этих контроллеров непосредственно связано с работой самой позиционной системы слежения Oculus. Датчики Oculus размещены не только на гарнитуре, но также на контроллерах. До тех пор пока датчики могут «видеть» контроллеры, они работают абсолютно прекрасно. Проблема, однако, заключается в том, что датчики иногда «забывают свои очки». Когда датчики не установлены должным для полного охвата образом, отслеживание теряется и контроллеры исчезают. Этого не произошло, когда мы строго следовали инструкции Oculus, но что-то может пойти не так, если не установить датчики правильно.
В итоге, если у вас есть пространство и ресурсы для запуска идеальной установки, с датчиками, расположенными так, как Oculus рекомендует, тогда вы, вероятно, не будете иметь никаких проблем с Touch. Если вы можете раскошелиться на три камеры и , то еще лучше. Тем не менее, если вы попытаетесь использовать Touch с меньшим пространством, то поиск «сладкого пятна» без мертвых зон может занять некоторое время.
Контент
Как всегда, Oculus и доллары Facebook проделали невероятную работу в наполнении библиотеки для запуска Touch. Dead and Buried, Ripcoil и The Unspoken являются одними из лучших многопользовательских , которые мы видели до сих пор. Quill, Medium и позволяют побывать творцом захватывающем 3D искусства. Конечно же, есть еще Arizona Sunshine, I Expect You to Die, и Job Simulator, которые отлично играются с Touch.
Есть более 50 игр, поддерживающих контроллер Touch, доступных в Oculus Home Store. Это уже неплохая библиотека, но данный длинный список удивительных тайтлов это только начало. Не говоря уже о всех Steam VR играх, которые тоже иногда поддерживают Touch, хоть и с ошибками.
Окончательный вердикт
Oculus Touch — лучший VR контроллер на сегодняшний день.
Его дизайн как можно ближе приближен к идеальному, а контента в Oculus Home и Steam достаточно, чтобы держать человека в пленену в течение нескольких месяцев. Контроллеры отлично работают в рекомендуемых условиях, а их система управления движениями пальцев должна быть стандартом для всей отрасли.
Touch является важным шагом вперед для VR, и мы не могли не удивиться, когда увидели их конструкцию и основные характеристики. Конечно, Touch — еще не предел, и со временем мы надеемся получить что-то еще лучше!