System tab: VMWare Settings

This Article contains the following:

Part 1: Basic setup

Estimated shutdown time

Dry Run installation test routine

What a "Dry Run" does

Part 2: Advanced settings

Part 3: Selecting “Hosts are also vSAN nodes” at Safely decommission vSAN nodes

The VMware settings control the overall shutdown behavior of servers and hosts within VMware. Depending on the configuration level and configuration type, different types of configurations are necessary in order to manage a VMware based infrastructure. In addition to the mandatory basic data like IP addresses and user credentials, you may need, among other things, more specific knowledge about the shutdown behavior of your IT landscape.

Please note, some data are not static. Values may change and should be adjusted during regular system checks.

RCCMD evaluates and displays estimated shutdown times according to entered data.

Part 1: Basic setup

The basic settings assume that you are running hosts without vCenter. You can shut down as many hosts as you want with one RCCMD appliance:

Virtual Machine Management

This menu defines whether you want the hosts and virtual machines to be managed by RCCMD or by a vCenter. If you operate the hosts in lock-down mode, e.g., the control commands are exclusively approved by a vCenter. Even if you enter the credentials correctly, the host will deny command execution.

In the default setting, "from RCCMD" is active.

Virtual machine behavior

Use this setting to define whether you want to use vMotion or just shut down your machines. A virtual machine shutdown will be controlled directly by the host:

The virtual machines are shut down normally, and then the hosts are turned off.

If you enable vMotion, local shutdown of virtual machines is the secondary protocol. First, the vCenter will try to move the virtual machines to another host.

The default setting is "Shut down virtual machines".

If maintenance mode is selected, additional information is required like credentials of the vCenter as well as a time window that should be available for the vCenter to move virtual machines to another host.

Safely decommission vSAN nodes or no vSAN in use

This setting defines the shutdown behavior in case a vSAN is in use. The vCenter provides different basic settings, to be selected at this configuration point. If you want to use an RCCMD-managed vSAN, refer to the basic requirements that must be met.

The default setting is "No vSAN in use".

VMware running RCCMD

RCCMD needs to know the name of the virtual machine that contains the RCCMD appliance. This setting prevents a shutdown of the RCCMD Client.

Tell RCCMD all ESXi Hosts to shut down

With this configuration dialog, declare which ESXi hosts have to be shut down by RCCMD:

The menu bar provides several functions:

• Add: Add another host.
• Remove: Select a host and click Remove to remove it from the current list.
• Edit: Select a host. With Edit you can edit the access data.
• Verify: If you press this button, the current configuration will be saved and the login data will be validated. After verification, RCCMD shows the connection attempt.

Estimated shutdown time

After the configuration job is done, RCCMD shows an estimated shutdown time:

This is the current average shutdown time of your IT infrastructure. Please note, this shutdown time is calculated and can be used to compare it with the emergency power time granted by the UPS.

Due to the fact this is a calculated value: 

Please test your shutdown setting before activating!

Dry Run installation test routine

With the Dry Run, RCCMD offers a unique function within the VMware settings:

The Dry Run is a simulation mode, in which your RCCMD installations simulate the behavior, but do not physically execute.

This feature is useful when installing an RCCMD installation on a production server:

Accidental shutdown is prevented in this way. With Save and Execute, this feature is enabled, protecting your future configuration from accidental shutdown.

Note

Some configuration menus are locked during testing and cannot be adjusted "in between".

What a "Dry Run" does

Normally, a CS141 is the RCCMD server that sends a valid RCCMD command to an RCCMD client - the RCCMD software. The command and what to trigger with it depends on the final operating scenario. Due to the fact you can use the event handling from the CS141 for sending individual commands in order to start very delicate and complex scripts, it is possible to automate a server via scripts in many parts. You do not necessarily just have to shut down a server with RCCMD.

With VMware, the RCCMD appliance differs from normal client installation:

It is designed to ensure a structured shutdown sequence for all hosts within a VMware environment.

To fulfill this task, RCCMD needs access data coming with system rights to allow a shutdown. The problem is that RCCMD cannot differ between a real emergency and a user who presses the test job button at CS141. During testing, this could be a problem. As soon as RCCMD accepts a valid signal, it will start the shutdown procedure. It is comparable with the "OK" console command of any normally shown "Are you sure" dialog inside an operating system.

Of course, you cannot simply shut down "all servers" during operation because you want to test your configuration. Shutting down a real-time system with 100% availability is just for real emergency issues.

The Dry Run is a built-in self-running simulation mode

1. All configured hosts will be contacted.

2. Credentials for the hosts will be tested.

3. A protocol log will be written to log configuration issues as well as successful login tests.

4. The standard RCCMD shutdown signal is suppressed as long as simulation mode is active.

As long as Dry Run is active, no emergency shutdown is possible via any valid RCCMD server device.

Note:

If you change or adjust the standard scripts coming with a default installation or add new scripts, they will be executed consequently. The Dry Run only suppresses its own standard scripted shutdown sequence. It does not check the changes you added manually.

This behavior contains advantages as well as disadvantages.

1. Due to the fact your "sharp" scripts are executed mercilessly, the Dry Run test should take place beforehand.

2. By adding your own scripts that trigger harmless actions, you can check if your "sharp" scripts would work and all administrative shares on the target system are met.

Part 2: Advanced settings

If Maintenance Mode (vMotion) is selected

RCCMD will present two additional menu entries:

Maintenance Mode Timeout in Seconds

This value defines the time window that RCCMD grants the vCenter to move virtual machines to hosts that are not going down into maintenance mode.

Virtual machines that have not been migrated within this time window will be left for shutdown by the ESXi host.

vCenter credentials

In order to use vMotion, RCCMD needs valid vCenter credentials. Please note, an RCCMD client can shut down many hosts, but technically only maintain one vCenter. If you need to configure several different configuration types, it may be necessary to use 2 RCCMD appliances that work together.

Check values

Test the vCenter credentials. RCCMD will try to log into the vCenter and give feedback including a reason why the login attempt failed.

Part 3: Selecting “Hosts are also vSAN nodes” at Safely decommission vSAN nodes

This setting enables several sub menus and a vSAN timeout warning.

Keep an eye on this warning message!

A vSAN is a little bit tricky when running a shutdown routine and the vSAN has been terminated incorrectly. It is even possible that a wrongly configured shutdown routine leads into data corruption or even total data loss.

vSAN shutdown options

No data evacuation

This is the fastest way to ensure system shutdown. It shuts down the virtual machines, and then the vCenter synchronizes all the hosts that are inside the vSAN. There will be no data migration or virtual machines to be moved to other hosts.

Evacuate all data to other hosts

In principle, it is the same function that triggers vMotion. A vSAN can also be spanned across different sites, so you can also offload virtual machines to external hosts that are not in the vSAN cluster you are about to shut down. If you use vMotion, it will be executed first. Due to this fact it is possible that your vSAN host has no virtual machines that need a migration. But you may use it as "second try" to move machines away from your vSAN.

Ensure data accessibility

If larger vSAN systems provide enough capacities for redundancies, no data will be moved. Data migration will only be done for data without redundancy.

Note

With vSAN extensions, RCCMD introduces a solution to allow you to perform an emergency shutdown of the entire vSAN system as fast as possible. Virtual machines that have been previously migrated to another location via vMotion are not affected.

Due to the fact you want to stop and shut down the vSAN because there is an emergency, selecting "No data evacuation" is the best choice.

vSAN Resync timeout in Seconds

This setting is the basic time window RCCMD grants the vCenter to synchronize the databases between the hosts before starting the next point in the shutdown sequence. This time window is a little bit tricky, because the resync time is a very relative value. In principle you can say it lasts as long as it takes. The vCenter does not tell you an estimated resync time, you need to test it during a manual shutdown. If your vCenter announces the job is done, you have the minimum time window for your emergency shutdown. Please calculate some extra time for this time window because the measured time during a manual shutdown is just a snapshot and not a general value.

Seconds to wait before setting Maintenance Mode for vSAN

Once the resync is completed, the vCenter is the last surviving virtual machine that needs to be shut down. With this setting, you define how long the vCenter has time to shut itself down before RCCMD starts the next step of the shutdown sequence.

Determine which VM is running the vCenter

Inside a vSAN, the vCenter is more:

The vCenter manages the complete data transfer within a vSAN and handles the complete post synchronization phase during a vSAN shutdown. This means:

If the vCenter runs inside a vSAN or runs on a host that will be shut down too fast, the complete vSAN can hang up. If the vCenter is located as a virtual machine within the vSAN, RCCMD needs to know the name of the virtual machine in order to exclude it from virtual machine shutdown.

Note:

The vCenter that handles a vSAN is not always inside this cluster. It may be installed somewhere and handled separately. If the virtual machine with the vCenter is not inside the list of the hosts to be shut down, you do not need to enter it at this point. But you need to keep an eye on it when using different RCCMD appliances. Without its vCenter, a vSAN cannot shut down as expected.