WilliamLam.com

New Parameter in vim-cmd snapshot.remove for ESX(i) 4.1 Update 2

by // 2 Comments

While going through my ghettoVCB backlog this past weekend, I came across an issue reported by a user with snapshot removal using vim-cmd in ghettoVCB. It looks like with the recent release of ESX(i) 4.1 Update 2, the "snapshot.remove" required parameters have changed. Prior to 4.1 Update 2, the command would just require a virtual machine's vmid and if it only had a single snapshot, it would automatically consolidate the snapshot.

If a VM had more than one snapshot, users would then need to specify some additional parameters that identified the particular level of the snapshot tree and the snapshot index to be removed. This was pretty difficult to use, even for myself. It now looks like VMware has simplified this command and introduced a new required parameter called snapshotId in ESX(i) 4.1 Update 2.

Here's an example VM with several snapshots and let's say we would like to consolidate snapshot3

First we'll need to query the VM snapshots using vim-cmd vmsvc/snapshot.get [vmid]

As you can see from the screenshot, there is a new property called "Snapshot Id" which can now be passed into the snapshot.remove operation.

After the snapshot3 is consolidated, the snapshot tree is re-displayed again to verify the operation. We can also confirm by looking at the vSphere Client UI

This now makes snapshot manipulation using vim-cmd extremely easy to use.

There is a fix in ghettoVCB.next that will support the new snapshot.remove operation which hopefully I'll be able to release very soon.

How to Create Custom Roles on Standalone ESX(i) Host

by // 9 Comments

There was an interesting question on the VMTN forums that caught my eye this week in which a user posted a question about controlling access to a limited set of virtual machines for users on a standalone ESX(i) host. For those of you who are familiar with vCenter Server know that this can easily be accomplished by using/creating roles which allows for granular access to various resources within a vSphere environment such as Datacenter, Resource Pool, Host, Virtual Machine, etc. This was the suggestion from several community members and it ended up being the simple solution as the user actually had a vCenter Server.

So what if the user did not have a vCenter Server and actually had standalone ESX(i) host, would he/she be out of luck? The answer is no, you can actually utilize roles on a standalone host but the default roles that are available are pretty limited in scope. By default, there are three roles: No access, Read-only and Administrator and these roles can be applied to both local and/or Active Directory users if your ESX(i) host is joined to an AD domain.

By leveraging our good friend vimsh/vim-cmd from either the classic ESX Service Console or Tech Support Mode of ESXi, we can actually create custom roles just like we would on vCenter Server with fine grain permissions to a virtual machine(s). You can not create custom roles using the vSphere Client like you would when connecting to a vCenter Server.

We will be using the commands found under vim-cmd vimsvc/auth:

[root@vesx41-1 ~]# vim-cmd vimsvc/auth
Commands available under vimsvc/auth/:
entity_permission_add lockdown_mode_enter role_permissions
entity_permission_remove lockdown_mode_exit role_remove
entity_permissions permissions roles
lockdown_is_enabled privileges
lockdown_is_possible role_add

Before we get started, it is good to understand what is a permission and how that relates to a particular entity such as a virtual machine. Here are some definitions from VMware:

Privilege - The ability to perform a specific action or read a specific property
Role - A collection of privileges. Roles provide a way to aggregate all the individual privileges that are required to perform a higher-level task, such as administer a virtual machine
Object - An entity upon which actions are performed. VirtualCenter objects are datacenters, folders, resource pools, clusters, hosts, and virtual machines

Permission = User/Group + Role + Object 

Basically we will be creating a custom role which contains a specific set of privileges to administrator a virtual machine and assign this role to a set of users on a standalone ESX(i) host.

To view all available privileges, you can run the following command:

~ # vim-cmd vimsvc/auth/privileges | grep privId | sed 's/^[ \t]*//;s/[ \t]*$//;s/,//;s/"//g' | awk '{print $3}' | sort
Alarm.Acknowledge
Alarm.Create
Alarm.Delete
Alarm.DisableActions
Alarm.Edit
Alarm.SetStatus
Authorization.ModifyPermissions
Authorization.ModifyRoles
Authorization.ReassignRolePermissions
DVPortgroup.Create
DVPortgroup.Delete
DVPortgroup.Modify
DVPortgroup.PolicyOp
DVPortgroup.ScopeOp
DVSwitch.Create
DVSwitch.Delete
DVSwitch.HostOp
.....

To view existing roles and what privileges are associated with a given role, you can run the following command:

vim-cmd vimsvc/auth/roles | less

From the above privilege list, you will need to select the privileges that you would like in your new role, for now you can just copy the entries into a temporarily file (/tmp/vm-privileges) as that will be used later.

In this example, I've selected the basic VM privileges that is associated with the "Virtual Machine User" found in vCenter Server but adding on additional privileges to support snapshots.

