Vpxuser vmware что это
Что-то я в последнее время всё о детях. Надо разбавить тенденцию, плеснув немного хардкорной ИТ-тематики. Вернёмся к теме виртуализации и VMware vSphere. В данный момент для меня стала актуальной тема назначения прав доступа.
Для предоставления доступа различным категориям пользователей к их виртуальным машинам, как правило, используется представление VM and Templates и система папок, на которые, собственно, и назначаются права. Однако, в некоторых случаях этого бывает недостаточно, поскольку для некоторых действий пользователь должен иметь права и на объекты среды, отсутствующие в отображении VM and Templates. Например, для добавления виртуального жёсткого диска или клонирования ВМ нужны права Datastore.Allocate Space или роль Datastore Consumer на объект Datastore или Datastore Cluster. А для возможности изменения сетевого интерфейса — права Network.Assign Network или роль Network Administrator на соответствующие портгруппы. Далее детальнее об этом и других нюансах назначения прав доступа в vSphere. Информация актуальна для версий vSphere 5.1 и 5.5.
Ввиду наличия различных представлений объектов инфраструктуры виртуализации, права доступа к некоторым объектам (VM, vApps) могут наследоваться от нескольких предков (например, VM folder и Resource Pool). что стоит иметь ввиду. Общая схема наследования представлена на рисунке:
Соответственно, если кого-то нужно в правах ограничить, нужно убедиться, что отнятые в одном месте права не наследуются из другого объекта.
Помимо этого, можно столкнуться на практике, что человек, имеющий полномочия администратора на уровне рута, вдруг оказывается ограниченным пользовательскими правами на уровне конкретной папки. Дело в особенностях выбора действующих прав в ситуации наложения ролей. При предоставлении полномочий следует иметь их ввиду.
1) Права, выданные дочерним объектам игнорируют наследованные. Другими словами, если пользователь входит в группы vSphereAdmins и CitrixAdmins, при этом первая имеет права админа на уровне root, а вторая — VM User на уровне папки Citrix, то как раз получим ситуацию, описанную в вышеприведённом абзаце.
2) Права выданные на конкретного пользователя преобладают над правами, выданными на группу (если и те и другие выданы на один объект и пользователь входит в группу).
3) Если используются пользователи из AD или иных источников, отличных от встроенного каталога vCenter SSO, vCenter периодически проверяет наличие учётной записи поиском по имени. И если после назначения прав в vCenter, учётка была переименована или удалена, соответствующие ей права из vCenter удаляются. И если в случае удалённой учётки это даже хорошо, то в случае, если кто-то переименовал группу (группы), например в соответствие с новыми политиками именования в организации, это может привести к неблагоприятным последствиям.
4) vCenter SSO не наследует права вложенных групп, если их участники не входят в Identity Sources. Например, если домен AD не добавлен в Identity Sources, то группа Domain Admins этого домена не будет иметь никаких полномочий на vCenter, даже с учётом того, что она входит в local\Administrators сервера vCenter.
А теперь немного рекомендаций лучших собаководов Best Practices по теме предоставления прав доступа.
- По возможности назначать права на группы, а не на конкретных пользователей. Контроль членства в группах можно делегировать и избавить себя от лишней работы. И даже если не делегировать, системой будет проще управлять.
- Выдавать права только там, где необходимо, тем, кому необходимо и с минимально необходимыми привилегиями. Опять же для понимания структуры, упрощения управления и должного контроля. Лучше план необходимых полномочий сформировать заранее и лиц, которым они нужны.
- Использовать папки для группировки объектов со схожими наборами прав. Папки, если что, можно создавать во всех представлениях, а не только в VM and Templates.
- Быть аккуратнее с предоставлением прав на корневом уровне. То есть на уровне самого vCenter в клиенте vSphere. Дело в том, что пользователь, имеющий права на этом уровне получает доступ не только к объектам инфраструктуры виртуализации, но и к управлению такими сущностями как лицензии, роли, интервалы сбора статистики, сессии и кастомизированные поля. А возможность модификации ролей может оказать влияние даже на те vCenter, на которые у пользователя вообще нет прав (при использовании Linked Mode).
- В большинстве случаев стоит включать наследование. Это гарантирует, что при добавлении нового объекта в определённую иерархию, пользователь, за него ответственный, получит к нему доступ.
- Для маскировки специфичных зон иерархии можно использовать роль «No Access»
- После перезагрузки и обновления vCenter стоит проверять наличие необходимых прав. Дело в том, что если на каком-то этапе возникли сетевые проблемы и vCenter не сможет верифицировать указанные группы или пользователей, они будут удалены и заменены local\Administrators.
- Удалить права на vCenter для локальной группы Administrators и пользователя Administrator сервера vCenter. Выдать права специализированной группе.
Напоследок упомяну о специализированных пользователях хостов ESXi. Спровоцировано тем, что коллега однажды решил убедиться, что сотрудники ИТ в некоторых регионах не наделали себе лазеек в инфраструктуре, и чуть было не вычистил ESXi-хосты от пользователя vpxuser.
vpxuser — специализированный пользователь, который создаётся при подключении хоста к vCenter и используется им для администрирования. Имеет, соответственно, административные права на хост и ни в коем случае не должен модернизироваться (не менять ни права ни пароль).
dcui user — ещё один специфичный пользователь, используемый в качестве агента при работе через Direct Console User Interface режиме lockdown mode хоста (в этом режиме любые подключения к хосту запрещены, кроме управления с помощью vCenter).
В качестве заключения хочу заметить, что никогда я настолько не осознавал значимости и актуальности AGDLP-подхода при назначении прав доступа к системе, как при разработке политики назначения прав на объекты vCenter. Ввиду вышеприведённых особенностей и большого количества ветвлений элементов иерархий.
Для предоставления доступа различным категориям пользователей к их виртуальным машинам, как правило, используется представление VM and Templates и система папок, на которые, собственно, и назначаются права. Однако, в некоторых случаях этого бывает недостаточно, поскольку для некоторых действий пользователь должен иметь права и на объекты среды, отсутствующие в отображении VM and Templates. Например, для добавления виртуального жёсткого диска или клонирования ВМ нужны права Datastore.Allocate Space или роль Datastore Consumer на объект Datastore или Datastore Cluster. А для возможности изменения сетевого интерфейса — права Network.Assign Network или роль Network Administrator на соответствующие портгруппы. Далее детальнее об этом и других нюансах назначения прав доступа в vSphere. Информация актуальна для версий vSphere 5.1 и 5.5.
Ввиду наличия различных представлений объектов инфраструктуры виртуализации, права доступа к некоторым объектам (VM, vApps) могут наследоваться от нескольких предков (например, VM folder и Resource Pool). что стоит иметь ввиду. Общая схема наследования представлена на рисунке:
Соответственно, если кого-то нужно в правах ограничить, нужно убедиться, что отнятые в одном месте права не наследуются из другого объекта.
Помимо этого, можно столкнуться на практике, что человек, имеющий полномочия администратора на уровне рута, вдруг оказывается ограниченным пользовательскими правами на уровне конкретной папки. Дело в особенностях выбора действующих прав в ситуации наложения ролей. При предоставлении полномочий следует иметь их ввиду.
1) Права, выданные дочерним объектам игнорируют наследованные. Другими словами, если пользователь входит в группы vSphereAdmins и CitrixAdmins, при этом первая имеет права админа на уровне root, а вторая — VM User на уровне папки Citrix, то как раз получим ситуацию, описанную в вышеприведённом абзаце.
2) Права выданные на конкретного пользователя преобладают над правами, выданными на группу (если и те и другие выданы на один объект и пользователь входит в группу).
3) Если используются пользователи из AD или иных источников, отличных от встроенного каталога vCenter SSO, vCenter периодически проверяет наличие учётной записи поиском по имени. И если после назначения прав в vCenter, учётка была переименована или удалена, соответствующие ей права из vCenter удаляются. И если в случае удалённой учётки это даже хорошо, то в случае, если кто-то переименовал группу (группы), например в соответствие с новыми политиками именования в организации, это может привести к неблагоприятным последствиям.
4) vCenter SSO не наследует права вложенных групп, если их участники не входят в Identity Sources. Например, если домен AD не добавлен в Identity Sources, то группа Domain Admins этого домена не будет иметь никаких полномочий на vCenter, даже с учётом того, что она входит в local\Administrators сервера vCenter.
Немного рекомендаций лучших собаководов Best Practices по теме предоставления прав доступа.
- По возможности назначать права на группы, а не на конкретных пользователей. Контроль членства в группах можно делегировать и избавить себя от лишней работы. И даже если не делегировать, системой будет проще управлять.
- Выдавать права только там, где необходимо, тем, кому необходимо и с минимально необходимыми привилегиями. Опять же для понимания структуры, упрощения управления и должного контроля. Лучше сформировать заранее план необходимых полномочий и лиц, которым они нужны.
- Использовать папки для группировки объектов со схожими наборами прав. Папки, если что, можно создавать во всех представлениях, а не только в VM and Templates.
- Быть аккуратнее с предоставлением прав на корневом уровне. То есть на уровне самого vCenter в клиенте vSphere. Дело в том, что пользователь, имеющий права на этом уровне получает доступ не только к объектам инфраструктуры виртуализации, но и к управлению такими сущностями как лицензии, роли, интервалы сбора статистики, сессии и кастомизированные поля. А возможность модификации ролей может оказать влияние даже на те vCenter, на которые у пользователя вообще нет прав (при использовании Linked Mode).
- В большинстве случаев стоит включать наследование. Это гарантирует, что при добавлении нового объекта в определённую иерархию, пользователь, за него ответственный, получит к нему доступ.
- Для маскировки специфичных зон иерархии можно использовать роль «No Access»
- После перезагрузки и обновления vCenter стоит проверять наличие необходимых прав. Дело в том, что если на каком-то этапе возникли сетевые проблемы и vCenter не сможет верифицировать указанные группы или пользователей, они будут удалены и заменены local\Administrators.
- Удалить права на vCenter для локальной группы Administrators и пользователя Administrator сервера vCenter. Выдать права специализированной группе.
Напоследок упомяну о специализированных пользователях хостов ESXi. Спровоцировано тем, что коллега однажды решил убедиться, что сотрудники ИТ в некоторых регионах не наделали себе лазеек в инфраструктуре, и чуть было не вычистил ESXi-хосты от пользователя vpxuser.
vpxuser — специализированный пользователь, который создаётся при подключении хоста к vCenter и используется им для администрирования. Имеет, соответственно, административные права на хост и ни в коем случае не должен модернизироваться (не менять ни права ни пароль).
dcui user — ещё один специфичный пользователь, используемый в качестве агента при работе через Direct Console User Interface режиме lockdown mode хоста (в этом режиме любые подключения к хосту запрещены, кроме управления с помощью vCenter).
В качестве заключения хочу заметить, что никогда я настолько не осознавал значимости и актуальности AGDLP-подхода при назначении прав доступа к системе, как при разработке политики назначения прав на объекты vCenter. Ввиду вышеприведённых особенностей и большого количества ветвлений элементов иерархий.
Вот то, что известно всем: vpxuser – учетная запись, используемая vCenter`ом для управления ESXi хостами (опрос гипервизора, отправка задачи), которые в него включены. Т.е. учетная запись root (ESXi) не имеет отношения к связи vCenter – ESXi (за исключением того нюанса, что она нужна для включения ESXi в vCenter).
Vpxuser имеет права администратора ESXi. Таким образом, администратор vCenter`а может выполнять практически все те же самые манипуляции с хостом, что и root (ESXi), кроме создания/удаления/изменения локальных пользователей и групп самого ESXi хоста.
Управлять учетной записью vpxuser с помощью службы каталогов AD нельзя.
Пароль vpxuser хранится в зашифрованном виде и на ESXi и в базе vCenter (логично, не правда ли?) и для каждого ESXi этот пароль уникален.
Типы виртуализации VMware
Все программы для виртуализации можно разделить на пять типов: серверная виртуализация, виртуализация десктопов, сетевая виртуализация, виртуализация хранилищ и ПО для управления облачными средами. О виртуализации в серверной среде мы уже немного рассказали выше, а вот что подразумевается под остальными типами?
Виртуализация десктопов и облачные среды
Виртуализация десктопов, которую иногда называют инфраструктурой виртуальных десктопов (VDI), — это такой тип виртуализации, при котором ОС настольных ПК работает как виртуальная машина на физическом сервере с другими виртуальными десктопами. Обработка нескольких виртуальных рабочих мест происходит на одном или нескольких физических серверах, обычно – в централизованном ЦОД. Копия ОС и приложений, которые использует каждый конечный пользователь, обычно кэшируется в памяти, как один образ на физическом сервере.
Пакет VMware Horizon позволяет организациям запускать рабочие столы Windows в центре обработки данных или в облачных сервисах на базе VMware Cloud, что устраняет необходимость размещения и управления десктопами с офисного рабочего места, централизует управление пользовательской средой и обеспечивает ее безопасность.
Сетевая виртуализация
При развертывании данного типа виртуализации используется ПО для выполнения сетевых функций путем отделения виртуальных сетей от базового сетевого оборудования. Как только вы начнете использовать виртуализацию сети, физическая сеть будет использоваться только для пересылки пакетов, поэтому все управление осуществляется с помощью виртуальных или программных коммутаторов. Поставщиками сетевой виртуализации являются внутренние виртуальные коммутаторы гипервизора. Кроме того, сторонние поставщики, такие как Cisco и IBM, разработали виртуальные коммутаторы, которые могут использоваться гипервизорами, такими как ESXi.
Виртуализация хранилищ
Как мы уже отмечали, для каждого типа виртуализации компания VMware предлагает определенный набор софта. Например, если мы говорим о хранении данных, то следует принимать во внимание такие решения, как VMware vSAN и VMware Site Recovery Manager (SRM). VMware vSAN — программная функция хранения, встроенная в гипервизор ESXi и интегрированная с vSphere. Она объединяет дисковое пространство от нескольких хостов ESXi и выделяет его с помощью интеллектуальных политик, таких как ограничения защиты, тонкое выделение ресурсов и кодирование стирания. А еще эта опция интегрируется с функцией vSphere High Availability, обеспечивая повышенную производительность вычислений и самого хранилища.
VMware Site Recovery Manager (SRM) предназначен для управления аварийным восстановлением, что позволяет администраторам создавать планы восстановления, которые автоматически выполняются в случае сбоя, а также автоматически организовывать аварийное переключение и восстановление виртуальных машин. SRM также интегрируется с VMware NSX (инструмент управления сетевыми операциями) для сохранения сетевых политик и политик безопасности на виртуальных машинах, перемещенных на новые физические сервера.
Устранение проблем
Если все-таки изменения в vpxuser были внесены (например, изменен пароль) и это повлекло недоступность ESXi из vCenter (обычно сопровождается ошибкой: "Call «ServiceInstance.RetrieveContent» for object «ServiceInstance» on Server «ip_address» failed"), то можно поступить следующим образом (если lockdown mode не включен и есть доступ к хосту по SSH):
- ПКМ на хосте в vSphere Client`е, disconnect (если, конечно, хост уже не находится в таком состоянии). НЕ УДАЛЯТЬ хост из vCenter`а.
- Подключиться по SSH к хосту и выполнить: “userdel vpxuser”.
- ПКМ на хосте и выбрать “Connect”. Игнорировать все возможные ошибки аутентификации.
- Ввести требуемый логин root и его пароль. Учетная запись vpxuser будет пересоздана.
Здесь стоит обратить внимание на фразу «если не включен lockdown mode». Если пароль vpxuser был изменен и vCenter потерял связь с ESXi и при этом lockdown mode включен, т.е. доступ к хосту ESXi запрещен всем кроме vCenter, то официальная позиция VMware на этот счет однозначна: «переустанавливайте ESXi».
Подключение к ESXi с помощью VPXUSER
В некоторых источниках я видел утверждения вроде этого: «Знание пароля от vpxuser Вам ничего не даст, использовать эту комбинацию для подключения к хосту и любых других целей невозможно». Однако, зная пароль vpxuser, можно подключиться к ESXi и управлять им (опробовано на Standalone ESXi 5.5 u1 и на ESXi 5.5 u1 под управлением vCenter 5.5, и не только на них).
С другой стороны, узнать пароль vpxuser нельзя (по крайней мере я способ так и не нашел), поэтому подключиться таким образом можно только изменив пароль vpxuser, а этого делать не нужно (читаем дальше).
Зачем нужна сертификация VMware Ready
Начнем с того, что сертификация VMware Ready означает высокий уровень одобрения для продуктов, созданных партнерами компании VMware. Нетрудно догадаться, что Kingston Digital входит в их число: в частности, является членом “Партнерского технологического альянса VMware”. Участники этого альянса разрабатывают свои устройства в соответствии со стандартами VMware и предоставляют их техническим специалистам компании, которые проводят различные сертификационные тесты.
По итогам проверок, сервера, компьютеры, устройства хранения и другие устройства, отвечающие сертификационным требованиям, получают заветный логотип VMware Ready. Кроме того, в дальнейшем эти продукты поддерживаются как со стороны компании-партнера, так и со стороны VMware. Подробную информацию о твердотельных накопителях Kingston из линейки, которые прошли сертификацию VMware можно найти и на портале VMware Solution Exchange (VSX). Там же размещаются обновления ПО для пользователей “железа” сертифицированного VMware.
Возвращаясь к “Партнерскому технологическому альянсу VMware”, стоит упомянуть о том, что участие в нем позволяет клиентам быстро находить сертифицированное оборудование партнеров, не занимаясь точечным и индивидуальным подбором компонентов, которые в итоге могут не обеспечить ожидаемую производительность. Не в последнюю очередь это способствует росту продаж накопителей Kingston. Только за первое полугодие 2019 года компании удалось реализовать более 13,3 миллиона твердотельных накопителей (по исследованиям TrendFocus). Если говорить о глобальных поставках, хорошие продажи обеспечили Kingston третье место в списке лидеров по реализации SSD-накопителей после Samsung и Western Digital.
Изменение пароля VPXUSER
В документации можно обнаружить предупреждение, которое в вольном (моем) переводе выглядит так:
Интересно и другое: далее в этой статье есть информация о политике паролей vpxuser, и по умолчанию длина его пароля 32 символа. Если менять его пароль вручную на ESXi, например с помощью “passwd”, то можно задать пароль намного короче. Видимо, связано это с тем, что политику паролей поддерживает vCenter, а поскольку меняется пароль vpxuser тоже vCenter`ом, то, как говорится «Я своей смешною рожей сам себя и веселю». Т.е. сменить-то пароль можно, и задать его несоответствующим политике можно, но связь с ESXi в итоге будет утеряна.
Потеря связи вполне логична, ведь при ручной смене пароля vpxuser, его пароль в базе vCenter`а не меняется.
Вывод: не меняйте пароль на vpxuser сами, пусть этим занимается vCenter. Если вы изменили пароль vpxuser руками, то с вероятностю 99% рано или поздно vCenter потеряет связь с ESXi. 1% я оставляю на магическое вмешательство.
Какие SSD-накопители обладают статусом VMware Ready
Применительно к накопителям Kingston серверного класса, сертификацию VMware Ready for Storage имеют твердотельные SATA-накопители Kingston DC500R и Kingston DC500M, рекомендованные для использования в ЦОД. Как мы уже отметили выше, присвоенный данным SSD-решениям статус говорит о том, что DC500R и DC500M получили полное одобрение от специалистов VMware, успешно пройдя все тесты.
Именно эта сертификация позволяет представителям Kingston Digital говорить о том, что при использовании SSD DC500R и DC500M в среде vSAN и серверах vSphere можно ожидать высокой производительности при выполнении большого количества операций чтения данных и смешанных нагрузках. К слову, для прохождения сертификации серверные накопители настраиваются в соответствии с требованиями от VMware и в итоге обеспечивают высокую пропускную способность, кол-во IPOS, а также минимальную задержку в 99% сценариев.
Как итог: сертифицированные SSD Kingston с чистой совестью можно отнести к классу высокопроизводительных ускорителей для виртуализированных рабочих нагрузок смешанного типа в рамках серверной среды. Также они позволяют облачным службам работать с максимальной эффективностью и предоставляют пользователям очень быстрый доступ к данным. Собственно, от них это и требуется.
Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.
This will be a very brief section on VMware security I am not going to cover every aspect of security within VMware but will lightly touch on the commonly used area's. Both the ESXi standalone server and vCenter security is the same, the only difference is where the users and groups come from, if using a ESXi stand-alone configuration they are held locally on the ESXi server, however if you use vCenter you can take advantage of Active Directory (AD) in Windows plus it can be stored locally. Note that users and groups come from the underlying O/S, if using stand-alone ESXi server then the users/groups will be held locally on the server (/etc/passwd and /etc/group), if using a vCenter running on Windows 2008, then these will be local windows accounts or if part of a domain then these will be domain accounts, you cannot administer user accounts or group via VMware only roles.
The VMware model of security involes three components: roles, groups and users, this type of setup is very similar to databases. First you create roles of responsibility then you can add users/groups to allow them to perform tasks. As vCenter has an organization of system folders, datacenter objects and subfolders, a system of inheritance does exist, if you set a role on a folder, it will pass your privileges down the folder hierarchy, vCenter does a good job of hiding objects that a user has no privilege to see. There are 11 predefined roles, I have highlighted which are available to vSphere client and to vCenter
Roles
So lets create a role and assign some privileges
To create a role, from the home page in vCenter select "roles" from the administration section
select "add role", and type in a meaningful name, then start selecting the privileges for this role, I am not going to cover all the privileges here, I have just selected "virtual machine", this in itself greatly expands into many privileges.
As you can see the new role appears at the bottom
To remove a role just right-click that role and select remove, you also have the ability to clone roles and then change them a little
One note about removing roles you may see the below warning message, this is justing letting you know what you want to do about the existing users within this role, either leave them with no access or assign them to another role.
Using Roles and privileges to access a certain VM can a bit of a task as you need to create the privileges from the top down, first start with the datacenter folder, then down to the ESXi hosts and finally the VM itself
First select the area that you want to add a privilege to, this could be a folder, host or a VM, in the example below I have selected the production folder, the panel on the left is what appears first, you can change the assigned role to your newly created role, then you need to add users or groups, this is done by selecting the "add" button which produces the right-panel. here you can choose from your user/group list, remember these will either be local accounts or domain accounts depending what you have setup
When you have choosen your users/group you should see something like below, here I have allowed a user called vallep to have read-only access, thus when I login via vSphere client or vCenter using the vallep account I will only have read-only access and will not be able to change anything.
Once you have added some users or groups you can go back to the role home page and see the changes you have made, you can clearly see the hierarchy format used.
Personally I just stick to the already created roles and generally do not need to create additional roles, most of the time I can get away with using the administrator, virtual machine user and read-only roles. Lastly I just what to touch on the ESXi default accounts that are created there are 4 of them,
Datastore Access
If you want to improve on security regarding the datastores within vCenter, you should create folders and then drag and drop the datastore into the folder, after which you can assign permissions on that folder restricting the access to the datastore, here is what I have done with my test environment, I created four folders and placed the datastores into the folders, I could then place different permissions on each of the folders.
I will come back to this section at a later date to update it with advanced security features but thats all i am going to cover for now.
Подключение к ESXi с помощью VPXUSER
В некоторых источниках я видел утверждения вроде этого: «Знание пароля от vpxuser Вам ничего не даст, использовать эту комбинацию для подключения к хосту и любых других целей невозможно». Однако, зная пароль vpxuser, можно подключиться к ESXi и управлять им (опробовано на Standalone ESXi 5.5 u1 и на ESXi 5.5 u1 под управлением vCenter 5.5, и не только на них).
С другой стороны, узнать пароль vpxuser нельзя (по крайней мере я способ так и не нашел), поэтому подключиться таким образом можно только изменив пароль vpxuser, а этого делать не нужно (читаем дальше).
Здесь должен быть какой-то вывод
Вывод касательно vpxuser предельно прост — это одна из тех вещей, которые тюнить не стоит практически ни при каких обстоятельствах. Пост призван лишь рассказать чуть больше об этой учетной записи, о ее присутствии в разных релизах и о мифах, вроде того, что её нельзя использовать для прямого подключения к ESXi.
Привет, Хабр! Сегодня мы поговорим о виртуальных машинах, программном обеспечении VMware и накопителях Kingston, конечно же. В частности, разберем вопросы на тему “зачем нужна сертификация VMware Ready, какие из SSD-решений получают статус VMware Ready for Storage, и о чем это говорит?”. Начнем с самого банального.
Безусловно, аудитории Хабра знакома компания VMware, которая занимается разработкой программного обеспечения для виртуализации и организации облачных вычислений. Продукты VMware включают в себя средства виртуализации, управления сетью и безопасностью, программное обеспечение для ЦОД и хранения данных.
Первым таким продуктом стала программа VMware Workstation, которая позволяла любому пользователю установить на своем ПК одну или несколько виртуальных машин: то бишь имитацию аппаратной начинки компьютера в лице процессора, видеокарты, накопителей, оптических приводов и т.д. Эдакий компьютер в компьютере.
В рамках серверной среды VMware Workstation вкупе с установленным гипервизором VMware ESX позволяет запускать несколько виртуальных машин на одном физическом сервере, при этом каждая из ВМ может работать со своей операционной системой. Следовательно — на одном сервере могут быть активными сразу несколько разных ОС.
При этом все установленные ВМ совместно используют доступные ресурсы (сетевую карту и оперативную память), но работают независимо друг от друга. Основными продуктами в этом направлении является платформа VMware vSphere, гипервизор VMware ESX и VMware ESXi, VMware Server и vCenter Server. Впрочем, серверная виртуализация — не единственный тип абстрагирования от аппаратной реализации.
Политика паролей для vpxuser
Время действия пароля
По умолчанию пароль vpxuser обновляется каждые 30 дней, но это можно изменить:
1. В vSphere Client → Administration.
2. vCenter Server Settings… → Advanced Settings.
3. Выбрать параметр VirtualCenter.VimPasswordExpirationInDays, установить нужное значение.
4. Перезагрузить службу vCenter.
Изменять этот параметр VMware не рекомендует. VMware вообще много чего не рекомендует делать, жить вредно, от этого умирают.
Сложность пароля
Пароль vpxuser состоит из 32х символов, и содержит минимум 1 символ из групп: специальные символы ( и др.), цифры (1-9), большие буквы (латиница) и строчные буквы (латиница).
В документации указано, что для изменения длины пароля vpxuser можно изменить значение параметра vpxd.hostPasswordLength в файле конфигурации на vCenter:
- Linux (VCSA) — /etc/vmware-vpx/vpxd.cfg;
- Windows – C:\ProgramData\VMware\VMware VirtualCenter\vpxd.cfg;
Т.е. внутрь vpxd, но не внутрь какого-либо другого вложенного тега.
Вывод: зачем вообще менять политику паролей для vpxuser? Да незачем, VMware не рекомендует заниматься подобной ерундой.
В разных релизах
Читайте также: