vicfg-authconfig Command

---

NAME

vicfg-authconfig - manage Active Directory authentication schemes.

---

SYNOPSIS

        vicfg-authconfig 
           <conn_options>
          [--adpassword |
           --adusername |
           --authscheme |
           --currentdomain |
           --force |
           --getremoteauthstore |
           --help |
           --leavecurrentdomain |
           --listauthstores 
           --vihost]

---

DESCRIPTION

List information about Active Directory domains for a host, join an Active Directory domain, or leave the current domain.

---

OPTIONS

--adpassword | -w <password>

Password with which to log into the domain controller. Use this option with the --joindomain option. If you do not specify an AD password at the command line, the system prompts you.

--adusername | -U <name>

User name with which to log in to the domain controller. Use this option with the --joindomain option. If you do not specify an AD user at the command line, the system prompts you.

--authscheme | -t AD

The authentication scheme to be configured. Currently the only supported argument is AD.

conn_options

Specifies the target server and authentication information if required. Run vicfg-authconfig --help for a list of all connection options.

--currentdomain | -c

Displays the currently joined domain. Use this option in conjunction with the --authscheme option. This option takes no arguments.

--force | -f

Use this option with the --leavecurrentdomain option to delete any AD user permissions on entities. If you run vicfig-authcfg --leavecurrentdomain, AD user permissions are present, and you do not use --force, the operation fails.

--getremoteauthstore | -a

Prints the active authentication mechanisms. This option takes no arguments.

--help

Prints a help message for each command-specific and each connection option. Calling the command with no arguments or with --help has the same effect.

--joindomain | -j <domain_FQDN>

Joins the specified Active Directory domain. Use this option with the --authscheme option. This option takes in the FQDN of the directory server as the argument.

--leavecurrentdomain | -L

Leaves the currently joined domain. Use this option with the --authscheme option. If AD user permissions on entities exist, the operation fails unless you specify--force. This option takes no arguments.

--listauthstores | -l

Prints the supported authentication mechanisms. This option takes no arguments.

--vihost | -h <esx_host>

When you execute a vSphere CLI with the --server option pointing to a vCenter Server system, use --vihost to specify the ESX/ESXi host to run the command against.

---

EXAMPLES

The following examples assume you are specifying connection options, either explicitly or, for example, by specifying the server, user name, and password. Run vicfg-authconfig --help for a list of common options including connection options.

List the supported authentication schemes:

 vicfg-authconfig <conn_options> --listauthstores

Get the currently set authentication schemes:

 vicfg-authconfig <conn_options> --getremoteauthstore

Join the specified AD Domain:

 vicfg-authconfig <conn_options> <ad_conn_options> --authscheme AD --joindomain <domain_FQDN>

Leave the current AD Domain:

 vicfg-authconfig <conn_options> --authscheme AD --leavecurrentdomain [--force]

Display the current AD Domain:

 vicfg-authconfig <conn_options> --authscheme AD --currentdomain

Thanks to Vmware Documentation

vifs command (ESXi)

NAME

vifs - perform file system operations on remote hosts

---

SYNOPSIS

 vifs [<connection_options>]
   [--copy <source> <target> |
    --dir <remote_dir> |
    --help |
    --force |
    --get <remote_path> <local_path> |
    --listdc |
    --listds [--dc <datacenter>] |
    --mkdir <remote_dir> |
    --move <source> <target> |
    --put <local_path> <remote_path> |
    --rm <remote_path> |
    --rmdir <remote_dir> ]

---

DESCRIPTION

The vifs command performs common operations such as copy, remove, get, and put on files and directories. The command is supported against ESX/ESXi hosts but not against vCenter Server systems.

Note: While there are some similarities between vifs and DOS or Unix file system management utilities, there are also many differences. For example, vifs does not support wildcard characters or current directories and, as a result, relative path names. Use vifs only as documented.

---

OPTIONS

connection_options

