| |
The esxcfg- Commands
|
| |
esxcfg- |
| |
There are a new set of command line tools in ESX 3.x which all start with "esxcfg-". These tools are used to configure each part of the ESX 3.x configuration. For example, esxcfg-firewall is used to manage the service console firewall while the esxcfg-nic is used to manage the physical Ethernet adapters present in the server.
|
| |
esxcfg-advcfg |
| |
The esxcfg-advcfg command is interesting as there is not a huge amount of help about this command. However, we can figure out that it is meant to do advanced configuration and we can figure out some settings that can be made. The -g switch is used to "get" settings; the -s switch is used to "set" settings.
Here are a few examples of some VMkernel parameters which can be interrogated.
[root@esx1host vmware]# esxcfg-advcfg -g /Misc/BlueScreenTimeout
Value of BlueScreenTimeout is 0
[root@esx1host vmware]# esxcfg-advcfg -g /Misc/HostName
Value of HostName is esx1.vmlab.net
[root@esx1host vmware]# esxcfg-advcfg -g /VMFS3/ZeroedThickVirtualDisks
Value of ZeroedThickVirtualDisks is 1
[root@esx1host vmware]# esxcfg-advcfg –g /Disk/SupportSparseLUN
Value of SupportSparseLUN is 1
[root@esx1host vmware]# esxcfg-advcfg –g /Disk/MaxLUN
Value of MaxLUN is
[root@esx1host vmware]# esxcfg-advcfg –g /Scsi/ConflictRetries
Value of ConflictRetries is
[root@esx1host vmware]# esxcfg-advcfg –g /LVM/EnableResignature
Value of EnableResignature is
The question is, how much is configurable? To figure out what is configurable, we recommend that you look in the directory /proc/vmware/config which you will find in the service console command line and then you will see the following directories
BufferCache
Cpu
Disk
FileSystem
Irq
LVM
Mem
Migrate
Misc
Net
NFS
Numa
Scsi
User
VMFS3
From these directories and the files within, you can work out the paths to be supplied to the esxcfg-advcfg command as parameters. Alternatively, you could also use the command
esxcfg-info –o
to list the advanced options.
When using the esxcfg-advcfg command, remember case sensitivity!
Usage: esxcfg-advcfg <options> [<adv cfg Path>]
-g|--get Get the value of the config option
-s|--set <value> Set the value of the config option
-d|--default Reset Config option to default
-q|--quiet Suppress output
-k|--set-kernel Set a VMkernel load time option value.
-j|--get-kernel Get a VMkernel load time option value.
-h|--help Show this message.
-r|--restore Restore all advanced options from the configuration file. (FOR INTERNAL USE ONLY).
|
| |
esxcfg-firewall |
| |
The service console in ESX 3 now has a firewall enabled by default. The network packet filtering found in Red Hat Linux is called iptables. As the management of iptables is not entirely straightforward, the esxcfg-firewall command makes things a load easier.
We use this command to view and configure the firewall rules.
The most popular switch will be the -q switch to query the firewall for its settings.
[root@esxhost1 root]# esxcfg-firewall -q
<output>
The -s switch will allow you to enable or disable network services that may traverse the firewall successfully. The list of known services are shown below - very case sensitive!....
nfsClient
ftpServer
ntpClient
dellom
nisClient
vncServer
tmpLicenseClient
swISCSIClient
CIMHttpsServer
sshClient
snmpd
tmpAAMClient
vpxHeartbeats
smbClient
hpim
tmpHostVmdbServer
tmpHostdSOAPServer
ftpClient
sshServer
ibmdirector
CIMHttpServer
telnetClient
The -l switch loads the firewall and enables the IP tables.
The -u switch unloads the firewall and disables the IP tables.
We use the -e switch to enable a particular known service, so if we wanted to enable ssh outbound connections from the service console we would simply enter
[root@esxhost1 root]# esxcfg-firewall -e sshClient
We use the -d switch to disable a service. In the following example, we prevent outbound connections
[root@esxhost1 root]# esxcfg-firewall -d smbClient
If we need to open a TCP or UDP port that is not described by a defined friendly name like "sshClient", then we can explicitly open that port with the -o switch. The service console firewall is bidirectional and so when opening a port you must also specify direction of incoming or outgoing. Equally, we can close an explicit port with the -c switch.
[root@esxhost1 root]# esxcfg-firewall -o tcpport,out,name
In the following example, we are opening a unique port which we are calling "customapp"
[root@esxhost1 root]# esxcfg-firewall -o 12345,out,custom-app
The service names such as sshClient and smbClient are defined in the file /etc/vmware/firewall/services.xml .
|
| |
esxcfg-module |
| |
This command produces an output similar to vmkload_mod -list
[root@esx1host tools-isoimages]# esxcfg-module -l
Module Type Enabled Loaded
vmkapimod vmkapimod true true
vmklinux linux true true
cciss.o scsi true false
tg3.o nic true false
qla2300_7xx.o fc true false
Although if you compare the output with the old command, things don't exactly match up. Not sure why just yet....
|
| |
esxcfg-rescan |
| |
This command is used to perform a rescan of a host bus adapter (HBA). Specifically it scans a named vmkernel hba device, i.e. a vmhba. This command does a similar job to vmkfstools -rescan.
In this example the esxcfg-rescan command is used to rescan the iSCSI software initiator vmhba.
[root@esx1host]# esxcfg-rescan vmhba40
|
| |
esxcfg-upgrade |
| |
esxcfg-upgrade -h --help
-g --convert-grub
-f --convert-fstab
-r --upgrade-pre-vmkernel
-o --upgrade-post-vmkernel
The -g option may only be used with the -r option.
|
| |
esxcfg-vswitch |
| |
This command allows you to list, add, modify or delete virtual Ethernet switches on an ESX host. The simplest option with this command is the -l option to list the virtual switches defined on the host.
[root@esx1host root]# esxcfg-vswitch -l
If you are having problems with your ESX server after an in-place upgrade, this tool is invaluable in resolving the problems with service console networking.
The output of this command is initially a little intimidating. It is best to keep in mind the network topology:
Service Console IP Interface (vswif0) ---- connected to ----> Service Console Port on vSwitch ----- up-linked to ----> vmnic
Where a vmnic is a physical Ethernet adapter.
In following screenshot taken from the VI Client, we can see this ESX host has 2 connections to vSwitch0, the service console connection a VMkernel port connection.
If we wish to view the same information at the service console command line, we would use the esxcfg-vswitch command with the "-l" switch to list the defined virtual switches.
[root@esx1host root]# esxcfg-vswitch -l
Switch Name Num Ports Used Ports Configured Ports Uplinks
vSwitch0 32 4 32 vmnic0
PortGroup Name Internal ID VLAN ID Used Ports Uplinks
Service Console portgroup0 0 1 vmnic0
NFS access portgroup1 0 1 vmnic0
If we wanted to add another virtual Ethernet switch, we would use esxcfg-vswitch command with the "-a" switch. Note that the -a is specified in lowercase. Take care to ensure you have specified lowercase because uppercase A performs a different function with this command. So, lets add a new virtual switch to our ESX host called vSwitch1 and then list the switches to check our command has worked ok.
[root@esx1host root]# esxcfg-vswitch -a vSwitch1
[root@esx1host root]# esxcfg-vswitch -l
Switch Name Num Ports Used Ports Configured Ports Uplinks
vSwitch0 32 4 32 vmnic0
PortGroup Name Internal ID VLAN ID Used Ports Uplinks
Service Console portgroup0 0 1 vmnic0
NFS access portgroup1 0 1 vmnic0
Switch Name Num Ports Used Ports Configured Ports Uplinks
vSwitch1 64 0 64
PortGroup Name Internal ID VLAN ID Used Ports Uplinks
Notice that the number of ports on the virtual switch is 64 on the newly created switch. The original virtual switch has only 32. This difference arises between creating the switch in the VI Client or the command line. Anyway, if you are like me and you can never remember which case of the letter "a" to use when adding a virtual switch, then use the esxcfg-vswitch command with the --add switch when creating a new switch like this:
esxcfg-vswitch --add vSwitch2
which I think is a little clearer to understand.
Now if we want to add a portgroup to the new virtual switch we have created, we can use the esxcfg-vswitch -A command. It does not matter whether you are creating a service console port, a VM port group or a VMkernel port when creating a port group; the way we create the connection to the virtual switch always starts out the same in the command line. Only after creating the port group do we then specify if it is to be anything other than a VM port group. In the following commands, we add a new portgroup called "Production" on the virtual switch vSwitch1.
[root@esx1host root]# esxcfg-vswitch -A "Production" vSwitch1
[root@esx1host root]# esxcfg-vswitch -l
Switch Name Num Ports Used Ports Configured Ports Uplinks
vSwitch0 32 4 32 vmnic0
PortGroup Name Internal ID VLAN ID Used Ports Uplinks
Service Console portgroup0 0 1 vmnic0
NFS access portgroup1 0 1 vmnic0
Switch Name Num Ports Used Ports Configured Ports Uplinks
vSwitch1 64 0 64
PortGroup Name Internal ID VLAN ID Used Ports Uplinks
Production portgroup2 0 0
Alternatively you could use the following command to add a port group to a virtual switch.
[root@esx1host root]# esxcfg-vswitch --add-pg="Production" vSwitch1
This alternative switch of using --ad-pg I think is clearer for understanding what the command is doing. The --add-pg option can clearly be seen to add a portgroup to a virtual switch, and again is simpler to understand than just “-A”. The portgroup name in our example is called “Production”, but it can be what you want. We recommend adoption of a standard across all your virtual infrastructure. I have seen somnts align their portgroup names with the IP subnets, so you could have a portgroup called something like “192.168.1.0 subnet”.
Although we have now created a new virtual switch and have created a VM port group on it, the virtual switch itself does not have any uplinks. Remember that when we bind a physical network adapter to a virtual switch we are uplinking a vmnic to the switch and the switch then "owns" that adapter, i.e. it is not available to be used by any other virtual switches. We perform the uplink by using the esxcfg-vswitch command with the -L switch for link.
[root@esx1host root]# esxcfg-vswitch -L vmnic1 vSwitch1
So in one simple command we have linked the physical network adapter vmnic1 to our new virtual ethernet switch vSwitch1. If we then realised we had used the wrong physical adapter, we can just as easily unlink with -U. In the next example, we swap the uplinked vmnic1 for an alternative adapter vmnic2
[root@esx1host root]# esxcfg-vswitch -U vmnic1 vSwitch1
[root@esx1host root]# esxcfg-vswitch -L vmnic2 vSwitch1
This changing of vmnic bound to a virtual switch is often required post-installation, as we may select the wrong physical adapter to use for the service console during the install and need to correct our configuration before we can connect to our host with VI client!
|
| |
esxcfg-auth |
| |
Configures the service console authentication options including NIS, LDAP, Kerberos and Active Directory.
|
| |
esxcfg-info |
| |
Produces an enormous amount of information about the ESX host. You really need to pipe this to a file for closer examination!
[root@esx1host root]# esxcfg-info >esxinfo.txt
|
| |
esxcfg-mpath |
| |
Manages storage multi-pathing just as the vmkmultipath utility did in previous versions of ESX Server. In the example below we are using the -l switch to list the storage and paths.
[root@esx1host tools-isoimages]# esxcfg-mpath -l
Disk vmhba0:0:0 /dev/cciss/c0d0 (69459MB) has 1 paths and policy of Fixed
Local 2:1.0 vmhba0:0:0 On active preferred
Disk vmhba1:0:0 (0MB) has 1 paths and policy of Most Recently Used
FC 10:1.0 210000e08b846a72<->5006016930221397 vmhba1:0:0 On active preferred
Disk vmhba1:0:6 /dev/sda (9216MB) has 1 paths and policy of Most Recently Used
FC 10:1.0 210000e08b846a72<->5006016930221397 vmhba1:0:6 On active preferred
Disk vmhba1:0:21 /dev/sdb (10240MB) has 1 paths and policy of Most Recently Used
FC 10:1.0 210000e08b846a72<->5006016930221397 vmhba1:0:21 On active preferred
|
| |
esxcfg-resgrp |
| |
Used to manage the new ESX feature called resource groups. This command can add, remove or modify existing resource groups.
|
| |
esxcfg-hbadevs |
| |
The esxcfg-vmhbadevs command is used to list the equivalent Linux device names for the visible disk devices that the VMkernel references using vmhba notation.
[root@esx1host root]# esxcfg-vmhbadevs
vmhba0:0:0 /dev/sda
vmhba0:0:1 /dev/sdb
vmhba0:0:2 /dev/sdc
vmhba0:0:3 /dev/sdd
vmhba2:0:0 /dev/sde
vmhba2:1:0 /dev/sdf
If we use this command with the –m switch, then we only list the LUNs which contain VMFS partitions. Alongside the Linux device name, a long unique hexadecimal value is listed. This is the VMFS volume signature assigned by the new logical volume manager (LVM).
[root@esx1host root]# esxcfg-vmhbadevs -m
vmhba0:0:0:1 /dev/sda1 45407607-fbc43ced-94cb-00145e231ce3
vmhba0:0:2:1 /dev/sdc1 455b08a8-8af7fee3-daa9-00145e231e35
vmhba2:0:0:3 /dev/sde3 4559c75f-831d8f3e-bc81-00145e231e35
You can view these volumes in the directory /vmfs/volumes/ |
| |
esxcfg-boot |
| |
Used to configure the GRUB options presented at boot time. One thing to note is that the new esxcfg commands will not run if you boot just into Linux. If you just want to query the boot settings, you can use the -q switch but this must be qualified with the keyword boot or vmkmod.
[root@esx1host root]# esxcfg-boot -q boot
272 2:;7:;10:; UUID=847199e4-d3c7-11da-8ef8-930e3d734c03 /vmlinuz-2.4.21-37.0.2.ELvmnix /initrd-2.4.21-37.0.2.ELvmnix.img
[root@esx1host root]# esxcfg-boot -q vmkmod
vmkapimod vmkapimod
vmklinux linux
cciss.o scsi
tg3.o nic
qla2300_7xx.o fc
This is also used if you making modifications to VMkernel device drivers defaults. For example, if you were modifying the queue depth for a fibre HBA, you would likely be using esxcfg-module. Then to rebuild the boot image you would enter
[root@esx1host root]# esxcfg-boot -m
After which, you would do a reboot to test the update to the boot image had worked.
|
| |
esxcfg-init |
| |
Should not be run manually!
|
| |
esxcfg-nas |
| |
The esxcfg-nas command is used to list, mount and dismount NFS exports for the VMkernel. In the first example we list the NFS datastores which the VMkernel has mounted.
[root@esx1host root]# esxcfg-nas -l
NFS01 is /NFS from 100.100.100.253 mounted
In the next example, we add a new VMkernel mount to a remote NFS server. This time we are connecting to the NFS server at IP address 100.100.100.253 and the name of the exported directory is “/Test”. We are labelled this NFS mount “NFS02”.
[root@esx1host etc]# esxcfg-nas -a -o 100.100.100.253 -s /Test NFS02
Connecting to NAS volume: NFS02
NFS02 created and connected.
Remember that to create a connection to an NFS datastore, the VMkernel needs to have an IP address, as it is the NFS client. We give the VMkernel an IP address by creating a VMkernel port on a virtual Ethernet switch. We can do this at the command line using the command esxcfg-vmknic
The command line options for esx are:
esxcfg-nas <options> [<label>]
-a|--add Add a new NAS filesystem to /vmfs volumes. Requires --host and --share options.
-o|--host <host> Set the host name or ip address for a NAS mount.
-s|--share <share> Set the name of the NAS share on the remote system.
-d|--delete Unmount and delete a filesystem.
-l|--list List the currently mounted NAS file systems.
-r|--restore Restore all NAS mounts from the configuration file. (FOR INTERNAL USE ONLY).
-h|--help Show this message.
|
| |
esxcfg-route |
| |
If we add an IP address to the VMkernel by adding a VMkernel port, then we can fully configure that IP stack by also assigning a default gateway. We can view (no parameters) and set (1st parameter) the VMkernel IP default gateway with the esxcfg-route command as shown here.
[root@esx1host etc]# esxcfg-route
VMkernel default gateway is 100.100.100.254
[root@esx1host etc]# esxcfg-route 100.100.100.1
VMkernel default gateway set to 100.100.100.1
|
| |
esxcfg-vmknic |
| |
Used to view and set configure the VMkernel ports on virtual Ethernet switches. A VMkernel port is a special type of port group on a virtual Ethernet switch which is used to assign an IP address to the VMkernel. The VMkernel only needs an IP address for VMotion, software-initiated iSCSI or NFS access.
If you need to create a VMkernel port at the command line, then you need to create a port group first and then enable it as a VMkernel port. This tool does not allow you to enable the VMkernel port for VMotion, you must either use vimsh or the VI client for that.
[root@esx1host root]# esxcfg-vswitch -A VMotion vSwitch0
[root@esx1host root]# esxcfg-vmknic -a -i 100.100.100.121 -n 255.255.255.0 VMotion
The above commands would result in an additional connection to the virtual Ethernet switch, specifically a VMkernel port. The esxcfg-vmknic command has assigned the VMkernel an IP address & the portgroup called VMotion is now explicitly VMkernel port. The following screenshot displays the new VMkernel port connection on vSwitch0.
In the following example, we list the VMkernel ports, then use esxcfg-vmknic to delete one of them and then list them again.
[root@esx1host etc]# esxcfg-vmknic -l
Port Group IP Address Netmask Broadcast MAC Address MTU Enabled
NFS access 100.100.100.21 255.255.255.0 100.100.100.255 00:50:56:62:ca:f6 1514 true
VMotion 100.100.100.121 255.255.255.0 100.100.100.255 00:50:56:6d:7c:7d 1514 true
[root@esx1host etc]# esxcfg-vmknic -d VMotion
[root@esx1host etc]# esxcfg-vmknic -l
Port Group IP Address Netmask Broadcast MAC Address MTU Enabled
NFS access 100.100.100.21 255.255.255.0 100.100.100.255 00:50:56:62:ca:f6 1514 true
The command line options are:
esxcfg-vmknic <options> [[<portgroup>]]
-a|--add Add a VMkernel NIC to the system, requires IP parameters and portgroup name.
-d|--del Delete VMkernel NIC on given portgroup.
-e|--enable Enable the given NIC if disabled.
-D|--disable Disable the given NIC if enabled.
-l|--list List VMkernel NICs.
-i|--ip <X.X.X.X> The IP address for this VMkernel NIC. Setting an IP address requires that the
--netmask option be given in same command.
-n|--netmask <X.X.X.X> The IP netmask for this VMkernel NIC. Setting the IP netmask requires that the --ip
option be given in the same command.
-r|--restore Restore VMkernel TCP/IP interfaces from Configuration file (FOR INTERNAL USE ONLY).
-h|--help Show this message.
|
| |
esxcfg-dumppart |
| |
Used to configure the VMkernel crash dump partition. The old ESX 2.x utility for this function (vmkdump) is still present on an ESX 3 server, but appears just to be for extracting dump files.
So far, we have only used this utility to interrogate ESX hosts to determine where the dump partition has been created. Here is an example of viewing the dump partition. # esxcfg-dumppart -l
VM Kernel Name Console Name Is Active Is Configured
vmhba0:0:0:7 /dev/cciss/c0d0p7 yes yes
Remember that the dump partition does not show up when you run the vdf utility. However it is visible if you run fdisk. In the following example, we are running fdisk to view the partitions. We can see the dump partition as c0d0p7, i.e. partition #7. Notice the Id of that partition is "fc", the custom partition type for VMkernel dump partitions.
# fdisk /dev/cciss/c0d0
Disk /dev/cciss/c0d0: 36.3 GB, 36385505280 bytes
64 heads, 32 sectors/track, 34699 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes Device Boot Start End Blocks Id System
/dev/cciss/c0d0p1 * 1 100 102384 83 Linux
/dev/cciss/c0d0p2 101 5100 5120000 83 Linux
/dev/cciss/c0d0p3 5101 7100 2048000 83 Linux
/dev/cciss/c0d0p4 7101 34699 28261376 f Win95 Ext'd (LBA)
/dev/cciss/c0d0p5 7101 7644 557040 82 Linux swap
/dev/cciss/c0d0p6 7645 34599 27601904 fb Unknown
/dev/cciss/c0d0p7 34600 34699 102384 fc Unknown
The command line options are:
esxcfg-dumppart <options> [<partition>]
-l|--list List the partitions available for Dump Partitions. WARNING: This will scan all LUNs on the system.
-t|--get-active Get the active Dump Partition for this system, returns the internal name of the partition
vmhbaX:X:X:X) or 'none'.
-c|--get-config Get the configured Dump Partition for this system, returns the internal name of the partition
vmhbaX:X:X:X) or 'none'.
-s|--set Set the Dump Partition for this system and activate it, either vmhbaX:X:X:X or 'none' to
deactivate the active dump partition.
-f|--find Find usable Dump partitions and list in order of preference.
-S|--smart-activate Activate the configured dump partition or find the first appropriate partition and use it(same
order as -f).
-a|--activate Activate the configured dump partition.
-d|--deactivate Deactivate the active dump partition.
-h|--help Show this message.
|
| |
esxcfg-linuxnet |
| |
There is not normally a command that a virtual infrastructure administrator should need. The tool is automatically used when you start an ESX server in troubleshooting mode; i.e. when you start only the service console Linux kernel and don't start the VMkernel.
When you are working in the service console while the VMkernel is loaded, the service console's network interface is not called eth0, but is called vswif0 instead. This is because the service console network interface is provided via a service console portgroup on a virtual Ethernet switch. If you restart your ESX server without the VMkernel, then standard Linux drivers and network card management is used. Therefore the network interface used in troubleshooting mode is called eth0 - just like any other regular Linux box. This tool is called by starting troubleshooting mode to replicate the IP parameters assigned to vswif0 to eth0.
Should you want to investigate this command, the options are:
esxcfg-linuxnet --setup
--remove
-h --help
The --setup option cannot be combined with the --remove option.
|
| |
esxcfg-nics |
| |
This tool can be used to view and configure the speed and duplex settings of the physical network cards in the ESX Server. This tool can replace the mii-tool and modules.conf for network card management.
In the following example, we run the list option to view all physical NICs and their properties.
[root@esx1host etc]# esxcfg-nics -l
Name PCI Driver Link Speed Duplex Description
vmnic2 01:01.00 tg3 Up 1000Mbps Full Broadcom Corporation NetXtreme BCM5703 Gigabit Ethernet
vmnic0 01:02.00 tg3 Up 100Mbps Full Broadcom Corporation NC7781 Gigabit Server Adapter (PCI-X, 10,100,1000-T)
vmnic1 04:02.00 tg3 Up 1000Mbps Full Broadcom Corporation NC7781 Gigabit Server Adapter (PCI-X, 10,100,1000-T)
This command has the following optional parameters:
esxcfg-nics <options> [nic]
-s|--speed <speed> Set the speed of this NIC to one of 10/100/1000/10000. Requires a NIC parameter.
-d|--duplex <duplex> Set the duplex of this NIC to one of 'full' or 'half'. Requires a NIC parameter.
-a|--auto Set speed and duplexity automatically. Requires a NIC parameter.
-l|--list Print the list of NICs and their settings.
-r|--restore Restore the nics configured speed/duplex settings (INTERNAL ONLY)
-h|--help Display this message.
|
| |
esxcfg-swiscsi |
| |
ESX server 3 supports both hardware and software initiated iSCSI. For hardware iSCSI, we can use host bus adapters which perform the TCP offload and so the vmkernel can just pass SCSI commands to them as normal. The iSCSI hba can then wrap the SCSI command in IP transport and forward them to the iSCSI target.
In software iSCSI, the wrapping of SCSI commands in IP is performed by the VMkernel and a regular physical network card is used to communicate with the iSCSI target. The software iSCSI configuration is exposed in the VI Client as a host bus adapter called vmhba40.
We can user the tool esxcfg-swiscsi to configure it. The software iSCSI initiator in the VMkernel has a dependency upon the service console, therefore both the service console and VMkernel must have an IP route to the iSCSI target.
1. Add a VMkernel port to a vSwitch that has an uplink and route to iSCSI target
2. Ensure service console IP interface has a route to the same iSCSI target
3. Using either the VI Client security profile or the esxcfg-firewall, open a port in the service console firewall for iSCSI (TCP:3260)
4. In the command line, enable iSCSI with esxcfg-swiscsi -e command
5. In the command line, run
6. At the service console command line, run esxcfg-swiscsi -s
7. In the VI Client your iSCSI target should become visible.
The command line options for this command are:
-e, --enable Enable sw iscsi
-d, --disable Disable sw iscsi
-q, --query Check if sw iscsi is on/off
-s, --scan Scan for disk available through sw iscsi interface
-k, --kill Try to forcibly remove iscsi sw stack
-r, --restore Restore sw iscsi configuration from file (FOR INTERNAL USE ONLY)
-h, --help Show this message
|
| |
esxcfg-vswif |
| |
This tool can manage the Ethernet interfaces of the service console. In a big change from previous versions of ESX, the Ethernet interface of the service console is named with the "vswif" prefix and not "eth" prefix as you may be used to in Linux.
During installation of ESX server, your service console Ethernet connection should have been created. However, maybe a mistake was made, or we want to add another service console port for redundancy.
In VI Client we can view the network configuration of our ESX host. Here is an example of a typical network configuration.
If we use the esxcfg-vswif tool, we are examining, creating or modifying a service console port. So in the first example here, we are simply listing what ports have been created. # esxcfg-vswif -l
Name Port Group IP Address Netmask Broadcast Enabled DHCP
vswif0 Service Console 192.168.31.31 255.255.255.0 192.168.31.255 true false
So the output is showing the same as the graphical output in VI client.
If we wanted to add a 2nd service console port, we could use this command. However, all this command will do is turn a regular portgroup into a service console port and bind an IP address to Linux. So in the following command line example, we create a portgroup first, and then we turn it into a service console port with esxcfg-vswif.
# esxcfg-vswitch --add-pg="Service Console Backup" vSwitch1
# esxcfg-vswif -a -i 10.10.1.31 -n 255.255.0.0 -p "Service Console Backup" vswif1
[2007-11-21 11:29:18 'Vnic' warning] Generated New MAC address, 00:50:56:4d:da:97 for vswif1
Nothing to flush.
So now if we run esxcfg-vswif to list the service console ports, we will be able to see the original service console port as well as our new one we just created. We've shown you the graphical representation as well from the VI client so you can compare. # esxcfg-vswif -l
Name Port Group IP Address Netmask Broadcast Enabled DHCP
vswif0 Service Console 192.168.31.31 255.255.255.0 192.168.31.255 true false
vswif1 Service Console Backup 10.10.1.31 255.255.0.0 10.10.255.255 true false
|
| |
Configuration Files
|
| |
/etc/vmware/esx.conf |
| |
An all new configuration file for ESX Server 3.x. This file replaces the functionality of the following configuration files found in earlier versions of ESX.
/etc/vmware/hwconfig
/etc/vmware/devnames.conf
/etc/vmware/vmkmodule.conf
/etc/vmware/netmap.conf
/etc/vmware/vmkconfig
|
| |
/etc/nsswitch.conf |
| |
This is the name service switch configuration file. If you need to modify the order of how names in the service console are resolved, this is the place to make the change. You can view and edit this conf file as usual.
There will be a number of lines to this file, but the one you are likely to be interested in will start "hosts:" as shown:
hosts: files dns
In the above example, the name service will use the /etc/hosts file, and then the DNS name server specified in the /etc/resolv.conf file. |
| |
/usr/bin/vmware-watchdog |
| |
This process watches over the hostd process and restarts it if it crashes.
|
| |
hostd |
| |
This is the daemon that replaces vmware-serverd that was found in the ESX 2.x products. This is the host management agent and is responsible for a number of key management functions on an ESX host. If you are having any "host not responding" type problems, before you even think of an ESX host restart, consider just a restart of the management agent; it's amazing how often a quick restart of hostd gets things going again.
We can restart the host management agent with the command
service mgmt-vmware restart
|
| |
/etc/vmware/firewall/services.xml |
| |
This file contains the definitions for the TCP ports and service names used by the service console firewall. When we use the esxcfg-firewall command to open ports based on friendly service names such as sshServer, that name is a definition in this XML file. A typical service definition in this file looks like <service id='0000'>
<id>sshServer</id>
<rule>
<direction>inbound</direction>
<protocol>tcp</protocol>
<port type='dst'>22</port>
<flags>-m state --state NEW</flags>
</rule>
</service>
You could modify this XML file to include your own definitions. We have not tested if such a change would persist patching/upgrades.
|
| |
vpxa |
| |
This is the name of the VirtualCenter server agent that runs in the service console of ESX 3.x servers (which was called vmware-ccagent in ESX 2.x). This can be stopped, started or restarted with the service command
service vmware-vpxa restart
|
| |
/etc/vmware/vpxa.cfg |
| |
This is the XML configuration file for the VirtualCenter Server Agent in the service console. Here is a typical vpxa.cfg file.
[root@esx1host vmware]# cat vpxa.cfg
<config>
<log>
<outputToConsole>false</outputToConsole>
</log>
<nfc>
<loglevel>error</loglevel>
</nfc>
<vmacore>
<ssl>
<doVersionCheck>false</doVersionCheck>
</ssl>
<threadpool>
<TaskMax>10</TaskMax>
</threadpool>
</vmacore>
<vpxa>
<datastorePrincipal>root</datastorePrincipal>
<hostIp>100.100.100.11</hostIp>
<memoryCheckerTimeInSecs>30</memoryCheckerTimeInSecs>
<serverIp>100.100.100.172</serverIp>
<serverPort>902</serverPort>
</vpxa>
<workingDir>/var/log/vmware/vpx</workingDir>
Notice the <loglevel> tag. If you are trying to troubleshoot an issue, then increasing the logging level is a good idea. We have used the level "verbose", there could be a higher debug level of logging, but we've not tested that.
|
| |
VMware Command Line Tools
|
| |
vmkfstools |
| |
Used to manipulate virtual disks at the service console command line. It is used most often for import and export operations, where a virtual disk is converted from monolithic format to sparse format (previously called COW format).
There is a great switch with the command -X which can be used to extend the size of your virtual disk; e.g. if you had a 10GB virtual disk and wanted to expand it to 20GB, you could use this command. The VM would need to be powered off for this to work.
vmkfstools -X 20GB /vmfs/volumes/storage1/vm.vmdk
Note that the -X switch specifies the NEW SIZE of the virtual disk and NOT how much you are extending it by.
If you have used the -X switch before in an older version of ESX server (earlier than 3.0) it was possible to specify a small disk size; thereby making the virtual disk smaller. This was dangerous but useful if your partition within the disk did not consume 100% of the disk size. However, this is not possible with vmkfstools command found in ESX Server version 3.x.
From ESX 3.5, the size of a virtual disk can now be increased in the VI Client! VMware are implementing more and more in the user interface, less time needed in the service console command line...
Previously, the main use of vmkfstools command was to import or export virtual disks. This would be required if you were deploying templates by hand instead of using VirtualCenter. It was also the primary method for moving VMs between the ESX server product and the hosted VMware products such as VMware Workstation or Server. The reason we say "previously" is that moving VMs between servers or between VMware products has become much simpler and cleaner by using the VMware Converter utility. This tool is task oriented and treats the VM as a whole object, not just the virtual disk files as vmkfstools.
If you do want to import virtual hard disks in 2GB sparse format into monolithic format by hand, then we can use vmkfstools command with the -i switch.
vmkfstools -i /importfiles/vm.vmdk /vmfs/volumes/storage1/vm/vm.vmdk
Notice that the import option requires two parameters, source and destination. This would not create a VM, but would create the monolithic virtual disk for a VM. You could then create a custom VM in the VI Client and select the option to "use an existing disk".
If you want to export a virtual disk you no longer use the -d switch, but just use -i and specify the virtual disk type at the destination of the import. So if you were exporting a virtual disk from VMFS to
vmkfstools -i /vmfs/volumes/storage1/vm/vm.vmdk -d 2gbsparse /exportvm/vm.vmdk
|
| |
vmware-cmd |
| |
This command has been in ESX for a number of versions and it's functionality has been extended with each major release.
|
| |
esxupdate |
| |
This utility is what we use to patch our ESX hosts with updates from VMware. You can use this tool interactively to install individual patches, or use it to scan your ESX host to see which patches are required as well as to do a "what-if" install of a host patch to identify if there will be any problems.
The power of the esxupdate command is realised when you use it with a patch repository. A patch repository can be exposed to a host via HTTP, FTP or NFS.
- Bundle Name - AppFlags --- Summary --- iFlags
ESX350-200710049-BG -------v Bugs fixed in some vmkernel. rm-
ESX350-200710050-SG i------v Security bugs fixed in vmkernel module.. rm-
ESX350-200710052-BG i------v Several bugs fixed in vmx module... -m-
ESX350-200710053-BG -------- Provided new PBM for SUSE 11 U2. ---
ESX350-200710054-BG -------v COS fix for Ooops. rm-
ESX350-200710055-BG -------- More fixes in scsi drivers. r--
ESX350-200710058-RG -------v This is a roll-up bundle. rm-
ESX350-200710059-RG -------v This is a roll-up security bundle. rm-
If you choose to use the new VirtualCenter Server 2.5 feature called Update Manager, then when you perform host scans and remediation, you are in fact just remotely invoking this utility, it's just you don't see it!
You can use the --explain switch when scanning to provide a greater level of detail to your host patch scan operation. If for example, the AppFlags for a patch indicated "c" for conflict, you would probably want to know what exactly the patch was in conflict with.
|
| |
contents.xml |
| |
Every ESX patch contains a file called contents.xml. This file describes the directory structure of the patch bundle contents.
|
| |
contents.xml.sig |
| |
This is a detached PGP signature of the contents.xml file in a ESX patch.
|
| |
vimsh |
| |
This is a superb utility that we use on occasion, particularly when we are creating scripted builds for ESX. The industry-recognised experts in the functions of this tool are the folks over at www.xtravirt.com. Where we have found this tool of unique use is in the enabling of a VMkernel port for VMotion.
If you are using ESX versions prior to 3.5 then use
vimsh -n -e "hostsvc/vmotion/vnic_set portgroupname
However, if you are using ESX version 3.5 then we need to use a slightly different syntax for specifying the portgroup to enable. We now need to specify using a vmkx notation. Trouble is, we don't know which portgroup corresponds to which vmkx number. So to first identify the mapping of portgroup name to vmk number, we enter the command
vimsh
and then enter hostsvc/vmotion/netconfig_get and we'll get a whole pile of output, but buried in there will be the device names in vmkx format that we can then use to enable VMotion on that portgroup with the following:
vimsh -n -e "hostsvc/vmotion/vnic_set vmk0
Using the vimsh command for enabling VMotion is just 1% of the functionality of this tool. It's not for the faint hearted and there really is no better source of information about it than the PDF documents that the xtravirt guys have written. Thanks also to Mike Laverick of RTFM Education for documenting the changes in vimsh in version 3.5.
|
| |
RPM Utilities
|
| |
rpm |
| |
As ESX service console is based on modified Red Hat Enterprise Linux 3, we can use the RPM package installation method to add applications to it. However, we should also point out that it's maybe not the best idea to add software to the service console. It is best to treat the service console as a dedicated console and not add applications to it.
If you are unfamiliar with RPMs in Linux, think of them like MSI packages in Windows.
The rpm command can be used to list and to install RPM-based applications. In the following example, we are using the command switch (-qa) to list the rpms installed in the service console.
# rpm -qa
libgcc-3.2.3-53
setup-2.5.27-1
basesystem-8.0-2
tzdata-2005m-1.EL3
glibc-2.3.2-95.37
bzip2-libs-1.0.2-11.EL3.4
etc!.....
If we are only interested in the VMware rpms, then we can just pipe the output of rpm -qa command into the grep search tool.
rpm -qa |grep VMware
which should yield an output something like
VMware-webCenter-esx-2.0.1-32041
VMware-esx-apps-3.0.1-32039
VMware-esx-iscsi-3.0.1-32039
VMware-esx-uwlibs-3.0.1-32039
VMware-esx-vmkernel-3.0.1-32039
VMware-esx-drivers-block-DAC960-2.4.11-32039
VMware-esx-drivers-net-bcm5700-7.3.5-32039
VMware-esx-drivers-net-e100-2.3.40-32039
VMware-esx-drivers-net-pcnet32-1.30c-32039
VMware-esx-drivers-net-tg3-3.43b.1vmw-32039
VMware-esx-drivers-scsi-adp94xx-0.0.5-32039
VMware-esx-drivers-scsi-aic7xxx-6.3.9-32039
VMware-esx-drivers-scsi-lpfcdd-v732-7.3.2.1vmw-32039
VMware-esx-drivers-scsi-megaraid_sas-0.0.2-32039
VMware-esx-drivers-scsi-qla2200-v7.07-7.7.4.1vmw-32039
VMware-esx-drivers-scsi-qla4010-3.24-32039
VMware-esx-drivers-scsi-vmkiscsi-3.4.2-32039
VMware-hostd-esx-3.0.1-32039
VMware-esx-lnxcfg-3.0.1-32039
VMware-esx-perftools-3.0.1-32039
VMware-esx-docs-3.0.1-32039
VMware-esx-tools-3.0.1-32039
VMware-esx-vmkctl-3.0.1-32039
VMware-esx-drivers-block-cciss-2.4.54-32039
VMware-esx-drivers-net-3c90x-1.0.2-32039
VMware-esx-drivers-net-bnx2-1.3.22-32039
VMware-esx-drivers-net-e1000-7.0.33.2vmw-32039
VMware-esx-drivers-net-s2io-1.7.6-32039
VMware-esx-drivers-scsi-aacraid_esx30-1.1.5.1vmw-32039
VMware-esx-drivers-scsi-aic79xx-6.3.9-32039
VMware-esx-drivers-scsi-ips-7.10.17.1vmw-32039
VMware-esx-drivers-scsi-megaraid2-2.10.7-32039
VMware-esx-drivers-scsi-mptscsi_2xx-2.6.34.1vmw-32039
VMware-esx-drivers-scsi-qla2300-v7.07-7.7.4.1vmw-32039
VMware-esx-drivers-scsi-qla4022-3.24-32039
VMware-esx-vmx-3.0.1-32039
VMware-esx-srvrmgmt-3.0.1-32039
VMware-esx-backuptools-3.0.1-32039
VMware-esx-scripts-3.0.1-32039
VMware-esx-3.0.1-32039
VMware-cim-esx-3.0.1-32039
VMware-vpxa-2.0.1-32042
If we then want to find out more information on an individual RPM package, we can use the rpm -qi option to query a package which reports the file version, vendor, license and description.
# rpm -qi VMware-hostd-esx-3.0.1-32039
Name : VMware-hostd-esx Relocations: (not relocatable)
Version : 3.0.1 Vendor: VMware, Inc.
Release : 32039 Build Date: Tue 26 Sep 2006 01:30:42 AM PDT
Install Date: Tue 06 Nov 2007 03:07:02 PM PST Build Host: pa-build43.eng.vmware.com
Group : Applications/Emulators Source RPM: VMware-hostd-esx-3.0.1-32039.src.rpm
Size : 269864433 License: commercial
Signature : (none)
Summary : VMware Host Agent package.
Description :
If we then want to know what files are included in the rpm package, we can use query with the list option to see the files inside. For example, to see the files
# rpm -ql VMware-hostd-esx-3.0.1-32039 /etc/vmware/hostd/config.xml /etc/vmware/hostd/env/0.xml /etc/vmware/hostd/env/1.xml /etc/vmware/hostd/env/vmconfigoption-esx-2.5.0.xml /etc/vmware/hostd/env/vmconfigoption-esx-3.0.0.xml /etc/vmware/hostd/environments.xml /etc/vmware/hostd/esxinfo.vha .....
|
| |
rpm2cpio |
| |
If you are wanting to extract a single file from a RPM package but you don't want to install the RPM, then this is the tool for you. Probably best if you copy the RPM to a temp directory so when you extract the RPM you can then navigate the directory structure created in that temp directory to find the file or files you need.
Once you have copied out the file you were after, you can safely delete the contents of that temp directory. In other words, we have used rpm2cpio to extract the RPM archive.
Here is an example using the RPM we've used in the previous examples.
# rpm2cpio VMware-hostd-esx-3.0.1-32039 | cpio -idmv
i = Restore archive
d = Create landing directories
m = Create previous file modification times
v = verbose |
| |
|
| |
|
| |
Linux Utilities
|
| |
/etc/ssh/sshd_config |
| |
The configuration of SSH client is stored in the text file /etc/ssh/ssh_config
The configuration of the SSH server daemon is stored in the text file /etc/ssh/sshd_config. An important setting in this file is PermitRootLogin=No. This is the default setting in ESX 3.x and it is recommended that you keep the setting at "No". This way you have an audit trail and see exactly who is logging in, rather than just "root". You can quickly what the setting is by using a grep operation on the file as shown:
# grep Permit /etc/ssh/sshd_config
If you do edit the file to change this setting to Yes, then make sure you restart the daemon for the changes to take effect using the command:
# service sshd restart
|
| |
su |
| |
This command is the switch user utility.
When it used without parameters, we are specifying to switch to the user root. However, we can use the su command to switch shell to any user account. In the first example, we are logged in as the user kevin and we are switching to user ali.
[kevin@esx1host kevin]$ su ali
Password:
[ali@esx1host kevin]
In this second example, we are switching from being logged on as a user called sara to being logged on as root. Notice to switch to root, we don't need to specify a username.
[sara@esx1host sara]$ su -
Password:
[root@esx1host root]#
If we restrict the built-in user account root from logging in over the SSH protocol, then we are forcing remote users to authenticate as themselves and then su to run privileged commands if need be, thus leaving a decent audit trail. The downside being that those users would still know the root account password. If you would like to restrict the use of the su command, then we can limit it to the members of a specific group called wheel. This group is defined in the /etc/group file by default and it's membership can be modified by root. In order to limit su to the wheel group members we need to modify a configuration file called /etc/pam.d/su
There is a single line in this file that needs to be uncommented to limit the use of su. The line is shown below as it appears it that file, all that is required is the removal of the # symbol at the start of the line.
#auth required /lib/security/$ISA/pam_wheel.so user_uid
|
| |
w |
| |
|
| |
who |
| |
|
| |
vi |
| |
We can't talk about the command line without talking about vi. This is the simple but powerful text editor in Linux and UNIX. People tend to love it or hate it. Either way, it's nearly always there in any *nix implementation and just by memorising a few commands you can be up and running with it. If you can use Windows Notepad, you can use vi!
vi filename
The first thing that throws you is that to enter text into your file, you need to press "i" for Insert mode. You can then enter your text just as any other text editor. When you are done with text entering, just press the Escape (Esc) key to come out of insert mode. If you are happy with your file, then we need to Write & Quit (wq). To enter commands in this command line editor, rather than having menus, we have a command prompt in the application. To reach the vi command prompt, simply enter ":" - the colon character which will automatically place your cursor at the bottom of the session. Here you can enter the "wq" command to write and quit the editor. That's it!
Here is a summary of the vi commands
i Changes to insert mode where you can edit the text
:wq Write the file and quit the editor
:q! Quit the editor without saving changes
SHIFT ZZ Quit the editor and save any changes made - just a fast way of doing ":wq"
Esc key Exits the current mode, e.g. out of insert mode back to view mode.
These commands are just extra if you have the inclination to learn!
/ search - if you entered /failed then the cursor would move to the first instance of "failed in the text $ jumps to the end of the opened file yy copy - it's y for yank! dd delete a line (cut) if you precede this with a number e.g. 8dd, then it would delete 8 lines p paste %s/old/new/g substitute any occurrences of the world "old" with the world "new" There are some great web sites which document the features of vi in superb depth, one of them is the staff site at University of Washington which helped me. Their site is at http://staff.washington.edu/rells/R110/
|
| |
nano |
| |
Another text editor, more friendly but you should use –w to avoid word wrap.
|
| |
date |
| |
If we are checking the time and date of our ESX Service Console, then the date command is very useful. Just entering the "date" command returns what the service console thinks the current date is.
If the date is incorrect and you wish to reset it you would enter the command with the -s switch and specify date in mm/dd/yyyy format.
# date -s "12/29/2007 23:48"
Once you have set the date, you will want to ensure that the hardware clock matches your newly entered date. We can do this with the hwclock command described below.
|
| |
hwclock |
| |
We can use this command to synchronise the server hardware clock with the date we set in the service console. If you enter the command with no parameters then the value of the hardware clock is displayed.
# hwclock
If we want to synchronise the hardware clock with the service console date and time, we use the following:
# hwclock -systohc
|
| |
cal |
| |
Display calendar for current month or set of months. The following command displays 3 months, current month and the month before and after.
# cal -3
March 2006 April 2006 May 2006
Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
1 2 3 4 1 1 2 3 4 5 6
5 6 7 8 9 10 11 2 3 4 5 6 7 8 7 8 9 10 11 12 13
12 13 14 15 16 17 18 9 10 11 12 13 14 15 14 15 16 17 18 19 20
19 20 21 22 23 24 25 16 17 18 19 20 21 22 21 22 23 24 25 26 27
26 27 28 29 30 31 23 24 25 26 27 28 29 28 29 30 31
30
|
| |
passwd |
| |
Used to change the password of the currently logged on user (use the command with no parameters) or for changing the password of a named user account (supply the user name as a parameter).
passwd <user>
Remember that passwords are not stored in the /etc/passwd file, but in the file /etc/shadow
If you are ever needing to reset an unknown root account password, then it is this utility you would run after booting into Linux single user mode.
|
| |
ethtool |
| |
This command can be used to view and configure the ethernet interfaces in your host. We didn't use this tool much until ESX 3.5, when we started to work with Distributed Power Management (DPM); an experimental feature of DRS clusters.
The output of this tool provides a load of information about the network cards, but of particular interest now is the support for Wake-on-LAN (WoL). DPM makes use of this NIC feature and so we need to check that our NICs both support the function AND have the function enabled. The ethtool allows us to view and set this functionality.
# ethtool vmnic1
Settings for vmnic1
If we noted that our NIC supported WoL but it was not currently enabled, then we could use this tool to effect the change.
# ethtool -s vmnic1 wol g
|
| |
VMware HA
|
| |
AAM |
| |
AAM is the Automated Availability Manager that runs in the service console when you create a VMware High Availability (VMware HA) cluster. The VMware HA feature was previously known as DAS (Distributed Availability Services) but we don't mention that anymore.
This software maintains an in-memory database on active nodes in the cluster and uses heartbeats to co-ordinate the active and passive nodes. It is suggested that you configure service console with 2 Ethernet interfaces to remove any single point of failure.
This is a piece of licensed Legato software which itself has been renamed to EMC AutoStart.
This component has a very high dependency upon fully functional host name resolution. So before you enable VMware HA, check the following files
/etc/hosts
/etc/FT_HOSTS
/etc/resolv.conf
/etc/vmware/esx.conf
to ensure accuracy. One thing you can do to check the name resolution functionality before enabling HA is run
hostname -s
to return the short name of the service console. If this fails, then the HA configuration WILL fail.
The log file for VMware HA in ESX 3.0.x can be found in the service console in the directory
/opt/LGTOaam512/
and for ESX 3.5 can be found in
/opt/VMware/
To avoid split brain scenarios, an ESX server can determine if it has become isolated from other servers and we can configure that servers' isolation response. If the AAM component loses contact with the other nodes in the HA cluster, it attempts to contact the configured default gateway for service console using ICMP echo request (PING). If this fails, then the ESX host is isolated. If your default gateway suppresses ICMP echo requests, then we can configure an alternate IP address called the das.isolationaddress. From ESX 3.5, you can configure multiple isolation addresses so that you can configure a host with more that one address to attempt contact with before declaring itself isolated.
|
| |
/opt/LGTOaam512/bin/ftcli |
| |
This utility allows you to view the active nodes in an HA cluster and the managed IP addresses. This utility will help you determine whether the HA agent is in a running state and which IP addresses are visible between those managed hosts.
|
| |
/etc/FT_HOSTS |
| |
This file is created when HA is enabled and is a copy of /etc/hosts. If you have problems with name resolution and configuring HA, you can safely delete this file and reconfigure that cluster node for HA again. FT_HOSTS will be re-created.
|
| |
Networking
|
| |
ifconfig |
| |
|
| |
ping |
| |
|
| |
/sbin/arping |
| |
|
| |
Network File System (NFS)
|
| |
showmount |
| |
This command is used by a NFS client to see what directories are being exported by a NFS server.
showmount –e nfsserver
This command can be specified with the hostname name or IP address of the NFS server holding the exported directories. Remember that by default the service console will block nfsClient traffic. You will need to use esxcfg-firewall to open up that port.
|
| |
portmap |
| |
If you are wanting to mount a NFS export on a remote system from the service console, you do not need all the nfs server daemons running. All you need is the portmap service. You can start it with
service portmap start
And you can ensure this service is launched at boot time using the chkconfig command.
|
| |
VirtualCenter Server & Update Manager
|
| |
vpxd |
| |
This is the process name of the Windows service that is the core service running on the VirtualCenter management server.
If there are problems with the VirtualCenter service starting and then stopping almost immediately or a few seconds later, then check your ODBC database string and then the health of the the database server. We have seen this when the database runs out of disk space; check if the log space is full on the DB server, many clients forget about regular backup of this database. When troubleshooting the VirtualCenter service you can try VirtualCenter in stand-alone mode. This is done by invoking the following command at the Windows command line
vpxd -s
You will get interactive logging of the start-up activity helping you to pinpoint where the problem is.
If all else fails, you can always re-initialize the VirtualCenter database, however we would not recommend this. By re-initializing the VirtualCenter database you are wiping out all VC data!! If you do want this, then use the -b command switch to vpxd.
|
| |
vpxd.cfg |
| |
This is the VirtualCenter management server configuration file. (Ok, so we are extending this command line guide to cover the VirtualCenter server now as well as the ESX host!)
There are a number of configuration changes to VirtualCenter we can make in this file, but as of VC 2.5, one such change you may wish to make is the disabling of "Guided Consolidation". This feature, shown just as a consolidation button in the VI client, is intended to help small customers select which physical Windows hosts are suitable for consolidation and then guide them to perform the physical to virtual migration.
If you have already been through the consolidation process, then you don't need this feature. It makes sense to disable the feature if you are not using it as this should improve VC performance. To disable Guided Consolidation, simply edit the vpxd.cfg file on the VC management server and make the following change:
config.vcp2v.dontStartConsolidation = true
|
| |
vum-proxyAuthCfg.exe |
| |
The Update Manager component of Virtual Infrastructure is new to version 2.5. This component allows the patch management of Windows & Linux guests as well as ESX hosts. When installing the Update Manager component, the Windows installer package prompts the operator if they wish to use a proxy server to connect to the Internet, the only options are proxy IP address and port. If your proxy server requires authentication, then this tool must be run to supply the proxy server credentials.
|
| |
vci-integrity.xml |
| |
This is the primary configuration file for the Update Manager.
One of the main reasons you may want to edit this file is if you wish to change the directory that patches are downloaded into, i.e. the patchstore.
|
| |
vmware-umds.exe |
| |
This is the VMware Update Manager Download Service. If you don't want the server where Update Manager is installed on to actually connect to the Internet and do the patch downloading, then UMDS is for you. Maybe you don't want the load of update downloads on the UM server or maybe the UM server is on a subnet that can't reach the Internet. Anyway, the UMDS installs on a Windows server (that is not the same server as UM) and doesn't create a start menu program group.
To start a download, simply enter the command
vmware-umds --download
Once the updates are downloaded, we can export them. This means we copy the patches from the download directory to another path. The intended purpose of exporting is to copy all or a subset of the downloaded patches to a location that will then be made available to the Update Manager server.
vmware-umds -E e:\exportedupdates
At this time UMDS does not support NFS/CIFS shares for the export operation. This is related to a permissions issue
|
| |
vmware-updateDownloadCli.exe |
| |
This tool is run on the Update Manager server to import the patches made available from the UMDS export. So if you had a DVD burned which had all the updates that was inserted to the UM server and available as drive Z:
|
| |
Remote Command Line Interface (RCLI)
|
| |
To perform remote command line operations on an ESX host on versions of ESX up to 3.0.2, required either direct console access or using secure shell, e.g. Putty. As of ESX 3.5.0, there is a new alternative which is called RCLI.
There are 3 RCLI options
- RCLI Appliance (a ready-made downloadable VM appliance built on Debian Linux)
- RCLI for Windows
- RCLI for Linux
These three options bring the ability to run a subset of the commands available at the service console remotely without having to grant ssh access to the actual console. This RCLI interface provides the ability for users of VMware ESX Server 3i (hardware embedded hypervisor) to run the esxcfg commands.
|
| |
svmotion |
| |
This command is run from an RCLI interface to perform a live migrate of a VMs storage from one datastore to another, known as storage VMotion. In a storage VMotion, only the virtual disks of the VM move, unlike a regular VMotion, the VM remains running on the same host.
To perform an interactive storage VMotion, we use the svmotion command with the --interactive switch. In the following example, we see the full text of prompts and responses. To make it easier to read, we've highlighted the user input with yellow.
svmotion --interactive
Entering interactive mode. All other options and environment variables will be ignored.
Enter the VirtualCenter service url you wish to connect to (e.g. https://myvc.mycorp.com/sdk, or just myvc.mycorp.com): 192.168.1.3
Enter your username: Administrator
Enter your password: *****
Attempting to connect to https://192.168.1.3/sdk
Connected to server.
Enter the name of the datacenter: DataCenter-1
Enter the datastore path of the virtual machine (e.g. [datastore1] myvm/myvmx.vmx): [esx1host:storage1] vm1/vm1.vmx
Enter the name of the destination datastore: esx1host:SharedVMFS
You can also move disks independently of the virtual machine. If you want the disks to stay with the virtual machine, then skip this step..
Would you like to individually place the disks (yes/no)? no
Performing Storage VMotion.
0% ¦################---------------------------------------------------------------------------------------------¦100%
Storage VMotion completed successfully.
Disconnecting.
So, from the above example, you can see that a storage VMotion run interactively is quite straightforward. When mistakes can creep in is when you are prompted for source and destination datastore names. The source datastore name requires square brackets [] around the name, followed by a space character and path to vmx file, whereas the destination prompt only requires the datastore name, this time without square brackets!
If you want to script this command, then the inputs can be supplied as parameters to the svmotion command.
svmotion --server <virtualcenterserver> --username <user_name> --password <user_password> --vm '[old_datastore] vm/vmx.vmx:new_datastore'
If you don't want to include user data in the command, then you can combine this method with an environment variables file called ./visdkrc
|
VMware ESX Server 3 Commands Guide
leesun
博客统计信息
热门文章
最新评论
友情链接