[root@vesx41-1 ~]# cat /tmp/vm-privileges
Global.CancelTask
VirtualMachine.Interact.AnswerQuestion
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.SetCDMedia
VirtualMachine.Interact.SetFloppyMedia
VirtualMachine.Interact.ConsoleInteract
VirtualMachine.Interact.DeviceConnection
VirtualMachine.Interact.PowerOff
VirtualMachine.Interact.PowerOn
VirtualMachine.Interact.Reset
VirtualMachine.Interact.Suspend
VirtualMachine.Interact.ToolsInstall
VirtualMachine.State.CreateSnapshot
VirtualMachine.State.RemoveSnapshot
VirtualMachine.State.RevertToSnapshot

Next we will need to know the virtual machine's VmId also known as the MoRefID (Managed Object ID) that uniquely identifies a given entity. To display the VmId of all virtual machines residing on your ESX(i) host, you can run the following command:
[root@vesx41-1 ~]# vim-cmd vmsvc/getallvms
Vmid Name File Guest OS Version Annotation
32 SteveJablonsky [datastore1] SteveJablonsky/SteveJablonsky.vmx freebsdGuest vmx-07
48 HansZimmer [datastore1] HansZimmer/HansZimmer.vmx dosGuest vmx-07
64 JamesNewton [datastore1] JamesNewton/JamesNewton.vmx dosGuest vmx-07
80 BrianTyler [datastore1] BrianTyler/BrianTyler.vmx dosGuest vmx-07

Next we need to identify the users in which we will create the new permissions for. In this example, I will use both a local (william) and Active Directory user (PRIMP-IND\primp):

[root@vesx41-1 ~]# id william
uid=501(william) gid=100(users) groups=100(users)

[root@vesx41-1 ~]# id PRIMP-IND\\primp
uid=37225554(PRIMP-IND\primp) gid=37224960(PRIMP-IND\domain^admins) groups=37224960(PRIMP-IND\domain^admins),37225020(PRIMP-IND\denied^rodc^password^replication^group)

In this example, I have a single ESX host that contains 4 virtual machines and the first two will only be visible to a user called "william" and the second two will only be visible to a user called "PRIMP-IND\primp":

  •  Owner: william
    • HansZimmer
    • BrianTyler
  •  Owner: PRIMP-IND\primp
    • SteveJablonsky
    • JamesNewton

We will create a virtual machine administrator role called "VMAdmin" which will then be associated with their respective virtual machines and system owners.

First we need to create the custom "VMAdmin" role by using the file that contains all the necessary privileges, we will run the following command:

[root@vesx41-1 ~]# vim-cmd vimsvc/auth/role_add VMAdmin $(cat /tmp/vm-privileges | awk '$1=$1' ORS=' ')

Note: The "role_add" operation takes in a roleName and then a list of privileges which are separated out by a space, this list can be as many as you need and by specifying it in a file, it makes it easier to edit/adjust

You can verify that the new role was created running the following command:

[root@vesx41-1 ~]# vim-cmd vimsvc/auth/roles
......
(vim.AuthorizationManager.Role) {
dynamicType = ,
roleId = 12,
system = false,
name = "VMAdmin",
info = (vim.Description) {
dynamicType = ,
label = "VMAdmin",
summary = "VMAdmin",
},
privilege = (string) [
"Global.CancelTask",
"System.Anonymous",
"System.Read",
"System.View",
"VirtualMachine.Interact.AnswerQuestion",
"VirtualMachine.Interact.ConsoleInteract",
"VirtualMachine.Interact.DeviceConnection",
"VirtualMachine.Interact.PowerOff",
"VirtualMachine.Interact.PowerOn",
"VirtualMachine.Interact.Reset",
"VirtualMachine.Interact.SetCDMedia",
"VirtualMachine.Interact.SetFloppyMedia",
"VirtualMachine.Interact.Suspend",
"VirtualMachine.Interact.ToolsInstall",
"VirtualMachine.State.CreateSnapshot",
"VirtualMachine.State.RemoveSnapshot",
"VirtualMachine.State.RevertToSnapshot"
],
}
]

Note: If you created a role that did not contain all the privileges and you need to update the role, you actually have to delete the role first. I have not found a way to "append" privileges, but removing a role is very straight forward and you can use "vim-cmd vimsvc/auth/role_remove" to do so.

Next we will associate this new role with the users and the virtual machines to create the permission mappings. If you recall earlier, we retrieved a list of virtual machines and the first column contains the VM's VmId which will be needed in this next section. We will be using the "vim-cmd vimsvc/auth/entity_permission_add" operation and if you would like to know what arguments it accept, you can just run it by itself without any arguments.To associate the first two virtual machines to the user "william" we will be running the following commands:

[root@vesx41-1 ~]# vim-cmd vimsvc/auth/entity_permission_add vim.VirtualMachine:80 william false VMAdmin true
[root@vesx41-1 ~]# vim-cmd vimsvc/auth/entity_permission_add vim.VirtualMachine:48 william false VMAdmin true

To associate the new two virtual machines with the user "PRIMP-IND\primp" we will be running the following commands:

[root@vesx41-1 ~]# vim-cmd vimsvc/auth/entity_permission_add vim.VirtualMachine:64 PRIMP-IND\\primp false VMAdmin true
[root@vesx41-1 ~]# vim-cmd vimsvc/auth/entity_permission_add vim.VirtualMachine:32 PRIMP-IND\\primp false VMAdmin true