Specifies the target server and authentication information if required. Run vifs --help for a list of all connection options

--copy | -c <source> <target>

Copies a file in a datastore to another location in a datastore. The <source> must be a remote source path, the <target> a remote target path or directory. Use the--force option to replace existing destination files.

--dir | -D <remote_dir>

Lists the contents of a datastore or host directory.

--help

Prints a help message for each command-specific and each connection option. Calling the command with no arguments or with --help has the same effect.

--force | -f

Overwrites the destination file. Use with --copy and --move.

--get | -g <remote_path> <local_path>

Downloads a file from the ESX/ESXi host to the machine on which you run the vCLI commands. This operation uses HTTP GET.

--listdc | -c

Lists the datacenter paths available on an ESX/ESXi system.

--listds | -S

Lists the datastore names on the ESX/ESXi system. When multiple datacenters are available, you can use the --dc|-Z <datacenter> argument to specify the name of the datacenter from which you want to list the datastore.

--mkdir | -M <remote_dir>

Creates a directory in a datastore. This operation fails if the parent directory of remote_dir does not exist.

--move | -m <source> <target>

Moves a file in a datastore to another location in a datastore. The <source> must be a remote source path, the <target> a remote target path or directory. The --force option replaces existing destination files.

--put | -p <local_path> <remote_path>

Uploads a file from the machine on which you run the vCLI commands to the ESX/ESXi host. This operation uses HTTP PUT. This command can replace existing host files but cannot create new files.

--rm | -r <remote_path>

Deletes a file or a directory.

--rmdir | -r <remote_dir>

Deletes a datastore directory. This operation fails if the directory is not empty.

---

EXAMPLES

The following examples assume you are specifying connection options, either explicitly or, for example, by specifying the server, user name, and password. Run vifs --help for a list of common options including connection options.

Copy a file to another location:

 vifs <connection_options> -c "[StorageName] VM/VM.vmx" "[StorageName] VM_backup/VM.vmx"

List all the datastores:

 vifs <connection_options> -S

List all the directories:

 vifs --server <connection_options> -D "[StorageName] vm"

Upload a file to the remote datastore:

 vifs <connection_options> -p "tmp/backup/VM.pl"
    "[StorageName] VM/VM.txt" -Z "ha-datacenter"

Delete a file:

 vifs <connection_options> -r "[StorageName] VM/VM.txt" -Z "ha-datacenter"

 vifs <connection_options> -rmdir "[StorageName] VM/VM.txt" -Z "ha-datacenter"

List the paths to all datacenters available in the server:

 vifs <connection_options> -C

Download a file on the host to a local path:

 vifs <connection_options> -g  "[StorageName] VM/VM.txt" 
    -Z "ha-datacenter" "tmp/backup/VM.txt"

Move a file to another location:

 vifs <connection_options> -m  "[StorageName] VM/VM.vmx"  
    "[StorageName] vm/vm_backup.vmx" -Z "ha-datacenter"

Remove an existing directory:

 vifs <connection_options> -R "[StorageName] VM/VM" -Z "ha-datacenter"

 vifs <connection_options> --rm "[StorageName] VM/VM" -Z "ha-datacenter"

Thanks to Vmware Documentation

Using ESXi Shell in ESXi 5.0 and 5.1 (2004746)

Purpose

This article provides guidance on the recommended use of ESXi Shell for VMware ESXi 5.0 and 5.1.

Resolution

Enabling ESXi Shell access using the vSphere Client

Use the vSphere Client to enable local and remote access to the ESXi Shell:

1. Log into a vCenter Server system using the vSphere Client.
2. Select the host in the inventory panel.
3. Click the Configuration tab and click Security Profile.
4. In the Services section, click Properties.
5. Select ESXi Shell from this list:
   
   ESXi Shell
SSH
Direct Console UI
   
6. Click Options and select Start and stop manually.
   
   Note: When you select Start and stop manually, the service does not start when you reboot the host. If you want the service to start when you reboot the host, select Start and stop with host.
   
7. Click Start to enable the service.
8. Click OK.

Enabling ESXi Shell access using the Direct Console User Interface

Use the direct console user interface to enable the ESXi Shell:

1. From the Direct Console User Interface, press F2 to access the System Customization menu.
2. Select Troubleshooting Options and press Enter.
3. From the Troubleshooting Mode Options menu, select Enable ESXi Shell.
   
   Enable ESXi Shell
Enable SSH
   
4. Press Enter to enable the service.

Configuring the timeout for the ESXi Shell

By default, the timeout setting for the ESXi Shell is 0 (disabled). The timeout setting is the number of minutes that can elapse before you must log in after the ESXi Shell is enabled. After the timeout period, if you have not logged in, the shell is disabled.

Note: If you are logged in when the timeout period elapses, your session persists. However, the ESXi Shell is disabled and it prevents other users from logging in.

• To set the ESXi Shell timeout from the Direct Console User Interface:
  
  
  1. From the Direct Console User Interface, press F2 to access the System Customization menu.
  2. Click Troubleshooting Mode Options.
  3. Modify ESXi Shell and SSH timeouts and press Enter.
  4. Enter the timeout in minutes.
  5. Press Enter.
  6. Press Esc until you return to the main menu of the Direct Console User Interface.
     
• To set the ESXi Shell timeout from vSphere Client:
  
  
  1. Log into a vCenter Server system using the vSphere Client.
  2. Select the host in the inventory panel and click Configuration tab.
  3. Under Software, click Advanced Settings.
  4. In the left panel, click UserVars.
  5. In the UserVars.ESXiShellTimeOut field, enter the timeout setting.
  6. Click OK.

Note: If ESXi Shell and SSH are enabled, the option to modify the timeout value is grayed out. To change the timeout value, ensure both ESXi Shell and SSH are disabled. This is by design and is intended to indicate when the timeout values would take effect.

Accessing the local ESXi Shell

1. If you have direct access to the host, press Alt+F1 to open the log in page on the machine's physical console.
2. Provide credentials when prompted.

Accessing the remote ESXi Shell

1. Open an SSH client.
2. Specify the IP address or domain name of the ESXi host.
   
   Notes:
   
   • Steps may vary depending on the SSH client you are using. For more information, consult the client documentation and support.
   • By default, SSH works on TCP port 22.
     
3. Provide credentials when prompted.

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004746

vSphere 5.1 – Full Admin Support for Named User Accounts (Shared root access is no longer required.)

Nestled among the many new features and capabilities introduced with vSphere 5.1 are some nice security improvements to the ESXi Shell.  One of the more notable improvements is the ability to assign full admin privileges to named user accounts.  This means there is no longer a dependency on a shared “root” account when working from the ESXi Shell.

Versions of ESXi prior to 5.1 only allow for a single administrative account on the host, and this was of course the “root” user.  While it is possible to create named user accounts and to use these accounts to logon to the ESXi Shell and perform many operations, these users are not granted full administrative rights on the host.  As such these named users often need to “su” to root in order to perform privileged operations such as viewing logs, creating a log bundle for support, or running commands like esxtop or vmkfstools.  This presents some challenges in terms of both security and auditing.   Not only is there an inherent dependency on a shared root account, but key administrative actions performed on the host are logged as “root” making it difficult to audit individual user activity on the host.

With vSphere 5.1 there is no longer a dependency on a shared root account.  ESXi 5.1 now allows assigning full administration rights to named users.  With this, users can now logon to the ESXi shell using individual accounts without the need to “su” to root, and because there is no longer a dependency on a shared root account all actions performed on the host are logged under the named user rather than the shared “root” account.  Thus helping to better secure the host while at the same time improve logging and auditing.

The ability to assign full admin rights to named users helps improve host security and allows you to limit access to the root account.  A couple things to remember when it comes to creating named users on an ESXi host:

1. You cannot create local ESXi users from the Web Client.  To create local users using the UI you need to use the vSphere client to connect directly to the ESXi host.
2. You can also use Host Profiles to create local users and assign privileges.  This can be very beneficial if you have a lot of hosts and want to ensure a common set of local user accounts gets created on each.

As an alternative to creating local user accounts on each ESXi hosts I would encourage you to consider adding your hosts to Active Directory (AD) instead.  This not only enables users to use their existing AD credentials to manage ESXi hosts, but it also simplifies the configuration by eliminating the need to create and maintain local user accounts on each host.   I’ll be posting some more info on this so be sure to check back.

Source:-
http://blogs.vmware.com/vsphere/2012/09/vsphere-5-1-full-admin-support-for-named-user-accounts.html

Eric Sloof vCloud Networking Video

http://www.youtube.com/watch?v=EZw1UemLBoE

VMware vCloud Management Pod - Private Cloud Diagram

This diagram illustrates VMware vCloud Management Pod - Private Cloud

Note: A PDF version of this diagram has also been attached to this article



PDF Link

Source:-
http://www.hypervizor.com/

VMware vCloud Management Pod - Public Cloud Diagram

This diagram illustrates VMware vCloud Management Pod - Public Cloud

Note: A PDF version of this diagram has also been attached to this article.

PDF Link

Source:-

http://www.hypervizor.com/

ESXi Management and Monitoring Diagram

This diagram illustrates ESXi Management and Monitoring

Note: A PDF version of this diagram has also been attached to this article.

PDF Link

Source:-
http://www.hypervizor.com/

Vmware vCloud Suite 5.x Diagram

This diagram illustrates Vmware vCloud Suite 5.x

Note: A PDF version of this diagram has also been attached to this article.

PDF Link

Source:-

http://www.hypervizor.com/

Vmware NSX for vSphere - System Architecture

This diagram illustrates Vmware NSX for vSphere - System Architecture

Note: A PDF version of this diagram has also been attached to this article.

PDF Link

Source:-

http://www.hypervizor.com/

VMware vCloud™ Director Networking Architecture

This diagram illustrates VMware vCloud™ Director Networking Architecture

Note: A PDF version of this diagram has also been attached to this article.

PDF Link

Source:-

http://www.hypervizor.com/

Diagram - VMware vCloud Director Cell Architecture

This diagram illustrates the vCloud Director cell architecture:

Note: A PDF version of this diagram has also been attached to this article.

Attachments

• Pdf Link

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1030954

VMware vCloud Director network ports diagram

This diagram shows the relationships of the VMware vCloud Director Network Ports:

Note: A PDF version of this diagram has also been attached to this article.

Attachments

Pdf Link

Source:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1030816

Creating network pools in VMware vCloud Director (1026300)

Purpose

This article provides:

• Information about the network pools available in VMware vCloud Director
• Steps to create a network pool

Resolution

 

To create Organization Networks or vApp Networks, a pool of network resources must be available. These network pools must be created in advance of the creation of Org and vApp networks. If they do not exist, the only network option available to an organization is the direct connect to the provider network.

Network pools can be one of these types:

• VLAN-backed – a range of VLAN IDs and a vNetwork distributed switch are available in vSphere. The VLAN IDs must be valid IDs that are configured in the physical switch to which the ESX/ESXi servers are connected.
  
• vCloud isolated networks – An isolation-backed network pool does not require pre-existing port groups in vSphere but needs a vSphere vNetwork distributed switch. It uses portgroups which are dynamically created. A Cloud isolated network spans hosts, provides traffic isolation from other networks and is the best source for vApp networks.
  
• vSphere port groups – Unlike other types of network pools, a network pool that is backed by port groups does not require a vNetwork distributed switch. This is the only type of network pool that works with Cisco Nexus 1000V virtual switches.
  