Note: The VM entity syntax is in the form of vim.VirtualMachine:XX where XX is the virtual machine's VmId extracted earlier which will need to be substituted in with your own VmId

We can verify the permissions by running a few commands, we can either check all permissions created with this particular role name, in our example, it is "VMAdmin" and the command to run would be the following:

[root@vesx41-1 ~]# vim-cmd vimsvc/auth/role_permissions VMAdmin
(vim.AuthorizationManager.Permission) [
(vim.AuthorizationManager.Permission) {
dynamicType = ,
entity = 'vim.VirtualMachine:32',
principal = "PRIMP-IND\primp",
group = false,
roleId = 12,
propagate = true,
},
(vim.AuthorizationManager.Permission) {
dynamicType = ,
entity = 'vim.VirtualMachine:48',
principal = "william",
group = false,
roleId = 12,
propagate = true,
},
(vim.AuthorizationManager.Permission) {
dynamicType = ,
entity = 'vim.VirtualMachine:64',
principal = "PRIMP-IND\primp",
group = false,
roleId = 12,
propagate = true,
},
(vim.AuthorizationManager.Permission) {
dynamicType = ,
entity = 'vim.VirtualMachine:80',
principal = "william",
group = false,
roleId = 12,
propagate = true,
}
]

You can also check a specific entity such as a virtual machine by running the following command:

[root@vesx41-1 ~]# vim-cmd vimsvc/auth/entity_permissions vim.VirtualMachine:64
(vim.AuthorizationManager.Permission) [
(vim.AuthorizationManager.Permission) {
dynamicType = ,
entity = 'vim.VirtualMachine:64',
principal = "PRIMP-IND\primp",
group = false,
roleId = 12,
propagate = true,
}
]

Now that we have confirmed the new permissions, we will want to verify that these users can only see the virtual machines we have specified both in the vSphere Client and webAccess (ESX only).

Here is a screenshot of user "william" connecting to the vSphere Client:

Here is a screenshot of user "PRIMP-IND\primp"connecting to the ESX webAccess:

Contrary to the default permissions on a stand alone host, you actually can reate custom roles just like on a vCenter Server to have fine grain access controls for your various users without having to give them full administrative privledges to an ESX(i) host. If you have vCenter Server, then of course that is the recommended approach but if you do not, you still have a way 🙂

Automating Active Directory User Management in ESXi Kickstart

by // 2 Comments

In the previous post we looked at Automating Active Directory Domain Join in ESXi Kickstart. We are now going to look at adding domain users without having to manually go through vSphere Client or external scripts after an ESXi host has been provisioned. We are going to be leveraging vim-cmd to accomplish this during the kickstart installation. Before doing so, you will need to know the the available roles on a default ESXi host and the syntax for a given permission.

To see the available roles, you can run the following command on an already provisioned ESXi host:

vim-cmd vimsvc/auth/roles | less

The default roles on an ESXi host are:

  • NoAccess
  • ReadOnly
  • Admin

To see the existing permissions, you can run the following command on an already provisioned ESXi host:

vim-cmd vimsvc/auth/permissions

These entries will match what you see in the vSphere Client and dictate who has login access to the ESXi host.

To add a new permission, we will be using the "vim-cmd vimsvc/auth/entity_permission_add" and it requires five parameters.

  • First - Entity (This can be found by looking at the output from permissions)
  • Second - Username
  • Third - Boolean on whether this is a group or not (should be false)
  • Fourth - The role to be applied to the user
  • Fifth - Boolean on whether to propagate this permission

If you manually add a domain user, you can easily verify the user can login by running the "id" command which will perform a look up on the user. If it is successful, it should return an entry corresponding to something like this:

Note: We need to use the double slash "\" to escape the initial slash when running the query. Also make note of the domain name as it may or may not match your full domain name.

We are now ready to craft a simple script that will add domain users as part of the ESXi kickstart process. The following snippet should be placed in the %firstboot section of your kickstart and after your Active Directory domain join code. Make sure you replace the DOMAIN_NAME variable along with the usernames. In the example I have two separate for loops to handle ReadOnly and Admin users, you do not need both if you are only adding one type of users.

The script basically performs a simple 60sec sleep to ensure the domain join process has completed before continuing. If you do not place a sleep, the subsequent code will fail to execute. The next step is to validate the user by doing a simple lookup using "id" command and upon successful look up of the user, we add the appropriate permissions.

Note: We only have two add these two entities: "vim.Folder:ha-folder-root" and "vim.ComputeResource:ha-compute-res" to properly add a permission.

If everything was successful, after your ESXi installation you now should have your host joined to your Active Directory and a list of domain users who now have permission to login to the ESXi host. You can verify by using the vSphere Client and taking a look at the Permissions tab.

If you would like to create custom roles on your ESXi host, you can use the following command:

vim-cmd vimsvc/auth/role_add

Note: The syntax for the privileges parameter lists only five, but it actually accepts as many as you need with the custom role