• vCloud Director 5.1 introduces VXLAN, which provides the capability to create isolated, multi-tenant domains across data center fabrics. For more information, see the:
• VXLAN Network Pools section of the vCloud  Director Administrator's Guide
• VXLAN Virtual Wires Management section of the vShield Administrator Guide

The network traffic on each network of a network pool is isolated at Layer 2 from all other network traffic. The VMware vCloud Director Network Isolation networks span hosts and are represented as portgroups on a vNetwork Distributed Switch.

 

Individual vCloud Director Network Isolated Networks are isolated from each other. They are enabled via an agent (vslad) running on each host that is participating in the network by opening a network tunnel. This is similar to the network isolation technology used in Lab Manager. However, isolation in vCloud Director is done with an ESX daemon alone and does not rely on Service virtual machines like Lab Manager.

To create a VLAN-backed network pool:

1. Create a Provider Network. For more information, see Creating External (Provider) Networks in VMware vCloud Director (1026299).
2. Click the Manage & Monitor tab, then click Network Pools (in the left pane).
3. Click Add Network Pool.
4. Select VLAN-backed and click Next.
5. Type a range of VLAN IDs and click Add.
   
   Note: You can create one network for each VLAN ID.
   
6. Select a vCenter Server and vNetwork distributed switch and click Next.
7. Type a name and optional description for the network and click Next.
8. Review the network pool settings and click Finish.

To create a vCloud isolated network:

1. Create a Provider Network. For more information, see Creating External (Provider) Networks in VMware vCloud Director (1026299).
2. Click the Manage & Monitor tab, then click Network Pools (in the left pane).
3. Click Add Network Pool.
4. Select VCD Network Isolation-backed and click Next.
5. Type the number of networks to create from the network pool.
6. (Optional) Type a VLAN ID.
7. Select a vCenter Server and a vNetwork distributed switch and click Next.
8. Type a name and optional description for the network and click Next.
9. Review the network pool settings and click Finish.
   
   Note: Cloud Director creates vCloud isolated networks in vSphere as they are needed.

To create vSphere Port Groups:

1. Create a Provider Network. For more information, see Creating External (Provider) Networks in VMware vCloud Director (1026299).
2. Click the Manage & Monitor tab, and click Network Pools (in the left pane).
3. Click Add Network Pool.
4. Select vSphere Port Group-backed and click Next.
5. Select a vCenter Server and click Next.
6. Select one or more port groups, click Add > Next.
   
   Note: You can create one network for each port group.
   
7. Type a name and optional description for the network and click Next.
8. Review the network pool settings and click Finish.

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026300

vCloud Director 5.1 Configuration Maximums (2036392)

Details

The limits presented in the following table represent tested, recommended limits for a vCloud Director 5.1 installation (single cell or multi-cell), and they are fully supported by VMware. To scale beyond these numbers, you will need to install an additional instance of vCloud Director 5.1. Please note that you cannot achieve the maximums in all categories at the same time, so make sure to understand how the limits apply to your use cases.

Solution

Category	Maximum
Total Virtual Machines	30,000
Powered-on Virtual Machines	10,000
Total vApps	30,000
Virtual Machines per vApp	128
ESX/i Hosts	2,000
vCenter Servers	25
vCloud Director Cells	10
Total Users	10,000
Concurrent Users	1,500
Logged-in Users	5,000
Total Organizations	10,000
Users per Organization	1,000
vApps per Organization	3,000
Virtual Datacenters (VDCs)	10,000
Resource Pools per VDC	32
Datastores	1,000
Concurrent Virtual Machine Consoles	500
Logical Networks	10,000
vApp Networks	1,000
External Networks	512
Isolated VDC Networks	2,000
Direct VDC Networks	10,000
Routed VDC Networks	2,000
Gateways	1,000
Network Pools	40
Catalogs	10,000
Media	1,000
Independent Disks	1,000
Storage Classes	50
Storage Pods	100