advertisement
everRun User's Guide
Notice
The information contained in this document is subject to change without notice.
UNLESS EXPRESSLY SET FORTH IN A WRITTEN AGREEMENT SIGNED BY AN AUTHORIZED
REPRESENTATIVE OF STRATUS TECHNOLOGIES, STRATUS MAKES NO WARRANTY OR
REPRESENTATION OF ANY KIND WITH RESPECT TO THE INFORMATION CONTAINED
HEREIN, INCLUDING WARRANTY OF MERCHANTABILITY AND FITNESS FOR A PURPOSE.
Stratus Technologies assumes no responsibility or obligation of any kind for any errors contained herein or in connection with the furnishing, performance, or use of this document. Software described in Stratus documents (a) is the property of Stratus Technologies Bermuda, Ltd. or the third party, (b) is furnished only under license, and (c) may be copied or used only as expressly permitted under the terms of the license.
Stratus documentation describes all supported features of the user interfaces and the application programming interfaces (API) developed by Stratus. Any undocumented features of these interfaces are intended solely for use by Stratus personnel and are subject to change without warning.
This document is protected by copyright. All rights are reserved. Stratus Technologies grants you limited permission to download and print a reasonable number of copies of this document (or any portions thereof), without change, for your internal use only, provided you retain all copyright notices and other restrictive legends and/or notices appearing in the copied document.
Copyrights
Stratus, the Stratus logo, everRun, and SplitSite are registered trademarks of Stratus Technologies Bermuda, Ltd. The Stratus Technologies logo, the Stratus 24 x 7 logo, and Automated Uptime are trademarks of Stratus Technologies Bermuda, Ltd.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Intel and the Intel Inside logo are registered trademarks and Xeon is a trademark of Intel Corporation or its subsidiaries in the United States and/or other countries/regions.
Microsoft, Windows, Windows Server, and Hyper-V are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries/regions.
VMware is a registered trademarks of VMware, Inc. in the United States and/or other jurisdictions.
The registered trademark Linux is used pursuant to a sublicense from the Linux Mark Institute, the exclusive licensee of Linus Torvalds, owner of the mark on a worldwide basis.
Google and the Google logo are registered trademarks of Google Inc., used with permission. The Chrome browser is a trademarks of Google Inc., used with permission.
Mozilla and Firefox are registered trademarks of the Mozilla Foundation.
Red Hat is a registered trademarks of Red Hat, Inc. in the United States and other countries.
Dell is a trademark of Dell Inc.
Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company.
All other trademarks and registered trademarks are the property of their respective holders.
Manual Name: everRun User's Guide
Product Release Number: everRun Release 7.4.0.0
Publication Date: Wednesday, April 19, 2017
Stratus Technologies, Inc.
5 Mill and Main Place, Suite 500
Maynard, Massachusetts 01754-2660
© 2016 Stratus Technologies Bermuda, Ltd. All rights reserved.
Table of Contents
Chapter 1: Introduction to everRun Systems everRun Quick Start Guide
Configuring Your RAID Controller
Installing the everRun Software
Logging On to the everRun Availability Console
Creating a Protected Virtual Machine everRun System Overview
Physical Machines and Virtual Machines
Logical Disks and Physical Disks
v
everRun User's Guide
Business and Management Networks
Accessing the Host Operating System
General Network Requirements and Configurations
Business and Management Network Requirements
A-Link and Private Network Requirements
SplitSite Network Requirements
Management Network Requirements
everRun Availability Console Requirements
Power Requirements and Considerations
vi
Configuring Settings in the Firmware Setup Utility
Installing Software on the First PM
To configure your keyboard layout during installation:
To configure your keyboard layout after installation:
Recording the Management IP Address
Installing Software on the Second PM
Obtaining System IP Information
Logging on to the everRun Availability Console for the First Time
Connecting Additional Networks
Chapter 3: Using the everRun Availability Console
The everRun Availability Console
Logging on to the everRun Availability Console
Resolving Outstanding Alerts on the Dashboard
Managing the everRun Product License
vii
everRun User's Guide
Configuring the Migration Policy
Configuring Secure Connections
Configuring the Host Inactivity Logout
Disabling and Enabling Snapshots
Uploading a Diagnostic File to Customer Support
Configuring Remote Support Settings
Configuring Internet Proxy Settings
Physical Machine States and Activities
Virtual Machine States and Activities
viii
Chapter 4: Upgrading everRun Software
Upgrading a System Using an Upgrade Kit
Upgrading a System To Release 7.4.x with a DVD
Chapter 5: Migrating From Avance or everRun MX Systems
Planning to Migrate from an everRun MX System
Guest Operating System Support
Converting an everRun MX System to an everRun 7.x System
Planning to Migrate from an Avance Unit
Guest Operating System Support
Converting an Avance Unit to an everRun 7.x System
Chapter 6: Managing Logical Disks
Responding to a Failed Logical Disk
ix
everRun User's Guide
Assigning a Logical Disk to a Storage Group
Chapter 7: Managing Physical Machines
Shutting Down a Physical Machine
Troubleshooting Physical Machines
Recovering a Failed Physical Machine
Recovering a Failed Physical Machine with External Storage
Resetting MTBF for a Failed Physical Machine
Chapter 8: Managing Virtual Machines
Planning Virtual Machine Resources
Planning Virtual Machine vCPUs
Planning Virtual Machine Memory
Planning Virtual Machine Storage
Planning Virtual Machine Networks
Creating and Migrating Virtual Machines
Creating a New Virtual Machine
Creating a New Windows Server 2003 Virtual Machine
Migrating a Physical Machine or Virtual Machine to an everRun 7.x System
Migrating a Windows Server 2003 VM to an everRun 7.x System
Importing an OVF File from an everRun MX System
Importing an OVF File from an Avance System
Importing an OVF File from an everRun 7.x System
Replacing a Virtual Machine from an OVF File
Exporting a Virtual Machine from an everRun System
Configuring Windows-based Virtual Machines
Updating the VirtIO Drivers (Windows-based VMs)
x
Creating and Initializing a Disk (Windows-based VMs)
Installing Applications (Windows-based VMs)
Installing the QEMU Guest Agent for Application-Consistent Snapshots (Windows-based
Configuring Linux-based Virtual Machines
Creating and Initializing a Disk (Linux-based VMs)
Installing Applications (Linux-based VMs)
Installing the QEMU Guest Agent for Application-Consistent Snapshots (Linux-based VMs) 225
Managing the Operation of a Virtual Machine 227
Shutting Down a Virtual Machine
Powering Off a Virtual Machine
Opening a Virtual Machine Console Session
Managing Virtual Machine Resources
Reprovisioning Virtual Machine Resources
Creating a Volume in a Virtual Machine
Attaching a Volume to a Virtual Machine
Detaching a Volume from a Virtual Machine
Removing a Volume from a Virtual Machine
Renaming a Volume on the everRun System
Expanding a Volume Container on the everRun System
Expanding a Volume on the everRun System
Recovering Virtual Machine Resources
xi
everRun User's Guide
Creating a Virtual Machine from a Snapshot
Advanced Topics (Virtual Machines)
Assigning a Specific MAC Address to a Virtual Machine
Selecting a Preferred PM for a Virtual Machine
Changing the Protection Level for a Virtual Machine (HA or FT)
Configuring the Boot Sequence for Virtual Machines
Resetting MTBF for a Failed Virtual Machine
Locating a Dump File in a Virtual Machine
Chapter 9: Maintaining Physical Machines
Physical Machine Hardware Maintenance Restrictions
Adding or Replacing Hot-Swappable Components
Adding or Replacing Components That Are Not Hot-Swappable
Replacing Physical Machines, Motherboards, NICs, or RAID Controllers
Replacing a Failed Physical Machine Connected to External Storage
Upgrading Both Physical Machines In a Running System
Chapter 10: Managing External Storage
Adding or Removing External Storage LUNs
Configuring External Storage in a Newly Installed Release 7.4.x System
Configuring Linux Multipathing
Upgrading a System with External Storage from Release 7.3.4 to 7.4.x
Removing External Storage Disks
Chapter 11: everRun Release 7.4.0.0 Release Notes
Accessing Stratus Knowledge Base Articles
New in everRun Release 7.4.0.0
Features No Longer Supported in everRun Release 7.4
Upgrading From Previous Releases of everRun
Using 4K Disks for Better Performance
xii
Do Not Update CentOS Host OS Directly From CentOS
Optimizing Performance of A-Link Networks
Status of RAID Physical Disks Is Not Monitored
Other Important everRun Considerations
Replacing an Existing Node Without First Removing It Fails
Avoid Removing a VM While Only One Node is Running
Invalid VM Names Prevent Some VM Operations from Executing
Windows 2008 (pre-R2) Guests May Crash
Information About PCI Devices May Not Be Displayed
State of External Storage Not Reflected in Node's State
Resizing Logical Disks on External Storage Is Not Supported
VMs May Not Boot If One Node is Removed From System
Removing Snapshots Temporarily Prevents Some VM Operations
Creation of Snapshots Results in Volume Conversion from RAW to QCOW2 Format
Moving an everRun System to a Different Subnet
Enabling Log Files for the Windows QEMU Guest Agent May Cause VM Timeouts When
Unsupported Network Adapter Card and Chip
Chapter 12: everRun Command Line Interface Reference
Displaying Help for a Specific Command
xiii
everRun User's Guide
xiv
xv
everRun User's Guide
xvi
Chapter 13: System Reference Information
Compatible Guest Operating Systems
Physical Machine System Requirements
Important Physical Machine and Virtual Machine Considerations
Virtual Machine Recommendations and Limits
Recommended Number of CPU Cores
xvii
everRun User's Guide
Combined Virtual Machine Maximums
Accessing Knowledge Base Articles
xviii
Part 1: everRun User's Guide
The everRun User's Guide describes everRun systems, how to install them, and how to use them.
For a summary of the steps required to install everRun software, see: l
"everRun Quick Start Guide" on page 1
For system descriptions including modes of operation and storage and network architecture, see: l
"Introduction to everRun Systems" on page 1
For planning and installation information, see: l
The following topics describe how to administer everRun systems.
l
"Using the everRun Availability Console" on page 59
l
"Upgrading everRun Software" on page 115
l
"Migrating From Avance or everRun MX Systems" on page 119
l
"Managing Logical Disks" on page 139
l
"Managing Physical Machines" on page 145
l
"Managing Virtual Machines" on page 155
l
"Maintaining Physical Machines" on page 271
l
"Managing External Storage " on page 281
1
Chapter 1: Introduction to everRun Systems
For a summary of the steps required to install everRun software, see the
"everRun Quick Start Guide" on page 1
See the following topics for an introduction to everRun systems: l
"everRun System Overview" on page 7
l
"Modes of Operation" on page 11
l
"everRun Storage Architecture" on page 15
l
"Network Architecture" on page 18
l
"System Usage Restrictions" on page 21
everRun Quick Start Guide
Use the everRun Quick Start Guide to get your everRun system up and running as quickly as possible.
An everRun system requires two x86-64 host servers (referred to as physical machines , or PMs ) that can support multiple virtual machines (VMs), and a remote management computer that can run the everRun
Availability Console. This guide explains how to set up your PMs and guides you through the basic installation and start-up tasks, including: l
"Assembling Required Items" on page 2
l
"Configuring Your RAID Controller" on page 2
l
"Cabling Your System" on page 3
l
"Obtaining the ISO Image" on page 4
Page 1 of 483
everRun User's Guide l
"Installing the everRun Software" on page 4
l
"Logging On to the everRun Availability Console " on page 6
l
"Creating a Protected Virtual Machine" on page 7
Note: If you need assistance during the installation process: l
Call 866-763-1813 (U.S. Toll-Free) or 602-852-3094 (International) l
Visit the Downloads page at http://www.stratus.com/go/support/everrun
Assembling Required Items
You need the following items/information: l
Two PMs that meet the requirements listed in
"System Requirements Overview" on page 24
l
Ethernet cables for each network you are connecting l
A remote management computer. This is a general-purpose PC with a supported web browser to access the everRun Availability Console. It must be located on the same business/management
l
A monitor, keyboard, and cables, used only during the installation l
The everRun license key you received from Stratus l
The everRun ISO image available for download at the Downloads page at http://www.stratus.com/go/support/everrun l
From your network administrator, the IPv4 address, netmask, default gateway address, and DNS address values for everRun and each PM
Configuring Your RAID Controller
Stratus strongly recommends that your everRun system uses a storage RAID controller. The RAID controllers in an everRun system create logical disks from the system's physical disks, and the logical disks are then collected into a storage group. Configuration recommendations follow: l
If the system has a single logical disk, Stratus strongly recommends that you configure the RAID controller so that logical disks presented to the host are backed by redundant physical drives.
Page 2 of 483
Cabling Your System l
Stratus strongly recommends that RAID controllers have a battery-backed write cache.
l
You must configure the RAID controller to boot off the first logical disk.
Cabling Your System
Attach the following cables: l
Private network: Connect an Ethernet cable from the first embedded port on the first PM to the first embedded port on the second PM. If you plan to use the private network as an A-Link, see
"A-Link and Private Networks" on page 19
.
l
Business/Management network: The first business network is the management network
. Connect
Ethernet cables from the second embedded port on each PM, through a network switch to a network, and connect the remote management computer to this network.
l
A-Link network(s): For each A-Link network, connect an Ethernet cable from any unused port on the first PM to any unused port on the second PM, either directly or through a network switch.
l
Business network(s): For each business network, connect Ethernet cables from a port on the first
PM to a port on the second PM, through a network switch to a network.
l
Make sure the remote management computer is connected, or routes to, the management network.
l
The following illustration shows these connections:
Page 3 of 483
everRun User's Guide
Note: When installing software on the first PM, connect the keyboard and monitor to the first
PM. When installing software on the second PM, connect the keyboard and monitor to the second PM. When software installation is complete, disconnect the keyboard and monitor from the system.
Obtaining the ISO Image
Obtain the ISO image and create a bootable medium:
1. From any computer connected to the Internet, go to the Downloads page at http://www.stratus.com/go/support/everrun .
2. To download the everRun software ISO image (everRun_install-7.
x .
x .
x xxx .iso), under Product
Download, click everRun 7.
x.x.x
ISO Image. Save the ISO image.
3. Create a bootable medium using the ISO image: n
To burn the ISO image to a DVD, use a commonly available application. For example, if you have the Roxio application installed, right click the ISO file and select the option to burn a
DVD.
n
To create a bootable USB medium, see
"Creating Bootable USB Media" on page 37 .
Occasionally an ISO file can be corrupted during the download process. You can choose to verify the installation medium during the software installation.
For additional information, see
"Obtaining everRun Software" on page 36 .
Installing the everRun Software
Allow 60 to 90 minutes to complete the everRun software installation process.
1. Install the everRun software on the first PM: a. Power on the first PM, and then insert the bootable medium or mount the ISO image.
b. As the PM powers on, configure the following settings in the firmware (BIOS or UEFI) setup utility:
Page 4 of 483
Installing the everRun Software o
Set the first boot device to the Optical Drive.
o
Enable Virtualization Technology.
o
Enable Execute-Disable Bit Capability.
Note: If you need to configure your keyboard for a different layout, see "Mapping
c. From the installation software's Welcome screen, use the arrow keys to select an installation option. Stratus recommends that, for an initial installation, you select Verify medium and Install everRun, which verifies the installation medium before installing the software
(verification adds about five minutes to the installation process). If you do not want to verify the medium, select Install everRun, Create a new system. After you select an option, press Enter.
d. If any disk contains previously installed data, the following message appears and the system reboots (if no disk contains previously installed data, installation continues with the next step):
Rebooting because disks
XXX were erased.
When the reboot is complete, the boot menu reappears and you must, again, select an installation option (Step 1,c, above).
e. From the Select interface for private Physical Machine connection screen, select an embedded port (for example, em1, which is the default), and press F12.
f. From the Select interface for managing the system (ibiz0) screen, select an embedded port (for example, em2, which is the default), and press F12.
g. From the Select the method to configure ibiz0 screen, select Manual configuration
(Static Address) and press F12.
Note: To perform a dynamic IP configuration, select Automatic configuration via DHCP instead and skip to Step 1h, where you will need to write down the
IPv4 address as described in "Recording the Management IP Address" on page
Page 5 of 483
everRun User's Guide h. From the Configure em2 screen, enter the IPv4 address, netmask, default gateway address, and DNS address values that you received from your network administrator, and then press F12.
i. No action from you is necessary until after the PM reboots. At that time, remove the bootable medium or unmount the ISO image, connect the keyboard/console to the second PM, and go to Step 2.
2. Install the everRun software on the second PM: a. Power on the second PM, and then insert the bootable medium or mount the ISO image.
b. As the PM powers on, configure the settings in the firmware (BIOS or UEFI) setup utility described in Step 1b.
c. From the installation software's Welcome screen, use the arrow keys to select Replace
PM, Join system: Initialize data, and press Enter.
d. If any disk contains previously installed data, the following message appears and the system reboots (if no disk contains previously installed data, installation continues with the next step):
Rebooting because disks
XXX were erased.
When the reboot is complete, the boot menu reappears and you must continue with Step
2,c, above.
e. Perform Steps 1e through 1h.
f. No action from you is necessary until after the second PM reboots. At that time, remove the bootable medium or unmount the ISO image, disconnect the keyboard/console, and log on to the everRun Availability Console.
Logging On to the everRun Availability Console
1. From the remote management computer, type the IP address of node0 (primary) into a browser address bar.
2. The logon page of the everRun Availability Console appears. Enter admin for the Username and admin for Password, and then click LOGIN.
3. The Stratus everRun EULA appears. Read the EULA and click Accept to accept it.
Page 6 of 483
Creating a Protected Virtual Machine
4. The INITIAL CONFIGURATION page appears. Under NOTIFICATIONS, the box for Enable Support Notifications is checked, by default. If you do not want the everRun system to send health and status notifications to your authorized Stratus service representative, uncheck the box. You can change this setting later (see
"Configuring Remote Support Settings" on page 93 ).
5. Under SYSTEM IP, for IP Address, enter the address you obtained from your network administrator. After you have entered the network information, click Continue.
6. The Portal Restart Required window appears. After waiting a minute (as indicated in the window), click OK to refresh the console and to continue.
7. The LICENSE INFORMATION window appears. Under Upload License Key, click Browse and navigate to the license .KEY file that you received from Stratus. Select the license file and click
Upload.
For security, change the default user login name and password for the admin account on the Users
& Groups page.
The everRun Availability Console appears. Bookmark or make note of the system IP address for use when logging in to the console in the future.
Creating a Protected Virtual Machine
First, create a virtual CD (VCD) to make software installation media available to the virtual machine (VM).
1. Open the Virtual CDs page in the everRun Availability Console
2. Click Create VCD to open the Virtual CD Creation Wizard.
3. Follow creation wizard prompts. For details, see
"Creating a Virtual CD" on page 246
in the online help.
Next, create a new virtual machine (VM) and install a guest operating system on your everRun system.
1. On the Virtual Machines page, click Create to open the VM Creation Wizard.
2. Follow the creation wizard prompts. For details, see
"Creating a New Virtual Machine" on page 163
in the online help.
After you install the operating system, perform any other guest OS configuration tasks (for example, initializing disks and installing applications). For details, see
"Post-Installation Tasks" on page 53
in the online help.
everRun System Overview
Page 7 of 483
everRun User's Guide
An everRun system provides uninterrupted operation with no lost data in the event of a hardware failure.
See the following topics for descriptions of system features and capabilities.
l
"everRun System Description" on page 8
l
"Physical Machines and Virtual Machines" on page 9
l
"Administrative Operations" on page 9
l
l
l
"Lights-Out Management" on page 10
l
"Third-party Management Tools" on page 10
everRun System Description everRun software allows two computers to work as a single, highly-available or fault-tolerant system.
Each computer is called a physical machine.
Both physical machines (PMs): l
Run the same host operating system (CentOS) l
Contain the same data, memory and storage (synchronized via direct Ethernet links between the two PMs) l
Support virtual machines running supported guest operating systems
The PMs must: l
Have compatible CPUs l
The data and memory contents of the two PMs are synchronized via direct Ethernet links. Other Ethernet connections to a network support virtual machine and management operations.
Related Topics
"System Requirements Overview" on page 24
"Compatible Guest Operating Systems" on page 472
"Network Architecture Overview" on page 19
Page 8 of 483
Physical Machines and Virtual Machines
Physical Machines and Virtual Machines
An everRun system transparently protects applications by creating redundant virtual machines (VMs) that run on two physical machines (PMs).
The everRun management software can create an everRun-protected VM from scratch. It is also possible to import existing VMs from other environments and convert them into an everRun-protected VMs. By creating an identical instance of the selected VM on a second host PM, everRun software provides FT-class protection of the VM. The system administrator manages this single entity from a separate, browser-based management console called the everRun Availability Console.
Neither the application nor the user is exposed to the redundant computing resources on the two host
PMs. The application sees only one hostname, one MAC address for each network interface presented to the VM, and one IP address for each VM network interface presented to the VM. A system administrator loads and configures the applications on the protected VM — just as if the system administrator were loading them onto a physical server. If a fault or failure occurs in a disk or network device, everRun software automatically redirects I/O to the paired host PM for continuous operation. Though redundancy is lost until the failure is repaired, the client experiences no interruption in connectivity and no loss of data. The application continues to execute as if nothing had happened. The redundancy, fault detection, isolation, and management are completely transparent to the Windows or Linux environment and the application running within it. Repair of the PM is equally transparent and automatic. When a failed component on the PM is repaired, everRun software automatically incorporates the repaired components into the protected environment and restores redundancy without interrupting the application.
Related Topics
"Using the everRun Availability Console" on page 59
"The Physical Machines Page" on page 97
"The Virtual Machines Page" on page 100
Administrative Operations
You can perform many administrative operations on the everRun system from the everRun Availability
Console, a browser-based interface that provides access to the system as a whole as well as to physical
Alerts
Page 9 of 483
everRun User's Guide everRun system alert messages notify the system administrator whenever an item needs attention. These can include: l
Configuration tasks that should be performed l
Notification of system operational states l
System problems that require attention
Click Dashboard in the left-hand navigation panel to see Alert messages and their descriptions. Click
Alerts in the left-hand navigation panel to see the Alert log.
The following icons indicate the state of an alert message.
Informational
Normal or OK state
Minor, warning, or inconsistent state
Moderate state
Broken, failed, or severe state
Remote Support
To access the everRun system's remote support features, click Preferences in the left-hand navigation panel. From there, you can configure support and proxy specifications by selecting the following: l
Support Configuration—Configure settings to allow remote support access of your system by your authorized Stratus service representative and to enable your system to send health and status
notifications to your authorized Stratus service representative. See "Configuring Remote Support
Settings" on page 93 for details.
l
Lights-Out Management
Some server vendors may provide lights-out capabilities. Lights-out capabilities enable administrators to perform a wide range of system management and operation functions remotely. everRun systems fully support lights-out management on vendor servers.
Third-party Management Tools
Page 10 of 483
Modes of Operation
You can install third-party management tools on everRun systems. Examples of such tools include vendor- or platform-specific management/monitoring utilities, enterprise management/monitoring utilities, and other miscellaneous management/monitoring software. Note the following: l
In general, management tools that run on the host operating system (CentOS) should run on ever-
Run systems. Possible exceptions are tools that manage/monitor the CentOS KVM-based virtualization. To manage/monitor everRun virtualization, use the integrated everRun management tools.
l
Before deploying your everRun system, Stratus recommends that you verify that it operates properly with the management tools installed and operational.
l
Stratus recommends that you set up a non-root account for third-party management tools.
l
You can access your everRun system via the management network using the IP address(es) specified during the installation process (or supplied by the DHCP server if the interface was configured for DHCP during install).
Related Topics
"System Reference Information" on page 472
Modes of Operation
An everRun system provides two modes of operation to set user-defined availability levels for VMs: l
"High Availability Operation" on page 11
l
"Fault Tolerant Operation" on page 12
Both HA operation and FT operation achieve their respective level of redundancy by using a pair of physical machines (PMs).
Stratus recommends configuring quorum service for both HA operation and FT operation. The quorum service prevents a condition called split-brain where both PMs of an HA operation and FT operation pair are running independently of each other; for information, see
High Availability Operation
Page 11 of 483
everRun User's Guide everRun software provides two user-defined availability levels for VMs: High Availability (HA) and Fault
Tolerant (FT).
In HA operation, everRun software automatically detects, isolates, and handles most hardware faults, thereby keeping your applications running. With HA remote-support technology, the everRun software notifies the Stratus support center of various issues, indicating the type of fault and its exact location. This combination of automatic fault detection, isolation, and remote-support technologies ensures speedy access to expert support technicians and rapid problem resolution.
You select a VM’s availability level when you create or import the VM by using the everRun Availability
Console.
When enabled, HA operation offers basic failover and recovery, with some faults requiring an (automatic)
VM reboot for recovery, and return to HA operation: l
Eliminates downtime for many, but not all, CPU, memory, I/O, or other physical machine (PM) failures.
l
Handles failures without IT intervention.
l
Provides continuous, active validation of all components.
l
Assures redundancy and recovery at all times.
HA is suitable for applications that can tolerate occasional interruptions of a few minutes.
Related Topics
"The Virtual Machines Page" on page 100
"Using the everRun Availability Console" on page 59
Fault Tolerant Operation everRun software provides two user-defined availability levels for VMs: High Availability (HA) and Fault
Tolerant (FT). In FT operation, an application continues to run without downtime during a fault. Use FT for applications that need the highest levels of availability.
You select a VM’s availability level when you create or import the VM by using the everRun Availability
Console.
In FT operation, the everRun software transparently protects an application by creating a redundant environment for a VM running across two physical machines (PMs). With an identical instance of the selected
VM on a second host, the everRun software provides FT-class protection of the VM.
Page 12 of 483
SplitSite Configurations
When enabled, FT operation transparently protects a VM from all faults, with no downtime, and
FT operation: l
Eliminates downtime due to any CPU, memory, I/O, or other physical machine (PM) failure.
l
Handles failures without IT intervention.
l
Ensures no data loss.
l
Provides continuous, active validation of all components.
l
Assures complete redundancy and recovery at all times.
Related Topics
"The Virtual Machines Page" on page 100
"Using the everRun Availability Console" on page 59
SplitSite Configurations
Note: An everRun SplitSite license is required to run SplitSite configurations.
A
SplitSite configuration connects two physical machines in two separate sites. It is a disaster-tolerant deployment that maintains hardware redundancy as well as redundancy of physical computer rooms and the buildings containing them. Because of the geographic separation, a SplitSite configuration requires careful planning of component placement and more complex networking topologies. For SplitSite configurations, Stratus strongly recommends that you use the quorum service because a SplitSite configuration exposes the A-Link networks to other potential failure scenarios.
"SplitSite Network Requirements" on page 30
lists the requirements for networks in a SplitSite configuration.
SplitSite and Quorum Service
In a SplitSite configuration, configure two quorum-service computers in compliance with the best practices recommended for quorum deployment (see
"Quorum Servers Considerations" on page 32 ). In any SplitSite
configuration, a preferred quorum-service computer is located in a third facility, and an alternate is located in a fourth site (or carefully placed in the third). The networks are interconnected.
Quorum-service computers should be as isolated as possible. If both must be placed in a common (third) site, make sure that they do not depend on common power sources.
Page 13 of 483
everRun User's Guide
Physical connectivity between an everRun PM and the quorum-service computers must not route through the other PM's site.
Placing a quorum-service computer in the same site as one of the everRun PMs ensures data integrity.
However, some site failures may then require that the VMs be shut down until manually recovered.
The management network physically connects the everRun PMs and the quorum-service computers. For this to work properly, you must configure each everRun PM to use a different gateway to reach the quorum-service computers. If the two PMs use the same gateway to reach the quorum-service computers, data integrity is ensured during failures. However, some site failures may then require that the VMs be shut down until manually recovered.
Related Topics
"Network Architecture Overview" on page 19
Quorum Servers
A quorum service is a Windows operating system-based service deployed on a server distinct from the two servers (physical machines or PMs) running HA- or FT-protected virtual machines (VMs). Quorum servers provide data integrity assurances and automatic restart capabilities for specific failures in an ever-
Run environment. Stratus strongly recommends using quorum servers, especially for SplitSite operation.
You can configure an everRun PM pair with 0, 1, or 2 quorum servers.
Quorum servers ensure the integrity of VMs against multiple network failure scenarios, including split brain, and provide for unattended startup of VMs after specific failures. Quorum server communication occurs via the management network.
Quorum servers are particularly important in SplitSite configurations. Best practice for SplitSite is to place a preferred quorum computer in a third facility and an alternate quorum computer in a fourth facility.
However, you can also place the alternate quorum service computer with the preferred quorum computer and still obtain satisfactory service.
If only two sites are available (thereby preventing the best practices configuration described above) and if one PM goes down and the surviving PM is unable to communicate with the quorum server (for example, because it is on the same site as the down PM), the VMs at the surviving site are automatically shut down to avoid a potential split-brain scenario.
Related Topics
Page 14 of 483
everRun Storage Architecture
"Quorum Servers Considerations" on page 32
"Configuring Quorum Servers" on page 75
"SplitSite Configurations" on page 13
everRun Storage Architecture
The RAID controllers in an everRun system create logical disks from the system's physical disks. The logical disks are collected into storage groups. Logical disks contain everRun system volumes and virtual machine (VM) volumes. Each volume resides in an associated container that includes the current data on that volume as well as any volume snapshots.
The two physical machines (PM) in an everRun system can have different storage capacities, but only the smaller capacity is available to the system. For example, if one PM has 1 TB of storage in a storage group and the other has 2 TB of storage in that same storage group, only 1 TB is available to the everRun system for that storage group.
everRun systems support internal and external disks.
For more information about everRun storage, see the following topics: l
"Logical Disks and Physical Disks" on page 15
l
l
l
"Managing External Storage " on page 281
l
"Sizing Volume Containers" on page 16
Logical Disks and Physical Disks
In an everRun system, the RAID controller creates logical disks from the system's physical disks. ever-
Run software is able to access logical disks that the RAID controller presents to the operating system.
The everRun software detects new logical disks and logical disk failures. You manage logical disks using the everRun Availability Console. For information, see
"Managing Logical Disks" on page 139 .
You need to use the RAID controller to manage and monitor physical disks. Follow the RAID controller manufacturer's requirements to add a new or replacement physical disk to a RAID array.
Related Topics
"Storage Requirements" on page 25
Page 15 of 483
everRun User's Guide
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
Storage Groups
In an everRun system, a storage group is a collection of logical disks. Multiple storage groups are supported. At install time, everRun software creates the Initial Storage Group which contains only the logical disk on which the software is being installed. After installation you can add other disks to any existing storage groups. If a logical disk is empty, you can move it to a different storage group.
With multiple storage groups, you can match application performance requirements to disk capabilities.
You can group slower disks in one storage group and higher performance disks in another storage group.
You can then assign the volumes of VMs that run more demanding applications to a storage group with higher performance disks.
You can view information about storage group from the Storage Groups page of the everRun Availability
Console. For information, see
"The Storage Groups Page" on page 107 .
Related Topics
"Creating a New Storage Group" on page 143
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
Sizing Volume Containers
A volume container is storage space that holds a volume and VM snapshot data associated with that volume.
You can specify the size of the volume container when you create a VM. As snapshot data accumulates, you may need to increase the size of the volume container. You can expand the volume container, but you cannot decrease its size.
The following factors affect the size of a volume container: l
The volume size l
If snapshots are being taken: o
The number of snapshots retained o
How much data changes between snapshots
Page 16 of 483
External Storage
Note: The amount of data that changes between snapshots varies for different applications and can have a large impact on what size the volume container should be. In order to properly size a volume container, you must consider the amount of data that your application changes between snapshots.
If you do not take snapshots, the size of the volume container can be the volume size.
If you take snapshots, the size of the volume container depends largely on the amount of data that is written to the volume between snapshots: l
For a VM created with a separate boot disk, or for applications that write relatively small amounts of data between snapshots, a reasonable volume-container size is 2.6 times larger than the volume size.
l
For applications that write moderate amounts of data between snapshots, a reasonable volume-container size is approximately 3.5 times larger than the volume size.
l
For applications that write larger amounts of data between snapshots, the volume-container size must be more than 3.5 times larger than the volume size.
The following is a general formula to calculate the approximate volume container size :
VolContSize = 2 * VolSize + [(# SnapshotsRetained + 1)*
SnapshotSize]
Related Topics
"Expanding a Volume Container on the everRun System" on page 243
"image-container-resize" on page 355
External Storage everRun systems support Fibre Channel, iSCSI, and Linux device mapper multipath external storage.
everRun software handles external storage in the same way it handles internal storage. It mirrors VM data between external storage logical disks attached to each node as it does for internal storage. This is known as everRun replicated storage.
everRun software has no external storage configuration feature. You must manage the installation and configuration of your particular external storage infrastructure. This may involve installing HBA cards, drivers, and tools required by your external storage system. Follow the instructions provided by your external
Page 17 of 483
everRun User's Guide storage system vendor. In addition you must configure the everRun system to use Linux multipathing in
Caution: everRun boot partitions and other everRun system data must reside on internal storage; they are not supported on external storage.
Note: The system administrator must have root access to the everRun host OS on each physical machine in order to install and/or configure external storage.
For Fibre Channel external storage, this typically involves:
1. Installing and configuring HBAs.
2. Obtaining information (WWNs, port addresses, etc.) to be used in masking and zoning operations supported by your SAN fabric infrastructure.
3. Provisioning LUNs on the external storage system.
4. Managing access to logical disks by configuring SAN zoning and LUN masking.
For iSCSI external storage, this typically involves:
1. Configuring your iSCSI initiators.
2. Provisioning LUNs on the external storage system.
3. Managing access to logical disks by configuring LUN masking.
After installing and configuring your external storage infrastructure you must configure the everRunsystem
Related Topics
"Managing External Storage " on page 281
Network Architecture
See the following topics for information about everRun network architecture.
Page 18 of 483
Network Architecture Overview l
"Network Architecture Overview" on page 19
l
"A-Link and Private Networks" on page 19
l
"Business and Management Networks" on page 20
Network Architecture Overview
Ethernet networks provide pathways for communications between two physical machines (PMs) in an everRun system. The main types of Ethernet networks are: l
Availability Link networks , or A-Link networks , are assigned to virtual machines (VMs) and are used to synchronize data or migrate VMs between two PMs. One A-Link network must be a private network
, which connects the two everRun PMs. See
"A-Link and Private Networks" on page 19
.
l
Business networks allow your applications to connect to your network. One business network must be a management network
, which connects to the everRun Availability Console and is used by the quorum servers. See
"Business and Management Networks" on page 20 .
An everRun system must have a minimum of one private network and one management network per PM.
A-Link and Private Networks
Every everRun system requires one private network, referred to as priv0 , that connects the two everRun physical machines (PMs). The private network is used only for discovery and can have no other entities on it that respond to IPv4 broadcasts.
In addition to the private network, an everRun system has A-Link networks to increase data-replication performance between PMs.
A-Link networks let you sync disks, shunt networks, migrate, perform heartbeat checks, and sync fault-tolerant memory.
By default, the private network also performs the role of an A-Link network under the following conditions: l
If the private network speed is at least 10 Gb l
If the private network speed is less than 10 Gb and the system contains no other 10 Gb ports (other than the management link). In this situation, you can remove the A-link role later as long as the private network is not currently in use as an A-Link and is not the only remaining A-Link.
The private network cannot perform the A-Link role if its speed is less than 10 Gb and the system contains any 10 Gb ports (other than the management link). However, you can assign the A-Link role to the private network at a later time.
Page 19 of 483
everRun User's Guide
The simplest private network consists of a single Ethernet cable (crossover or straight-through) that directly connects an embedded Ethernet port on each server. If a networking device other than a single Ethernet cable is used for the private network, see
"SplitSite Configurations" on page 13
.
Connect A-link networks between PMs either directly (that is, in the same manner that you connect the private network) or through a network switch.
Be sure to set up redundant A-Link networks.
The everRun installation software sets up the private network. It also sets up A-Link networks for any A-
Link network ports that are physically connected at the time of the installation. To set up an A-Link network after the installation is complete (recommended if the network includes many additional A-Link network ports), see
"Connecting Additional Networks" on page 56 .
Related Topics
"Business and Management Networks" on page 20
"A-Link and Private Network Requirements" on page 29
"Network Architecture Overview" on page 19
"Fixing a Network Connection" on page 109
Business and Management Networks
All Ethernet ports--other than those used by A-Link networks (including the private network port)--are considered business-network ports, which your guest operating systems use to connect to your network.
One business network is the management network, which accesses the everRun Availability Console and handles miscellaneous management tasks and the quorum server. Each everRun PM has a single management network, referred to as ibiz0 .
The everRun installation software sets up the management network. It also sets up business networks for any business-network ports that are physically connected at the time of the installation. To set up business networks after the installation is complete, see
"Connecting Additional Networks" on page 56
.
Related Topics
"A-Link and Private Networks" on page 19
"Business and Management Network Requirements" on page 28
"Network Architecture Overview" on page 19
"Fixing a Network Connection" on page 109
Page 20 of 483
System Usage Restrictions
System Usage Restrictions
Observe the restrictions to system usage that are described in the following topics: l
l
"Accessing the Host Operating System" on page 21
QEMU
Stratus everRun systems support the open-sourced hypervisor QEMU ("Quick EMUlator"), which performs hardware virtualization. When used as a virtualizer, QEMU executes the guest code directly on the host CPU, achieving a high level of performance.
everRun users should make no changes to the QEMU virtualization engine or to its configuration.
Accessing the Host Operating System
After the everRun software installation process completes, you can access the host operating system
(CentOS) locally via the PM's physical console, or you can access it remotely via SSH.
If you access the host operating system via SSH, use the management IP addresses specified during the installation process (or supplied by the DHCP server, if the interface was configured for DHCP during installation). See
"Recording the Management IP Address" on page 50
.
Note: Do not use the system IP address to access the host operating system, as it can move from PM to PM.
The default password for the root account is everRun.
Note: For security reasons, change the username and password as soon as possible.
For information about using third-party management tools on CentOS, see "Third-party Management
Page 21 of 483
2
Chapter 2: Getting Started
The following topics describe the everRun planning, installation and post-installation tasks: l
l
"Software Installation" on page 34
l
"Post-Installation Tasks" on page 53
Planning
See the following topics for information about planning your system configuration.
l
"System Requirements Overview" on page 24
l
"Storage Requirements" on page 25
l
"Memory Requirements" on page 27
l
"General Network Requirements and Configurations" on page 27
l
"Business and Management Network Requirements" on page 28
l
"A-Link and Private Network Requirements" on page 29
l
"SplitSite Network Requirements" on page 30
l
"everRun Availability Console Requirements" on page 32
l
"Compatible Internet Browsers" on page 32
l
"Quorum Servers Considerations" on page 32
l
"Power Requirements and Considerations" on page 34
Page 23 of 483
everRun User's Guide
System Requirements Overview
An everRun system requires two x86-64 host servers that can support multiple virtual machines (VMs), and a remote management computer (that is, a general-purpose PC) that can run the everRun Availability
Console.
requirements are described below. See "System Software" on page 25 for software requirements.
System Hardware
Supported Servers
Stratus everRun software will run on any systems listed on the Red Hat
®
Linux Hardware Catalog that
A second computer with identical processors is required for use as a redundant server for Protected Virtual
Machines (or
PVMs
—virtual machines that are protected by Stratus everRun software). The CPUs for every host computer must have hardware support for virtualization enabled in the firmware (BIOS or UEFI) setup utility.
RAM
A minimum of 8 GB of RAM (physical memory) is recommended.
Disk Space Requirements
Internal disks and external Fibre Channel and iSCSI disks are supported. A minimum of two drives per physical machine is required.
477 MB is required on each internal logical disk for the host CentOS operating system. In addition, 22 GB is required on two of the internal logical disks for everRun system data including logs. Only internal disks may be boot disks. The amount of disk space required for a VM’s boot volume varies depending on the operating system being used. Additional storage is needed for applications and data on each VM, as well as VM snapshots.
Network
The minimum network configuration includes two ports: one for A-link and one for a shared management/business link.
Page 24 of 483
IP Addresses
An optimal network configuration includes two 10-GbE network ports for A-Links (one of which also serves as priv0, the private network), a network interface for the management network, and as many business/production ports as your protected VMs may need. If planning to run multiple protected VMs, consider adding pairs of A-Links, up to the supported total of four pairs.
All network components in a SplitSite configuration must have more than 155 Mbps minimum capacity, end-to-end. When fault-tolerant SMP is used, the A-Link networks must be a minimum of 1Gbps.
"Network Architecture Overview" on page 19
"A-Link and Private Networks" on page 19
, and "Business and Management Networks" on page 20 for more information.
IP Addresses
Each everRun host must have a static IPv4 IP address assigned for use by the management software.
Obtain IP addresses for DNS primary and secondary servers, and gateway and subnet mask information
Ports everRun systems use port 443 in the local firewall for HTTPS communications, port 22 for ssh, and 5900-
59 nn for each active VNC associated with each VM. Firewalls must allow traffic through the appropriate ports. Firewalls must permit everRun-protected VMs to contact quorum service computers using UDP port 4557. For additional information on TCP and UDP ports, access the Knowledge Base to search for the article everRun TCP and UDP ports . See
"Accessing Knowledge Base Articles" on page 479
.
System Software
See
"Compatible Guest Operating Systems" on page 472
.
Related Topics
"Physical Machine System Requirements" on page 473
"Important Physical Machine and Virtual Machine Considerations" on page 476
"Virtual Machine Recommendations and Limits" on page 476
"Planning Virtual Machine Resources" on page 156
"Configuring IP Settings" on page 73
Storage Requirements
Page 25 of 483
everRun User's Guide
An everRun system has the following storage requirements and recommendations: l
Each physical machine must contain at least two physical disks.
l
Stratus strongly recommends that your system use a storage RAID controller.
n
If the system has a single logical disk, Stratus strongly recommends that you configure the
RAID controller so that logical disks presented to the host are backed by redundant physical drives.
n
Stratus strongly recommends that RAID controllers have a battery-backed write cache.
n
You must configure the RAID controller to boot off the first logical disk.
Disk drives support standard format, 512e format, and Advanced 4K Native format with sectors, as follows:
Format Physical Sectors Logical Sectors
Standard
512e
Advanced
4K Native
512B
4KiB
4KiB
512B
512B
4KiB
Stratus recommends using disks with the 4K sector size for better performance. When using 4K storage, observe the following restrictions: l
Each storage group must contain logical disks of the same sector size. For example, you cannot add a 4K logical disk to a 512B storage group.
l
The sector size of a storage group is automatically defined by the sector size of the first logical disk that you add to the group. After the sector size of the storage group is set, you cannot change it.
You would need to create a new storage group with logical disks of the new sector size.
l
Because the sector size of a storage group affects the sector size of your VM volumes, it is important to plan your storage groups carefully: n
A storage group with the 512B sector size supports only 512B VM volumes.
n
A storage group with the 4K sector size supports 4K or 512B VM volumes.
Page 26 of 483
Memory Requirements
Note that the boot volume for each VM must be 512B, regardless of the storage group's sector size.
Only data volumes can use the 4K sector size. Ensure that your guest operating systems support
4K volumes before creating or attaching them.
When planning your system configuration, confirm that your storage configuration meets these requirements and then return to
"Site and System Preparation" on page 34 .
Related Topics
"everRun Storage Architecture" on page 15
Memory Requirements
A minimum of 8 GB of RAM (physical memory) is recommended. The total amount of memory available on an everRun system is equal to the minimum of the amount of memory presented by either physical machine (PM) in the system. For example, in a system where one PM has 32 GB memory and another PM has 16 GB memory, the total amount of memory is 16 GB (the least memory of either PM).
Related Topics
"Planning Virtual Machine Memory" on page 158
General Network Requirements and Configurations
This topic discusses general network requirements and provides some recommended network configurations.
Requirements
Before you install everRun software, make sure your network meets the following requirement: l everRun systems utilize full IPv4 and IPv6 protocol access, including IPv6 multicast. Any obstruction of this traffic may prevent a successful installation or compromise the availability of a running everRun system.
In addition, see the following topics for the requirements specific to each network type: l
"A-Link and Private Network Requirements" on page 29
l
"Business and Management Network Requirements" on page 28
l
"SplitSite Network Requirements" on page 30
Recommended Configurations
Recommendations for possible configurations follow:
Page 27 of 483
everRun User's Guide l
If your system has two 1 Gb and two 10 Gb Ethernet ports: n
Set one 10 Gb port as the private network (priv0).
n
Set the other 10 Gb port as an A-Link network.
n
Set one 1 Gb port as the management link.
n
Set the other 1 Gb port as a business link.
l
If your system has four Ethernet ports of the same type (for example, four 1 Gb or four 10 Gb interfaces): n
Set one port as the private network (priv0).
n
Set one port as an A-Link network.
n
Set one port as the management link.
n
Set one port as a business link.
Note: A system with four 1 Gb Ethernet ports may not provide sufficient throughput for acceptable performance. The system may require 10 Gb add-on cards to achieve acceptable performance.
Business and Management Network Requirements
Business and management networks have the following requirements: l
The networks use IPv6 link-local addressing.
l
The speed of business or management networks should be less than or equal to the speed of A-
Link networks.
l
The networks support an MTU value of up to 9000.
l
The networks do not support bonding or VLAN trunking.
l
VMs can use IPv4, IPv6, and other Ethernet protocols.
l
All business networks can be used for IPv6 host access if your site has SLAAC or DHCPv6 enabled.
l
To reach the everRun Availability Console, use biz0:0, which is the IPv4 address that migrates to the primary management PM. Each PM also has its own IPv4 address (ibiz0) on the management network.
Page 28 of 483
A-Link and Private Network Requirements l
Each PM requires at least one business network (specifically, the management network), with a maximum of 20 business networks.
To ensure that Ethernet traffic flows unobstructed to and from VMs from either PM: l
The switch ports connected to business networks must not filter ARP packets, including gratuitous
ARP packets. An everRun system sends gratuitous ARP packets on behalf of guest VMs in order to prompt Ethernet switches to update their port-forwarding tables to direct VM traffic to the appropriate physical Ethernet port on the appropriate everRun PM.
l
The switch ports connected to business networks must allow layer2 multicasts (address:
01:E0:09:05:00:02) with ethertype: 0x8807.
l
If you configure RHEL or Centos guests to have multiple NICs on same subnet, you may experience guest network connectivity issues due to asymmetric routing. To avoid this problem, modify the /etc/sysctl.conf file on the Protected Virtual Machine (PVM) to contain the following lines, save the file, and reboot the PVM.
n net.ipv4.conf.default.rp_filter = 2 n net.ipv4.conf.all.rp_filter = 2 l
The switches connected to business networks must not enable any MAC address security features that would disable the movement of a MAC address from one business link to the matching business link on the other PM.
l
For optimal failover response, configure any switches connected to your everRun system to have
MAC aging timeout values of less than one second.
If these requirements are not met, or if the switch does not properly update its forwarding table when a VM is migrated from one everRun PM to the other, the VM may experience a blackout in which network traffic is not properly directed to and from the VM.
Related Topics
"Network Architecture Overview" on page 19
"Business and Management Networks" on page 20
and
"network-change-mtu" on page 378
A-Link and Private Network Requirements
A-Link and private networks have the following requirements:
Page 29 of 483
everRun User's Guide l
The networks use IPv6 link-local addressing.
l
All A-Link and private networks on one PM of an everRun system must be in the same L2 broadcast domain as its matching links on the other PM, without any protocol filtering.
l
Ethernet packets sent between two everRun PMs must not be obstructed or rate-limited. Ensure that they are not routed or switched by any L3 network infrastructure.
l
Each PM can have one to eight A-Link networks; however, a minimum of two is recommended.
l
The networks use 1 Gb to 10 Gb Ethernet ports. The speed of A-Link networks should be equal to or greater than the speed of business or management networks.
l
Network traffic for storage replication between PMs is sent over A-Link networks. A-Link networks are not required to be directly connected; instead, they can connect to a network switch.
l
Private networks have no network hosts connected other than the everRun end-points.
l
The system assigns each VM to a minimum of one or a maximum of two A-Link networks.
However, each A-Link network can have multiple VMs assigned to it.
Related Topics
"A-Link and Private Networks" on page 19
SplitSite Network Requirements
This topic describes the requirements for networks in a SplitSite configuration.
l
"A-Link Network Requirements" on page 30
l
"Private Network Requirements" on page 31
l
"Business Network Requirements" on page 31
l
"Management Network Requirements" on page 31
A-Link Network Requirements
A-Link networks in a SplitSite configuration require the following: l
NICs must be at least 1 Gb and full-duplex; use 10 Gb, if possible.
l
For systems running FT-protected virtual machines (VMs), A-Links require: n
A minimum bandwidth of 1 Gbps per VM n
A maximum inter-site latency of 2 ms, round-trip time
Page 30 of 483
Private Network Requirements l
For systems running only HA-protected VMs, A-Links require: n
A minimum bandwidth of 155 Mbps per VM n
A maximum inter-site latency of 10 ms, round-trip time l
Do not use a common card (multiport NIC) for both A-Links.
l
A-Links can be dedicated point-to-point fiber connections. If they are not, they must be configured on a VLAN. The A-Links can share a single VLAN, or they can use separate VLANs. Multiple ever-
Run systems can share the same VLAN(s) for use by the A-Links.
Private Network Requirements
The private network in a SplitSite configuration requires the following: l
NICs must be at least 1 Gb and full-duplex; use 10 Gb, if possible.
l
A minimum bandwidth of 155 Mbps per VM.
l
A maximum inter-site latency of 10 ms, round-trip time. Switches and/or fiber-to-copper converters connected to the private network must be non-routed and non-blocking, with a round-trip latency that does not exceed 10 ms. Calculate latency at 1 ms for each 100 miles of fiber, plus any latency added by non-routed, non-blocking switches or fiber converters.
l
The private network can be a dedicated point-to-point fiber connection. If it is not, it must be configured on a private VLAN. VLANs used to connect the private-network ports must not add any filtering on any of the network equipment between the two VLAN switch ports that are connected to the everRun PMs.
Business Network Requirements
Business networks in a SplitSite configuration require the following: l
Configure the network on a business VLAN. The business network for both nodes must be on this
VLAN.
l
The nodes must be in the same layer-2 multicast domain.
l
Connect the business networks on each PM to a switch separate from the other PM’s switch.
l
An everRun system requires at least one business network. All of these requirements apply to each business network.
Management Network Requirements
Page 31 of 483
everRun User's Guide
A management network in a SplitSite configuration requires the following: l
By default, the management network is shared with a business network. In this case, all requirements for a business network apply.
l
Configure gateways to a business LAN for remote management.
Related Topics
"SplitSite Configurations" on page 13
"Network Architecture Overview" on page 19
everRun Availability Console Requirements
The everRun Availability Console provides browser-based remote management of the everRun system, its physical machines (PMs), and virtual machines (VMs).
l
Your computer must be able to access the subnet containing the everRun system.
l
Use a supported browser. See
"Compatible Internet Browsers" on page 32
.
For more information, see
"Using the everRun Availability Console" on page 59
.
Compatible Internet Browsers
A browser is used to connect to the everRun Availability Console. Use only browsers that are compatible with everRun systems. Using an incompatible browser can result in some rendering problems and the omission of some wizards.
The following browsers are compatible with everRun systems.
Compatible Browsers Release
IE9 or newer
1
Microsoft Internet Explorer™
Mozilla
®
Firefox
®
®
Chrome™
25 or newer
31 or newer
Quorum Servers Considerations
1
IE8 is not recommended and it does not support some everRun functionality.
Page 32 of 483
Quorum Servers Considerations
Enabling or configuring quorum service is a post-install configuration task. Stratus recommends configuring two quorum service computers: a preferred quorum server and an alternate. For an overview of quorum servers, see
.
Quorum service software, if deployed, can be installed on any general-purpose computer or laptop running the Windows operating system with these requirements: l
OS: Windows Server 2012, Windows Server 2008, Windows Server 2003, Windows Vista, Windows 7, or Windows 8; always powered on l
Disk space: 100 MB (minimum) l
NIC: at least one (1) l
Connectivity: Available to the everRun configuration via the management network
To install quorum server software:
1. Open the Downloads page at http://www.stratus.com/go/support/everrun : scroll down to the Software Downloads section and then, for Select Product & Version, select everRun and the appropriate version number.
2. Scroll down to the Drivers and Tools section and then click Quorum Service to download the quorum server software installer file to the quorum server.
3. On the quorum server, double click the installer file.
Note: When upgrading to a more recent version of quorum server software, you do not need to uninstall the previous version.
In addition, consider the following for quorum service best practices: l
Configure two quorum service computers with minimum common networking between the quorum computers and the hosts.
l
As installed, protected VMs contact quorum service computers using UDP port 4557. Firewalls must permit everRun-protected VMs to contact quorum service computers using UDP port 4557. (If this port assignment conflicts with your local infrastructure, you can use different port numbers when you configure the quorum servers using the everRun Availability Console.) l
Quorum service computers should not reside on the same site as any host when deploying in a
SplitSite. If both preferred and alternate quorum computers fail for a common reason, VMs will
Page 33 of 483
everRun User's Guide gracefully downgrade redundancy, and then continue to operate using one host, pending recovery of a quorum computer. However, if a host and the elected quorum computer fail for a common reason, the VMs running on the surviving server shut themselves down. For additional information
about quorum servers and SplitSite configurations, see "SplitSite Network Requirements" on page
30 and "SplitSite Configurations" on page 13 .
l
If the preferred and alternate quorum service computers must reside on a common site, power them from separate AC power sources (phases) or configure them on separate UPS devices.
Related Topics
"Physical Machines and Virtual Machines" on page 9
"Configuring Quorum Servers" on page 75
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
Power Requirements and Considerations
To ensure maximum availability, Stratus strongly recommends that everRun's fault-tolerant (FT) software run on physical machines (PMs) that are powered by redundant power supplies. In addition, each
PM power supply should connect to a separate power source.
See
for illustrations of some sample power-connection configurations.
Also, refer to your server vendor documentation for other power-related information.
Software Installation
When you install the everRun software for the first time:
1. Prepare your site and system for the installation. See
"Site and System Preparation" on page 34
.
2. Connect power to your system. See
"Connecting Power" on page 35 .
3. Install the everRun software. See
"Installing everRun Software" on page 41 .
When the software installation is complete, see
"Post-Installation Tasks" on page 53
.
Related Topics
"Upgrading everRun Software" on page 115
Site and System Preparation
Page 34 of 483
Connecting Power
Before you install everRun software, make sure that your site and system meet the following requirements: l
The system meets all of the requirements described in "System Requirements Overview" on page
l
l
Provide keyboard and console access to each physical machine. This access can be in the form of a physical keyboard and monitor, a keyboard-video-mouse switch, or a properly-configured remotemanagement card capable of providing remote console and keyboard access. Connect the keyboard/console access as described in the vendor's documentation (for example, through direct
VGA or USB connections).
Note: You cannot install everRun software from a serial console.
l
Provide a remote management computer for the everRun Availability Console, and make sure it
meets all of the requirements described in "everRun Availability Console Requirements" on page
l
l
Connecting Power
To connect power, configure your everRun server with redundant power supplies connected to separate sources. After connecting power, return to
"Software Installation" on page 34 .
UPS (Optional)
The illustrations show how to connect one or two optional uninterruptible power supplies (UPS) to the ever-
Run system.
Single UPS:
Page 35 of 483
everRun User's Guide
Dual UPS:
Related Topics
"Power Requirements and Considerations" on page 34
Obtaining everRun Software
Stratus provides the everRun software as an ISO image. You can boot from it directly, or you can create bootable media.
Obtaining the ISO Image
1. From any computer connected to the Internet, go to the Downloads page at http://www.stratus.com/go/support/everrun .
Page 36 of 483
Final Step
2. To download the everRun software ISO image (everRun_install-7.
x .
x .
x xxx .iso), under Product
Downloads, click everRun 7.
x.x.x
ISO Image. Save the ISO image.
Note: Depending on your Internet connection, the download can take up to 30 minutes.
Final Step
After you have obtained the ISO image, do one of the following: l
Create bootable media. Burn the ISO image to a DVD using a commonly available application, or create a bootable USB medium (see
"Creating Bootable USB Media" on page 37
). Then, perform the next step in
"Installing everRun Software" on page 41 .
l
Occasionally an ISO file can be corrupted during the download process. You can choose to verify the installation medium during the software installation.
Creating Bootable USB Media
After you have saved the everRun installation software ISO image, you have the option of copying the image to a bootable USB medium, such as a thumbdrive. Follow the procedure below for your system.
Creating a bootable USB medium on a Linux-based system
Caution: This procedure will destroy any data on the USB medium.
1. Log in to the system as root.
2. Insert a USB medium such as a thumbdrive into the system. Determine the name of the thumbdrive.
One method of determining the name of the thumbdrive is to execute the dmesg command to display a log of all recent events, as in this example:
# dmesg | tail
The end of the log includes messages related to the recently inserted thumbdrive, as in this example: sd 6:0:0:0: [sdc] Attached SCSI removable disk
Page 37 of 483
everRun User's Guide
Make note of the thumbdrive name in the messages (sdc, in the example).
3. Check if the system mounted the thumbdrive automatically.
One method of determining if the system mounted the thumbdrive automatically is to execute the findmnt thumbdrive_name command, as in this example:
# findmnt | grep sdc
If the command displays no output, the thumbdrive was not mounted and you can continue with the next step. If the command displays output, the system mounted the thumbdrive automatically and you must unmount it. Note the TARGET in the command output, as in this example:
TARGET SOURCE FSTYPE OPTIONS
/media/MY-DATA /dev/sdc1 vfat
Then, issue the command unmount TARGET , as in this example
# umount /media/MY-DATA
4. Write the installation software ISO image directly to the thumbdrive.
One method of writing the image is to execute the dd command in the format dd if= path_ to_image iso of=/dev/sd x bs= blocksize , where path_to_image is the full path to the
ISO image file that you saved, sd x is the thumbdrive device name, and blocksize is an amount that ensures a timely writing process. The following command is an example:
# dd if=Downloads/everRun_install-7.4.0.0-97.iso
of=/dev/sdc bs=8K
Wait while the dd command completes processing. A prompt appears when the command is complete.
5. Log out and remove the thumbdrive. The thumbdrive is ready to be used as a boot device.
Creating a bootable USB medium on a Windows-based system
Caution: This procedure will destroy any data on the USB medium.
Note: Copying an ISO image to a USB medium using a file manager such as Windows
Explorer or a similar tool does not create a bootable device.
Page 38 of 483
Creating Bootable USB Media
Many utilities write an ISO image to a USB medium such as a thumbdrive on Windows-based systems. The following procedure uses the utility Rufus, which is available at http://rufus.akeo.ie/ .
2. Ensure the integrity of the ISO image using a tool for verifying MD5 checksums on Windows-based systems. For example, use the Microsoft File Checksum Integrity Verifier tool, which is available at https://www.microsoft.com/en-us/download/details.aspx?id=11533 .
3. Download and install the Rufus utility at http://rufus.akeo.ie/ . Be sure to click the Download link that is about halfway down the web page (below Last updated); do not click advertisements, including Download links that appear in advertisements.
4. Insert a USB medium such as a thumbdrive into the system
5. Run the Rufus utility, selecting the following options:
Option Value(s)
Partition scheme and target system type
MBR partition scheme for BIOS and UEFI
File system
Cluster size
Format Option
FAT32
4096 bytes
Create a bootable disk using ISO Image
(browse to the xxx.iso image)
Create extended label and icon files
6. Click Start after selecting the options.
7. On the menu that appears, select Write in DD image mode.
8. Click OK to write to the USB device.
Page 39 of 483
everRun User's Guide
When the utility has completed writing the USB stick, READY appears in the horizontal box near the bottom of the utility interface. You can remove the USB device and use it to install everRun.
Related Topics
"Obtaining everRun Software" on page 36
"Software Installation" on page 34
Configuring Settings in the Firmware Setup Utility
Before you install the software, you must modify settings in the firmware (BIOS or UEFI) setup utility. You can also modify some optional, though recommended, settings.
Note: A system with UEFI firmware always boots from the original software boot disk. If the
After you modify the settings, save them and perform the next step in the installation procedure (either
"Installing Software on the First PM" on page 45
or
"Installing Software on the Second PM" on page 51 ).
Note: This topic provides general information about settings in the firmware setup utility.
Because settings--including setting names--vary, refer to the manufacturer's documentation for specific instructions for modifying any setting.
Required Settings
The following settings are required.
First Boot
Device
Controls which device boots the operating system. Set the first boot device to the
Optical Drive.
Virtualization
Technology
Allows the processor to use virtualization technology. Set this to Enabled.
Page 40 of 483
Recommended Settings
Execute-Disable Bit Capability
Allows the processor to classify areas in memory where application code can or cannot execute. Set this to Enabled to help prevent malicious code attacks.
Recommended Settings
The following settings are optional but recommended.
AC Power Recovery
Determines whether the server automatically powers on and boots after a power cycle. The recommended setting is ON.
F1/F2 Prompt on
Error (Dell systems only)
Terminates booting if an error is detected during the process. Set this to Disable, as the everRun system may be able to provide more information once the server is running.
Installing everRun Software
Follow these instructions to install everRun software for the first time on a system.
Warning: Installing everRun software erases all hard drives.
To install everRun software for the first time:
2. On your everRun system: a. Provide keyboard and console access to your physical machines (PMs), if you have not already done so (see
"Site and System Preparation" on page 34
).
b. Connect Ethernet cables for the networks you are configuring. See "Connecting Ethernet
3. Perform the installation on the first PM. See
"Installing Software on the First PM" on page 45 .
4. After you have finished installing the software on the first PM, perform the installation on the second PM. See
"Installing Software on the Second PM" on page 51 .
Page 41 of 483
everRun User's Guide
Installation Tasks" on page 53 .
Connecting Ethernet Cables
Before you install everRun software for the first time, you need to connect Ethernet cables for your networks.
Note: To install additional networks after you have completed the software installation, see
"Connecting Additional Networks" on page 56
.
On each physical machine (PM), assign one network port as the private network (priv0), and assign another network port as the management network (ibiz0). Although you can use any network port (1 Gb or
10 Gb) for the private network or management network, Stratus recommends that you use embedded network ports. Use CAT5E, CAT6, or CAT7 network cables for all network ports.
The following illustration shows an example of an everRun network configuration.
Stratus recommends the following Ethernet cable configurations: l
For the private network, directly connect an Ethernet cable from any embedded port on the first PM to the same embedded port on the second PM. If you plan to use the private network as an A-Link, connect the cable to 10 Gb ports, if installed.
l
For the management network, connect Ethernet cables from an embedded port on each PM to a network that is accessible from the remote management computer.
Page 42 of 483
Installation Options
Note: Take note of the ports you used for the private and management networks. The installation software will prompt you for this information.
l
For each A-Link network, connect an Ethernet cable from a port on the first PM to a port on the second PM, either directly or through a network switch.
Note: Stratus recommends that you configure at least one A-Link network in addition to the private network. See
"A-Link and Private Network Requirements" on page 29
l
For each business network, connect an Ethernet cable from a port on the first PM to a port on the second PM, through a network switch.
Related Topics
"A-Link and Private Network Requirements" on page 29
"Business and Management Network Requirements" on page 28
"everRun Availability Console Requirements" on page 32
"Connecting Additional Networks" on page 56
Installation Options
When you insert the everRun DVD, the Welcome screen appears with the following list of installationrelated options. Use the up and down arrow keys to select an option based on the task you want to perform. You can then press the Tab key to modify the command line. Finally, press the Enter key to boot the installation program from the DVD.
Task Option Description
Verify the installation medium and then perform the installation.
Verify medium and Install ever-
Run
Verifies the installation medium first, then installs the
CentOS and everRun software, and, finally, creates a new system. (Stratus recommends that you verify installation medium the first time you use it; note, though, that verification adds five or so minutes to the installation.)
Page 43 of 483
everRun User's Guide
Task Option Description
See
"Installing Software on the First PM" on page 45 .
Verify the installation medium and then recover a physical machine.
Verify medium and Recover
Physical
Machine
Verifies the installation medium and then recovers a phys-
ical machine. (This option is the default.) See "Recovering a Failed Physical Machine" on page 150 .
Verify the installation medium and then replace a physical machine.
Verify medium and Replace
Physical
Machine
Verifies the installation medium and then replaces a phys-
Perform initial installation on the first PM
Install everRun ,
Create a new system
Deletes all partitions on all connected disks, installs the
CentOS and everRun software, and creates a new sys-
tem. See "Installing Software on the First PM" on page
Recover failing
PM
Recover PM,
Join system:
Preserving data
Preserves all data but re-creates the
/boot and root file systems, reinstalls the CentOS and everRun software, and attempts to connect to an existing system. See
"Recovering a Failed Physical Machine" on page 150
.
Perform initial installation on the second
PM; replace a
PM
Replace PM,
Join system:
Initialize data
Deletes all partitions on all connected disks, installs
CentOS and everRun software, and attempts to connect
to an existing system. See "Installing Software on the
Second PM" on page 51 and "Replacing Physical
Machines, Motherboards, NICs, or RAID Controllers" on page 276 .
Page 44 of 483
Installing Software on the First PM
Task Option
Boot to rescue mode
(UEFI firmware installation only)
Rescue the installed system
Description
Boots to rescue mode.
Access additional troubleshooting options (BIOS firmware installation only).
Troubleshooting Provides access to additional troubleshooting options.
See table below.
Troubleshooting Submenu (BIOS Firmware Installation)
Task Option
Boot to rescue mode
Boot from local drive
Perform memory test
Rescue the installed system
Boot from local disk drive
Memory test
Description
Boots to rescue mode.
Boots from a local disk drive.
Performs a memory test.
Installing Software on the First PM
This topic describes how to perform an initial installation of the everRun software on node0, which is the first physical machine (PM).
Note: To perform an installation by mounting the ISO image, you must first configure your system's remote-management feature (for example, iDRAC on a Dell system). See the manufacturer's documentation for instructions.
To perform an initial installation of the software on the first PM:
Page 45 of 483
everRun User's Guide
1. Power on the first PM, if it is not already powered on, and either insert the bootable medium or mount the ISO image.
2. As the system powers on, enter the firmware (BIOS or UEFI) setup utility, and configure the
Note: If you need to configure your keyboard for a different language, see "Mapping
3. When the installation software loads, the Welcome screen appears and displays the options shown in
"Installation Options" on page 43
. From this screen, you can choose to perform the initial installation in one of two ways: n
Method 1: Installing via the user interface. This method is best for users who are not familiar with the installation process and who prefer to follow a GUI-based procedure with prompts.
n
Method 2: Installing via the command line. This method allows you to automate the installation. You can enter the IP settings in advance, and the installation proceeds without human intervention. This method is especially useful when you need to reinstall the software and you know all of the IP settings in advance.
Method 1: Installing via the User Interface i. Use the arrow keys to select an installation option. Stratus recommends that, for an initial installation, you select Verify medium and Install everRun, which verifies the installation medium before installing the software (verification adds about five minutes to the installation process). If you do not want to verify the medium, select Install everRun, Create a new system. After you select an option, press Enter.
ii. If any disk contains previously installed data, the following message appears and the system reboots (if no disk contains previously installed data, installation continues with the next step):
Rebooting because disks XXX were erased.
When the reboot is complete, the boot menu reappears and you must, again, select Method
1 or Method 2 (Step 3, above).
Page 46 of 483
Installing Software on the First PM iii. The Select interface for private Physical Machine connection screen sets the physical interface to use for the private network. To use the first embedded port, use the arrow keys to select em1 (if it is not already selected), and then press F12 to save your selection and go to the next screen.
Notes:
1. If you are not sure of which port to use, use the arrow keys to select one of the ports, and click the Identify button. The LED on the selected port will then flash for 30 seconds, allowing you to identify it. Since the LED may also flash due to activity on that network, Stratus recommends that you leave the cable disconnected during the identification process. Reconnect the cable immediately after identification is complete.
2. If the system contains no embedded ports, select the first option interface instead.
iv. The Select interface for managing the system (ibiz0) screen sets the physical interface to use for the management network. To use the second embedded port, use the arrow keys to select em2 (if it is not already selected), and then press F12 to save your selection and go to the next screen.
Note: If the system contains only one embedded port, select the first option interface. If the system contains no embedded ports, select the second option interface.
v. The Select the method to configure ibiz0 screen sets the management network for node0 as either a dynamic or static IP configuration. Typically, you set this as a static IP configuration, so use the arrow keys to select Manual configuration (Static Address) and press F12 to save your selection and go to the next screen. However, to set this as a dynamic IP configuration, select Automatic configuration via DHCP and press F12 to save your selection and go to the next screen.
vi. If you selected Manual configuration(Static Address) in the previous step, the Configure em2 screen appears. Enter the following information and press F12.
Page 47 of 483
everRun User's Guide n
IPv4 address n
Netmask n
Default gateway address n
Domain name server address
See your network administrator for this information.
Note: If you enter invalid information, the screen redisplays until you enter valid information.
Method 2: Installing via the Command Line i. Press the Tab key to bring up the command line.
ii. Set the value for the private network (priv0).
n
To use the first embedded interface, type: priv0=em1 n
To automatically select the default interface, type: priv0=auto n
To use the interface with a MAC address, type one of the following: priv0=AA-BB-CC-DD-EE-FF or priv0=AABBCCDDEEFF iii. Set the value for the management network (ibiz0).
n
To use the second embedded interface with BOOTP: ibiz0=em2:bootp n
To automatically choose an interface and use DHCP: ibiz0=auto:dhcp n
To use a static configuration with IP address 10.83.51.116, netmask 255.255.0.0 , default gateway 10.83.0.1, and two DNS servers 134.111.24.254 and 134.111.18.14: ibiz0=em2:10.83.51.116/16:10.83.0.1:134.111.24.254,134.111.18.14
n
To query the system administrator to configure the default interface: ibiz0=auto
Page 48 of 483
Mapping Your Keyboard iv. After entering the desired values on the command line, press Enter.
v. If any disk contains previously installed data, the following message appears and the system reboots (if no disk contains previously installed data, installation continues with the next step):
Rebooting because disks XXX were erased.
When the reboot is complete, the boot menu reappears and you must, again, select Method
1 or Method 2 (Step 3, above).
4. At this point, the installation continues without additional prompts. No action from you is required until the first PM reboots.After it reboots: a. Remove the bootable medium, or unmount the ISO image.
5. Perform the next step in
"Installing everRun Software" on page 41 .
Mapping Your Keyboard
You can configure your keyboard for a different layout either during or after installation.
Supported keyboard layouts include:
Layout Language de German de-latin1 de-latin1-nodeadkey dvorak jp106 sg sg-latin1
German (latin1)
German (latin1 without dead keys)
Dvorak
Japanese
Swiss German
Swiss German (latin1)
Page 49 of 483
everRun User's Guide
Layout uk us us-acentos
Language
United Kingdom
U.S. English
U.S. International
To configure your keyboard layout during installation:
1. As the first PM boots, select Install, Recover, or Repair from the boot menu.
2. On legacy BIOS systems, press Tab to access the kernel command line. On UEFI systems, press e.
3. Specify the inst.keymap
kernel argument to configure the correct keyboard layout. The following example configures the Japanese keyboard layout: inst.keymap=jp106
4. On legacy BIOS systems, press Enter to continue the boot sequence. On UEFI systems, press
Ctrl-x.
5. Repeat the preceding steps on the second PM.
To configure your keyboard layout after installation:
1. Log in to the first PM as root .
2. From the command line, issue the localectl command to configure the correct keyboard layout. The following example configures the German keyboard layout:
#
localectl set-keymap de
3. Repeat the preceding steps on the second PM.
Related Topics
"Installing Software on the First PM" on page 45
"Post-Installation Tasks" on page 53
Recording the Management IP Address
Page 50 of 483
Installing Software on the Second PM
Your network administrator may require the management IP address for each physical machine (PM) in order to configure the system IP address. Perform this procedure if you configured the management network to have a dynamic IP address. (Your network administrator already has this information if the management network has a static IP address.)
1. When the PM completes its installation and reboots, a login screen similar to the following appears: everRun
IPv4 address 10.84.52.117
IPv6 address 3d00:feed:face:1083:225:64ff:fe8d:1b6e
IPv6 address fe80: :225:64ff:fe8d:1b6e
2. Record the IPv4 address shown on the screen.
3. Give this IP address to your network administrator.
Return to
"Installing everRun Software" on page 41
to see the next step.
Installing Software on the Second PM
This topic describes how to perform an initial installation of the everRun software on node1, which is the second physical machine (PM).
Note: To perform an installation by mounting the ISO image, you must first configure your system's remote-management feature (for example, iDRAC on a Dell system). See the manufacturer's documentation for instructions.
To perform an initial installation of the software on the second PM:
1. Power on the second PM, if it is not already powered on, and either insert the bootable media or mount the ISO image.
2. As the system powers on, enter the firmware (BIOS or UEFI) setup utility, and configure the
3. When the installation software loads, the Welcome screen appears and displays the options shown in
"Installation Options" on page 43
. From this screen, you can perform the initial installation using either the user interface or the command line. This topic describes how to perform the
Page 51 of 483
everRun User's Guide installation with the user interface. To perform the installation with the command line, see "Method
2: Installing via the Command Line" in
"Installing Software on the First PM" on page 45 .
4. Use the arrow keys to select Replace PM, Join system: Initialize data, and press Enter. (If you verified the installation medium when installing the software on the first PM, you do not need to verify the installation medium now.)
Note: No action from you is required until the screen described in the next step appears.
5. If any disk contains previously installed data, the following message appears and the system reboots (if no disk contains previously installed data, installation continues with the next step):
Rebooting because disks XXX were erased.
When the reboot is complete, the boot menu reappears and you must continue with Step 3, above.
6. The Select interface for private Physical Machine connection screen sets the physical interface to use for the private network. To use the first embedded port, use the arrow keys to select em1 (if it is not already selected), and then press F12 to save your selection and go to the next screen.
Notes:
1. If you are not sure of which port to use, use the arrow keys to select one of the ports, and click the Identify button. The LED on the selected port will then flash for 30 seconds, allowing you to identify it. Since the LED may also flash due to activity on that network, Stratus recommends that you leave the cable disconnected during the identification process. Reconnect the cable immediately after identification is complete.
2. If the system contains no embedded ports, select the first option interface instead.
7. The Select interface for managing the system (ibiz0) screen sets the physical interface to use for the management network. To use the second embedded port, use the arrow keys to select em2
(if it is not already selected), and then press F12 to save your selection and go to the next screen.
Note: If the system contains only one embedded port, select the first option interface. If the system contains no embedded ports, select the second option interface.
Page 52 of 483
Post-Installation Tasks
8. The Select the method to configure ibiz0 screen sets the management network for node1 as either a dynamic or static IP configuration. Typically, you set this as a static IP configuration, so use the arrow keys to select Manual configuration (Static Address) and press F12 to save your selection and go to the next screen. However, to set this as a dynamic IP configuration, select
Automatic configuration via DHCP and press F12 to save your selection and go to the next screen.
9. If you selected Manual configuration(Static Address) in the previous step, the Configure em2 screen appears. Enter the following information and press F12.
n
IPv4 address n
Netmask n
Default gateway address n
Domain name server address
See your network administrator for this information.
Note: If you enter invalid information, the screen redisplays until you enter valid information.
10. At this point, the installation continues without additional prompts. No action from you is required until the second PM reboots. After it reboots: a. Remove the bootable media, or unmount the ISO image.
11. Perform the next step in
"Installing everRun Software" on page 41 .
Post-Installation Tasks
After completing system installation, you must complete several post-installation tasks, including: l
"Obtaining System IP Information" on page 54
l
"Logging on to the everRun Availability Console for the First Time" on page 54
Page 53 of 483
everRun User's Guide l
Configuring Required System Preferences: n
"Configuring Date and Time" on page 77
n
"Configuring Remote Support Settings" on page 93
n
"Configuring Quorum Servers" on page 75
n
"Specifying Owner Information" on page 68
l
"Configuring Active Directory" on page 79
l
"Managing Local User Accounts" on page 111
l
"Resolving Outstanding Alerts on the Dashboard" on page 62
l
"Connecting Additional Networks" on page 56
Obtaining System IP Information
After you install the everRun software, you need the node0 IP address to log on to the everRun Availability
administrator should provide. Give the network administrator the node0 and node1 IP addresses (see
"Recording the Management IP Address" on page 50 ), which helps the network administrator determine
system IP information. The system IP address must be a static IP address. Do not use a dynamic IP address.
Related Topics
"Software Installation" on page 34
"Post-Installation Tasks" on page 53
Logging on to the everRun Availability Console for the First Time
After completing the installation of the everRun software, log on to the everRun Availability Console to accept the end-user license agreement (EULA) and to manage the everRun system.
Page 54 of 483
Logging on to the everRun Availability Console for the First Time
Prerequisites: To log on to the everRun Availability Console the first time, you need the following: l
l
The system IP address—The network administrator provides this information. See
"Obtaining System IP Information" on page 54 .
l
The license .KEY file that you received from Stratus when you purchased the everRun software—You must upload this file to the everRun Availability Console to complete the initial logon. Locate the file before you begin the initial logon.
To log on to the everRun Availability Console for the first time
1. From the remote management computer, type the IP address of node0 (primary) into a browser address bar.
The logon page of the everRun Availability Console appears.
2. Enter admin for the Username and admin for Password, and then click LOGIN
The Stratus everRun EULA appears.
3. Read the EULA and then, if appropriate, click Accept to accept it.
The INITIAL CONFIGURATION page appears.
4. Under NOTIFICATIONS, the box for Enable Support Notifications is checked, by default. If you do not want the everRun system to send health and status notifications to your authorized Stratus
service representative, uncheck the box. You can change this setting later (see "Configuring
Remote Support Settings" on page 93 ).
5. Under SYSTEM IP, for IP Address, enter the address you obtained from your network administrator.
After you have entered the network information, click Continue.
6. The Portal Restart Required window appears. After waiting a minute (as indicated in the window), click OK to refresh the console and to continue.
Page 55 of 483
everRun User's Guide
7. The LICENSE INFORMATION window appears. Under Upload License Key, click Browse and navigate to the license .KEY file that you received from Stratus. Select the license file and click
Upload.
The initial logon is complete, and the everRun Availability Console appears. Bookmark or otherwise make note of the system IP address for use when logging in to the console in the future.
For security, change the default user login name and password for the admin account on the Users
& Groups page. See
"Managing Local User Accounts" on page 111
.
Related Topics
"Software Installation" on page 34
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
Connecting Additional Networks
The everRun installation software connects networks for all network ports that are physically connected at the time of the installation. This topic describes how to connect additional networks after the software installation is complete.
To connect a network:
1. Connect an Ethernet cable from a port on the first PM to a port on the second PM. Ideally, use the same NIC slot and port number in each PM. Connect the cable either directly (for an A-Link network) or through a network switch (for an A-Link or business network).
2. In the everRun Availability Console, go to the Networks page.
a. The new shared-network name should appear within a minute or so. If not, either your cable is on different subnets or the NIC ports between the PMs are incompatible (for example, if one end is connected to a 10 Gb port and the other end is connected to a 1 Gb port).
b. Click the Config button to select whether the network should be an A-Link or a business network. If the connection is direct, the network must be an A-Link. Otherwise, the network can be either an A-Link or a business network.
c. Verify that the new shared network displays a green check.
3. Connect additional network cables to both PMs, one pair at a time. Ideally, use the same NIC slot and port number in each PM.
Page 56 of 483
Related Topics
"Connecting Ethernet Cables" on page 42
"A-Link and Private Network Requirements" on page 29
"Business and Management Network Requirements" on page 28
"General Network Requirements and Configurations" on page 27
Connecting Additional Networks
Page 57 of 483
3
Chapter 3: Using the everRun Availability Console
The everRun Availability Console is a browser-based interface that provides management and monitoring
For information on pages within the everRun Availability Console, see the following topics: l
"The Dashboard Page" on page 62
l
l
"The Preferences Page" on page 65
l
l
l
"The Physical Machines Page" on page 97
l
"The Virtual Machines Page" on page 100
l
"The Snapshots Page" on page 105
l
"The Volumes Page" on page 106
l
"The Storage Groups Page" on page 107
l
"The Networks Page" on page 108
l
"The Virtual CDs Page" on page 110
l
"The Upgrade Kits Page" on page 110
l
"The Users & Groups Page" on page 111
Page 59 of 483
everRun User's Guide
The everRun Availability Console
The everRun Availability Console is a browser-based interface that provides management and monitoring of an everRun system from a remote management computer. You can perform many administrative operations from the console because it provides access to the system as a whole as well as to physical machines (PMs), virtual machines (VMs), and other resources.
For information on the requirements of the remote management computer that runs the everRun Availability Console, see
"everRun Availability Console Requirements" on page 32
.
Using the everRun Availability Console, you can perform a variety of administrative functions: l
Read system alerts from the Dashboard. See
"The Dashboard Page" on page 62
.
l
View VM, CPU, memory, and storage statistics, and reboot or shutdown the system from the System page. See
.
l
Set preferences for the system, diagnostics, notifications (e-Alerts and SNMP configuration), and remote support (notification and access); and access administrative tools that enable you to set a migration policy, create a secure connection, configure snapshots, and set other functionality. System preferences include owner information and configuration values for IP address, quorum services, date and time, etc. See
"The Preferences Page" on page 65
.
l
View alerts and audit logs. See
and
.
l
Monitor, manage, and maintain resources: n
PM status, storage, disks, network, and sensors: see "The Physical Machines Page" on page 97 .
n
VM status and management tasks such as creating, importing/restoring, managing, and maintaining VMs: see
"The Virtual Machines Page" on page 100 .
n
Snapshot status and management tasks such as exporting and deleting snapshots: see
"The Snapshots Page" on page 105 .
n
Volumes, including their state, size, and storage group: see "The Volumes Page" on page
n
Storage groups, including name, size used, size, and number of volumes: see "The Storage
Page 60 of 483
Logging on to the everRun Availability Console n
Networks, including state, physical interface, speed, MAC address, and network bandwidth: see
"The Networks Page" on page 108 .
n
Virtual CDs, including their state, name, size, and storage group: see "The Virtual CDs
l
Monitor and manage upgrade kits, and users and groups in the LIBRARY. See "The Upgrade Kits
Page" on page 110 and "The Users & Groups Page" on page 111 .
Related Topics
"Logging on to the everRun Availability Console for the First Time" on page 54
"Logging on to the everRun Availability Console" on page 61
"Using the everRun Availability Console" on page 59
Logging on to the everRun Availability Console
Log on to the everRun Availability Console to manage the everRun system. Using the console, you can manage the system, including its physical machines (PMs), virtual machines (VMs), storage, and networks. You can also generate statistics and view alerts and logs.
To log on to the everRun Availability Console
1. Type the everRun system’s IP address or name that is a fully qualified domain name (FQDN) into a browser address bar: http:// IP_address
OR http:// FQDN_name
IP_address is the everRun system’s static IP address, supplied during installation.
FQDN_name is the FQDN corresponding to that IP address.
2. When the logon page appears, enter your Username and Password.
3. Click LOGIN.
Related Topics
"Logging on to the everRun Availability Console for the First Time" on page 54
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
Page 61 of 483
everRun User's Guide
The Dashboard Page
The Dashboard page displays a summary of outstanding alerts on the everRun system. To open this page, click Dashboard in the left-hand navigation panel.
To display additional information about outstanding alerts, click an alert symbol (for example, ) in the everRun system diagram or click an entry in the list of alerts below the system diagram. Alert lists may appear in tabs such as All, System, or Ignored, which may appear below the system diagram, depending on the alerts. The alert information includes: l
The component associated with the issue (for example, the everRun system, physical machine
(PM), or virtual machine (VM)).
l
A description of the activity or task that requires attention.
l
The reason the issue should be resolved, if available.
Understanding the everRun System Diagram
The system diagram on the Dashboard page displays a graphical representation of system status. A star symbol indicates the primary PM. Alert symbols, if present, represent informational or critical alerts that require attention. Click an alert symbol to display information about the alert.
Related Topics
"The Physical Machines Page" on page 97
"The Virtual Machines Page" on page 100
Resolving Outstanding Alerts on the Dashboard
After completing system installation, resolve any outstanding alerts that appear on the Dashboard page.
To resolve outstanding alerts
On the everRun Availability Console Dashboard page, view any alerts listed in the lower portion of the page. Your options are as follows:
Page 62 of 483
The System Page l
Resolve the alert.
For instance, if you see the message Support Notification service should be enabled to ensure the best possible support from Stratus, then enable support notification service.
l
Click Ignore (beneath the Action column) to ignore the alert and remove it from the list. Minor alerts can be ignored rather than resolved. Clicking Ignore hides the alert.
To restore the ignored alert to the list, click Ignored, above the alerts list, and then Restore, under the Action column.
Related Topics
"The Dashboard Page" on page 62
The System Page
The System page displays information about the everRun system, and enables you to reboot or shut down the system. To open this page, click System in the left-hand navigation panel.
The System page displays resource allocations for the everRun system.
You can use the System page for administrative tasks including: l
"Rebooting the System" on page 63
l
"Shutting Down the System" on page 64
You perform many other administrative tasks on the everRun system using the everRun Availability Console. For information, see
"The everRun Availability Console" on page 60
.
To manage everRun system resources, see
"Configuring System Resources" on page 78 .
Related Topics
"Using the everRun Availability Console" on page 59
Rebooting the System
Reboot the everRun system using the everRun Availability Console to safely restart both PMs without incurring downtime for the VMs.
Caution: Rebooting the everRun system by any method other than following (for example, rebooting from the PMs individually) may result in data loss.
Page 63 of 483
everRun User's Guide
Note: You can reboot the system only if both PMs are running, healthy, and not in maintenance mode.
Prerequisite: Confirm that both PMs are running before rebooting.
To reboot the everRun system
1. Select System in the left-hand navigation panel.
2. Click the Reboot button. A message appears, asking you to confirm the reboot. Click Yes to continue.
Rebooting can take up to 15 minutes. You can observe the process in the Dashboard and the masthead of the everRun Availability Console. The system's PMs sequentially enter and then exit maintenance mode (for information on maintenance mode, see
"Maintenance Mode" on page 145 ).
3. Verify that the PMs restart and that all VMs continue running as expected.
After you initiate a reboot, a message in the masthead shows the status of the reboot. If necessary, you can cancel the reboot by clicking Cancel Reboot in the masthead.
Caution: If you cancel a reboot, the system is left in its current state and you need to manually restore it to a healthy state.
Related Topics
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
Shutting Down the System
Use the everRun Availability Console to shut down the everRun system. Doing so performs an orderly shutdown by first shutting down the virtual machines (VMs) and then the physical machines (PMs). Use only this method to shutdown the everRun system. Make sure both PMs are running before shutting down.
Page 64 of 483
The Preferences Page
Cautions:
1. Shutting down the everRun system takes the VMs offline, so shutdown the system only during a planned maintenance period.
2. Shutting down the everRun system by any other method (for example, removing power from both PMs individually) may result in data loss.
To shut down the everRun system
1. Confirm that both PMs are running so that the disks can synchronize between nodes.
2. Select System in the left-hand navigation panel.
3. Click the Shutdown button. A warning appears: It will shut down the entire system and stop one or more VMs!
Click Yes to shutdown or No to cancel the shutdown. After clicking Yes, a second warning appears, asking you to confirm the shutdown. Click Yes (again) to shutdown or No to cancel the shutdown.
You can observe some of the shutdown process in the Dashboard and the masthead of the everRun
Availability Console as the system's PMs sequentially enter maintenance mode (for information on maintenance mode, see
"Maintenance Mode" on page 145
). When the system shuts down completely, though, the everRun Availability Console is unavailable and the masthead displays Lost Communication.
After the system shuts down, you lose the connection to the console. If the everRun system cannot shutdown completely, a VM may not be shutting down properly. Do one of the following to shut down the VM: l
Use the VM console or a remote desktop application to log on to the VM. Use operating system commands to shut down the VM.
l
Log on to the everRun Availability Console. Click Virtual Machines in the left-hand navigation panel, select the VM, and then click Power Off.
Related Topics
"Managing the Operation of a Virtual Machine" on page 227
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
The Preferences Page
Page 65 of 483
everRun User's Guide
The Preferences page enables you to configure everRun system settings. To open this page, click
Preferences in the left-hand navigation panel.
The following table lists and describes the preferences.
Preference Description
System
Owner Information
Product License
IP Configuration
Quorum Servers
Date & Time
System Resources
Allows you to specify and then view the name and contact information for an everRun system administrator. This information is also provided in response
Allows you to view and manage the everRun product license. See
"Managing the everRun Product License" on page 69 .
Allows you to view and specify the Internet Protocol (IP) address and net-
work settings for the everRun system. See "Configuring IP Settings" on page 73 .
Allows you to view existing and new Quorum servers. Quorum servers provide data integrity assurances and automatic restart capabilities for specific failures in the everRun environment. See
and
"Configuring Quorum Servers" on page 75
.
Allows you to view the system time, specify values for Network Time Protocol (NTP) (recommended), or to manually set the time and date on the ever-
Run system. See
"Configuring Date and Time" on page 77 .
Allows you to specify the number of virtual CPUs (VCPUs) and the amount
of memory reserved for the everRun software. See "Configuring System
Administrative Tools
Page 66 of 483
The Preferences Page
Preference
Active Directory
Migration Policy
Secure Connection
Description
Allows you to enable (and disable) Active Directory. When enabled, Active
Directory allows you to authorize existing users or groups from the Active
Directory domain to log on to the everRun Availability Console and manage the everRun system. See
"Configuring Active Directory" on page 79 .
Allows you to disable VMs' automatic load balancing that occurs, by default, when the node they are running on returns to service after recovering from a
node failure or exiting maintenance mode. See "Configuring the Migration
Host Inactivity Logout
Allows you to disable the host inactivity logout or to change the timeout. See
"Configuring the Host Inactivity Logout" on page 82 .
Snapshot Configuration
Allows you to disable the creation of snapshots. See "Disabling and
Enabling Snapshots" on page 83 .
IPtables Security
Allows you to manage IP packet filtering using the administrative tool IPtables.
Diagnostics
Diagnostics
Allows you to generate a diagnostic file for your authorized Stratus service representative. See
"Managing Diagnostic Files" on page 86
.
Notification e-Alerts
SNMP Configuration
Allows you to enable email alerts (e-Alerts) for system administrators. See
"Configuring e-Alerts" on page 89 .
Allows you to enable Simple Network Management Protocol (SNMP) requests and traps for remote system monitoring. See
Page 67 of 483
everRun User's Guide
Preference Description
.
Remote Support
Support Configuration
Allows you to configure remote access and notifications. Remote access enables your authorized Stratus service representative to log on to the system remotely for troubleshooting. When enabled, the everRun system can send notifications to your authorized Stratus service representative about
problems with the system. See "Configuring Remote Support Settings" on page 93 .
Proxy Configuration
Allows you to configure proxy settings for the everRun system if your organization requires a proxy server to access the Internet and you have a service agreement with Stratus or another authorized everRun service representative. everRun software uses proxy server information for support noti-
fication messaging and remote support access features. See "Configuring
Internet Proxy Settings" on page 95 .
Related Topics
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
Specifying Owner Information
Specify the name and contact information for an administrator or owner of the everRun system to make this information available for support purposes.
This contact information is available in the everRun Availability Console and provided in response to
Simple Network Management Protocol (SNMP) requests.
To specify system owner information
1. Click Preferences in the left-hand pane.
2. On the Preferences page, click Owner Information.
Page 68 of 483
Managing the everRun Product License
3. Supply information in the Full Name, Phone Number, Email, and Site Address fields.
4. Click Save.
Related Topics
"The Preferences Page" on page 65
"The everRun Availability Console" on page 60
Managing the everRun Product License
Manage the product license for the everRun system by: l
Viewing current license information such as status, type, expiration date. and other information.
l
Uploading a license .key file saved on a computer.
l
Downloading an activated license .key file to a computer and then uploading it to the everRun system.
l
Activating, renewing, or checking the status of an existing license.
When you purchase an everRun system, Stratus provides you with a license .key file (via email). Save the license .key file to a location on a computer (not your everRun system) that you can access when you need to upload (and activate) the license to the everRun system.
If you do not yet have a license, or if you need to upgrade or renew a license or support, you must contact everRun Customer Support or your authorized Stratus service representative. See the everRun Support page at http://www.stratus.com/services-support/customer-support .
Your license is automatically activated/renewed each time you upload a license .key file to an everRun system that has Internet connectivity to the Stratus alas.stratus.com
server via port 443 (https).
The everRun system also attempts to activate/renew your license every 24 hours. If your everRun system does not have Internet connectivity, you can manually download an activated .key file to a computer and then upload it to the everRun system.
Follow the procedure below that is appropriate for your needs.
To upload a new license .key file to an everRun system with Internet connectivity
After you have saved a license.key file to a computer, use this procedure to upload the license.key
file to the everRun system. The everRun system must have Internet connectivity.
Page 69 of 483
everRun User's Guide
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. On the Preferences page, click Product License.
3. Click the New License bar to display its options.
4. Under Upload New License Key, click Choose File and navigate to the location of the license .key file on your computer. Select the license .key file and click Open. Then click
Upload to upload the file to the everRun system. The everRun system contacts the Stratus server to activate the license.
To license an everRun system with no Internet connectivity but with a connection to a computer that has Internet connectivity
If your everRun system is not connected to the Internet but has private intranet connectivity to a computer that is connected to the Internet, perform the following steps to download an activated license and then upload it to an everRun system.
1. In the everRun Availability Console, click Preferences in the left-hand navigation panel.
2. On the Preferences page, click Product License.
3. Click the License Check and Activation bar to display its options.
4. Under Step 1, Download Activated License Key, click Activated License to activate and download a license .key file to a computer (not the everRun system).
The Opening av_ number
_A.key dialog box appears. In the dialog box, select Save File and select a location on the computer to save the downloaded .key file. (Depending on the browser, the default location for saving the file may be the Downloads folder.)
5. Under Step 2, Upload Activated License Key, click Choose File and navigate to the license .key file that you saved in the previous step. Then, click Upload to upload it to the everRun system.
To license an everRun system with no Internet connectivity
If your everRun system is not connected to the Internet and has no private intranet connectivity to a computer that is connected to the Internet, perform the following steps to obtain an activated license and then move it to an everRun system.
For this procedure:
Page 70 of 483
Managing the everRun Product License l
You will need a USB flash drive and two computers (A and B) in addition to the everRun system.
l
Computer A has Internet access and has no connection to the everRun system.
l
Computer B has access to the everRun Availability Console on the everRun system but both of these computers are not connected to the Internet.
On Computer B
1. Insert a USB flash drive into a USB port.
2. Log on to the everRun Availability Console.
3. Click Preferences in the left-hand navigation panel.
4. On the Preferences page, click Product License.
5. Click the License Check and Activation bar to display its options.
6. Under Step 1, right click the Activate License link and select your browser's option to copy the link (for example, Copy Link Location or Copy Link Address).
7. Open a text editor (notepad.exe), paste the copied URL in to it, and save the contents of the editor to a text file on the USB flash drive.
8. Remove the USB flash drive.
On Computer A
1. Insert the USB flash drive into a USB port.
2. In a text editor, open the text file on the USB flash drive. Copy the URL in the text editor to the clipboard.
3. Open a web browser and paste the URL into the address bar. Press Enter. A license .key
file will be downloaded.
4. Copy the license .key file to the USB flash drive.
5. Remove the USB flash drive.
On Computer B
1. Insert the USB flash drive into a USB port.
2. Click Preferences in the left-hand navigation panel.
Page 71 of 483
everRun User's Guide
3. On the Preferences page, click Product License.
4. Click the License Check and Activation bar to display its options.
5. Click Choose File, navigate to the license .key file on the USB flash drive, and select it.
Click Open.
6. In the Product License pane, click Upload.
To check the status of a license
Use this procedure to check the status of a license .key file that you have already uploaded on a computer that has Internet connectivity to the Stratus alas.stratus.com
server via port 443
(https).
1. In the everRun Availability Console, click Preferences in the left-hand navigation panel.
2. On the Preferences page, click Product License.
Click the License Check and Activation bar.
3. Click Check License Now. The console displays the status of the license:
STATUS
TYPE OF LICENSE
EXPIRATION
LAST CHECK
ASSET ID
FT Enabled
Split Site Allowed
License is activated and expires in
Enterprise Edition (volume) month dd
, 20 yy
, time month dd , 20 yy , time month dd
, 20 yy
, time true_or_false true_or_false nn days nn hours
If a license activation fails, the License Activation Server (or ALAS) returns a numeric error code. The following drop-down menu lists the error codes.
To view the license activation error codes
If a license activation fails, the License Activation Server (or ALAS) returns one of the following numeric error codes.
2.1: ALAS_UNKNOWN_SITEID
The specified Asset ID key does not exist in the Stratus customer database Atlas. If the license was just created (for example, with trial IDs), the license information might not yet have propagated
Page 72 of 483
Configuring IP Settings to ALAS. Wait 15 minutes and try again. If the activation fails again, contact your authorized
Stratus service representative and provide them with the return code.
3.1: ALAS_INVALID_ARG
The ALAS URL was called without an Asset ID parameter. This error can occur with an improperly formed license key that does not include the Asset ID.
3.2: ALAS_INVALID_SITEID
The Asset ID parameter has been specified but does not contain a value. This error can occur with an improperly formed license key that includes a blank Asset ID.
3.3: ALAS_NO_SIGN
ALAS cannot communicate with the SSL certificate signing server.
3.4: ALAS_NO_ATLAS_UPDATE
ALAS failed to update activation information, OS release number, and/or other information in Atlas.
This error occurs on the ALAS side of the license activation.
3.5: ALAS_NO_MORE_ACTIVATION
The site has exceeded the number of activations allowed (typically 3). If necessary, your authorized Stratus service representative can change the limit.
9.0: ALAS_UNKNOWN
Unknown error.
Related Topics
"The everRun Availability Console" on page 60
"The Preferences Page" on page 65
"Using the everRun Availability Console" on page 59
Configuring IP Settings
Configure Internet Protocol (IP) settings for the everRun system to set or modify the IP address of the system and nodes as well as values for applicable settings such as network mask, gateway address, and
Domain Name System (DNS) server.
During installation and post-installation of everRun software, you configure three IP addresses: one for the everRun system and one for each node. You can change the IP addresses and other IP settings after
Page 73 of 483
everRun User's Guide installation using the appropriate procedure below. You must specify a static IPv4 address for the everRun system.
Warnings:
1. Do not change the IP configuration settings, especially on systems with running VMs, without the advice and knowledge of your network administrator. Doing so could make the system and all its VMs inaccessible.
2. If you change the Static System IP address, any MAC addresses automatically assigned to the VMs will change when the VMs reboot, because the everRun software generates MAC addresses for the VMs based on the system IP address. To prevent changes to the MAC address for a VM (for example, to support software applications that are licensed on a MAC-address basis), set a persistent MAC address as described in
"Assigning a Specific MAC Address to a Virtual Machine" on page 265
.
3. You must use the everRun Availability Console to change IP addresses. Do not use
Linux tools.
Notes:
1. The procedure you use to configure IP settings depends on whether the everRun system stays on the same subnet or moves to a new subnet. For instructions on how to move the system to a new subnet, access the Knowledge Base to search for the article
Moving an everRun System to a Different Subnet (KB-
4264
2. Changing IP settings for a new subnet typically includes changing the node's physical network connections (for example, disconnecting and then re-attaching network cables if moving the PMs). Before you disconnect cables from nodes, you must shut down the nodes.
3. In a single-node system, the IP Configuration page displays settings for only one node.
To change the system and/or node IP settings with the system on same subnet
The everRun system and all virtual machines (VMs) continue to run throughout this procedure; however, the everRun Availability Console briefly loses its connection to the system if you change the system IP address. You can access the everRun Availability Console at the new system IP address within 1-2
Page 74 of 483
Configuring Quorum Servers minutes. (You can change node IP addresses on each node, individually, but the console connection is not lost.)
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. Click IP Configuration.
3. In the Static System IP box, type the static system IP address that you obtained from your network administrator.
4. Click the Static button and type valid, unique values for Primary DNS and Secondary DNS.
5. Verify that the displayed NetMask value is correct.
6. For Node0 and Node1, enter appropriate values for IP Address and Gateway IP.
7. Click Save to save the values (or click Reset to restore previous values).
If you have changed the system IP address, the Portal Restart Required dialog box appears.
Wait about a minute and then click OK. This redirects the browser to the new system IP address.
Related Topics
"Software Installation" on page 34
"Obtaining System IP Information" on page 54
"Logging on to the everRun Availability Console for the First Time" on page 54
"The Preferences Page" on page 65
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
Configuring Quorum Servers
When you log on to the everRun system for the first time, configure quorum servers.
Prerequisite: Before you configure quorum servers, read
and
"Quorum Servers Considerations" on page 32
.
Page 75 of 483
everRun User's Guide
Notes:
1. For a VM to recognize quorum server configuration changes, you must reboot the VM by
shutting it down and then restarting it. See "Shutting Down a Virtual Machine" on page
227 and "Starting a Virtual Machine" on page 227 .
2. Windows Updates on a quorum server can interrupt the server's operation, which affects fault-recovery behavior. On quorum servers, you should schedule Windows
Updates during a maintenance period or disable Windows Updates.
To configure quorum servers
1. Click Preferences in the left-hand navigation panel, to open the Preferences page.
2. Click Quorum Servers.
3. Click Add Quorum Server.
4. In the Add Preferred Quorum Server dialog box, enter the following values (if a preferred quorum server already exists, the Add Alternate Quorum Server dialog box appears): n
DNS or IP Address—Type the fully-qualified DNS host name or IP address for the preferred quorum server.
n
Port (the default value is 4557)—Type the port number if it is different from the default.
Click Save to save the values.
5. Repeat steps 4 and 5 to configure a second, alternate quorum server. Stratus recommends configuring two quorum servers.
6. To enable quorum service, select the Enabled check box and click Save.
To remove a quorum server
Caution: If you remove the preferred quorum server, the alternate quorum server becomes the preferred quorum server. If no alternate quorum server exists, removing the preferred quorum server automatically disables quorum service.
1. Navigate to the Preferences page of the everRun Availability Console.
2. Click Quorum Servers.
Page 76 of 483
Configuring Date and Time
3. Locate the entry for the quorum server you want to remove.
4. In the right-most column, click Remove.
Note: If a VM is using the quorum server that you are removing, you must reboot the VM so that it no longer recognizes the quorum server, which allows the removal process to finish.
Related Topics
"The everRun Availability Console" on page 60
"The Preferences Page" on page 65
"Using the everRun Availability Console" on page 59
Configuring Date and Time
When you log on to the everRun system for the first time, configure the date and time to enable the Network Time Protocol (NTP) service. Using the NTP service automatically sets the system clock and ensures that it does not drift from the actual time.
Caution: When you change the date and time settings, the primary physical machine (PMs) may reboot and the secondary PM may shutdown if system time has drifted from actual time.
All virtual machines (VMs) are stopped and business processing is interrupted until the reboot is complete.
Note: The clock swaps between time zones whenever VMs migrate or restart. To ensure that the time zone in VMs does not change: l
Set the time zone in all VMs to correspond to the time zone configured for the everRun system.
l
Configure all VMs to use the same NTP servers as those configured for the everRun system.
To configure date and time settings
1. Click Preferences in the left-hand navigation panel, to open the Preferences page.
2. On the Preferences page, click Date & Time.
Page 77 of 483
everRun User's Guide
3. In the Date & Time display, the default setting for Configure Time Zone is America, New York.
Select a time zone appropriate for your location, if necessary.
4. Select one of the following for Configure Date and Time: n
Automatically (Recommended) enables NTP service. Type NTP server addresses in the text area, one per line. Specifying multiple NTP servers provides redundancy.
n
Manually allows you to manually enter settings.
Note: If you configure time manually, the everRun system's time may drift from actual time.
5. Click Save (or click Reset to restore the previously-saved values).
If the system requires a reboot because of time drift, a message appears in the everRun Availability Consolemasthead telling you that the system will reboot. In this case, the primary physical machine (PM)
reboots and the secondary PM shuts down. While the primary PM reboots, you lose your connection to the everRun Availability Console. When the reboot is complete, the PM re-establishes a connection to the console and you receive an alert telling you to restart the secondary PM.
Related Topics
"The everRun Availability Console" on page 60
"The Preferences Page" on page 65
"Using the everRun Availability Console" on page 59
Configuring System Resources
Configure system resources to specify how the everRun system manages virtual CPUs (vCPUs) and memory. Use default values; change a value only if your service representative instructs you to.
To configure system resources for the everRun system
1. In the everRun Availability Console, click Preferences in the left-hand navigation panel, to open the Preference page.
2. Click System Resources.
3. Modify the settings only if your service representative instructs you to:
Page 78 of 483
Configuring Active Directory n
System VCPUs, which sets the number of VCPUs reserved for the everRun software. Values are 2 (the default) and 4.
n
System Memory, which sets the amount of memory reserved for the everRun software. Values are 1024 MB, 2048 MB (the default), and 4096 MB.
4. Scroll to the bottom of the System Resources section and click Save (or click Reset to restore the previously-saved values).
Related Topics
"The everRun Availability Console" on page 60
"The Preferences Page" on page 65
"Using the everRun Availability Console" on page 59
Configuring Active Directory
Configure Active Directory for the everRun system to authorize existing users or groups from an Active Directory domain to log on to the everRun Availability Console with their Active Directory credentials.
After you add the everRun system to an Active Directory domain , you can assign administrative privileges to domain users using the Grant Access wizard, which you start from the Users & Groups page (see
"The Users & Groups Page" on page 111
).
To add the everRun system to an Active Directory domain
1. Click Preferences in the left-hand navigation panel, to open the Preferences page.
2. Click Active Directory.
3. Click Enable Active Directory.
4. Next to Active Directory Domain, type the name of the domain to use.
5. Click one of the following to select whether the system will prevent or allow all AD users from being automatically assigned the "everyone" role: n
Prevent all AD users from being automatically assigned the "Everyone" role (the default).
n
Allow all AD users to authenticate and be authorized for "Everyone" role access.
6. Click Add System to Active Directory.
Page 79 of 483
everRun User's Guide
7. Type the Username and Password of an Active Directory Administrator in order to add this ever-
Run system to the domain.
8. Click Add.
9. Assign administrative privileges to domain users on the Users & Groups page, as described in
"Managing Domain User Accounts" on page 113 .
To remove an everRun system from an Active Directory domain
1. In the everRun Availability Console, click Preferences in the left panel, to open the Preferences page.
2. Click Active Directory.
3. Click Remove System from Active Directory.
4. Type a Username and Password that provides you with administrative privileges within the domain.
5. Click Remove.
To disable domain authentication
1. In the everRun Availability Console, click Preferences in the left panel, to open the Preferences page.
2. Click Active Directory.
3. Click Disable Active Directory.
Note: Disabling Active Directory prevents the use of domain authentication for authorizing administrators of the everRun system; however, it does not remove the system from the domain. To restore the use of domain authentication, click Enable Active Directory. You do not need to retype the name of the controller or restore domain users on the Users & Groups page.
Related Topics
"The Users & Groups Page" on page 111
"Managing Domain User Accounts" on page 113
"Managing Local User Accounts" on page 111
"The Preferences Page" on page 65
Page 80 of 483
Configuring the Migration Policy
"The everRun Availability Console" on page 60
Configuring the Migration Policy
By default, VMs automatically load balance when the node they are running on returns to service after recovering from a node failure or exiting maintenance mode. You can disable this automatic load balancing by setting the migration policy.
To set the migration policy
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. On the Preferences page, click Migration Policy.
3. Select Disable automatic load balancing after bringing a node back into service to prevent
VMs from automatically load balancing.
4. Click Save.
After the migration policy is set and a node returns to service, a load-balancing scale ( ) appears in the masthead with the message VMs are not load balanced and a link to
"Load Balancing" on page 149 .
Click the link to rebalance the load.
Related Topics
"Managing Virtual Machines" on page 155
"The Preferences Page" on page 65
"The everRun Availability Console" on page 60
Configuring Secure Connections
For security, you may want the everRun system to allow only HTTPS connections. By default, the system allows HTTPS and HTTP connections.
To enable only HTTPS connections
1. Click Preferences in the left-hand navigation panel, to open the Preferences page.
2. Under Administrative Tools, click Secure Connection.
3. Activate the check box next to Enable HTTPS Only / Disable HTTP.
4. Click Save.
Page 81 of 483
everRun User's Guide
If the system allows only HTTPS connections and you want to allow HTTP connections, you need to deactivate the check box.
To enable HTTP and HTTPS connections
1. Click Preferences in the left-hand navigation panel, to open the Preferences page.
2. Under Administrative Tools, click Secure Connection.
3. Deactivate the check box next to Enable HTTPS Only / Disable HTTP.
4. Click Save.
Related Topics
"The everRun Availability Console" on page 60
"The Preferences Page" on page 65
"Using the everRun Availability Console" on page 59
Configuring the Host Inactivity Logout
For security, an everRun system limits the inactivity time of a login session on a host operating system.
The default timeout is 10 minutes. After 10 minutes (or other specified time) of inactivity, the everRun system automatically logs out the session. A host inactivity logout prevents a login session from remaining open indefinitely without use.
To enable the Host Inactivity Logout and set the timeout
1. Click Preferences in the left-hand navigation panel, to open the Preferences page.
2. On the Preferences page, click Host Inactivity Logout.
3. Activate the check box next to Enable Host Inactivity Logout.
4. The default Host Inactivity Logout timeout is 10 minutes. To specify a different timeout, type a number of minutes next to Timeout Minutes.
Enter minutes in whole numbers. You cannot enter 0.
5. Click Save to save the values (or click Reset to restore previous values).
Related Topics
"The Preferences Page" on page 65
"The everRun Availability Console" on page 60
Page 82 of 483
Disabling and Enabling Snapshots
Disabling and Enabling Snapshots
Snapshots provide an image of a VM at a particular moment in time. By default, the everRun system's ability to take snapshots is enabled. At times, you may want to disable the system's ability to create snapshots, for security reasons. Or, if disabled, you may want to re-enable the system's ability to create snapshots.
To disable the ability to take snapshots
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. On the Preferences page, click Snapshot Configuration.
3. Activate the check box next to Disable Snapshot.
4. Click Save.
If snapshots are disabled and you want to take a snapshot, you need to enable snapshots.
To enable the ability to take snapshots
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. On the Preferences page, click Snapshot Configuration.
3. Deactivate the check box next to Disable Snapshot.
4. Click Save.
Related Topics
"The Snapshots Page" on page 105
"Managing Snapshots" on page 251
"Using the everRun Availability Console" on page 59
Managing IPtables
The administration tool for managing IP packet filtering for the Linux operating system is known as iptables . With everRun systems, the task of working with iptables has been simplified and streamlined.
Using the IPtables Security page, you can set up, maintain, and inspect the various filter table chains and their underlying rules. You have access to the three main chains (INPUT, OUTPUT, and FORWARD) for applying the packet-filtering rules you need. With everRun systems, the rules are applied to each physical machine (PM), to both IPv4 and IPv6 packets, and the rules remain persistent after rebooting.
Page 83 of 483
everRun User's Guide
When you create a rule, you specify a chain (INPUT, OUTPUT, or FORWARD) and a Rule ID. When processing inbound packets, the kernel applies the rules associated with the INPUT chain, and when processing outbound packets, the kernel applies the rules associated with the OUTPUT chain. The kernel applies the rules associated with the FORWARD chain when processing received inbound packets that must be routed to another host. Rules are applied in order of the Rule ID. (A Rule ID is similar to a row ID, where, for example, Rule ID 1 equals row 1.) Instead of creating rules, however, you can load default settings for the rules.
The IPtables Security page displays a separate table for each of the three chains and their associated rules. The rules, if they exist for a particular chain, are sorted by Rule ID. If necessary, use the scroll-bar on the right side of the page to view all of the rules. For more information on iptables functionality, see the
Linux manual (man) pages for iptables.
Notes:
1. For information on the ports that everRun software uses, see "System Requirements
2. For additional information on everRun TCP and UDP ports, access the Knowledge
Base to search for the article TCP and UDP ports used by everRun 7 (KB2123 ). See
"Accessing Knowledge Base Articles" on page 479
.
To manage IPtables, perform the appropriate task below.
To create a new rule
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. On the Preferences page, click IPtables Security.
3. Ensure that the Enable Port Management box has a check mark.
4. Click the Insert New Rule button to open the Insert New Rule pop-up window.
5. In the Insert New Rule pop-up window, set values for the following: n
Chain—Select INPUT, OUTPUT, or FORWARD from the drop-down list.
n
Rule ID—Enter a number that establishes the order for processing the rule. Enter a value, starting with 1 and up to a maximum value that is the total number of rules within the chain. Each Rule ID value must be unique.
Page 84 of 483
Managing IPtables
If you enter a number that is already assigned to a rule, the existing rule is incremented by 1 (as are subsequent rules, if any) and the number you enter is assigned to the new rule. So, if, for example, Rule ID 1 already exists and you enter 1 for the new rule, the existing Rule ID 1 becomes Rule ID 2, the existing Rule ID 2 (if it exists) becomes Rule ID 3, and so on.
n
Shared Network—Select a network from the drop-down list of all available shared networks.
n
Protocol—Select udp, tcp, or all.
Selecting all causes the Grouping and Port Number fields to become inactive
(gray) because setting a range of port numbers is unnecessary.
n
Target—Select drop, accept, or reject for the action you want to apply to the packet that matches the rule's specifications.
n
Grouping—Select one of the following values: o range: If you select this value, both Port Number fields (see below) become active and you must enter values in the fields.
o single: If you select this value, one port number field becomes active, and you must enter a value in it.
o all: Selecting this value causes both Port Number fields to become inactive
(gray). (The value all for Grouping is selected automatically when you select all for Protocol.) n
Port Number (starting)—Enter a number 0 to 65535 for the first port of the range.
n
Port Number (ending)—Enter a number 1 to 65535 that is greater than Port Number
(starting) for the last port of the range.
Click Insert to insert the new rule.
6. Click Save at the bottom of the page, or click Reset to cancel any unsaved changes, which restores rules to those of the last saved session.
After the new rule is saved, the IPtables Security page displays it in the appropriate chain.
To remove a rule
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
Page 85 of 483
everRun User's Guide
2. On the Preferences page, click IPtables Security.
3. Ensure that the Enable Port Management box has a check mark.
4. Select the rule that you want to remove.
5. Click Remove (in the right-most column), for the rule you selected.
6. Click Save at the bottom of the page, or click Reset to cancel any unsaved changes, which restores rules to those of the last saved session.
After the rule is removed, it disappears from the IPtables Security page .
To load default settings
Caution: Loading default settings will override current settings. .
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. On the Preferences page, click IPtables Security.
3. Ensure that the Enable Port Management box has a check mark.
4. Click Load Default Settings at the bottom of the page.
A warning appears:
Current settings will be overridden by the initial settings!
Click OK if you want to load the default settings, or click Cancel to cancel the loading of default settings.
Related Topics
"The Preferences Page" on page 65
"The everRun Availability Console" on page 60
Managing Diagnostic Files
Diagnostic files provide a snapshot of an everRun system's log files and configuration information. This information enables your authorized Stratus service representative to resolve an issue with the system.
When you create diagnostic files, you can choose to include log files from the last 24 hours, the previous seven days, or all available log information and statistics for the everRun system. You can also choose to include only performance statistics.
For additional information, see:
Page 86 of 483
Creating a Diagnostic File l
"Creating a Diagnostic File" on page 87
l
"Deleting a Diagnostic File" on page 88
l
"Uploading a Diagnostic File to Customer Support" on page 88
Related Topics
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
"The Preferences Page" on page 65
Creating a Diagnostic File
Diagnostic files provide a snapshot of an everRun system's log files and configuration information. You create a diagnostic file to help your authorized Stratus service representative resolve issues with the system.
Note: everRun software allocates a fixed amount of storage space for diagnostic files. If sufficient space is not available when you create a diagnostic file, the system will delete previously created files.
To create diagnostic files
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. In the Diagnostics category, click Diagnostics.
3. Select an option from the pulldown menu: n
Minimal diagnostics contain log information for the last 24 hours.
n
Medium diagnostics contain log information for the last 7 days.
n
Full diagnostics contain all available log information with statistics for the everRun system.
4. Click Generate Diagnostic File.
Related Topics
"The everRun Availability Console" on page 60
"The Preferences Page" on page 65
Page 87 of 483
everRun User's Guide
"Using the everRun Availability Console" on page 59
Uploading a Diagnostic File to Customer Support
Upload a diagnostic file to the Stratus everRun Customer Support web site to help resolve an issue with the everRun system. (To create a diagnostic file, see
"Creating a Diagnostic File" on page 87
.)
To upload a diagnostic file to Customer Support
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. In the Diagnostics category, click Diagnostics
3. Do one of the following: n
If the everRun system has Internet connectivity, upload the diagnostic file directly to the
Stratus everRun Customer Support web site by clicking Upload. An Alert appears with the message that the diagnostic was uploaded successfully, if the upload succeeds.
n
If the everRun system does not have Internet connectivity or if the Upload fails, you can manually upload the diagnostic file to the Stratus Diagnostic File Upload web page. First, click Download on the everRun Availability Console to download the diagnostic file as a
.zip file to your local computer. Transfer the diagnostic zip file to a computer with Internet connectivity . Open a web browser, and in its address bar, enter http://diags.stratus.com/DiagUpload.html
. On the Stratus Diagnostic File Upload page, click
Choose File, select the zip file on the computer, and click Submit.
If you need help with this procedure, call everRun Customer Support at the phone number listed on the everRun Support page at http://www.stratus.com/services-support/customer-support .
After you are certain that you no longer need the file (for example, Customer Support confirms that the file
Related Topics
"The everRun Availability Console" on page 60
"The Preferences Page" on page 65
"Using the everRun Availability Console" on page 59
Deleting a Diagnostic File
Page 88 of 483
Configuring e-Alerts
Delete a diagnostic file from the everRun system after you have uploaded it to your authorized Stratus service representative.
To delete a diagnostic file
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. In the Diagnostics category, click Diagnostics.
3. Select the diagnostic file and click Delete.
Related Topics
"The everRun Availability Console" on page 60
"The Preferences Page" on page 65
"Using the everRun Availability Console" on page 59
Configuring e-Alerts
Configure email alerts (e-Alerts) to enable the everRun system to send email to system administrators whenever the system detects an event requiring administrator attention.
To enable e-Alerts
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. Under Notification, click e-Alerts.
3. Click the Enable e-Alerts box. Boxes for specifying or selecting the following settings appear: n
SMTP Server (required)—Enter the name of the Simple Mail Transfer Protocol (SMTP) server that your company uses to send email.
n
Port Number (optional)—Enter the port number to use when sending e-Alerts. If no port number is specified, the default SMTP port 25 will be used. (For additional information on all ports, including the SMTP port, access the Knowledge Base to search for the article TCP
and UDP ports used by everRun 7 (KB-
2123
). See "Accessing Knowledge Base Articles" on page 479 .)
n e-Alerts Language—Select a language from the pull-down menu.
n
Sender's Email Address—Enable e-Alert delivery by specifying a valid sender's email address in either of the following cases:
Page 89 of 483
everRun User's Guide o
You have not specified a DNS server on the everRun system and your SMTP server is not configured to accept domain literals ( From addresses in the form noreply@IP_address
).
o
You want the e-Alert to provide a different sender's email address (for example, [email protected]).
Any email address that the SMTP server accepts is sufficient.
n
Encrypted Connection—Select a value from the pull-down menu for the encryption protocol that the SMTP server requires: o
None for no encryption. By default, port number 25 is used.
o
TLS for the Transport Layer Security (TLS) protocol. For TLS, Stratus recommends that you specify 587 for Port Number, though 25 is used by default.
o
SSL for the Secure Sockets Layer (SSL) protocol. For SSL, Stratus recommends that you specify 465 for Port Number, though 25 is used by default.
n
Enable Authentication—Click this box if the SMTP server requires authentication to send email and type the Username and Password for the SMTP account.
n
List of Recipients (required)—Enter email addresses for all e-Alert recipients.
4. Click Save (or click Reset to restore the previously-saved values).
Note: When you enable or update the e-Alert configuration, generate a test alert to confirm that you receive the alerts.
To generate a test alert
Click Generate Test Alert. The everRun software generates a test alert and sends a sample email with the subject "Test Alert" to all email recipients; SNMP sends traps to recipients of SNMP traps, if configured (see
"Configuring SNMP Settings" on page 91
); and Support Configuration sends a
notification to your authorized Stratus service representative, if configured (see "Configuring
Remote Support Settings" on page 93 ). Watch the Alerts History log (see
"The Alerts Page" on page 96 ) for delivery status.
You can also test e-Alerts by putting the secondary physical machine into maintenance mode (see
"Maintenance Mode" on page 145
), and then removing it from maintenance mode. Verify that you receive e-Alerts for both maintenance mode events.
Page 90 of 483
Configuring SNMP Settings
Related Topics
"The everRun Availability Console" on page 60
"The Preferences Page" on page 65
"Using the everRun Availability Console" on page 59
Configuring SNMP Settings
Configure Simple Network Management Protocol (SNMP) settings for your everRun system to allow
SNMP management applications to remotely monitor your systems. (SNMP information pertains only to systems and not individual PMs.) You can enable SNMP requests and SNMP traps: l
SNMP request—a request sent to the everRun system to retrieve the values of objects listed in the
Management Information Bases (MIBs) supported by the everRun software. These MIBs include an everRun-specific MIB that is a collection of objects describing the everRun system. You can download a copy of the MIB file from the Drivers and Tools section of the Downloads page at http://www.stratus.com/go/support/everrun .
l
SNMP trap—a message initiated by one of the nodes in the everRun system after an event such as an alert that is then sent to an identified list of recipients, typically a network management station
(NMS).
To specify the desired security parameters, you must edit the standard
/etc/snmp/snmpd.conf
file on both nodes. For example, to allow SNMP requests by any user using the default public community, comment out or delete the following lines from that file on each node: com2sec notConfigUser default public group notConfigGroup v1 notConfigUser group notConfigGroup v2c notConfigUser view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1
access notConfigGroup "" any noauth exact systemview none none
After you save the edited files, you must restart the snmpd process on each node by entering the following command: service snmpd restart
Follow the appropriate procedure to enable SNMP requests or traps.
Page 91 of 483
everRun User's Guide
To enable SNMP requests
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. Under Notification, click SNMP Configuration.
3. Activate the check box next to Enable SNMP Requests.
4. Click Save. (Or click Reset to restore the previously-saved values.)
To enable SNMP traps
Note: When you enable or modify the SNMP trap settings, generate a test alert to confirm that traps are received.
1. Click Preferences in the left-hand navigation panel, to open the Preference page.
2. Under Notification, click SNMP Configuration.
3. Activate the check box next to Enable SNMP Traps.
4. Type the name of the SNMP Community, or keep the default (public).
5. Next to List of Recipients for SNMP traps(Version 2c), type the IP address or host name for each SNMP version 2 recipient, one per line.
6. Next to List of Recipients for SNMP traps (Version 1), type the IP address or host name for each SNMP version 1 recipient, one per line.
7. Click Save. (Or click Reset to restore the previously saved values.)
8. Configure your organization's firewall to allow SNMP operations, which enables SNMP management systems to receive alerts from and send traps to the everRun system. To do so, configure your organization's firewall to open the SNMP port:
Message Type: SNMP
Protocol: SNMP
Port: 161 (Get/Walk) 162 (Traps)
9. Generate a test alert by clicking Generate Test Alert.
The everRun software generates a test alert and SNMP sends traps to recipients of SNMP traps; e-Alerts send a sample email with the subject "Test Alert" to all email recipients of e-
Alerts, if configured (see
"Configuring e-Alerts" on page 89 ); and Support Configuration
sends a notification to your authorized Stratus service representative, if configured (see
Page 92 of 483
Configuring Remote Support Settings
"Configuring Remote Support Settings" on page 93
). Watch the Alerts History log (see "The
Alerts Page" on page 96 ) for delivery status.
Related Topics
"The everRun Availability Console" on page 60
"The Preferences Page" on page 65
"Using the everRun Availability Console" on page 59
Configuring Remote Support Settings
When you log on to the everRun system for the first time, configure support configuration settings that enable the everRun system to send support notifications (alerts) to your authorized Stratus service representative when an event requires attention.
To configure support configuration settings
Note: When you enable or modify support configuration settings, generate a test alert to confirm that your authorized Stratus service representative can receive system health messages from your system.
1. Click Preferences in the left-hand navigation panel, to open the Preferences page.
2. Under Remote Support, click Support Configuration.
3. Modify the settings, as appropriate for your system: n
Enable Remote Support Access allows your authorized Stratus service representative to remotely connect to the everRun system for troubleshooting purposes. Note that you can enable and then disable this setting, as needed.
n
Enable Notifications allows the everRun system to send health and status notifications to your authorized Stratus service representative.
o
Enable Support Notifications sends an alert for any event that requires attention.
o
Enable Periodic Reporting sends a daily summary of system information to help improve product and service quality.
4. Click Save (or click Reset to restore the previously saved values).
Page 93 of 483
everRun User's Guide
5. Configure your organization's firewall to allow support messages.
To configure your firewall to allow support messages
Use the following information to configure your organization’s firewall to allow communication with your authorized Stratus service representative:
Message Type: Call-Home and Licensing
Protocol: TCP
Port: 443
Stratus support server address: *.stratus.com
Message Type: Support Diagnostics
Protocol: TCP
Port: 443
Stratus support server address: *.stratus.com
Message Type: Dial-In
Protocol: TCP
Port: 443, Default proxy port: 3128 (You can change the default proxy port number.)
Stratus support server address: *.ecacsupport.com
Message Type: e-Alert
Protocol: SMTP
Port: 25
(For additional information on TCP and UDP ports, access the Knowledge Base to search
for the article TCP and UDP ports used by everRun 7 (KB-
2123
). See "Accessing Knowledge Base Articles" on page 479 .)
To enable SNMP management systems to receive alerts and send traps to the everRun system, configure the firewall for the following:
Message Type: SNMP
Protocol: SNMP
Port: 161(Get/Walk) 162(Traps)
6. Generate a test alert.
To generate a test alert
Click Generate Test Alert. The everRun software generates a test alert and Support
Page 94 of 483
Configuring Internet Proxy Settings
Configuration sends a notification to your authorized Stratus service representative; e-Alerts send a sample email with the subject "Test Alert" to all email recipients of e-Alerts, if configured (see
"Configuring e-Alerts" on page 89 ); and SNMP sends traps to recipients of
SNMP traps, if configured (see
"Configuring SNMP Settings" on page 91 ). Watch the Alerts
History log (see
"The Alerts Page" on page 96 ) for delivery status. A subsequent alert will be
generated if the support notification fails.
Related Topics
"The everRun Availability Console" on page 60
"The Preferences Page" on page 65
"Using the everRun Availability Console" on page 59
Configuring Internet Proxy Settings
Configure proxy settings for the everRun system if your organization requires a proxy server to access the
Internet and you have a service agreement with Stratus or another authorized everRun service representative.
A proxy server provides a secure bridge between the everRun system and the Internet. everRun software uses proxy server information for only outbound HTTP traffic related to support notification messaging and remote support access features.
To configure Internet proxy settings
1. Click Preferences in the left-hand navigation panel, to open the Preferences page.
2. Under Remote Support, click Proxy Configuration.
3. To enable proxy service, click the Enable Proxy box.
4. In the Proxy Server box, type the fully-qualified proxy server host name or IP address.
5. In the Port Number box, type the port number if it is different from the default number (3128).
6. If the proxy server requires authentication, click the Enable Authentication box and type the Username and Password.
7. Click Save (or click Reset to restore the previously-saved values).
Related Topics
"The everRun Availability Console" on page 60
Page 95 of 483
everRun User's Guide
"The Preferences Page" on page 65
"Using the everRun Availability Console" on page 59
The Alerts Page
The Alerts page displays messages about events on the everRun system.
To open the Alerts page, click Alerts in the left-hand navigation panel of the everRun Availability Console.
(To view a log of user activity on the everRun system, see
.)
To view alert information, scroll through the alerts, which are, by default, listed in reverse chronological order. Click an alert to display information about the problem and resolution (if available), and whether Support Notifications, an e-Alert, or an SNMP Trap was sent for this alert.
Note: Support notification alerts, e-Alerts, and SNMP traps are generated only when you enable them in the everRun Availability Console console. For information see: l
"Configuring Remote Support Settings" on page 93
l
"Configuring e-Alerts" on page 89
l
"Configuring SNMP Settings" on page 91
Related Topics
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
The Audits Page
The Audits page displays a log of user activity in the everRun Availability Console. To open this page, click Audits in the left-hand navigation panel. (To display information about events on the everRun system, see
"The Alerts Page" on page 96 .)
To view log information, scroll through the log entries, which are, by default, listed in reverse chronological order. The information includes: l
Time—The date and time of the action.
l
Username—The name of the user that initiated the action.
l
Originating Host—The IP address of the host on which the everRun Availability Console was run-
Page 96 of 483
The Physical Machines Page ning.
l
Action—The action performed in the everRun Availability Console.
Related Topics
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
The Physical Machines Page
The Physical Machines page enables you to manage the physical machines (PMs) in the everRun system. (PMs are also referred to as nodes.) To open this page, click Physical Machines in the left-hand navigation panel.
State, Activity, Name, Model, and # of VMs columns appear immediately under the
PHYSICAL MACHINES heading and masthead. To manage a specific PM, click node0 (primary) or
The bottom pane displays action buttons for and details about the selected node: l
Action buttons: Various action buttons appear, with inactive buttons grayed out, depending upon the state of the selected node. The Work On button ( ) appears initially. To perform most maintenance tasks, click Work On, which places a node into maintenance mode (for information, see
"Maintenance Mode" on page 145
). To learn about additional PM actions available in maintenance mode, see
"Physical Machine Actions" on page 98
or the help topic for the task you want to complete.
l
Detailed information: To view detailed information or statistics about the selected node, click one of the following tabs: n
Summary (in the initial display), which displays the model,overall state, activity, and configuration (memory and logical disks) for the selected node.
n
Description, which displays a window where you can enter information about the node.
n
Storage, which displays the state, logical ID, size, controller an current action (if any) of storage.
n
Network, which displays the state, name, speed, and MAC address of networks.
n
Sensors, which displays the name and current state of sensors.
Page 97 of 483
everRun User's Guide n
Virtual Machines, which displays the state, activity, and name of virtual machines.
n
Details, which displays the manufacturer, model, and serial number of the selected node.
Related Topics
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
Physical Machine Actions
When you select a physical machine (PM), some or all of the following action buttons appear, with inactive buttons grayed out, depending on the PM's state and activity.
Caution: Use the Physical Machines page of the everRun Availability Console when you perform maintenance on a PM. Do not use controls on the computer (for example, the power switch on the PC) because the everRun Availability Console protects the everRun system from most actions that are potentially disruptive.
Commands
Work On
Description
Enters a PM into maintenance mode. VMs running on this PM migrate to the other PM, if it is in service. (Otherwise, you are asked to re-confirm the request and then shut down VMs.) When VMs are migrated or shut down, the PM displays running (in Maintenance). See
"Maintenance Mode" on page 145 .
The following actions are available after clicking the Work On button, when the PM has entered maintenance mode.
Finalize
Removes a PM from the state running (in Maintenance). See "Maintenance
Shutdown
Shuts down a PM. The PM transitions to off (in Maintenance). See "Shutting
Down a Physical Machine" on page 147 .
Reboots the PM. The PM transitions to preparing for reboot (in Main-
Page 98 of 483
Physical Machine States and Activities
Commands
Reboot
Description tenance). See
"Rebooting a Physical Machine" on page 147
.
Remove
Causes the everRun software to delete the PM from the everRun system’s data-
base, so that you can replace the PM or one of its components. See "Replacing
Physical Machines, Motherboards, NICs, or RAID Controllers" on page 276 .
The following actions may be available when a PM has failed or when everRun software has removed a
PM from service and powered it off, due to an excessive failure rate.
Reset Device
Recover
Resets the mean time between failures (MTBF) counter for a PM so it can be
brought back into service. See "Resetting MTBF for a Failed Physical Machine" on page 152 .
Recovers a failed PM. In some cases, the everRun Availability Console displays the state of a failed PM as Unreachable (Syncing/Evacuating…). See
"Recovering a Failed Physical Machine" on page 150 .
Related Topics
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
"The Physical Machines Page" on page 97
Physical Machine States and Activities
The following states and activities apply to physical machines (PMs). Only certain actions are enabled during each state and activity.
Available Commands Description State Activity
Running
Work On PM is running normally.
Evacuating
Finalize
Virtual machines are migrating from this PM to its partner.
Page 99 of 483
everRun User's Guide
Running
Running
Work On
Work On
Powered Off
Work On
Reset Device
PM is predicted to fail.
PM failed.
everRun has powered off the PM because of an excessive failure rate. The PM is left powered off until Reset Device is clicked.
See "Resetting MTBF for a Failed Physical
PM is booting.
PM is rebooting.
Booting
Rebooting
Running
Finalize
Finalize
Finalize
Shutdown
Reboot
Recover
Replace
PM is running in Maintenance Mode. See
"Maintenance Mode" on page 145
.
Related Topics
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
"The Physical Machines Page" on page 97
The Virtual Machines Page
Use the Virtual Machines page to manage the virtual machines (VMs) running on your everRun system.
To open this page, click Virtual Machines in the left-hand navigation panel of the everRun Availability Console.
To manage a specific VM, click the name of a VM in the top pane of the Virtual Machines page. The bottom pane displays controls and information for managing the VM.
Page 100 of 483
Virtual Machine Actions
101 or the help topic for a specific task.
You can use the Virtual Machines page for administrative tasks including: l
Creating, copying, exporting, importing, or restoring VMs, as described in "Creating and Migrating
l
"Opening a Virtual Machine Console Session" on page 229
l
"Reprovisioning Virtual Machine Resources" on page 233
l
l
Controlling the power state of a VM, as described in: n
"Starting a Virtual Machine" on page 227
n
"Shutting Down a Virtual Machine" on page 227
n
"Powering Off a Virtual Machine" on page 228
l
"Removing a Virtual Machine" on page 231
or
"Renaming a Virtual Machine" on page 231
l
Managing advanced tasks or troubleshooting, as summarized in "Advanced Topics (Virtual
l
Viewing information about a VM, including its name, operating system, description, and resources in the tabs of the bottom pane
Related Topics
"Managing Virtual Machines" on page 155
"Using the everRun Availability Console" on page 59
Virtual Machine Actions
When you select a virtual machine (VM), the following action buttons can appear, with inactive buttons grayed out, depending on the VM's state and activity.
Page 101 of 483
everRun User's Guide
Action Description
Launches the Create VM Wizard. See "Creating a New Virtual Machine" on page
Create
Copy
Copies an existing VM on your system to create a new VM or to create a duplicate
VM for troubleshooting. See
"Copying a Virtual Machine" on page 169 .
Import/Restore
The import wizard allows you to import a VM to create a new instance of the VM or restore a VM to create an identical VM with the same hardware IDs provided in the
OVF and VHD files.
Open Virtual Machine Format (OVF) is an open standard for packaging and distributing physical or virtual machine data. The OVF format contains meta-data information about the VM. A Virtual Hard Disk (VHD) is a file that contains the virtual disk information.
The following actions are available for use if the VM is running.
Opens a console for the selected VM. See "Opening a Virtual Machine Console
Console
Creates a VM snapshot that you can export to OVF and VHD files. See
"Managing Snapshots" on page 251 .
Snapshot
Shutdown
Power Off
Shuts down the selected VM. See "Shutting Down a Virtual Machine" on page
Immediately stops processing in the selected VM and destroys its memory state.
Use this only as a last resort, when the VM cannot be successfully shutdown.
See
"Powering Off a Virtual Machine" on page 228 .
Page 102 of 483
Virtual Machine Actions
Action Description
The following actions are available if the VM is shut down or stopped.
Config
Export
Restore
Launches the Reprovision Virtual Machine wizard. The VM must be shut down
prior to launching this wizard. See "Reprovisioning Virtual Machine Resources" on page 233
Saves the image of a VM to a set of OVF and VHD files. You can import these files on another system or import them back to the same everRun system to
restore or duplicate the original VM. See "Exporting a Virtual Machine from an ever-
Recovers an existing VM on your everRun system by overwriting the VM from a
Snapshot
Creates a VM snapshot that you can use to create a new VM or export to OVF and
VHD files. See
"Managing Snapshots" on page 251 .
Boots the selected VM. See
"Starting a Virtual Machine" on page 227
.
Start
Boot From CD
Boots a VM from the selected virtual CD. See "Booting from a Virtual CD" on page
The following action is available if the everRun software has removed the VM from service and powered it off because an excessive failure rate.
Reset Device
Resets the mean time between failures (MTBF) counter for a VM so it can be
brought back into service. See "Resetting MTBF for a Failed Virtual Machine" on page 269 .
When a VM crashes, the everRun software automatically restarts it, unless it has
Page 103 of 483
everRun User's Guide
Action Description fallen below its MTBF threshold. If the VM is below the MTBF threshold, the ever-
Run software leaves it in the crashed state. If necessary, you can click Reset
Device to restart the VM and reset the MTBF counter.
Related Topics
"Managing the Operation of a Virtual Machine" on page 227
"The Virtual Machines Page" on page 100
"Using the everRun Availability Console" on page 59
Virtual Machine States and Activities
A virtual machine (VM) can have the following states and activities, during which only certain actions are enabled.
State Activity Enabled Actions Description installing everRun software is installing the boot volume for a new VM.
stopped booting running
Start
Copy
Config
Export
Snapshot
Boot From CD
Remove
Console
Power Off
Console
Snapshot
VM has been shut down or powered off.
VM is starting.
VM is operating normally on redundant physical machines
Page 104 of 483
The Snapshots Page
State Activity running
Enabled Actions
Shutdown
Power Off
Console
Shutdown
Power Off
Description
VM is operating normally, but is not running on fully redundant resources.
stopping crashed crashed
Power Off
Remove
VM is being shut down in response to the Shutdown action, or shut down because the remaining physical machine is transitioning into maintenance mode.
VM crashed and is restarting. If enabled, e-Alerts and support notification messages are sent.
VM crashed too many times and exceeded its MTBF threshold. The VM is left in a crashed state until Reset
Device is clicked. See "Resetting
MTBF for a Failed Virtual Machine" on page 269 .
Related Topics
"Managing the Operation of a Virtual Machine" on page 227
"The Virtual Machines Page" on page 100
"Using the everRun Availability Console" on page 59
The Snapshots Page
Use the Snapshots page to manage virtual machine (VM) snapshots, which represent an image of a VM at a particular point in time. You can use a snapshot to restore a VM on the everRun system or you can
Page 105 of 483
everRun User's Guide export a snapshot for use in a new VM. To open this page, click Snapshots in the left-hand navigation panel of the everRun Availability Console.
To create a snapshot (on the Virtual Machines page), see
"Creating a Snapshot" on page 252 .
The everRun system's ability to take snapshots is enabled, by default. To disable or to re-enable the system's ability to take snapshots, see
"Disabling and Enabling Snapshots" on page 83 .
To manage an existing snapshot, click the name of a snapshot in the top pane of the Snapshots page.
The bottom pane displays a description of the snapshot.
You can use the Snapshots page for administrative tasks including: l
"Exporting a Snapshot" on page 258
l
"Creating a Virtual Machine from a Snapshot" on page 256
l
"Removing a Snapshot" on page 264
l
Adding a description for each volume, in the Description text box
Related Topics
"Managing Snapshots" on page 251
"Using the everRun Availability Console" on page 59
The Volumes Page
The Volumes page displays information about volumes that are attached to virtual machines (VMs) in the everRun system. To open this page, click Volumes in the left-hand navigation panel of the everRun Availability Console. The Volumes page displays the following columns with information about volumes in the top pane: l
State l
Name l
Disk Synchronization l
Sector Size l
Size l
Bootable l
Storage Group
Page 106 of 483
The Storage Groups Page l
Used By, which displays one of the following: n
A link to a VM when a VM is using the volume.
n
A link to the physical machine (PM) page (node0 or node1) when the volume is root or swap.
n
System for a shared volume (shared.fs) .
n
None when the volume is not a system volume and is not used by a VM.
Click the name of a volume in the top pane of the Volumes page to display additional information about the volume in the bottom pane. You can perform some administrative tasks on volumes from the bottom pane, including: l
Add a description for each volume in the Description text box.
l
Rename a volume (see
"Renaming a Volume on the everRun System" on page 242
).
l
View information about the volume container, including the volumes and snapshots it contains, on the Container tab.
l
Expand a volume container on the Container tab (see "Expanding a Volume Container on the ever-
l
Remove a volume by clicking Remove. Note, though, that the Remove button is grayed out when a VM is using a volume.
You perform other volume management tasks from the virtual machines page. These tasks include: l
"Attaching a Volume to a Virtual Machine" on page 238
l
"Creating a Volume in a Virtual Machine" on page 236
l
"Detaching a Volume from a Virtual Machine" on page 239
l
"Removing a Volume from a Virtual Machine" on page 240
Related Topics
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
The Storage Groups Page
The Storage Groups page displays information about disks in the everRun system. To open this page, click Storage Groups in the left-hand navigation panel of the everRun Availability Console.
Page 107 of 483
everRun User's Guide
You can use the Storage Groups page to view information about a storage group, including the name, sector size, size used, size, and number of volumes. You can also add a description for the storage group using the Description tab in the bottom pane.
To view information about a specific storage group, click the storage group name in the top pane of the
Storage Groups page. The bottom pane displays additional information about the storage group.
Columns in the Summary tab display information about the logical ID, size, sector size, and state of each disk within the group as well as the PM on which the disk runs. To display or hide columns, move the cursor to the right of a column heading, click the down-arrow that appears, and then click Columns, selecting or de-selecting the columns that you want to show or hide.
Caution: The everRun software automatically synchronizes disks on the secondary physical machine (PM) with disks on the primary PM, when, for example, you change disks or when you upgrade or restore PMs. During synchronization of volumes between PMs, a busy icon ( ) appears on System and Volumes in the left-hand navigation panel. Do not remove either PM during synchronization.
For more information about storage and everRun systems, see "everRun Storage Architecture" on page
Related Topics
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
The Networks Page
The Networks page displays information about the shared networks attached to the everRun system. To open this page, click Networks in the left-hand navigation panel of the everRun Availability Console.
You can use the Networks page to view information about a specific network, including its state, type, number of Virtual Machines, and speed. You can also add a description for the network using the Description tab in the bottom pane.
To manage a specific network or simply view information about it, click the network name under Shared
Network in the top pane of the Networks page, or click a port in the network connectivity diagram on the
Summary tab. The bottom pane displays additional information about nodes on the network. Columns in the Summary tab display information about the node's state, physical interface, speed, MAC address,
Page 108 of 483
Fixing a Network Connection slot, and port. To display or hide columns, move the cursor to the right of a column heading, click the down-arrow that appears, and then click Columns, selecting or de-selecting the columns that you want to show or hide.
You can use the Networks page for administrative tasks, including: l
"Connecting Additional Networks" on page 56 .
l
"Fixing a Network Connection" on page 109
.
l
Viewing a list of the physical adapters that compose the network, on the Summary tab.
l
Adding a description for a network, on the Description tab.
l
Viewing a list of virtual machines that use the network, on the Virtual Machines tab.
For additional information on networks, see the following topic: l
"General Network Requirements and Configurations" on page 27
l
"SplitSite Network Requirements" on page 30
Note: The Networks page displays only networks that have physical connectivity on both physical machines. If a network that you expect to see does not appear, check that both network connections are cabled correctly and that their LINK is active.
Related Topics
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
Fixing a Network Connection
The everRun system software monitors and analyzes network connections. If it determines that an existing network connection is not optimal (for example if a 1Gb port is connected to a 10Gb port), and it cannot automatically reconfigure the network, it issues an alert stating that cabled network ports could not be paired automatically. In this case, perform the following procedure to reconfigure network connections so that they are optimal.
To reconfigure non-optimal network connections
1. Place the secondary PM into maintenance mode. See
"Maintenance Mode" on page 145
for details.
2. Open the Networks page in the everRun Availability Console.
Page 109 of 483
everRun User's Guide
3. Click the Fix Network button if it is active (the button is inactive if networks have no problems or no fixable problems). As the everRun system software reconfigures the networks, the connection topology displayed in the diagram on the Networks page will change to show the new optimal configuration.
4. Remove the secondary PM from maintenance mode. See
"Maintenance Mode" on page 145
for details.
The Virtual CDs Page
Use the Virtual CDs page to create virtual CDs (VCDs). Use VCDs to make software installation or recovery media available to the virtual machines on your everRun system. To open this page, click Virtual CDs in the left-hand navigation panel of the everRun Availability Console.
To manage a specific VCD, click the name of a VCD in the top pane of the Virtual CDs page. The bottom pane displays a description of the VCD.
You can use the Virtual CDs page for administrative tasks including: l
"Creating a Virtual CD" on page 246
l
"Removing a Virtual CD" on page 250
l
"Renaming a Virtual CD" on page 250
l
Adding a description for each volume, in the Description text box
To complete other VCD management tasks, see
"Managing Virtual CDs" on page 246
.
Related Topics
"Inserting a Virtual CD" on page 248
"Ejecting a Virtual CD" on page 248
"Using the everRun Availability Console" on page 59
The Upgrade Kits Page
The everRun Upgrade Kits page enables you to upload and manage software kits that you use to upgrade your system to newer versions of everRun. To open the Upgrade Kits page, click Upgrade Kits in the left-hand navigation panel in the everRun Availability Console.
For information about upgrading your everRun software, see
"Upgrading everRun Software" on page 115
.
Related Topics
Page 110 of 483
The Users & Groups Page
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
The Users & Groups Page
Use the Users & Groups page to add, modify, or remove user accounts on, or to grant access for Active
Directory users to manage your everRun system. To open this page, click Users & Groups in the lefthand navigation panel of the everRun Availability Console.
To manage local user accounts
To add a new user, click Add in the right side of the top pane. To modify an existing user, click the name of
To manage domain user accounts
see
"Managing Domain User Accounts" on page 113 .
Note: If you are logged on as administrator to a system that has Active Directory users or groups configured, the Grant Access button will appear in the upper-right corner of the Users
& Groups page. Clicking the Grant Access button launches the Grant Access wizard. The
"Managing Domain User Accounts" on page 113
topic discusses using the Grant Access wizard.
To sort and locate user accounts
If you have a large number of accounts, you can click a column heading to sort the accounts by parameter.
You can sort accounts by Type, Username, Real Name, Email address, or Role.
Related Topics
"Configuring Active Directory" on page 79
"Managing Domain User Accounts" on page 113
"Managing Local User Accounts" on page 111
Managing Local User Accounts
Page 111 of 483
everRun User's Guide
You add, edit, or remove users, specify passwords, and assign user roles to local-user accounts on the
User & Groups page in the everRun Availability Console. (To grant or deny access for established user accounts in an Active Directory domain, see
"Managing Domain User Accounts" on page 113 .)
Local user accounts reside on the everRun system itself, as opposed to a central domain server. You can find local accounts on the Users & Groups page by looking for entries labeled Local User in the Type column.
User roles are: l
Administrator: full system administrator privileges l
Platform Manager: system administrator privileges except for adding, removing, and modifying users l
Read-only: ability to view but not to change system configuration or to install system software
To add a user account
1. In the left-hand navigation panel, select Users & Groups.
2. In the top pane, click Add.
3. In the Role drop-down window, select Administrator, Platform Manager, or Read-only.
4. Provide values for the User Name, Password (and Confirm Password), Email Address, and
Real Name fields. User names and passwords may be from 1 to 64 characters long, and must include no white space.
5. Click Save.
To edit a user account
1. In the left-hand navigation panel, select Users & Groups.
2. Under USERS & GROUPS, select the account you want to edit.
3. In the top pane, click Edit.
4. To change a user’s role, in the Role drop-down window, select Administrator, Platform Manager, or Read-only.
5. Click Save.
To remove a user account
Page 112 of 483
Managing Domain User Accounts
1. Under USERS & GROUPS, select the account to remove.
2. Click Remove.
3. Click Yes in the Confirm dialog box.
Note: You cannot delete the default admin account, although you should change its name and password by editing the account.
Related Topics
"Configuring Active Directory" on page 79
"Managing Domain User Accounts" on page 113
"The Users & Groups Page" on page 111
Managing Domain User Accounts
You can grant Active Directory (AD) domain user accounts access to the everRun Availability Console.
Domain user accounts are managed on a central AD domain server, as opposed to the local everRun system.
After granting access to domain accounts, you can use the Grant Access wizard (on the Users & Groups page) to view, manage, and sort the AD accounts that have access to the system.
Prerequisites: You must add the everRun system to an Active Directory domain before you can manage domain accounts. (See
"Configuring Active Directory" on page 79
.) If Active Directory is not configured, or if the user who is logged onto the interface does not have administrator privileges, the Grant Access button is grayed out on the Users & Groups page.
To grant access to a domain user account
1. In the left-hand navigation panel, select the Users & Groups page.
2. In the upper right-hand corner, click Grant Access.
3. In the everRun - Grant Access Wizard, specify the search range in the Search for menu.
4. Type the name or group for which to search. Partial names and text are allowed.
5. Click Search.
Page 113 of 483
everRun User's Guide
6. Click the green plus sign (+) next to the users or groups you want to add as everRun Availability
Console Global Users or Groups of the system.
7. Use the drop-down menus in the Role column to assign a role to the user or group to which you have just granted access. You can assign the following roles:
Administrator — enables performance of the full range of system administration activities.
Platform Admin — enables Administrator privileges, except for managing user accounts.
Read Only — enables read access but no management functions.
Everyone — enables only limited read access to certain information.
8. Click Finish. The new domain users are displayed in the Grant Access wizard.
To remove access for a domain user account
1. In the left-hand navigation panel, select the Users & Groups page.
2. In the upper right-hand corner, click Grant Access.
3. In the everRun - Grant Access Wizard, click the check box next to users or groups you want to remove.
4. Click Deny Access, then click Finish.
Related Topic
"Configuring Active Directory" on page 79
Page 114 of 483
4
Chapter 4: Upgrading everRun Software
To upgrade everRun software, use one of the following procedures:
Caution: If your system has external storage, you must call Stratus Customer Assistance to perform an upgrade to everRun Release 7.4
.x
.
l
Use an upgrade kit. See
"Upgrading a System Using an Upgrade Kit" on page 115
.
l
Use a DVD. See
"Upgrading a System To Release 7.4.x with a DVD" on page 118 .
Related Topics
"The Upgrade Kits Page" on page 110
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
"Upgrading a System with External Storage from Release 7.3.4 to 7.4.x" on page 286
Upgrading a System Using an Upgrade Kit
This topic describes how to upload an upgrade kit and then use the kit to upgrade everRun software. (If
Caution: Please contact Stratus Support for updated Upgrade instructions.
Page 115 of 483
everRun User's Guide
Prerequisites: l
All PMs and VMs must be in good health before performing an upgrade of everRun software. Before starting an upgrade, examine the everRun Availability Console to verify that there are no alerts indicating PM or VM problems.
l
To verify that your system meets the requirements of the upgrade kit, use the Qualify button as described in the following procedure.
l
Upgrading from Release 7.3.4 to 7.4.
x requires up to 10GiB of additional disk space for the LVM physical volume that is on the boot disk. If you are upgrading a system with
external storage from Release 7.3.4 to Release 7.4.
your system.
Note: Upgrading from Release 7.3.4 to 7.4.
x may take approximately two hours depending on the complexity of your configuration and the number of VMs to be migrated during the upgrade.
You cannot use the everRun Availability Console while the upgrade is in progress, but the ever-
Run Availability Console may display informational or error messages as needed.
To upgrade the system using an upgrade kit
1. In the everRun Availability Console, click Upgrade Kits in the left-hand navigation panel.
2. On the Upgrade Kits page, click the Add a Kit button beneath the masthead, which opens the everRun - Kit Upload Wizard.
3. In the everRun - Kit Upload Wizard dialog box, click Choose File (in Google Chrome) or Browse
(in Firefox or Internet Explorer), and then browse to select a .kit file.
4. After you have selected a .kit file, click Upload or Finish (they perform the same function).The message Uploading file (DO NOT CLOSE WIZARD) appears while the file is uploading. The upload may require up to two minutes for a file stored locally, to ten or more minutes for a file stored over a network.
5. After the upload is complete, the message Kit uploaded successfully. Click OK to close the wizard.
Page 116 of 483
Upgrading a System Using an Upgrade Kit
The Upgrade Kits page now lists the state and version number of the upgrade kit. The Upgrade and Delete buttons also appear with the Add a Kit button.
6. If more than one upgrade kit is loaded, select the one to use.
7. Click Qualify to verify that your system meets the requirements of the upgrade kit. (This step is recommended, but not required.) After a minute or two, a message appears stating whether or not the kit qualified successfully. If the qualification succeeds, continue with the next step.
If the qualification fails, log on to the host operating system of each PM and see the
/var/opt/ft/log/unity_upgrade.log
file to determine the cause. For example, if there is not enough disk space to complete the upgrade, a message will indicate
Insufficient free space and report the amount of space needed. If you need help resolving a qualification issue, search for the qualification error message in the Knowledge Base in the Stratus Customer
Service Portal at https://support.stratus.com.
8. Click Upgrade to upgrade the everRun system.
First, the everRun software upgrades and reboots the secondary PM. The newly upgraded
PM becomes primary, and then the everRun software upgrades and reboots the other PM.
9. After the everRun software upgrade is complete, update the VirtIO drivers in any Windows-based
Note: The everRun software upgrade also upgrades the AVCLI software on the everRun system; however, if you have installed AVCLI on a remote management computer, you must manually upgrade AVCLI to the most recent version on the remote computer. You can obtain AVCLI software from the Drivers and Tools section of the Downloads page at http://www.stratus.com/go/support/everrun . For information about how to manually install AVCLI on a remote computer see
"AVCLI Command Overview" on page 304
.
Related Topics
"The Upgrade Kits Page" on page 110
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
"Upgrading a System with External Storage from Release 7.3.4 to 7.4.x" on page 286
Page 117 of 483
everRun User's Guide
Upgrading a System To Release 7.4.
x with a DVD
You can upgrade a system, with or without external storage, from everRun Release 7.3.4.0 to Release
7.4.
x using a DVD.
Caution: If your system has external storage, you must call Stratus Customer Assistance to perform an upgrade to everRun Release 7.4
.x
.
Prerequisites: l
All PMs and VMs in must be in good health before performing an upgrade of everRun software. Before starting an upgrade, examine the everRun Availability Console to verify that there are no alerts indicating PM or VM problems.
l
Upgrading from Release 7.3.4 to 7.4.
x requires up to 10GiB of additional disk space for the LVM physical volume that is on the boot disk. Before you begin the upgrade, make sure that your system has at least 10GiB of additional disk space.
Note: Upgrading from Release 7.3.4 to 7.4
.x
may take approximately two hours depending on the complexity of your configuration. You cannot use the everRun Availability Console while the upgrade is in progress, but the everRun Availability Console may display informational or error messages as part of the procedure.
The procedure includes shutting down VMs and then sequentially on each node: putting the node in maintenance mode, shutting down the node, powering on the node and using the BIOS setup utility to boot from
DVD and then recover the node. Note that you cannot use the UEFI setup utility to upgrade from a DVD.
For detailed information, access the Knowledge Base (see "Accessing Knowledge Base Articles" on page
(KB4346 ).
Related Topics
"Upgrading everRun Software" on page 115
"The everRun Availability Console" on page 60
"Using the everRun Availability Console" on page 59
"Upgrading a System with External Storage from Release 7.3.4 to 7.4.x" on page 286
Page 118 of 483
5
Chapter 5: Migrating From Avance or everRun MX Systems
If you are migrating from an everRun MX system or an Avance unit to an everRun 7.
x system, and you
want to transfer virtual machines (VMs) from the other system, see "Creating and Migrating Virtual
To learn more about migrating your system-wide configuration to an everRun system, start with one of the following topics, depending on your needs: l
"Planning to Migrate from an everRun MX System" on page 120
(System-to-System Migration)
Use this planning information to consider the system-wide configuration and settings that are affected when you migrate an everRun MX system and its VMs to an everRun 7.
x system.
l
"Converting an everRun MX System to an everRun 7.x System" on page 122
(In-Place Migration)
Use this procedure to perform an in-place migration of an everRun MX system and its VMs to the everRun 7.
x software.
l
"Planning to Migrate from an Avance Unit" on page 129
(System-to-System Migration)
Use this planning information to consider the system-wide configuration and settings that are affected when you migrate an Avance unit and its VMs to an everRun 7.
x system.
l
"Converting an Avance Unit to an everRun 7.x System" on page 132
(In-Place Migration)
Use this procedure to perform an in-place migration of an Avance unit and its VMs to the everRun
7.
x software.
Related Topics
Page 119 of 483
everRun User's Guide
"Software Installation" on page 34
"Post-Installation Tasks" on page 53
"Creating and Migrating Virtual Machines" on page 161
Planning to Migrate from an everRun MX System
If you have an existing everRun MX system, this topic describes some items to consider when migrating to an everRun 7.
x system.
For all systems, see
"Creating and Migrating Virtual Machines" on page 161
for information about migrating your virtual machines (VMs) to the everRun 7.
x system.
Note: For best results, contact your authorized Stratus service representative for assistance in evaluating and performing upgrades from an everRun MX system.
Platform Requirements
Whether you reuse the existing everRun MX hardware or migrate to new hardware, the platform must meet
the minimum system requirements for everRun 7.
x systems, as described in "Physical Machine System
Multi-node XenServer pools are supported by everRun MX, but only two-node configurations are supported for everRun 7.
x systems.
Planned Outage
The considerations in this help topic assume that an outage can be tolerated throughout the migration process. If you have minimum downtime requirements, contact your authorized Stratus service representative for assistance.
Guest Operating System Support
Verify that the Windows guest operating system running in each of the everRun MX virtual machines is supported by the everRun 7.
x software. See
"Compatible Guest Operating Systems" on page 472 .
Also, verify that each Windows guest operating system is supported by the migration process (as described in
"Migrating a Physical Machine or Virtual Machine to an everRun 7.x System" on page 171 ) or
the import process (as described in
"Importing an OVF File from an everRun MX System" on page 183 ).
Network Preparation
Page 120 of 483
Management Network Access
Prepare the platform network and the networking environment to conform to the everRun 7.
x requirements.
See
"General Network Requirements and Configurations" on page 27
.
Management Network Access
The XenServer management network becomes the everRun 7.
x business network. As in everRun MX, the management console (everRun Availability Console) is accessed over this network.
Bonded network interfaces are recommend for the XenServer management network, but they are not supported for the everRun 7.
x management network.
In everRun MX, each node in the XenServer pool has an IPv4 address associated with it. The same is true for an everRun 7.
x system, but a system IP address is also required, and it must be a static address (not
DHCP). This system IP address provides access to the everRun Availability Console; it is failed-over between everRun 7.
x nodes as necessary by the everRun 7.
x software.
Availability Link Networks
The A-Link networks that were in use in everRun MX will continue to be the A-Link networks on the ever-
Run 7.
x system. In everRun MX, the A-Links could have networking interfaces in each node that were not on the same subnet, but this is not possible on an everRun 7.
x system. For each of the two possible A-
Links, the network interfaces associated with them in each node must exist in the same local network, because IPv6 link local addresses are used to identify them.
Two 10-Gb networks are recommended for the A-Links.
It is not required that the A-Link connections be point-to-point (that is, they can be on a switched network).
Private Network
The everRun private network must be identified. Only one everRun 7.
x system can be installed and operational on the private network at any one time, so it is recommended that the private network be a point-topoint connection between the two everRun 7.
x nodes.
On the everRun 7.
x system, it is typical to share one of the A-Links for the private network when at least one of the A-Link networks is connected point-to-point.
A 10-Gb network is recommended for the private network.
Business Networks
Page 121 of 483
everRun User's Guide
All networks that are not the private network or an A-Link network can also be business networks (that is, networks available for use by the VMs). The management network can be used simultaneously as a business network.
Storage Considerations everRun MX supported redundant-path storage, but this is not supported on an everRun 7.x system.
For physical storage requirements, see
"Storage Requirements" on page 25 .
Quorum Support
Prior to everRun MX 6.2, the quorum servers could be available only over the A-Links. As of everRun MX
6.2, the quorum servers could be available over any network in the XenServer pool. On everRun 7.
x systems, the quorum servers must be available over the business network, which is configured with an IPv4 address and required for quorum.
The Preferred Quorum Server should be configured as the first Quorum Server and the Alternate Quorum
Server should be configured as the second Quorum Server in the everRun Availability Console.
Installing everRun
After the nodes in the everRun 7.
x system are configured, you can install and configure the everRun 7.
x software, as described in
"Software Installation" on page 34 .
Migrating Virtual Machines
Using either the P2V client migration process or the OVF import process, migrate the VMs to the everRun
7.
x system. For an overview of each process, see
"Creating and Migrating Virtual Machines" on page 161 .
Converting an everRun MX System to an everRun 7.
x
System
Convert an everRun MX system to an everRun 7.
x system to perform an in-place migration of the everRun
MX system and its virtual machines (VMs) to the everRun 7.
x software.
To convert an everRun MX system, shut down one physical machine (PM) or node in the everRun
MX system and install the everRun 7.
x software on that node. Use the P2V client to transfer each VM from the everRun MX node to the everRun 7.
x node over the network. Then, install the everRun 7.
x software on the remaining node.
Page 122 of 483
Converting an everRun MX System to an everRun 7.x System
Caution: Consider backing up the everRun MX system and its VMs and recording its settings before the conversion. Converting an everRun MX system to an everRun 7.
x system ultimately overwrites everything on your everRun MX system (after you migrate your VMs to the everRun
7.
x node).
Notes: l
For best results, contact your authorized Stratus service representative for assistance in evaluating and performing upgrades from an everRun MX system.
l
Before converting an everRun MX system to an everRun 7.
x system, verify that your
To prepare for converting an everRun MX system
1. Plan for converting your everRun MX system by reviewing the information: n
"Planning to Migrate from an everRun MX System" on page 120
Describes some items to consider when migrating or converting from an everRun MX system to an everRun 7.
x system.
n
"Software Installation" on page 34
Summarizes the steps for installing the everRun 7.
x software.
n
"Migrating a Physical Machine or Virtual Machine to an everRun 7.x System" on page
Describes how to use the P2V client to migrate a VM from one system to another.
Also describes some steps you may need to complete in your guest operating systems before migrating the VMs to ensure that the VMs will function properly on the everRun 7.
x system.
2. Back up your everRun MX system and VMs.
3. Download the everRun 7.
x ISO file from the Downloads page at http://www.stratus.com/go/support/everrun .
Page 123 of 483
everRun User's Guide a. On the Downloads page, click everRun (if it is not already displayed) and select the appropriate version.
b. Scroll down to Product Downloads, and under Install, click the link to the appropriate ISO image (everRun_install-7.
x
.
x
.
x
xxx
.iso).
c. Save the ISO image
4. Download the P2V client ISO file from the same Downloads page.
a. On the Downloads page, click everRun (if it is not already displayed) and then select the appropriate version.
b. Scroll down to the Drivers and Tools bar and then continue scrolling to everRun
P2V Client for Virtual or Physical Machine Migration.
c. Select the P2V Client (virt-p2v) file.
d. Save the file.
5. Burn the everRun 7.
x ISO file to a physical DVD that you will use to install the everRun 7.
x software on each PM in your system.
6. Burn the P2V client ISO file to a physical CD that you will boot in each everRun MX VM to transfer the VMs to the everRun 7.
x system.
7. Contact your network administrator to request at least one static IP address to use as the system-wide IP address for your converted everRun 7.
x system. Request an additional static IP address for each of the two nodes if you do not have a DHCP server to automatically assign these addresses or if you prefer to use only static addresses.
Note: You must maintain unique system IP addresses for the everRun MX system and the everRun 7.
x system while both systems are online; however, if you want to re-use the original everRun MX system IP address for the everRun 7.
x system, you can change the network settings of the everRun 7.
x system after the conversion is complete.
To shut down the master server of the everRun MX system
Starting with both nodes running the everRun MX software, do the following:
Page 124 of 483
Converting an everRun MX System to an everRun 7.x System
1. Log on to the everRun Availability Center with the hostname or IP address of your ever-
Run MX master node at: http:// everRunMX-address :8080
2. On left-hand navigation panel, click the Hosts tab.
3. Right-click the master server and select Shutdown.
4. Allow the server to evacuate the VMs and properly shut down. You can watch its progress on the everRun Log tab.
When the server is shut down, a message describes that you have lost connection to the everRun Availability Center. This is expected.
5. Open Citrix XenCenter and connect to remaining server of the everRun MX system, which is now the master server.
6. Make sure the VMs are still running on the remaining server before continuing.
To convert the first node of the everRun MX system to an everRun 7.
x node
Caution: Converting a node to the everRun 7.
x software erases all hard drives in that node.
Starting one node shut down and the second node running the everRun MX software, do the following:
1. Insert the everRun 7.
x DVD into the physical DVD drive of the offline node and boot the node to start the installation program.
2. Follow the instructions in
"Installing Software on the First PM" on page 45
to install the ever-
Run 7.
x software on the first node. Power on the node, update the necessary settings in the firmware (BIOS or UEFI) setup utility, and boot the node from the everRun 7.
x
DVD to run the installation program.
When configuring the management network, select a DHCP-assigned address for now and record the IP address as described in
"Recording the Management IP Address" on page 50 .
(You can optionally specify a static IP address for each node later, after converting the second node.)
Page 125 of 483
everRun User's Guide
Caution: Do not convert the remaining node of the everRun MX system at this point; otherwise, all everRun MX data and VMs will be lost.
3. When you finish installing the everRun 7.
x software on the first node, verify that you can connect to the everRun Availability Console at the IP address of the newly-installed node.
When prompted for the initial configuration settings, type the static IP address you obtained from your network administrator as the System IP address. Also, if you want to fully enable the features of your everRun 7.
x system for testing, upload and activate your product license on the LICENSE INFORMATION page.
Notes: n
When specifying the System IP address, type the system-wide IP address of the everRun system, and not the node0 or node1 address.
n
If you want to verify that your VMs work on the first node before you install the everRun 7.
x software on the remaining node, activate your product license now. You can use the P2V client to migrate your VMs to the ever-
Run 7.
x system without a product license, but you cannot start and test your VMs on the everRun 7.
x system unless you activate a valid license.
To migrate VMs from the everRun MX node to the everRun 7.
x node
With the first node running the everRun 7.
x software and the second node running the everRun MX software, do the following:
In some cases, you need to perform steps in the guest operating system before migrating a
VM to ensure that the VM will function properly on the everRun 7.
x system.
2. Log on to the everRun Availability Center on the remaining node of the everRun MX
Page 126 of 483
Converting an everRun MX System to an everRun 7.x System system at: http:// everRunMX-system :8080
3. In the left-hand navigation panel, click Virtual Machines.
4. Right-click a VM that you want to migrate and click Unprotect.
5. When the VM is unprotected and automatically shut down, go back to XenCenter.
6. In the left-hand navigation panel of XenCenter, locate and expand the entry for the everRun
MX system. Click the VM, and click Start.
7. After the VM starts, click the Console tab and click Click here to create a DVD Drive.
Shut down the VM to save the change.
8. Insert the P2V client CD into the DVD drive of the remaining everRun MX node.
9. In the Console tab, next to DVD drive n
, select the physical P2V client CD in the drop down menu. Click Start to begin booting the VM from the P2V client CD.
11. After the migration completes, power off the VM and close the VM console window.
12. In the everRun Availability Console connected to the everRun 7.
x node, verify that the VM appears on the Virtual Machines page.
13. Start the migrated VM and verify that it is functioning properly. Follow the instructions in
"Migrating a Physical Machine or Virtual Machine to an everRun 7.x System" on page 171
to complete any migration steps in the VM. For example, you may need to install drivers or disable certain services.
Caution: The original VM on the everRun MX system must remain shut down when you use the VM on the everRun 7.
x system; otherwise, the VMs will have network and software licensing conflicts.
Note: You can start a VM on the everRun 7.
x system only if you have activated your product license. Upload and activate your license as described in
"Managing the everRun Product License" on page 69
.
Page 127 of 483
everRun User's Guide
n
"Configuring Windows-based Virtual Machines" on page 217
n
"Configuring Linux-based Virtual Machines" on page 224
15. Follow steps 1-14 to migrate additional VMs.
16. Verify that all of your VMs are functioning properly, and that you have recorded any additional settings that you need from the remaining everRun MX server, which you will overwrite in the next procedure.
To complete the conversion to the everRun 7.
x software
Caution: Converting a node to the everRun 7.
x software erases all hard drives in that node. After you convert the second node, you cannot recover the original VMs except by restoring from exports or third-party backups.
1. Shut down the remaining node of the everRun MX system.
2. Follow the instructions in
"Installing Software on the Second PM" on page 51
to install the everRun 7.
x software on the remaining node. Power on the node, update the necessary settings in the firmware (BIOS or UEFI) setup utility, and boot the node from the everRun 7.
x
DVD to run the installation program.
When configuring the management network, select a DHCP-assigned address for now.
(You can specify a static IP address after the software installation.)
3. When the installation finishes, connect to the everRun Availability Console at the system IP address of the everRun 7.
x system.
4. On the Physical Machines page, wait until both PMs reach the running state, and then
assign logical disks to storage groups on the everRun 7.
x system, as described in "Assigning a Logical Disk to a Storage Group" on page 144 .
Page 128 of 483
Planning to Migrate from an Avance Unit
Notes: n
When the second PM joins the everRun system, the system automatically adds the secondary everRun system disk to the Initial Storage
Group; however, the system does not assign any other logical disks from the second PM to existing storage groups.
n
If you assigned logical disks to the Initial Storage Group or other storage groups on the first PM, you must manually add matching logical disks from the second PM to the same storage groups; otherwise, the everRun system cannot fully synchronize.
5. Verify that both PMs reach the running state and that the PMs finish synchronizing. The initial synchronization may take minutes or hours depending on your configuration, including the amount of storage and the number of VMs.
6. Optionally, update the network settings for the everRun 7.
x system: n
If you want to reuse the static IP address of the everRun MX system as the system
IP address of the everRun 7.
x system, open the Preferences page and click IP Configuration. On the System IP tab, enter the static IP settings that were used by the everRun MX system and click Save.
n
If you want to specify a static IP address for each node, click each Node n IP tab, enter the new settings, and click Save.
If necessary, the everRun Availability Console reloads to reflect the new addresses.
7. Configure the everRun 7.
x settings summarized in
"Post-Installation Tasks" on page 53
.
Troubleshooting
If necessary, use the following information to resolve problems with the export or import process.
To resolve network connectivity problems with the everRun 7.
x system
If you have trouble connecting to the everRun Availability Console after installing the first node, you may have used the same IP address for node0 and for the system IP address of the everRun 7.
x system To correct the problem, reinstall the everRun 7.
x software on node0 and ensure that the IP addresses you type for node0 and the system IP address are unique.
Planning to Migrate from an Avance Unit
Page 129 of 483
everRun User's Guide
If you have an existing Avance unit, this topic describes some items to consider when migrating to an ever-
Run 7.
x system.
For all systems, see
"Creating and Migrating Virtual Machines" on page 161
for information about migrating your virtual machines (VMs) to the everRun 7.
x system.
Note: For best results, contact your authorized Stratus service representative for assistance in evaluating and performing upgrades from an Avance unit.
Platform Requirements
Whether you reuse the existing Avance hardware or migrate to new hardware, the platform must meet the
Planned Outage
The considerations in this help topic assume that an outage can be tolerated throughout the migration process. If you have minimum downtime requirements, contact your authorized Stratus service representative for assistance.
Guest Operating System Support
Verify that the Windows or Linux guest operating system running in each of the Avance VMs is supported by the everRun software. See
"Compatible Guest Operating Systems" on page 472
.
Also, verify that each guest operating system is supported by the migration process (as described in
process (as described in
"Importing an OVF File from an everRun MX System" on page 183
).
Network Preparation
Prepare the platform network and the networking environment to conform to the everRun system requirements. See
"General Network Requirements and Configurations" on page 27 .
Management Network Access
The same network that was used to access the Avance Management Console will be used for the ever-
Run Availability Console.
Page 130 of 483
Availability Link Networks
In Avance, the nodes were available on the management network for management only through the IPv4 system address, which could be failed-over to either node in the system. The everRun software uses the same system address, but it also requires separate IPv4 addresses for each node in the same subnet as the system IP address.
Availability Link Networks
Avance had no Availability Links; therefore, these networks must be added to the hardware configuration.
Two 10-Gb networks are recommended for the A-Links.
It is not required that the A-Link connections be point-to-point (that is, they can be on a switched network).
Private Network
The same network used as the private network on the Avance unit can be used for the private network on the everRun system.
Only one everRun system can be installed and operational on the private network at any one time, so it is recommended that the private network be a point-to-point connection between the two everRun nodes.
It is typical to share one of the A-Links for the private network when at least one of the A-Link networks is connected point-to-point.
A 10-Gb network is recommended for the private network.
Business Networks
All networks that are not the private network or an A-Link network can also be business networks (that is, networks available for use by the VMs). The management network can be used simultaneously with the business network.
Storage Considerations
Avance unit storage can be used as-is in the everRun system. For physical storage requirements, see
"Storage Requirements" on page 25 .
Installing everRun
After the nodes in the everRun system are configured, you can install and configure the everRun software, as described in
"Software Installation" on page 34 .
Migrating Virtual Machines
Page 131 of 483
everRun User's Guide
Using either the P2V client migration process or the OVF import process, migrate the VMs to the everRun system. For an overview of each process, see
"Creating and Migrating Virtual Machines" on page 161
.
Converting an Avance Unit to an everRun 7.
x System
Convert an Avance unit to an everRun system to perform an in-place migration of the Avance unit and its virtual machines (VMs) to the everRun 7.
x software.
To convert an Avance unit, shut down one physical machine (PM) or node in the Avance unit and install the everRun software on that node. Use the P2V client to transfer each VM from the Avance node to the everRun node over the network. Then, install the everRun software on the remaining node.
Caution: Consider backing up the Avance unit and its VMs and recording its settings before the conversion. Converting an Avance unit to an everRun system ultimately overwrites everything on your Avance unit (after you migrate your VMs to the everRun node).
Notes: l
For best results, contact your authorized Stratus service representative for assistance in evaluating and performing upgrades from an Avance unit.
l
Before converting an Avance system to an everRun system, verify that your PMs and
VMs are supported as described in "Physical Machine System Requirements" on page
473 and "Compatible Guest Operating Systems" on page 472 .
To prepare for converting an Avance unit
1. Plan for converting your Avance unit by reviewing the following information: n
"Planning to Migrate from an Avance Unit" on page 129
Describes some items to consider when migrating or converting from an Avance unit to an everRun system.
n
"Software Installation" on page 34
Summarizes the steps for installing the everRun software.
n
"Migrating a Physical Machine or Virtual Machine to an everRun 7.x System" on page
Page 132 of 483
Converting an Avance Unit to an everRun 7.x System
Describes how to use the P2V client to migrate a VM from one system to another.
Also describes some steps you may need to complete in your guest operating systems before migrating the VMs to ensure that the VMs will function properly on the everRun system.
2. Back up your Avance unit and VMs.
3. Download the everRun ISO file from the Downloads page at http://www.stratus.com/go/support/everrun .
4. Download the P2V client ISO file from the Drivers and Tools section of the same support page.
5. Burn the everRun ISO file to a physical DVD that you will use to install the everRun software on each PM in your system.
6. In the Avance Management Console, use the P2V client ISO file to create a VCD that you will boot in each Avance VM to transfer the VMs to the everRun system.
7. Contact your network administrator to request at least one static IP address to use as the system-wide IP address for your converted everRun system. Request an additional static
IP address for each of the two nodes if you do not have a DHCP server to automatically assign these addresses or if you prefer to use only static addresses.
Note: You must maintain unique system IP addresses for the Avance unit and the everRun system while both systems are online; however, if you want to reuse the original Avance unit IP address for the everRun system, you can change the network settings of the everRun system after the conversion is complete.
To convert node0 of the Avance unit to an everRun node
Caution: Converting a node to the everRun software erases all hard drives in that node.
Starting with both nodes running the Avance software, do the following:
1. In Avance Management Console, verify that your Avance unit is running properly and that both PMs are online.
2. Enable maintenance mode on node0 of the Avance unit.
Page 133 of 483
everRun User's Guide
Note: Start with node0 of the Avance unit for consistency, because this first node that you convert will become node0 of the everRun system.
3. Verify that the VMs migrate from node0 to node1.
4. Shut down node0.
5. Follow the instructions in
"Installing Software on the First PM" on page 45
to install the ever-
Run software on node0. Power on the node, update the necessary settings in the firmware
(BIOS or UEFI) setup utility, and boot the node from the everRun DVD to run the installation program.
When configuring the management network, select a DHCP-assigned address for now and record the IP address as described in
"Recording the Management IP Address" on page 50 .
(You can optionally specify a static IP address for each node later, after converting the second node.)
Caution: Do not convert the remaining node of the Avance unit at this point; otherwise, all Avance data and VMs will be lost.
6. When you finish installing the everRun software on node0, verify that you can connect to the everRun Availability Console at the IP address of the newly-installed node.
7. Log on to the everRun Availability Console on node0 as described in "Logging on to the ever-
Run Availability Console for the First Time" on page 54 .
When prompted for the initial configuration settings, type the static IP address you obtained from your network administrator as the System IP address. Also, if you want to fully enable the features of your everRun system for testing, upload and activate your product license on the LICENSE INFORMATION page.
Page 134 of 483
Converting an Avance Unit to an everRun 7.x System
Notes: n
When specifying the System IP address, type the system-wide IP address, and not the node0 or node1 address.
n
If you want to verify that your VMs work on node0 before you install the everRun software on the remaining node, activate your product license now. You can use the P2V client to migrate your VMs to the everRun system without a product license, but you cannot start and test your VMs on the everRun system unless you activate a valid license.
To migrate VMs from the Avance node to the everRun node
With node0 running the everRun software and node1 running the Avance software, do the following:
In some cases, you need to perform steps in the guest operating system before migrating a
VM to ensure that the VM will function properly on the everRun system.
2. In the Avance Management Console, shut down a VM that you want to migrate.
4. After the migration completes, power off the VM and close the VM console window.
5. In the everRun Availability Console connected to the everRun node, verify that the VM appears on the Virtual Machines page.
6. Start the migrated VM and verify that it is functioning properly. Follow the instructions in
"Migrating a Physical Machine or Virtual Machine to an everRun 7.x System" on page 171
to complete any migration steps in the VM. For example, you may need to install drivers or disable certain services.
Page 135 of 483
everRun User's Guide
Caution: The original VM on the Avance system must remain shut down when you use the VM on the everRun system; otherwise, the VMs will have network and software licensing conflicts.
Note: You can start a VM on the everRun system only if you have activated your
n
"Configuring Windows-based Virtual Machines" on page 217
n
"Configuring Linux-based Virtual Machines" on page 224
8. Follow steps 1-7 to migrate additional VMs.
9. Verify that all of your VMs are functioning properly, and that you have recorded any additional settings you that need from the remaining Avance node (node1), which you will overwrite in the next procedure.
To complete the conversion to the everRun software
Caution: Converting a node to the everRun software erases all hard drives in that node.
After you convert the second node, you cannot recover the original VMs except by restoring from exports or third-party backups.
1. Shut down the Avance unit to power off the remaining Avance node (node1). In the Avance
Management Console, on the Unit page, click Shutdown .
2. Follow the instructions in
"Installing Software on the Second PM" on page 51
to install the everRun software on node1. Power on the node, update the necessary settings in the firmware (BIOS or UEFI) setup utility, and boot the node from the everRun DVD to run the installation program.
When configuring the management network, select a DHCP-assigned address for now.
(You can specify a static IP address after the software installation.)
Page 136 of 483
Converting an Avance Unit to an everRun 7.x System
3. When the installation finishes, connect to the everRun Availability Console at the system IP address of the everRun system.
4. On the Physical Machines page, wait until both PMs reach the running state, and then
assign logical disks to storage groups on the everRun 7.
x system, as described in "Assigning a Logical Disk to a Storage Group" on page 144 .
Notes: n
When the second PM joins the everRun system, the system automatically adds the secondary everRun system disk to the Initial Storage
Group; however, the system does not assign any other logical disks from the second PM to existing storage groups.
n
If you assigned logical disks to the Initial Storage Group or other storage groups on the first PM, you must manually add matching logical disks from the second PM to the same storage groups; otherwise, the everRun system cannot fully synchronize.
5. Verify that both PMs reach the running state and that the PMs finish synchronizing. The initial synchronization may take minutes or hours depending on your configuration, including the amount of storage and the number of VMs.
6. Optionally, update the network settings for the everRun system: n
If you want to reuse the static IP address of the Avance unit as the system IP address of the everRun system, open the Preferences page and click IP Configuration. On the System IP tab, enter the static IP settings that were used by the
Avance unit and click Save.
n
If you want to specify a static IP address for each node, click each Node n IP tab, enter the new settings, and click Save.
If necessary, the everRun Availability Console reloads to reflect the new addresses.
7. Configure the everRun settings summarized in
"Post-Installation Tasks" on page 53 .
Troubleshooting
If necessary, use the following information to resolve problems with the export or import process.
To resolve network connectivity problems with the everRun system
Page 137 of 483
everRun User's Guide
If you have trouble connecting to the everRun Availability Console, especially after installing the first node (node0), you may have used the same IP address for node0 and for the system IP address. To correct the problem, reinstall the everRun software on node0 and ensure that the IP addresses you type for node0 and the system IP address are unique.
Page 138 of 483
6
Chapter 6: Managing Logical Disks
Management" on page 139 as well as "Logical Disks and Physical Disks" on page 15 .
To perform tasks, see the following: l
"Responding to a Failed Logical Disk" on page 140
l
"Activating a New Logical Disk" on page 142
l
"Creating a New Storage Group" on page 143
l
"Deleting a Storage Group" on page 143
l
"Assigning a Logical Disk to a Storage Group" on page 144
For information on working with external storage, see
"Managing External Storage " on page 281
.
Logical Disk Management
In an everRun system, use the everRun Availability Console to manage logical disks by activating a new logical disk and responding to a failed logical disk.
In some cases, you need to activate a new logical disk even though the everRun software automatically recognizes new logical disks that the RAID controller presents to the operating system. For information, see
"Activating a New Logical Disk" on page 142
.
You need to respond to alerts regarding missing or failed logical disks. everRun software may detect a logical disk failure when a physical disk is removed or fails. The everRun software then generates an alert that appears on the DASHBOARD. The following alerts are examples:
Page 139 of 483
everRun User's Guide l
System has missing or failed Logical Disks.
l
Logical Disk - 1 on PM node1 has failed.
On the Physical Machines page of the everRun Availability Console, the Storage tab for each
When a logical disk has failed, system storage is frozen. You cannot allocate new volumes until you have responded to the alert. Your response might require using the RAID controller BIOS or the Repair button on the masthead. For information, see
"Responding to a Failed Logical Disk" on page 140
Related Topics
"Logical Disks and Physical Disks" on page 15
"The everRun Availability Console" on page 60
Responding to a Failed Logical Disk
When everRun software detects a missing or broken logical disk, it displays a failed logical disk alert on
the DASHBOARD page of the everRun Availability Console. (For examples of alerts, see "Logical Disk
Management" on page 139 .) You can also view the alert on the ALERT HISTORY page. The everRun
Availability Console continues to display the alert until you respond to the problem using one of the following methods, as appropriate for your situation: l
If a physical disk has been pulled, reinsert the appropriate physical disk. In this case, the physical machine restores the disk and you may need to use RAID controller software to complete the logical disk restoration.
l
If a logical disk is broken or missing, you can attempt to use RAID controller software to recover it.
If you are able to use RAID controller software to restore the logical disk to service, the everRun software will detect the restored logical disk and start using its data l
If a logical disk is broken or missing, and you cannot recover the logical disk using RAID controller software (for example, a failed physical disk needs to be replaced), click the Repair button in the masthead to complete the repair. After clicking the Repair button, the everRun software: n
Dismisses the alert.
n
Evacuates all failed logical disks.
Page 140 of 483
Responding to a Failed Logical Disk n
Removes all failed logical disks from their storage groups.
n
Attempts to repair any volumes that had been using the failed logical disks.
Caution:
1. Clicking the Repair button removes all data on failed logical disks.
2. Repairing storage causes virtual machines (VMs) that are using failed logical disks to become simplex until repair is complete.
3. Systems configured for UEFI will only boot from the logical disk that the everRun software was originally installed on.
4. In some legacy BIOS configurations, if you need to repair a logical disk that is the boot disk, you may need to reconfigure the RAID controller to boot from one of the remaining logical disks. Any logical disk that is not affected by the failed disk is able to boot the server. The everRun software mirrors the boot files for each node, in order to maximize overall availability. However, some systems may be able to boot from only the predefined boot logical disk in the RAID controller, and may be unable to boot from an alternate logical disk, if the predefined boot logical disk is present but not bootable. After the node has recovered and the logical disk with the replacement drive has been brought up to date, you should restore the boot device to the original value in the RAID controller.
To repair a failed logical disk
1. Click the Repair button that appears in the masthead of the everRun Availability Console.
2. Click Yes in the Confirm message box if you want to continue with the repair.
After you click the Repair button, the everRun software attempts to repair all broken volumes by migrating data to other logical disks. When other logical disks have enough space for the data, the everRun software can successfully complete the repair. When other logical disks do not have enough space for the data, the everRun software generates the alert Not enough space for repair. In this case, you need to add more storage to the storage group by creating new logical disks or by deleting some existing volumes.
When enough space for the data exists, the everRun software automatically re-mirrors broken volumes.
Page 141 of 483
everRun User's Guide
After the repair is complete, use RAID controller software to remove the failed logical disk and to create a new logical disk. everRun software automatically recognizes the new logical disk and brings it into service if the disk does not contain data. If the disk contains data, the DASHBOARD displays the message
Logical Disk – n on PM node n is foreign and should be activated or removed. To activate the logical disk, see
"Activating a New Logical Disk" on page 142 .
Related Topics
"Logical Disks and Physical Disks" on page 15
"The everRun Availability Console" on page 60
Activating a New Logical Disk
In an everRun system, the RAID controller creates logical disks from the system’s physical disks. The everRun software is able to access logical disks that the RAID controller presents to the operating system. When the everRun software recognizes a new logical disk, it performs one of the following actions: l
If the logical disk does not contain data, the everRun software brings the logical disk into service.
l
If it is a known logical disk that was not evacuated, the everRun software starts using the logical disk and its data.
l
If the disk contains unknown data, the DASHBOARD displays the message Logical Disk – n on
PM node n is foreign and should be activated or removed. In this case, you can activate or remove the disk now, or you can do nothing now, but later activate or remove the disk.
Caution: Activating the logical disk causes all data on the disk to be lost.
To activate a new logical disk
1. Click Physical Machines in the left-hand navigation panel.
2. On the Physical Machines page, select either node0 or node1 in the top pane.
3. On the Physical Machines page, click the Storage tab in the bottom pane.
4. In the Action column, click the Activate Foreign button to activate the corresponding logical disk.
5. When the Confirm message box appears, click Yes to confirm activating the logical disk. Activating the logical disk causes all data on the disk to be lost.
The everRun software partitions the new logical disk and makes it available to be added to a storage group.
Page 142 of 483
Creating a New Storage Group
Related Topics
"Responding to a Failed Logical Disk" on page 140
"Logical Disk Management" on page 139
"Logical Disks and Physical Disks" on page 15
"The everRun Availability Console" on page 60
Creating a New Storage Group
You can create a new storage group. When you create a new storage group, it will have no logical disks assigned to it. See
"Assigning a Logical Disk to a Storage Group" on page 144
for more information.
To create a new storage group
1. On the STORAGE GROUPS page, click the Create button. The New Storage Group dialog box appears.
2. In the Name box, type the name of the new storage group.
3. Click Create Storage Group.
Related Topics l
"Assigning a Logical Disk to a Storage Group" on page 144
l
"Deleting a Storage Group" on page 143
Deleting a Storage Group
You can delete a storage group as long as no logical disks are assigned to it.
Note: If you attempt to delete a storage group that has one or more logical disks assigned to it, the system will prompt you to first move the logical disks to another storage group and then perform the Delete operation.
To delete a storage group
1. On the Storage Groups page, select the storage group you wish to delete.
2. Click the Delete button. The Confirm dialog box appears.
3. Click Yes to delete the storage group.
Related Topics
Page 143 of 483
everRun User's Guide l
"Creating a New Storage Group" on page 143
Assigning a Logical Disk to a Storage Group
You can assign an empty logical disk to a storage group.
Notes: l
The logical disk that you want to add must be empty. Its Size Used value must be zero.
l
The sector size (4K or 512B) of the logical disk must match the sector size of the storage group.
To assign a logical disk to a storage group
1. On the PHYSICAL MACHINES page, select node 0.
2. Click the Storage tab.
3. Select an empty logical disk (its Size Used is 0).
4. In the Actions column, click Move to Storage Group.
5. The Move Disk to Storage Group dialog box appears. In the Storage Group drop down box, select the storage group.
6. Click Move to Storage Group.
7. On the PHYSICAL MACHINES page, select node 1.
8. Repeat steps 2 through 6 above.
On the STORAGE GROUPS page, the new storage group will appear with a non-zero size.
Page 144 of 483
7
Chapter 7: Managing Physical Machines
Manage a physical machine (PM) to control its operation and perform maintenance.
You view and manage PMs using the Physical Machines page of everRun Availability Console; for information, see
"The Physical Machines Page" on page 97 .
Many of the tasks you perform from the Physical Machines page require maintenance mode; for information, see
"Maintenance Mode" on page 145 .
To manage the operational state of a PM (in maintenance mode), see: l
"Rebooting a Physical Machine" on page 147
l
"Shutting Down a Physical Machine" on page 147
l
To perform maintenance tasks, see
"Maintaining Physical Machines" on page 271
.
Maintenance Mode
When a physical machine (PM) enters maintenance mode, it goes offline for service. When you finalize service, the PM exits maintenance mode and goes back online, becoming available for running virtual machines (VMs).
When one PM enters maintenance mode, the PM migrates the VMs running on it to the other PM, which protects the VMs from any potential disruption caused by the service.
When the primary PM (node x
(primary)) enters maintenance mode, the other PM becomes primary.
Page 145 of 483
everRun User's Guide
When both PMs enter maintenance mode, the PMs perform an orderly shutdown of all VMs, which protects their memory state before the PMs shut down or reboot.
Shut down the PMs only from the Physical Machines page with the PM in maintenance mode because the everRun Availability Console protects the system from disruptive action that results from manually powering down a PM.
Cautions:
1. An everRun system is not fault tolerant when a PM is in maintenance mode. For continuous uptime, finalize service as soon as possible so that the PM can exit maintenance mode and go back online.
2. Avoid entering both PMs into maintenance mode at the same time. To keep the virtual machines running, at least one PM must be up and running normally. (If you need to shut
down the entire everRun system, see "Shutting Down a Physical Machine" on page
Note: If you want both PMs in maintenance mode, first enter the secondary PM into maintenance mode, and then enter the primary PM into maintenance mode. This sequence avoids the unnecessary migration of VMs.
To enter a PM into maintenance mode
1. Select a PM from the Physical Machines page.
2. Click Work On.
When the PM is in maintenance mode, its state displays .
To finalize and exit a PM from maintenance mode
1. Select a physical machine from the Physical Machines page.
2. Click Finalize, which exits the PM from maintenance mode.
Related Topics
"The everRun Availability Console" on page 60
"Managing Physical Machines" on page 145
"Physical Machines and Virtual Machines" on page 9
Page 146 of 483
Rebooting a Physical Machine
"The Physical Machines Page" on page 97
"The Virtual Machines Page" on page 100
Rebooting a Physical Machine
Reboot a physical machine (PM) to restart its everRun software, and optionally exit the PM from main-
To reboot a PM
1. Determine which PM (node0 or node1) you want to reboot.
2. In the everRun Availability Console, click Physical Machines in the left-hand navigation panel.
3. Select the appropriate PM (node0 or node1) and then click Work On, which changes the PM’s
Overall State to Maintenance Mode and the Activity state to running (in Maintenance).
4. Click Reboot. As the PM reboots, the Activity state displays: n preparing for reboot (in Maintenance) n rebooting (in Maintenance) n booting (in Maintenance) n running (in Maintenance).
5. To exit the PM from maintenance mode and make it available for running virtual machines, click Finalize.
Related Topics
"Maintenance Mode" on page 145
"The everRun Availability Console" on page 60
"Managing Physical Machines" on page 145
"The Physical Machines Page" on page 97
Shutting Down a Physical Machine
Shut down a physical machine (PM) to stop it from running when you need to service or replace the PM.
Use this procedure to shut down one and only one PM.
Page 147 of 483
everRun User's Guide
Cautions:
1. Using this procedure to shut down both PMs will result in data loss. If you need to stop both PMs, shut down the everRun system (which also shuts down the virtual machines
(VMs)), as described in
"Shutting Down the System" on page 64
.
2. Do not use the
-f
(force) option with the halt
, poweroff
, or reboot command of the CentOS operating system. Doing so causes FT guests that are active on the same node to hang. Instead, use the everRun Availability Console and maintenance mode to shutdown a PM, as described in the procedure below.
3. The everRun system is not fault tolerant when you shut down a PM. For continuous uptime, bring an offline PM back into service as soon as possible.
To shut down a PM, you must place the PM into maintenance mode, which migrates any virtual machines running on that PM to the remaining PM.
To shut down a PM
1. Determine which PM you want to shut down.
2. In the everRun Availability Console, click Physical Machines in the left-hand navigation panel.
3. Select the appropriate PM (node0 or node1) and then click Work On, which changes the PM’s
Overall State to Maintenance Mode and the Activity state to running (in Maintenance).
4. After the PM displays running (in Maintenance), click Shutdown.
Caution: If the PM does not turn off after you click Shutdown, you must manually power off the PM, though doing so destroys its memory state. Manually power off a PM only as a last resort.
After the PM has shutdown, its activity is off (in Maintenance). You must manually restart the PM.
Related Topics
"Maintenance Mode" on page 145
"The everRun Availability Console" on page 60
"Managing Physical Machines" on page 145
"The Physical Machines Page" on page 97
Page 148 of 483
Load Balancing
Load Balancing
HA Load Balancing distributes VMs across both PMs to improve performance and availability. Load balancing is configured per VM and is enabled automatically on everRun systems.
If a PM is out of service, all VMs will run on the surviving PM. VMs automatically migrate back as soon as the PM they are targeted to run on returns to service and is fully synchronized.
Modes of Operation
Load balancing is set for a VM on its Load Balance tab on the Virtual Machines page. The following modes are supported: l automatically balance. This provides automatic load balancing of a VM. When a VM is set to balance automatically, it will run on the available PM with the most resources. When the system determines that better load balancing can be achieved by moving one or more VMs with the automatic setting, an alert is generated. The alert appears on the Dashboard, and a Load Balancing notification appears on the masthead.
Click Load Balance to initiate automatic load balancing of a VM.
The icon on the Virtual Machines page under Current PM column indicates VMs that will migrate imminently.
l manually place on node
N
. Advanced users can manually assign a preferred PM (node) for each individual VM, rather than relying on the automatic policy, if preferred.
A graphic appears on the Virtual Machine page under the Current PM tab for each VM. It indicates the current status of the VM’s load-balancing state, the PM the VM is running on, and its preference.
The following sample graphic indicates that the VMs are currently at PM 0 and that PM 1 is the preference.
everRun policy ensures that a VM is always running. In the event that one PM is predicted to fail, is under maintenance, or is taken out of service, the VM will run on the healthy PM. When both PMs are healthy, a
VM migrates to its preferred PM.
Related Topic
"Selecting a Preferred PM for a Virtual Machine" on page 267
Troubleshooting Physical Machines
Page 149 of 483
everRun User's Guide
The following topics describe troubleshooting procedures for PMs: l
"Recovering a Failed Physical Machine" on page 150
l
"Recovering a Failed Physical Machine with External Storage " on page 152
l
"Resetting MTBF for a Failed Physical Machine" on page 152
Recovering a Failed Physical Machine
Recover a physical machine (PM) when it cannot boot or if it fails to become a PM in the everRun system.
In some cases, the everRun Availability Console displays the state of a failed PM as Unreachable
(Syncing/Evacuating…).
To recover a PM, you must reinstall the everRun release that the PM has been running using an install
ISO. Recovering a failed PM, though, is different from installing the software for the first time. The recovery preserves all data, but it re-creates the /boot and root file systems, re-installs CentOS and the everRun software, and attempts to connect to an existing system.
Warning: This procedure deletes all software you may have installed on the PM and all PM configuration information you may have entered before recovery. After you complete this procedure, you must manually re-install all your software and reconfigure the PM to match your original settings.
node in maintenance mode.
Page 150 of 483
Recovering a Failed Physical Machine
Prerequisites:
1. Determine which PM you need to recover.
2. Obtain installation software for the everRun release that the PM has been running by using one of the following methods: n
Download an install ISO from your authorized Stratus service representative.
n
Extract an install ISO into the current working directory from the most recently used upgrade kit by executing a command similar to the following ( x.x.x.x
is the release number and nnn is the build number): tar -xzvf everRun_upgradex.x.x.x
nnn .kit *.iso
After you obtain the correct install ISO, save it or burn it to a DVD. See "Obtaining ever-
3. Check that a monitor and keyboard are connected to the PM that you are recovering.
4. Check that Ethernet cables are connected from the PM you are recovering to the network or directly to the other PM, if the two everRun system PMs are in close proximity.
The Ethernet cable should connect from the first embedded port on the PM you are recovering or from an option (that is, add-on or expansion) port if the PM does not have an embedded port.
To recover a PM
1. Manually power on the PM that you want to recover. As the PM powers on, enter the firmware
(BIOS or UEFI) setup utility and set the Optical Drive as the first boot device.
2. Either mount the ISO image or insert the DVD into the PM.
3. At the Welcome screen, select Recover PM, Join system: Preserving data and press Enter.
4. When prompted, respond to the Select interface for private Physical Machine connection, and then respond to the prompt Select interface for managing the system (ibiz0).
5. When prompted to configure ibiz0, select Automatic configuration via DHCP or Manual Configuration (Static Address). (The installation software configures priv0 automatically.)
6. When installation is complete, the PM ejects the install DVD (if used) and reboots.
Page 151 of 483
everRun User's Guide
7. As the PM boots, you can view its activity on the Physical Machines page of the everRun Availability Console. The Activity column displays the PM as recovery (in Maintenance) and then running after recovery is complete.
8. Manually reinstall applications and any other host-level software and reconfigure the PM to match your original settings.
Related Topics
"Maintenance Mode" on page 145
"Managing Physical Machines" on page 145
"The everRun Availability Console" on page 60
"The Physical Machines Page" on page 97
Recovering a Failed Physical Machine with External Storage
You can recover a failed physical machine (PM) that is connected to external storage while the system is running. For systems with Fibre Channel or iSCSI external storage, you begin by recovering the PM, and then you update initrd and modify the multipath.conf
and lvm.conf
files. For systems with iSCSI external storage, you also stop and restart the everrun-sim service, remap LUNs, and use iscsiadmin for various tasks.
For detailed information, access the Knowledge Base to search for the article
Recovering a Failed Physical Machine with External Storage
(KB4300 ). See
"Accessing Knowledge Base Articles" on page 479
.
Related Topics
"Recovering a Failed Physical Machine" on page 150
"Managing External Storage " on page 281
"Managing Physical Machines" on page 145
Resetting MTBF for a Failed Physical Machine
Page 152 of 483
Resetting MTBF for a Failed Physical Machine
Reset the mean time between failures (MTBF) counter for a physical machine (PM) to attempt to restart a failed PM.
If a PM crashes, the everRun software automatically restarts it, unless it has fallen below its MTBF threshold. If the PM is below the MTBF threshold, the everRun software leaves the machine powered off.
If necessary, you can reset the MTBF counter and restart the PM.
Caution: Do not reset the MTBF counter unless instructed to do so by your authorized Stratus service representative, as doing so may affect the fault tolerance of your system.
Note: The Reset Device button is displayed only if the PM falls below its MBTF threshold.
To reset the MTBF counter for a PM
1. Determine which PM has the MTBF counter you want to reset.
2. In the everRun Availability Console, click Physical Machines in the left-hand navigation panel.
3. Select the appropriate PM (node0 or node1) and then click Work On, which changes the PM’s
Overall State to Maintenance Mode and the Activity state to running (in Maintenance).
4. After the PM displays running (in Maintenance), click Reset Device.
Related Topics
"Maintenance Mode" on page 145
"Managing Physical Machines" on page 145
"The everRun Availability Console" on page 60
"The Physical Machines Page" on page 97
Page 153 of 483
8
Chapter 8: Managing Virtual Machines
Manage a virtual machine (VM) to control its operation, provision its resources, or configure its guest operating systems and applications.
You can view and manage VMs on the Virtual Machines page of the everRun Availability Console, which you access as described in
"The Virtual Machines Page" on page 100 . To perform specific management
tasks, see the following topics.
To manage the operational state of a VM, see: l
"Starting a Virtual Machine" on page 227
l
"Shutting Down a Virtual Machine" on page 227
l
"Powering Off a Virtual Machine" on page 228
l
"Opening a Virtual Machine Console Session" on page 229
l
"Renaming a Virtual Machine" on page 231
l
"Removing a Virtual Machine" on page 231
To create or configure a VM, see: l
"Planning Virtual Machine Resources" on page 156
(virtual CPUs, memory, storage, and networks) l
"Creating and Migrating Virtual Machines" on page 161
l
"Managing Snapshots" on page 251
l
"Managing Virtual CDs" on page 246
l
"Configuring Windows-based Virtual Machines" on page 217
Page 155 of 483
everRun User's Guide l
"Configuring Linux-based Virtual Machines" on page 224
l
"Managing Virtual Machine Resources" on page 232
To complete advanced tasks, see: l
"Assigning a Specific MAC Address to a Virtual Machine" on page 265
l
"Selecting a Preferred PM for a Virtual Machine" on page 267
l
"Changing the Protection Level for a Virtual Machine (HA or FT)" on page 267
l
"Configuring the Boot Sequence for Virtual Machines" on page 268
l
"Resetting MTBF for a Failed Virtual Machine" on page 269
l
"Locating a Dump File in a Virtual Machine" on page 270
Planning Virtual Machine Resources
When creating virtual machines, plan to allocate system resources to maximize system performance and continuous uptime.
To plan for allocating resources to your virtual machines, see: l
"Planning Virtual Machine vCPUs" on page 156
l
"Planning Virtual Machine Memory" on page 158
l
"Planning Virtual Machine Storage" on page 159
l
"Planning Virtual Machine Networks" on page 161
Planning Virtual Machine vCPUs
Allocate virtual CPUs (vCPUs) to assign computing resources to a virtual machine (VM) on your everRun system.
When allocating vCPUs to a VM, consider the following information and restrictions: l
Each vCPU represents a virtual unit of processing power. The total number of vCPUs available on an everRun system is equal to the minimum of the number of hardware threads presented by either physical machine (PM) in the system. For example, in a system where one PM that has 4 cores and 2 threads per core (8 vCPUs) and another PM that has 8 cores and 2 threads per core (16 vCPUs), the total number of vCPUs available is 8 vCPUs (fewest threads of either PM).
Page 156 of 483
Planning Virtual Machine vCPUs l
The number of vCPUs available for the VMs is equal to the total number of vCPUs available on the everRun system minus the number of vCPUs allocated to the everRun system software (which you can set to 2 or 4 vCPUs, as described in
"Configuring System Resources" on page 78
). For example, if the total number of vCPUs is 8, and you allocate 2 vCPUs to the system software, there are 6 vCPUs that can be assigned to running VMs without over-provisioning the system.
l
The maximum number of vCPUs you can allocate to any one VM is the total number of vCPUs in the system. Each VM consumes its configured number of vCPUs plus 2 additional vCPUs for
FT VMs or 1 additional vCPU for HA VMs.
l
Windows-based VMs: If you change the number of assigned vCPUs from 1 to n or n to 1, after
restarting the VM at the end of the reprovisioning process (see "Reprovisioning Virtual Machine
Resources" on page 233 ), you must shut down and restart the VM a second time. This allows the
VM to correctly reconfigure itself for Symmetric Multiprocessing (SMP). The VM displays odd behavior and is not usable until it is restarted.
l
The System page of the everRun Availability Console (see
"The System Page" on page 63 ) indic-
ates the total number of vCPUs, the number of vCPUs allocated to the everRun system software, the number of vCPUs consumed by running VMs, and the number of free vCPUs.
l
The everRun software allows the over-provisioning of vCPUs. If the number of free vCPUs on the
System page is less than zero, you have over-provisioned the vCPUs; the console indicates this and displays an estimate of the degree to which vCPUs have been over-provisioned.
l
The over-provisioning of vCPUs does not prevent you from creating or starting VMs; however, it is best to avoid running the system in an over-provisioned state.
Considerations When Over-Provisioning Virtual CPUs
Note: In general, avoid over-provisioning VM resources. It is best to isolate each VM's resources to protect the VM against other VMs that might experience resource leaks or unexpected performance peaks. When you create and configure VMs, assign dedicated resources that cannot be used by other VMs.
You should over-provision physical CPUs only under the following conditions: l
The peak vCPU resources consumed by the combined VMs does not exceed the physical resources of the everRun system.
Page 157 of 483
everRun User's Guide l
One or more VMs are used at different times (such as off-peak backups).
l
One or more of the VMs will be stopped while the other is running, for example, during VM upgrades or VM point-in-time backup or recovery.
l
Peak total CPU use by VMs will not affect service level agreements or required response times.
l
Each VM’s CPU use is well understood, and its application(s) are not prone to resource leaks.
When CPUs are over-provisioned, a leak in one VM can affect the performance of other VMs.
Related Topics
"System Requirements Overview" on page 24
"Creating and Migrating Virtual Machines" on page 161
"Managing Virtual Machine Resources" on page 232
Planning Virtual Machine Memory
Allocate memory to assign physical memory to a virtual machine (VM) on your everRun system.
When allocating memory to a VM, consider the following information and restrictions: l
The total memory you can allocate to the VMs is equal to the total amount of memory available on the everRun system (see
"Memory Requirements" on page 27
) minus the memory allocated to the
you allocate 2 GB to the system software, there are 14 GB of memory available to the VMs.
l
You can provision a single VM with memory up the total amount of memory available to the VMs.
Each VM consumes its requested amount of memory plus an additional 20% memory for overhead.
l
The minimum memory allocation is 256 MB, but 64-bit operating systems require 600 MB or more.
Be sure to verify the memory requirements for your guest operating systems.
l
The System page of the everRun Availability Console (see
"The System Page" on page 63 ) indic-
ates the total amount of memory, the memory allocated to the everRun system software, the memory consumed by running VMs, and the amount of free memory. Use this page to verify your memory allocations.
l
The everRun software does not allow over-provisioning of memory for running VMs; it prevents you from starting VMs that would exceed the total physical memory of the physical machines. You
Page 158 of 483
Planning Virtual Machine Storage may safely allow over-provisioning of memory to occur only if one or more of the VMs is stopped while the other is running, for example, during VM upgrades or VM point-in-time backup or recovery.
l
If necessary, you can manually redistribute memory by shutting down or reconfiguring one or more under-utilized VMs and then reassigning the available resources to a more heavily-utilized VM.
Related Topics
"Memory Requirements" on page 27
"Creating and Migrating Virtual Machines" on page 161
"Managing Virtual Machine Resources" on page 232
Planning Virtual Machine Storage
Plan the allocation of storage on your everRun system to ensure that you have space for your virtual machines (VMs) and system management needs.
When you configure the everRun system, you create storage groups from the available logical disks. You allocate VM volumes and virtual CDs (VCDs) from these storage groups, the assignment of which can have a dramatic impact on system performance and your ability to fully utilize available storage capacity.
When allocating storage to your virtual machines (VMs), consider the following actions: l
Observe storage maximums
The everRun software does not allow over-provisioning of storage. The aggregate required storage for all VMs and VCDs must be no more than the total available storage in the everRun system. The system prevents you from creating a volume for a VM from a storage group that does not have enough space.
l
Minimize stranded storage
Ensure that each PM has the same amount of storage capacity. If one PM has more storage than the other, only the minimum amount of space is available. For example, if one PM has 3 terabytes
(TB) of storage and another PM has 2 TB of storage, the total amount of storage is 2 TB (least storage of either PM).
l
Observe 512B and 4K sector size restrictions
Page 159 of 483
everRun User's Guide
Stratus recommends using disks with the 4K sector size for better performance. When using 4K storage, ensure that your storage groups support the sector size of the VM volumes that you want to create or import: n
A storage group with the 512B sector size supports only 512B VM volumes.
n
A storage group with the 4K sector size supports 4K or 512B VM volumes.
Note that the boot volume for each VM must be 512B, regardless of the storage group's sector size.
Only data volumes can use the 4K sector size. Ensure that your guest operating systems support
4K volumes before creating or attaching them.
l
Leave storage space for additional VCDs
Leave at least 5 GB of free space in a storage group to allow room to create VCDs for installing additional VMs and applications. (To conserve this storage space, consider deleting VCDs when you are finished using them.) l
Leave storage space for VM snapshots
When you create each VM volume, you specify its volume size as well as the size of the larger volume container in which the volume and its snapshots are stored. To leave enough space for the snapshots that you plan to create, start by allocating a volume container that is at least two times the size of the volume that it contains; however, your needs may vary depending on VM snapshot activity. For more information about estimating the amount of storage needed in a volume container, see
"Sizing Volume Containers" on page 16
.
To conserve storage space in a volume container, you can remove older or obsolete snapshots as described in
"Removing a Snapshot" on page 264
. If necessary, you can also expand a volume container as described in
"Expanding a Volume Container on the everRun System" on page 243
.
l
Create separate boot and data volumes for each VM
Install the guest operating system and applications in the first (boot) volume, and create separate volumes for associated data. Separating the boot and data volumes helps to preserve the data and makes it easier to recover a VM if the boot volume crashes.
l
Create a boot volume with enough capacity for the guest operating system plus overhead
Observe the minimum space requirements of your guest operating system and consider allocating slightly more space to account for the formatted capacity of the volume and usage. For example, if you allocate 5 GB to the boot drive when creating the VM, the formatted capacity of the boot
Page 160 of 483
Planning Virtual Machine Networks volume starts at approximately 4.8 GB before usage, and this might be insufficient to meet a 5
GB requirement.
Related Topic
"Storage Requirements" on page 25
"Creating and Migrating Virtual Machines" on page 161
"Managing Virtual Machine Resources" on page 232
Planning Virtual Machine Networks
Plan network resources to determine how you will allocate available virtual networks to the virtual machines (VMs) on your everRun system.
When you install the everRun software, it binds pairs of physical network ports across the two physical machines (PMs) to form redundant virtual networks. When you create or reprovision VMs on your everRun system, you connect the VMs to these virtual networks instead of the physical network ports.
When connecting VMs to virtual networks, consider the following information and restrictions: l
You can connect one VM to multiple virtual networks, and you can connect multiple VMs to the same virtual network.
l
The everRun software allows unlimited over-provisioning of network resources; therefore, be sure to profile a VM’s network bandwidth/response time requirements when allocating virtual networks.
l
When multiple VMs share the same virtual network, available network bandwidth is shared equally between the VMs. Unlike vCPU capacity, there is no way to proportionately allocate bandwidth resources. Therefore, high use of network resources by one VM can reduce the performance of all
VMs on that network. If a VM has a large bandwidth requirement, consider connecting a dedicated virtual network to that VM.
Related Topics
"General Network Requirements and Configurations" on page 27
"Creating and Migrating Virtual Machines" on page 161
"Managing Virtual Machine Resources" on page 232
Creating and Migrating Virtual Machines
Page 161 of 483
everRun User's Guide
Generate a new virtual machine (VM) on the everRun 7.
x system by creating a new VM, migrating an existing VM or physical machine (PM) directly over the network , or importing an Open Virtualization Format
(OVF) file from an existing everRun or Avance VM.
To copy an existing VM on your system for the purpose of creating a new VM or creating a duplicate VM for troubleshooting, see
"Copying a Virtual Machine" on page 169
.
To migrate or import a system from a non-everRun 7.
x source, see "Migrating From Avance or everRun
needs: l
"Migrating a Physical Machine or Virtual Machine to an everRun 7.x System" on page 171
(most
VMs or PMs, including everRun MX- and Avance-based VMs)
Use the P2V client (virt-p2v) to transfer a PM or VM directly over the network to a new VM on the everRun system.
l
"Importing an OVF File from an everRun MX System" on page 183
(everRun MX-based VMs only)
Use XenConvert to export a VM from the everRun MX system to OVF and Virtual Hard Disk (VHD) files on a network share, and then use everRun Availability Console to import those files to the ever-
Run 7.
x system.
l
"Importing an OVF File from an Avance System" on page 192
(Avance-based VMs only)
Use Avance Management Console to export a VM from the Avance Unit to OVF and raw tar hard disk files on a management PC or network share, and then use everRun Availability Console to import those files to the everRun 7.
x system.
To migrate or import a VM from another everRun 7.
x system, or to restore a VM on the same everRun 7.
x system, see one of the following topics: l
"Migrating a Physical Machine or Virtual Machine to an everRun 7.x System" on page 171
Use the
P2V client
(virt-p2v) to transfer a VM directly over the network to a new VM on another everRun 7.
x system or on the same everRun 7.
x system.
l
"Exporting a Virtual Machine from an everRun System" on page 210
Page 162 of 483
Creating a New Virtual Machine
Use the everRun Availability Console to export the source VM to OVF and VHD files on a network share.
l
"Managing Snapshots" on page 251
Use the everRun Availability Console to create a snapshot of the source VM, then use the snapshot to create a new VM on the same everRun system or export the snapshot to OVF and VHD files on a network share.
l
"Importing an OVF File from an everRun 7.x System " on page 200
Use the everRun Availability Console to import OVF and VHD files to another everRun 7.
x system or back to the same everRun 7.
x system.
"Replacing a Virtual Machine from an OVF File" on page 205
Use the everRun Availability Console to import OVF and VHD files back to the same everRun 7.
x system to overwrite and restore an existing VM from a previous backup copy.
Related Topics
"Managing Virtual Machines" on page 155
Creating a New Virtual Machine
Create a new virtual machine (VM) to install a guest operating system on your everRun system. (You can
Launch the VM Creation Wizard by clicking Create on the Virtual Machines page. The wizard steps you through the process of allocating resources to the VM.
Note:
If you need to create a Windows Server 2003 VM, see "Creating a New Windows Server 2003
Virtual Machine" on page 167 . You must perform a different procedure to create a Windows
Server 2003 VM.
Page 163 of 483
everRun User's Guide
Prerequisites: l
Review the prerequisites and considerations for allocating CPUs, memory, storage, and
network resources to the VM, as listed in "Planning Virtual Machine Resources" on page 156 .
l
You can select a remote ISO or a bootable virtual CD (VCD) as the source that the
VM boots from. For a remote ISO, you must have a URL or path name for the repository; and for a remote ISO on a shared network drive, you must have a user name and password. If you need a bootable VCD of the Windows or Linux installation media, create it as described in
"Creating a Virtual CD" on page 246
. The bootable VCD must be a single CD or DVD. Multiple CDs or DVDs are not supported.
l
Ensure that both PMs of the everRun system are online; otherwise, the system cannot properly create the VM.
To create a new VM
1. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify that both
PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
2. On the Virtual Machines page (see
"The Virtual Machines Page" on page 100 ), click Create to
open the VM Creation Wizard.
3. On the Name, Description, Protection and OS page: a. Type the Name and an optional Description for the VM as they will appear in the everRun
Availability Console.
b. Select the level of protection to use for the VM: o
Fault Tolerant (FT)—Transparently protects an application by creating a redundant environment for a VM running across two physical machines. Use FT for applications that need greater downtime protection than HA provides.
o
High Availability (HA)—Provides basic failover and recovery, with some faults requiring an (automatic) VM reboot for recovery. Use HA for applications that can tolerate some downtime and that do not need the downtime protection that FT provides.
Page 164 of 483
Creating a New Virtual Machine
For more information about these levels of protection, see
"Modes of Operation" on page 11 .
c. For Boot From, select one of the following as the boot source: o
VCD—The boot source is a VCD. Select a source from the pull-down menu.
o
Remote ISO via Windows Share (CIFS/SMB)—The boot source is a remote
ISO file on a shared network drive. You must enter values for User Name and Password. For Repository, enter a value in the format // iso_url / path_to_ISO_folder .
o
Remote ISO via NFS—The boot source is a remote ISO file, accessed through NFS.
For Repository, enter a value in the format // iso_url / path_to_ISO_folder .
For a list of available ISO repositories, click List ISOs, and select an ISO file. The full path name of the selected ISO file appears under Repository. You cannot edit the ISO URL that is displayed.
d. Click Next.
4. On the vCPUs and Memory page: a. Specify the number of vCPUs and the amount of Memory to assign to the VM. For more
"Planning Virtual Machine vCPUs" on page 156
b. If applicable, select the Keyboard Layout in Console to set the keyboard type for your country.
c. Click Next.
5. On the Volumes page: a. Type the Name of the boot volume as it will appear in the everRun Availability Console.
b. Type the Container Size and Volume Size of the volume to create in gigabytes (GB). The container size is the total size for the volume including extra space to store snapshots. The volume size is the portion of the container that is available to the guest operating system.
For more information about allocating storage, see
"Sizing Volume Containers" on page 16
and
"Planning Virtual Machine Storage" on page 159
.
Page 165 of 483
everRun User's Guide c. Select the Disk Image format: n
RAW—raw disk format n
QCOW2—QEMU Copy On Write (QCOW2) format, which supports snapshots d. Select the Storage Group in which to create the volume, and, if applicable, select the
Sector Size.
Ensure that you select a storage group that supports the sector size of the volume that you want to create (see
"Planning Virtual Machine Storage" on page 159
). Note that the boot volume must have a sector size of 512 B. You can select the sector size, either 4K or 512B, only for data disks.
e. If applicable, create additional data volumes by clicking Add New Volume and specifying the parameters for each volume. (You can also add volumes after you create the VM by
f. Click Next.
6. On the Networks page, select the shared networks to attach to the VM. For more information, see
"Planning Virtual Machine Networks" on page 161 . To continue, click Next.
7. On the Creation Summary page: a. Review the creation summary. If you need to make changes, click Back.
b. If you want to prevent a console session from automatically starting to observe the software installation, deselect Launch Console.
c. To accept the VM as provisioned and begin the software installation, click Finish.
8. If applicable, observe the progress of the installation of the operating system (allow pop-ups in your browser, if necessary) and respond to any prompts in the VM console session.
9. After you install the operating system, configure the additional resources and software necessary for production use, as described in: n
"Configuring Windows-based Virtual Machines" on page 217
n
"Configuring Linux-based Virtual Machines" on page 224
Page 166 of 483
Creating a New Windows Server 2003 Virtual Machine
Caution: If the primary PM fails or the VM crashes before the final reboot after the installation process is completed, the installation of the VM may need to be restarted.
The VM may not reboot if installations of any of the following are aborted: l
The guest operating system, including the configuration steps l
Any middleware or applications that manipulate system files
Related Topics
"Copying a Virtual Machine" on page 169
"Renaming a Virtual Machine" on page 231
"Removing a Virtual Machine" on page 231
"Creating and Migrating Virtual Machines" on page 161
"Managing Virtual Machine Resources" on page 232
"Managing the Operation of a Virtual Machine" on page 227
Creating a New Windows Server 2003 Virtual Machine
Follow these instructions to create a new Windows Server 2003 VM on your everRun system. You should understand the following considerations before you create the Windows Server 2003 VM: l
The Windows Server 2003 operating system is no longer supported by Microsoft.
l
The only version of Windows Server 2003 that everRun systems support is the Windows Server
2003 R2 Enterprise SP2 32-bit operating system.
l
The network VirtIO driver is not automatically installed as it is when creating VMs with other operating systems. The manual steps required to do this are provided in the procedure below.
Note: The following procedure documents only the unique actions that are required to install this guest OS on your everRun system. You must also respond to other normal installation prompts not documented here (for example choosing a locale).
To create a new Windows Server 2003 VM
1. Create a bootable virtual CD (VCD) of the Windows Server 2003 media as described in "Creating a
Page 167 of 483
everRun User's Guide
3. When the dialog box informing you that the software has not passed Windows Logo testing appears click Yes to continue the installation.
4. When the dialog box informing you that the RedHat VirtIO SCSI controller driver has not passed
Windows Logo testing appears, click Yes to continue the installation.
5. When the dialog box informing you that Windows Setup is not complete, click Cancel.
6. In the Windows Setup message informing you that you have chosen to not continue Setup, click
OK.
7. Open Computer Management and click Device Manager.
8. In the right-hand pane of Computer Manager, under Other Devices, right click Ethernet Controller. In the pop-up menu click Update Driver.
9. In the Hardware Update Wizard, select No, not this time. Click Next.
10. In the Hardware Update Wizard, select Install from a list or specific location (Advanced).
Click Next.
11. In the Hardware Update Wizard, select Search removable media (floppy, CD-ROM...). Click
Next.
12. In the Hardware Update Wizard, select the top-most Red Hat VirtIO Ethernet Adapter entry.
Click Next.
13. When the Hardware Installation message informs you that the software has not passed Windows
Logo testing click Continue Anyway, then click Finish.
14. Close Computer Management.
15. Shut down the VM that was just installed. This must be done in order to remove the virtual floppy drive that was automatically installed earlier during the installation.
Note: If you need to install optional software from the Windows Server CD2 you must obtain an ISO image of that media. Place that ISO image on a network that the system can access, and run the setup.exe file.
Page 168 of 483
Copying a Virtual Machine
16. After you install the operating system, configure the additional resources and software necessary for production use, as described in
"Configuring Windows-based Virtual Machines" on page 217 .
Related Topics
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Copying a Virtual Machine
Copy a virtual machine (VM) if you want to clone an existing VM on your everRun system. For example, you can copy a healthy VM to create a new VM, or you can copy a VM that is not working properly and use the copy for troubleshooting purposes. (If you want to import or migrate a VM from a different system, see the overview in
"Creating and Migrating Virtual Machines" on page 161
.)
To copy a VM, select a VM on the Virtual Machines page and click Copy. A wizard steps you through the process of renaming and allocating resources to the new VM.
Copying a VM creates an identical VM with a unique SMBIOS UUID, system serial number, MAC addresses, and hardware ID.
Notes: l
Copying a VM does not copy the snapshots from the source VM, but you can configure the container size of the new VM to make it possible to create new snapshots.
l
To prevent conflicts with the source VM, the copy wizard automatically assigns a new
MAC address to each network interface in the new VM; however, you may need to manually update any IP addresses and host names.
l
If the everRun system switches from the primary PM to the secondary PM while copying a VM, the copy process fails. This does not affect the continuous uptime of your system, but you must delete any volumes associated with the copied VM and start the copy again.
Prerequisites: l
You must shut down a VM before copying it.
l
Both PMs of the everRun system must be online for the copy process to function properly.
Page 169 of 483
everRun User's Guide
To copy a VM on the everRun system
1. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify that both
PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
2. On the Virtual Machines page (see
"The Virtual Machines Page" on page 100 ), select the VM that
you want to copy and click Shutdown.
3. When the VM has stopped, click Copy to open the copy wizard.
4. On the Name, Description, and Protection page: a. Type the Name and an optional Description for the VM as they will appear in the everRun
Availability Console.
b. Select the level of protection to use for the VM: o
Fault Tolerant (FT) o
High Availability (HA)
c. Click Next.
5. On the vCPUs, Memory, and Console Keyboard Layout page: a. Specify the number of vCPUs and the amount of Memory to assign to the VM. For more
"Planning Virtual Machine vCPUs" on page 156
b. If applicable, select the Keyboard Layout in Console to set the keyboard type for your country.
c. Click Next.
6. On the Volumes page, you can: n
Type the volume Name.
n
Specify the Container Size and Volume Size of each volume to make room for snapshots.
n
Assign each volume to a Storage Group.
n
Specify a Sector Size.
Page 170 of 483
Migrating a Physical Machine or Virtual Machine to an everRun 7.x System n
Click Add New Volume to create a new data volume. (If the button is not visible, scroll down to the bottom of the wizard page.)
For more information, see
"Planning Virtual Machine Storage" on page 159 . To continue, click
Next.
7. On the Networks page, activate the check box for each shared network that you want to attach to the VM.
8. On the Copy Summary page: a. Review the configuration summary. If you need to make changes, click Back.
b. To proceed with copying the VM, click Finish.
After the copy process is complete; the everRun system may continue to synchronize data between PMs to enable High Availability (HA) or Fault Tolerant (FT) operation.
Troubleshooting
If necessary, use the following information to resolve problems with the copy process.
To clean up after a canceled or failed copy process
Remove any volumes associated with the copied VM.
Related Topics
"Creating and Migrating Virtual Machines" on page 161
"Managing Virtual Machine Resources" on page 232
"Managing the Operation of a Virtual Machine" on page 227
Migrating a Physical Machine or Virtual Machine to an everRun 7.
x
System
Migrate a physical machine (PM) or virtual machine (VM) to transfer it over the network to a new VM on the everRun 7.
x system. (You can also import an Open Virtualization Format (OVF) file to the everRun 7.
x system, as summarized in
"Creating and Migrating Virtual Machines" on page 161 .)
To migrate a PM or VM over the network, boot the P2V client (virt-p2v) on the source PM or VM and use the client to configure, initiate, and monitor the secure network transfer from source side. No configuration steps are required on the everRun system until after the migration is complete, but you can confirm that the migration is in progress on the Volumes page of the everRun Availability Console as volumes associated with the new VM begin to appear.
Page 171 of 483
everRun User's Guide
Caution: Consider backing up your source PM or VM before preparing to migrate it.
Page 172 of 483
Migrating a Physical Machine or Virtual Machine to an everRun 7.x System
Notes: l
The migration process supports only PMs or VMs running CentOS/RHEL 6 and 7, Windows 7 and 8.x, and Windows Server 2008 R2 and 2012. (If you need to migrate a Win-
dows Server 2003 VM, see "Migrating a Windows Server 2003 VM to an everRun 7.x
System" on page 180 . You must perform a different procedure to migrate a Windows
Server 2003 VM.) l
For Windows-based PMs or VMs that support fast startup mode, you must disable this feature before the migration process; otherwise, the migration process will fail as described below in Troubleshooting.
l
For Linux-based PMs or VMs, consider editing the
/etc/fstab file before the migration process to comment out entries for data volumes and allow only the boot volume to mount. Because Linux-based VMs use different device names on the everRun system, your new VM may boot into single-user mode if it cannot the mount volumes with their original device names. You can restore the
/etc/fstab entries with the correct device names after the migration process, as described below in Troubleshooting.
l
Your source PM or VM must be offline for the duration of the migration process. Consider scheduling a planned maintenance period for the migration.
l
The time required for the PM or VM migration depends on the size and number of volumes on the source system as well as the network bandwidth between the source and the target everRun system. For example, transferring a source system with one
20 GB boot volume over a 1 Gb/s network may take about 30 minutes.
l
You can migrate multiple PMs or VMs at one time, but sharing network bandwidth may increase migration times.
l
To prevent conflicts with the original PM or VM, the P2V client automatically assigns a new MAC address to each network interface in the new VM; however, you must manually update any IP addresses and host names as needed.
l
If the everRun system switches from the primary PM to the secondary PM during a migration, the migration process fails. This does not affect the continuous uptime of your system, but you must reboot the P2V client on the source PM or VM and start over.
See Troubleshooting below for more information.
Page 173 of 483
everRun User's Guide
Prerequisite: Both PMs of the everRun system must be online for the migration process to function properly. On the Physical Machines page of the everRun Availability Console, verify that both PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
To prepare for migrating a PM to the everRun system
1. Download the P2V client ISO file from the Downloads page at http://www.stratus.com/go/support/everrun .
a. On the Downloads page, click everRun (if it is not already displayed) and then select the appropriate version.
b. Scroll down to Drivers and Tools and then continue scrolling to everRun P2V Client for Virtual or Physical Machine Migration.
c. Select the P2V Client (virt-p2v) file.
2. If you want to verify the integrity of the ISO image, also download the associated fciv checksum file, and then download the Microsoft File Checksum Integrity Verifier (FCIV) executable file from the Microsoft Support web site. Save both files to the directory that contains the downloaded ISO file.
Open a command prompt. From the directory containing the ISO, executable, and verification files, type a command similar to the following to verify the ISO image: fciv -v -xml virt-p2v-n.n.n-n.nnnnnnnn.n.el6.centos.xml
If the command succeeds (that is, it returns the message
All files verified successfully
), go to the next step. If the command fails, repeat the download.
3. Burn the P2V client ISO file to a CD-ROM that you will use to boot the physical machine.
4. Insert the P2V client CD into the CD/DVD drive of the source PM.
5. Shut down the PM in preparation to boot the P2V client.
To prepare for migrating a VM to the everRun system
1. Download the P2V client ISO file from the Drivers and Tools section of the Downloads page at http://www.stratus.com/go/support/everrun . Ensure that you download the version of the P2V client that matches the version of the everRun system to which you are migrating
Page 174 of 483
Migrating a Physical Machine or Virtual Machine to an everRun 7.x System the VM.
2. If you want to verify the integrity of the ISO image, also download the associated fciv checksum file, and then download the Microsoft File Checksum Integrity Verifier (FCIV) executable file from the Microsoft Support web site. Save both files to the directory that contains the downloaded ISO file.
Open a command prompt. From the directory containing the ISO, executable, and verification files, type a command similar to the following to verify the ISO image: fciv -v -xml virt-p2v-n.n.n-n.nnnnnnnn.n.el6.centos.xml
If the command succeeds (that is, it returns the message All files verified successfully
), go to the next step. If the command fails, repeat the download.
3. Insert or connect the P2V client ISO file to the source VM and set the virtual CD drive as the boot device in the associated hypervisor.
4. Shut down the VM in preparation to boot the P2V client.
To migrate a PM or VM to the everRun system
1. Power on the source PM or VM to boot the P2V client. After a minute or so, the virt-p2v window is displayed.
2. The P2V client automatically obtains network settings through DHCP. Static settings are unnecessary for the migration process, but you can optionally click Configure network to specify the settings. (If necessary, configure the network settings of the target VM later on the everRun system.)
3. Enter the connection settings for the Conversion server (the everRun system). Enter the hostname or IP address of the system and the Password for the root account. (You must
4. Click Test connection. If the P2V client connects to the everRun system, click Next to continue. The Target properties page is displayed.
If the P2V client cannot connect, verify the connection settings and try to connect again.
5. Enter the Name for the target VM that will be displayed in the everRun Availability Console.
(The name must be different from any existing VMs on the everRun system.)
Page 175 of 483
everRun User's Guide
6. The # vCPUs and Memory(MB) values are automatically detected and completed, but optionally modify them if you want the VM on the everRun system to have more CPUs or memory than the source PM or VM.
7. Specify the Virt-v2v output options for the target VM, as follows: a. Next to Output to, select everrunha (High Availability) or everrunft (Fault Tolerant)
b. Next to Output format, select the disk image format, raw or qcow2. (The qcow2 format supports snapshots.)
8. If you want to save debugging messages from the migration process, optionally select the
Enable server-side debugging check box. (The debugging messages are included if you generate a diagnostic file for your authorized Stratus service representative, as described in
"Creating a Diagnostic File" on page 87
.)
9. Select which Fixed hard disks (volumes) to include in the migration by activating the check box next to each device.
You must select at least one volume, including the boot volume. (Because the P2V client is a Linux-based utility, all devices are listed by Linux device names, where sda or vda represents the boot volume.)
If the target everRun system has more than one storage group, you can also select the storage group in which to create each volume. Double-click the volume entry to open the
Choose Storage Group panel. Ensure that you select a Storage Group that supports the
sector size of the volume you are importing (see "Planning Virtual Machine Storage" on page
159 ) and select the Sector Size that matches the source volume (the P2V client cannot con-
vert the sector size of a volume). Note that the boot volume must have a sector size of 512
B. You can select the sector size, either 4K or 512B, only for data disks.
10. Select which Network Interfaces to include in the migration by activating the check box next to each device.
If the target everRun system has more than one shared network, you can also select the shared network to connect with each network interface. Double-click the network interface to open the Choose Shared Network panel, select the shared network, and click OK.
Page 176 of 483
Migrating a Physical Machine or Virtual Machine to an everRun 7.x System
11. When you are ready to migrate the PM or VM to the everRun system, click Start conversion. (If you need to cancel the migration for any reason, see Troubleshooting below.)
12. When the migration is complete, the P2V client displays a success message. If applicable, you can eject the CD or virtual CD and click Power Off to shut down the source PM or VM.
Note: After the migration, the new VM on the everRun system is located on the primary
PM, and it remains in a stopped state. Before starting the VM, complete the migration as described in the next procedure.
To complete the migration on the everRun system
1. Open the Virtual Machines page (see
"The Virtual Machines Page" on page 100
) in the ever-
Run Availability Console.
2. Select the new VM in the top pane and click Config to open the Reprovision Virtual
Machine wizard, as described in
"Reprovisioning Virtual Machine Resources" on page 233 .
Use the wizard to configure the desired vCPUs, memory, storage, and network settings for the VM: n
If your source PM or VM had more than one network interface, configure the additional network interfaces that were not included in the migration process.
n
If you will continue running the source PM or VM, ensure that the MAC address for each network interface in the new VM is different from the source PM or VM.
Click Finish on the last wizard page to implement the changes.
3. Click Start to boot the new VM.
4. Click Console to open the console of the VM and log on to the guest operating system. (For
information about using the console, see "Opening a Virtual Machine Console Session" on page 229 .)
5. For Windows-based VMs only, update the VirtIO drivers to the latest supported versions, as described in
"Updating the VirtIO Drivers (Windows-based VMs)" on page 218 . (The correct
VirtIO drivers are already present in Linux-based VMs.)
Note: After updating the drivers, you may need to restart the guest operating system.
Page 177 of 483
everRun User's Guide
6. Disable any guest operating system services that are unnecessary for operation on the ever-
Run system: n
If you migrated from a PM source, disable any services that interact directly with hardware. Examples include: n
Dell OpenManage (OMSA) n
HP Insight Manager n
Diskeeper n
If you migrated from a VM source, disable any services associated with other hypervisors. Examples include: n
VMware Tools n
Hyper-V Tools n
Citrix Tools for Virtual Machines
After disabling these services, restart the guest operating system to implement your changes.
7. If necessary, update the network configuration settings in the guest operating system and restart it to enable the settings.
8. Verify that you have configured your guest operating system with the additional Windows- or
Linux-based system settings described in: n
"Configuring Windows-based Virtual Machines" on page 217
n
"Configuring Linux-based Virtual Machines" on page 224
After you verify that the new VM is functioning properly, the migration process is complete; however, the everRun system may continue to synchronize data between PMs to enable High Availability (HA) or Fault Tolerant (FT) operation.
Troubleshooting
If necessary, use the following information to resolve problems with the migration process.
To cancel the migration process
Power down the source PM or VM running the P2V client.
To clean up after a canceled or failed migration
Page 178 of 483
Migrating a Physical Machine or Virtual Machine to an everRun 7.x System
Open the everRun Availability Console and remove any migrated volumes associated with the source PM or VM. If you want to restart the migration process, reboot the P2V client on the source
PM or VM.
To recover from a failed migration
If the migration process fails, an error message is displayed in the P2V client on the source PM or
VM. Another message may be displayed on the everRun system. Use these messages to determine the problem.
If the migration continues to fail, and the option is available, enable server-side debugging. After the migration, generate a diagnostic file to send to your authorized Stratus service representative, as described in
"Creating a Diagnostic File" on page 87
. The diagnostic file includes any server-side debugging messages from the migration process.
To recover from a migration that fails with the error message,
Failed to mount
'/dev/sda1: Operation not permitted
For Windows-based VMs, if the migration process fails with the following error message, it may indicate that fast startup mode is enabled:
Failed to mount '/dev/sda1': Operation not permitted
The NTFS partition is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting), or mount the volume read-only with the 'ro' mount option.
To resolve the issue, log on to the guest operating system of the source VM, disable fast startup mode, and shut down the operating system. Then, restart the migration process.
To recover when a newly migrated Linux-based VM is stuck in the "booting" state
A Linux-based VM may fail to exit the booting state in everRun Availability Console if the VM's network is offline.
During the migration process, the P2V client attempts to set a new MAC address for each network interface to prevent conflicts with the original VM. Some Linux-based operating systems detect a new MAC address and automatically create a new network interface for it while still retaining the original interface. The guest operating system boots, but the network may remain offline until you manually configure the network settings.
Page 179 of 483
everRun User's Guide
To correct the problem, open the VM console, log on to the guest operating system, and update the network startup scripts. Ensure that you retain only one entry for each network interface, and that each interface uses a unique MAC address and correct network settings for your environment.
To recover missing data volumes in the VM on the everRun system
If your data volumes do not appear in the VM on the everRun system after the import, you may need to manually restore the volumes, as follows: l
Shut down the VM, run the Reprovision Virtual Machine wizard, and verify that you have included the volumes on the Volumes page.
l
For Windows-based VMs, use Disk Management to bring data volumes online.
l
For Linux-based VMs, edit the
/etc/fstab file to reflect the new device names for the storage devices, from Avance (
/dev/xvda through
/dev/xvdh
) to everRun
(
/dev/vda through
/dev/vdh
). Device names also may have shifted, for example, if volumes were not included in the import.
To recover missing network devices in the VM on the everRun system
If your network devices do not appear in the VM on the everRun system after the import , you may need to manually restore them, as follows: l
Shut down the VM, run the Reprovision Virtual Machine wizard, and verify that you have included the networks on the Networks page.
l
For Linux-based VMs, reconfigure the network startup script to reflect the new device names for the network interfaces.
Related Topics
"Migrating From Avance or everRun MX Systems" on page 119
"Creating and Migrating Virtual Machines" on page 161
"Configuring Windows-based Virtual Machines" on page 217
"Configuring Linux-based Virtual Machines" on page 224
"Managing Virtual Machine Resources" on page 232
"Managing the Operation of a Virtual Machine" on page 227
Migrating a Windows Server 2003 VM to an everRun 7.x System
Page 180 of 483
Migrating a Windows Server 2003 VM to an everRun 7.x System
Follow these instructions to migrate a Windows Server 2003 virtual machine (VM) from an Avance unit or an everRun MX system to a destination everRun 7.2 or later system. You should understand the following considerations before you migrate the Windows Server 2003 VM: l
The Windows Server 2003 operating system is no longer supported by Microsoft.
l
The only version of Windows Server 2003 that everRun systems support is the Windows Server
2003 R2 Enterprise SP2 32-bit operating system.
l
The destination system must be running everRun software release 7.2 or later.
To migrate the VM, boot the P2V client (virt-p2v) in the source Windows Server 2003 VM and use the client to configure, initiate, and monitor a secure network transfer from source side. To begin, follow the appropriate procedure: To prepare for migrating a Windows Server 2003 VM from your source system, and then continue with To migrate a Windows Server 2003 VM from Avance or everRun MX system .
To prepare for migrating a Windows Server 2003 VM from an Avance unit
1. Download the P2V client ISO file from the Drivers and Tools section of the Downloads page at http://www.stratus.com/go/support/everrun .
a. On the Downloads page, click everRun (if it is not already displayed) and then select the appropriate version.
b. Scroll down to Drivers and Tools and then continue scrolling to everRun P2V Client for Virtual or Physical Machine Migration.
c. Select the P2V Client (virt-p2v) file.
2. If you want to verify the integrity of the ISO image, also download the associated fciv checksum file, and then download the Microsoft File Checksum Integrity Verifier (FCIV) executable file from the Microsoft Support Website. Save both files to the directory that contains the downloaded ISO file.
Open a command prompt. From the directory containing the ISO, executable, and verification files, type a command similar to the following to verify the ISO image: fciv -v -xml virt-p2v-n.n.n-n.nnnnnnnn.n.el6.centos.xml
If the command succeeds (that is, it returns the message All files verified successfully
), go to the next step. If the command fails, repeat the download.
Page 181 of 483
everRun User's Guide
3. In the Avance Management Console, use the P2V client ISO file to create a VCD that you will boot in the Windows Server 2003 VM to transfer it to the everRunsystem.
4. On the Virtual Machines page, select the Windows Server 2003 VM and click Shutdown.
5. When the Windows Server 2003 VM is stopped, click Boot from CD.
6. In the Boot from a CD dialog box, select the P2V client VCD and click Boot.
To prepare for migrating a Windows Server 2003 VM from an everRun MX system
1. Download the P2V client ISO file from the Drivers and Tools section of the Downloads page at http://www.stratus.com/go/support/everrun .
2. Burn the P2V client ISO file to a physical CD that you will boot in the Windows Server 2003
VM to transfer it to the everRun 7.2 or later system.
3. Perform steps 1 through 9 in the To migrate VMs from the everRun MX node to the everRun
7.x node section of "Converting an everRun MX System to an everRun 7.x System" on page
122 to shut down the Windows Server 2003 VM and boot it from the P2V client CD.
To migrate a Windows Server 2003 VM from an Avance or everRun MX system
1. In the virt-p2v window, fill in the destination everRun system's host name (or host
IP address) and password. Click Test connection and Next.
2. In the next virt-p2v window, click Start conversion.
You can monitor the progress of the migration in the virt-p2v window and on the Volumes page of the destination everRun system's everRun Availability Console as volumes associated with the new VM begin to appear.
3. When the migration is complete, the virt-p2v window displays a success message. Click
Power Off to shut down the source VM.
4. In the destination everRun system's everRun Availability Console, click Virtual Machines.
5. Select the newly created VM and click Start.
6. Log on to the Windows Server 2003 guest operating system.
7. A service control manager warning about a driver failing during system startup appears.
Click OK.
8. In the Found New Hardware wizard, select No, not this time and click Next.
Page 182 of 483
Importing an OVF File from an everRun MX System
9. Select Install the software automatically. Click Next.
10. A warning about the RedHat VirtIO Ethernet Adapter not passing Windows Logo testing appears. Click Continue Anyway.
11. When the Found New Hardware wizard completes, click Finish.
12. A warning about the RedHat VirtIO SCSI Adapter not passing Windows Logo testing appears. Click Continue Anyway.
13. The Found New Hardware wizard displays a Cannot Install this Hardware message.
Select Don't prompt me again to install this software and click Finish.
14. At the prompt to restart the computer, click Yes.
15. A service control manager warning about a driver failing during system startup appears again. Click OK.
16. If necessary, update the network configuration settings in the guest operating system and restart it to enable the settings.
After you verify that the new VM is functioning properly, the migration process is complete; however, the everRun system may continue to synchronize data between PMs to enable High Availability (HA) or Fault Tolerant (FT) operation.
Related Topics
"Migrating From Avance or everRun MX Systems" on page 119
"Creating and Migrating Virtual Machines" on page 161
"Configuring Windows-based Virtual Machines" on page 217
"Managing Virtual Machine Resources" on page 232
"Managing the Operation of a Virtual Machine" on page 227
Importing an OVF File from an everRun MX System
Import an Open Virtualization Format (OVF) file from an everRun MX system if you want to transfer a
VM to the everRun 7.
x system for deployment. (To migrate a physical machine (PM) or virtual machine
x system without using an OVF file, see "Migrating a Physical Machine or Virtual
Machine to an everRun 7.x System" on page 171 .)
Page 183 of 483
everRun User's Guide
To import a VM from an everRun MX system, first use XenConvert 2.1 to export OVF and Virtual Hard
Disk (VHD) files from the everRun MX system to a network share, and then use the everRun Availability
Console to import the OVF and VHD files from the network share to the everRun 7.
x system.
Caution: Consider backing up your source VM before preparing it for export from the everRun
MX system.
Page 184 of 483
Importing an OVF File from an everRun MX System
Notes: l
You can import only VMs running Windows Server 2008 from everRun MX systems.
Importing a Windows Server 2003 VM from an OVF file is not supported. If you need to
transfer a Windows Server 2003 VM to an everRun 7.
x system, see "Migrating a Windows Server 2003 VM to an everRun 7.x System" on page 180 .
l
For Windows-based VMs, you must install VirtIO drivers in the guest operating system before exporting the VM from the everRun MX system, as described in this topic. If you do not install the VirtIO drivers, the imported VM crashes while booting on the everRun
7.
x system.
l
You need to map a network share that is accessible from the source VM on the everRun
MX system and also accessible by the management PC running the everRun Availability Console. You use XenConvert to export the VM to this share, then you import the
VM to the everRun 7.
x system from this share.
l
In preparation for exporting the OVF file from the everRun MX system, you must unprotect the VM in the everRun Availability Center, which automatically shuts down the VM.
Consider scheduling a planned maintenance period for this process.
l
The time required for the export and import depends on the size and number of volumes in the source VM as well as network bandwidth. For example, transferring a VM with one 20 GB boot volume over a 1 Gb/s network may take about 30 minutes each way, export and import.
l
When you import the VM on the everRun 7.x system, the import wizard creates a new instance of the VM with unique hardware IDs. The import wizard does not offer the
Restore option that creates an identical VM with the same hardware IDs (SMBIOS
UUID, system serial number, and MAC addresses), because the export files from ever-
Run MX systems do not include this information.
l
If you will continue to use the source VM on the everRun MX system after the import, remember to set a different IP address and hostname for the VM on the everRun 7.
x system.
l
If the everRun 7.
x system switches from the primary PM to the secondary PM during an import, the import process fails. This does not affect the continuous uptime of your
Page 185 of 483
everRun User's Guide system, but you must delete the incomplete VM and associated volumes on the ever-
Run 7.
x system, and import them again.
Exporting an OVF File from the everRun MX System
Exporting a VM from the everRun MX system exports the VM's configuration in an OVF file along with a copy of the selected volumes on your management PC.
To prepare for exporting a VM from the everRun MX system
1. Log on to the everRun Availability Center with the hostname or IP address of your ever-
Run MX master node at: http:// everRunMX-system :8080
2. In the left-hand navigation panel, click Virtual Machines.
3. Right-click a VM that you want to export and click Unprotect.
4. When the VM is unprotected and automatically shut down, open Citrix XenCenter.
5. In the left-hand navigation panel of XenCenter, locate and expand the entry for the everRun
MX system. Click the VM that you want to export, and click Start.
6. Click the Console tab to open the console of the VM and log on to the Windows guest operating system.
7. Ensure that all volumes are labeled accurately, as summarized in "Managing Windows
8. Run the Windows System Preparation Tool (
Sysprep
) to prepare the guest operating system for redeployment.
9. Install the VirtIO drivers and the XenConvert utility in the Windows guest operating system: a. Download the VirtIO.exe driver installation utility from the Drivers and Tools section of the Downloads page at http://www.stratus.com/go/support/everrun to the guest operating system. This installation utility installs the VirtIO drivers and also the
XenConvert utility required for an export from the everRun MX system.
b. Right-click the installation utility and click Run as administrator.
c. Click OK to install the software, and monitor the progress in the command prompt window.
Page 186 of 483
Importing an OVF File from an everRun MX System d. Click Restart Later when Windows prompts you to restart the guest operating system.
Note: Windows prompts you to restart while the installation utility is still working. Do not restart the VM until you complete the following steps; otherwise, the driver installation fails and your imported VM will not boot on the everRun 7.
x system.
e. Wait until the command prompt window indicates that the installation is finished and prompts you to Press any key to continue.
f. Click the command prompt window to make it the active window, then press any key and wait for command prompt window and WinZip window to close.
g. Restart the guest operating system to load the new drivers.
You can optionally uninstall the VirtIO drivers and the XenConvert utility after a successful import, as described later in this topic.
To export the VM and boot volume from the everRun MX system
1. In the Windows guest operating system on the everRun MX system, map a network share to which you will export the VM. For example, you can access a network share on your management PC that runs the everRun Availability Console.
2. Start Citrix XenConvert in the source VM.
3. Verify that From: This machine is selected.
4. Select To: Open Virtualization Format (OVF) Package. Click Next.
5. Select only the (Boot) volume to export. Explicitly deselect other volumes by clicking the
Source Volume pulldown menu and selecting None. Do not change any other settings on this page. Click Next.
Note: You can export only one volume at a time; otherwise, the export fails. See the next procedure to export additional volumes.
Page 187 of 483
everRun User's Guide
6. Specify a path in the Please choose a folder to store the Open Virtualization (OVF) package text area. Click Browse and select a new, empty folder on the network share that you mounted for the export.
7. Ensure that the following XenConvert options are disabled. These options are not supported, and they can prevent a successful import: n
Include a EULA in the OVF package n
Create Open Virtual Appliance (OVA) n
Compress Open Virtual Appliance (OVA) n
Encrypt n
Sign with Certificate
8. Click Next.
9. Optionally modify the name of the target OVF file. Click Next.
10. Click Convert.
Note: During the export process, if Windows displays a message indicating that you need to format a hard disk to use it, you can click Cancel to dismiss this message. The export continues normally.
To export each additional volume from the VM on the everRun MX system
1. Restart Citrix XenConvert on the source VM.
2. Verify that From: This machine is selected.
3. Select To: XenServer Virtual Hard Disk (VHD). Click Next.
4. Select only one volume to export. Explicitly deselect other volumes by clicking the Source
Volume pulldown menu and selecting None.
Do not change any other settings on this page. Click Next
5. Specify a path in the Please choose a folder to store the Open Virtualization (OVF) package text area. Click Browse and select a new, empty folder on the network share that you mounted for the export. Click Next.
Page 188 of 483
Importing an OVF File from an everRun MX System
Note: XenConvert does not give the option of specifying VHD file names, so each VHD export must initially be stored in a different folder to avoid overwriting the previous files.
6. Click Convert. This creates a VHD file and a PVP file.
7. After the VHD export, rename the new VHD file to give it a new, unique name and move it to the folder with the boot volume OVF and VHD. The PVP file is not used.
8. Repeat this procedure for each additional volume.
Importing the OVF file to the everRun 7.
x System
Importing a VM to the everRun 7.
x system imports the VM's configuration and any associated volumes that you select from your exported files.
Prerequisites: l
The selected OVF file (boot volume) and all associated VHD files (additional volumes) must be in the same directory, and no other VHD files can be in that directory.
l
Both PMs of the everRun 7.
x system must be online for the import process to function properly.
To import a VM to the everRun 7.
x system
1. If applicable, on your management PC, map the network share containing the exported OVF and VHD files.
2. Log on to the everRun 7.
x system with the everRun Availability Console.
3. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify
that both PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
4. On the Virtual Machines page (see
"The Virtual Machines Page" on page 100 ), click
Import/Restore to open the import wizard.
5. Click Browse. In the file browser, select the .ovf file that you want to import from your management PC and click Import.
6. Click Import to create a new instance of the VM with unique hardware IDs.
Page 189 of 483
everRun User's Guide
7. When prompted, click Browse and select a .vhd file to include for each volume associated with the VM.
8. Review the information and make any desired edits, if necessary: n
Name, CPU, and Memory
Change the name of the virtual machine, edit the number of vCPUs, or allocate the total memory it can use.
n
Storage
Shows all of the volumes. Select the Create box for a volume to allocate a storage container for the volume on the everRun 7.
x system (the boot volume is required).
Select the Restore Data box to import data for a volume from the OVF file.
n
Network
Displays all of the available networks. You can remove a network or add one that is not already allocated. A minimum of one network is required.
9. Optionally, clear the check box for Auto start Virtual Machine after import if you need to reprovision the VM before starting it for the first time on the everRun 7.
x system.
10. Click Import to begin importing the VM. When the transfer is complete, click Done to close the import wizard.
Note: Imported volumes begin to appear on the Volumes page of the everRun
Availability Console while the import is still in progress. Do not attach or remove any of these imported volumes until the import window reports that the process is complete; otherwise, the import fails.
11. If applicable, use the Reprovision Virtual Machine wizard to allocate additional resources to the VM, as described in
"Reprovisioning Virtual Machine Resources" on page 233 .
When you are finished reprovisioning the VM, click Start to boot the VM.
12. Click Console to open the console of the VM and log on to the guest operating system.
13. Update the VirtIO drivers to the latest supported versions, as described in "Updating the
VirtIO Drivers (Windows-based VMs)" on page 218 .
14. If necessary, update the network settings in the guest operating system.
Page 190 of 483
Importing an OVF File from an everRun MX System
After you verify that the new VM is functioning properly, the import process is complete; however, the everRun 7.
x system continues to synchronize data between PMs to enable High Availability
(HA) or Fault Tolerant (FT) operation.
Note: Your new VM and its associated volumes may be marked with warning symbols until the data has been synchronized and the VirtIO drivers are running.
To optionally uninstall the VirtIO drivers from the source VM on the everRun MX system
(Windows-based VMs only)
After you successfully import the new VM to the everRun 7.
x system, you can uninstall the VirtIO drivers and the XenConvert utility from the Windows-based source VM on the everRun MX system.
However, uninstalling this software is optional, as it does not interfere with the operation of the VM.
1. In the console of the source Windows-based VM, locate the VirtIO.exe installation utility.
(This same utility is used to uninstall the VirtIO drivers if they are present.)
2. Right-click the installation utility and click Run as administrator.
3. Click OK to uninstall the VirtIO drivers, and monitor the progress in the command prompt session.
4. When prompted, press any key to close the utility. No restart is necessary.
Troubleshooting
If necessary, use the following information to resolve problems with the export or import process.
To clean up after a canceled or failed export from the everRun MX system
In the Windows guest operating system, consider saving log file information from XenConvert, then close the utility. Remove all of the files from the export folder on your network share, or create a new folder for a subsequent export. You must select an empty folder for each new export.
To clean up after a canceled or failed import on the everRun 7.
x system
In the everRun Availability Console, remove the imported VM and any volumes associated with the imported VM.
To recover from a failed export from the everRun MX system
Page 191 of 483
everRun User's Guide
The export fails if you export more than one volume at a time. Run XenConvert again and be careful to explicitly deselect all but one volume for the export. Also, ensure that you use an empty folder for each new export.
To recover from a failed import to the everRun 7.
x system
The imported VM crashes if the VirtIO drivers are not present in a Windows-based VM. Before running the XenConvert export again, ensure that you install the VirtIO drivers in the VM on the ever-
Run MX system.
To recover missing data volumes in the VM on the everRun 7.
x system
If your data volumes do not appear in the VM on the everRun 7.
x system after the import, you may need to manually restore the volumes, as follows: l
Shut down the VM, run the Reprovision Virtual Machine wizard, and verify that you have included the volumes on the Volumes page.
l
Use Disk Management to bring data volumes online.
To recover missing network devices in the VM on the everRun 7.
x system
Shut down the VM, run the Reprovision Virtual Machine wizard, and verify that you have included the networks on the Networks page.
Related Topics
"Migrating From Avance or everRun MX Systems" on page 119
"Creating and Migrating Virtual Machines" on page 161
"Configuring Windows-based Virtual Machines" on page 217
"Configuring Linux-based Virtual Machines" on page 224
"Managing Virtual Machine Resources" on page 232
"Managing the Operation of a Virtual Machine" on page 227
Importing an OVF File from an Avance System
Import an Open Virtualization Format (OVF) file from an Avance unit if you want to transfer a VM to the everRun 7.
x system for deployment. (To migrate a physical machine (PM) or virtual machine (VM) to the
Page 192 of 483
Importing an OVF File from an Avance System
To import a VM from an Avance unit, first use the Avance Management Console to export OVF and hard disk files to a management PC, and then use the everRun Availability Console to import the OVF and hard disk files from the management PC to the everRun system.
When you import a VM image in the everRun Availability Console, the import wizard allows you to choose between importing or restoring the VM. Importing a VM creates a new instance of the VM with unique hardware IDs. Restoring a VM creates an identical VM with the same hardware IDs (SMBIOS UUID, system serial number, and MAC addresses, if provided in the VM image) that your guest operating system and applications may require for software licensing. To prevent conflicts with the original VM, restore a VM only if you want to transfer it to the everRun system and stop using it on the source system.
Caution: Consider backing up your source VM before preparing it for export from the Avance unit.
Page 193 of 483
everRun User's Guide
Notes: l
You can import only VMs running CentOS/RHEL 6, Windows 7, Windows Server 2008, or Ubuntu 12.04 or later from Avance units.
l
Windows Server 2003 VM from an OVF file is not supported.
l
For Windows-based VMs, you must install VirtIO drivers in the guest operating system before exporting the VM from the Avance unit, as described in this topic. If you do not install the VirtIO drivers, the imported VM crashes while booting on the everRun 7.
x system.
l
For Linux-based VMs, before exporting the VM from the Avance unit, consider editing the
/etc/fstab file to comment out entries for data volumes and allow only the boot volume to mount. Because Linux-based VMs use different device names on the ever-
Run system, your new VM may boot into single-user mode if it cannot mount the volumes with their original device names. You can restore the
/etc/fstab entries in the new VM with the correct device names after the import process, as described below in Troubleshooting.
l
For Ubuntu-based VMs, you must edit the /boot/grub/grub.cfg
file and change the gfxmode parameter to text
(for example, set gfxmode=text
) before exporting the VM from the Avance unit; otherwise, the new VM's console hangs on the everRun system. You can restore the original setting in the source VM after the migration.
l
Your source VM must be shut down while you are exporting the OVF file or creating a snapshot on the Avance unit. Consider scheduling a planned maintenance period for this process.
l
The time required for the export and import depends on the size and number of volumes in the source VM as well as network bandwidth. For example, transferring a VM with one 20 GB boot volume over a 1 Gb/s network may take about 30 minutes each way, export and import.
Page 194 of 483
Importing an OVF File from an Avance System l
To prevent conflicts with the source VM on the Avance unit, the import wizard automatically assigns a new MAC address to each network interface in the new VM; however, you may need to manually update any IP addresses and host names as needed.
l
If the everRun system switches from the primary PM to the secondary PM during an import, the import process fails. This does not affect the continuous uptime of your system, but you must delete the incomplete VM and associated volumes on the everRun system, and import them again.
Exporting an OVF File from the Avance Unit
Exporting a VM from the Avance unit exports the VM's configuration in an OVF file along with a copy of the selected volumes on your management PC.
To prepare for exporting a VM from the Avance unit (Windows-based VMs only)
1. Log on to the Avance unit with the Avance Management Console.
2. On the Virtual Machines page, select the VM to export.
3. Click Console to open the console of the VM and log on to the Windows guest operating system.
4. Ensure that all volumes are labeled accurately, as summarized in "Managing Windows
5. Run the Windows System Preparation Tool (
Sysprep
) to prepare the guest operating system for redeployment.
6. Install the VirtIO drivers in the Windows guest operating system: a. Download the VirtIO.exe driver installation utility from the Drivers and Tools section of the Downloads page at http://www.stratus.com/go/support/everrun to the guest operating system.
b. Right-click the installation utility and click Run as administrator.
c. Click OK to install the VirtIO drivers, and monitor the progress in the command prompt window.
d. Click Restart Later when Windows prompts you to restart the guest operating system.
Page 195 of 483
everRun User's Guide
Note: Windows prompts you to restart while the installation utility is still working. Do not restart the VM until you complete the following steps; otherwise, the driver installation fails and your imported VM will not boot on the everRun system.
e. Wait until the command prompt window indicates that the VirtIO driver installation is finished and prompts you to Press any key to continue.
f. Click the command prompt window to make it the active window, then press any key and wait for command prompt window and WinZip window to close.
g. Restart the guest operating system to load the new drivers.
Installing the VirtIO drivers also installs the XenConvert utility required for exports from everRun MX systems; however, this utility is not used on Avance units. You can optionally uninstall the VirtIO drivers and the XenConvert utility after a successful import, as described later in this topic.
To export a VM from the Avance unit
The following procedure describes how to export a VM from Avance, but you can also create a snapshot and export the snapshot to reduce downtime for the source VM. To create a snapshot, see the
Avance online help.
1. Log on to the Avance unit with the Avance Management Console.
2. On the Virtual Machines page, select the VM to export.
3. With the VM selected, click Shutdown and wait for the VM to power off.
4. Click Export to display the export wizard.
5. If prompted, allow the required Java™ plugins to load in your web browser.
6. Click Export VM. (Click Export Snapshot if you created a snapshot.)
7. Click Browse. Select a location for the export on your management PC running the Avance
Management Console and click Save.
8. Select the volumes you want capture, or click VM Configuration Only to include only the configuration details of each volume in the export file, but not the data.
9. Click Export.
Page 196 of 483
Importing an OVF File from an Avance System
Importing the OVF file to the everRun System
Importing a VM to the everRun system imports the VM's configuration and any associated volumes that you select from the OVF export on your management PC.
Prerequisite: Both PMs of the everRun system must be online for the import process to function properly.
To import a VM to the everRun system
1. Log on to the everRun system with the everRun Availability Console.
2. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify
that both PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
3. On the Virtual Machines page (see
"The Virtual Machines Page" on page 100 ), click
Import/Restore to open the import wizard.
4. Click Browse. In the file browser, select the .ovf file that you want to import from your management PC and click Import.
5. Select Import or Restore. Import creates a new instance of the VM with unique hardware
IDs. Restore creates an identical VM with the same hardware IDs that are provided in the
OVF file.
6. When prompted, click Browse and select a .vhd file to include for each volume associated with the VM.
7. Review the information and make any desired edits, if necessary: n
Name, CPU, and Memory
Change the name of the virtual machine, edit the number of vCPUs, or allocate the total memory it can use.
n
Storage
Shows all of the volumes. Select the Create box for a volume to allocate a storage container for the volume on the everRun system (the boot volume is required). Select the Restore Data box to import data for a volume from the OVF file.
n
Network
Page 197 of 483
everRun User's Guide
Displays all of the available networks. You can remove a network or add one that is not already allocated. A minimum of one network is required.
8. Optionally, clear the check box for Auto start Virtual Machine after import if you need to reprovision the VM before starting it for the first time on the everRun system.
9. Click Import to begin importing the VM. When the transfer is complete, click Done to close the import wizard.
Note: Imported volumes begin to appear on the Volumes page of the everRun
Availability Console while the import is still in progress. Do not attach or remove any of these imported volumes until the import window reports that the process is complete; otherwise, the import fails.
10. If applicable, use the Reprovision Virtual Machine wizard to allocate additional resources to the VM, as described in
"Reprovisioning Virtual Machine Resources" on page 233 .
When you are finished reprovisioning the VM, click Start to boot the VM.
11. Click Console to open the console of the VM and log on to the guest operating system.
12. For Windows-based VMs only, update the VirtIO drivers to the latest supported versions, as described in
"Updating the VirtIO Drivers (Windows-based VMs)" on page 218 .
13. If necessary, update the network settings in the guest operating system.
After you verify that the new VM is functioning properly, the import process is complete; however, the everRun system may continue to synchronize data between PMs to enable High Availability
(HA) or Fault Tolerant (FT) operation.
Note: Your new VM and its associated volumes may be marked with warning symbols until the data has been synchronized and the VirtIO drivers are running.
To optionally uninstall the VirtIO drivers from the source VM on the Avance unit (Windowsbased VMs only)
After you successfully import the new VM to the everRun system, you can uninstall the VirtIO drivers and the XenConvert utility from the Windows-based source VM on the Avance unit.
However, uninstalling this software is optional, as it does not interfere with the operation or continuous uptime of the Avance unit.
Page 198 of 483
Importing an OVF File from an Avance System
1. In the console of the source Windows-based VM, locate the VirtIO.exe installation utility.
(This same utility is used to uninstall the VirtIO drivers if they are present.)
2. Right-click the installation utility and click Run as administrator.
3. Click OK to uninstall the VirtIO drivers, and monitor the progress in the command prompt session.
4. When prompted, press any key to close the utility. No restart is necessary.
Troubleshooting
If necessary, use the following information to resolve problems with the export or import process.
To clean up after a canceled or failed export from the Avance unit
On your management PC, remove all of the files from the export folder or create a new folder for a subsequent export.
To clean up after a canceled or failed import on the everRun system
In the everRun Availability Console, remove the imported VM and any volumes associated with the imported VM.
To recover from a failed import to the everRun system
The imported VM crashes if the VirtIO drivers are not present in a Windows-based VM. Before running the export again, ensure that you install the VirtIO drivers in the VM on the Avance unit.
To recover when the new VM's console hangs on the everRun system
For Ubuntu-based VMs, the VM console hangs in everRun Availability Console if you do not properly set the gfxmode parameter before the import process (as described in Notes). If the
VM console hangs, keep restarting the VM until the console opens properly in everRun Availability
Console and then modify the gfxmode parameter to prevent subsequent issues.
To recover missing data volumes in the VM on the everRun system
If your data volumes do not appear in the VM on the everRun system after the import, you may need to manually restore the volumes, as follows: l
Shut down the VM, run the Reprovision Virtual Machine wizard, and verify that you have included the volumes on the Volumes page.
Page 199 of 483
everRun User's Guide l
For Windows-based VMs, use Disk Management to bring data volumes online.
l
For Linux-based VMs, edit the
/etc/fstab file to reflect the new device names for the storage devices, from Avance ( /dev/xvda through /dev/xvdh ) to everRun
(
/dev/vda through
/dev/vdh
). Device names also may have shifted, for example, if volumes were not included in the import.
To recover missing network devices in the VM on the everRun system
If your network devices do not appear in the VM on the everRun system after the import , you may need to manually restore them, as follows: l
Shut down the VM, run the Reprovision Virtual Machine wizard, and verify that you have included the networks on the Networks page.
l
For Linux-based VMs, reconfigure the network startup script to reflect the new device names for the network interfaces.
Related Topics
"Migrating From Avance or everRun MX Systems" on page 119
"Creating and Migrating Virtual Machines" on page 161
"Configuring Windows-based Virtual Machines" on page 217
"Configuring Linux-based Virtual Machines" on page 224
"Managing Virtual Machine Resources" on page 232
"Managing the Operation of a Virtual Machine" on page 227
Importing an OVF File from an everRun 7.
x System
Import Open Virtualization Format (OVF) file from an everRun system if you want to transfer a VM from one everRun 7.
x system to another, or if you want to transfer an image that you created back to the same everRun 7.
x system to restore or duplicate the original VM. (To migrate a physical machine (PM) or virtual
machine (VM) to the everRun 7.
x system without using an OVF file, see "Migrating a Physical Machine or
Virtual Machine to an everRun 7.x System" on page 171 .)
To import a VM image from an everRun system, first use the everRun Availability Console on the source
VM snapshot ( "Exporting a Snapshot" on page 258
) to OVF and Virtual Hard Disk (VHD) files on a supported network share. Copy these files to your management PC (or mount the network share), and then
Page 200 of 483
Importing an OVF File from an everRun 7.x System use the everRun Availability Console on the target everRun system to import the OVF and VHD files from your management PC.
When you import a VM image in the everRun Availability Console, the import wizard allows you to choose between importing or restoring the VM. Importing a VM creates a new instance of the VM with unique hardware IDs. Restoring a VM creates an identical VM with the same hardware IDs (SMBIOS UUID, system serial number, and MAC addresses, if provided in the VM image) that your guest operating system and applications may require for software licensing. To prevent conflicts with the original VM, restore a VM only if you want to transfer it to the everRun system and stop using it on the source system.
If you want to restore an existing VM on the same everRun system to overwrite the VM and recover it from a previous backup copy, see
"Replacing a Virtual Machine from an OVF File" on page 205 .
Page 201 of 483
everRun User's Guide
Notes: l
You can import VMs only if they are running supported guest operating systems, as described in
"Compatible Guest Operating Systems" on page 472
.
l
The time required for the import depends on the size and number of volumes in the source VM as well as network bandwidth. For example, transferring a VM with one
20 GB boot volume over a 1 Gb/s network may take about 30 minutes.
l
When you import or restore an everRun VM, the original container size for each volume you include is not preserved. For example, if your source VM has a 20 GB boot volume in a 40 GB volume container, the target VM will have a 20 GB boot volume in a 20 GB volume container. If necessary, you can expand the volume containers on the target sys-
tem as described in "Expanding a Volume Container on the everRun System" on page
l
If you are importing a VM back to the same everRun system to duplicate the VM, you must rename the VM and duplicate volumes during either the export or import process.
l
To prevent conflicts with the source VM, the import wizard automatically assigns a new
MAC address to each network interface in the new VM; however, you may need to manually update any IP addresses and host names as needed.
l
If the everRun system switches from the primary PM to the secondary PM during an import, the import process fails. This does not affect the continuous uptime of your system, but you must delete the incomplete VM and associated volumes on the everRun system, and import them again.
Prerequisite: Both PMs of the everRun system must be online for the import process to function properly.
To import a VM to the everRun system
1. Export a VM or a VM snapshot from the source everRun system.
2. Copy the exported OVF and VHD files to the management PC that you use to run the everRun
Availability Console, or mount the export network share that contains these files.
3. Log on to the everRun Availability Console on the target everRun system.
Page 202 of 483
Importing an OVF File from an everRun 7.x System
4. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify that both
PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
5. On the Virtual Machines page (see
"The Virtual Machines Page" on page 100 ), click
Import/Restore to open the import wizard.
6. Click Browse. In the file browser, locate the exported files. Select the .ovf file that you want to import, and click Import.
7. Select Import or Restore. Import creates a new instance of the VM with unique hardware IDs.
Restore creates an identical VM with the same hardware IDs that are provided in the OVF file.
8. When prompted, click Browse and select a .vhd file to include for each volume associated with the
VM.
9. Review the information and make any desired edits, if necessary: n
Name, CPU, and Memory
Change the name of the virtual machine, edit the number of vCPUs, or allocate the total memory it can use.
n
Storage
Shows all of the volumes. Select the Create box for a volume to allocate a storage container for the volume on the everRun system (the boot volume is required). Select the
Restore Data box to import data for a volume from the VHD file.
If the target everRun system has more than one storage group, you can also select the storage group in which to create each volume. Ensure that you select a Destination group that
wizard cannot convert the sector size of a volume). Note that the boot volume must have a sector size of 512 B. You can select the sector size, either 4K or 512B, only for data disks.
n
Network
Displays all of the available networks. You can remove a network or add one that is not already allocated. A minimum of one network is required.
Page 203 of 483
everRun User's Guide
10. Optionally, clear the check box for Auto start Virtual Machine after import if you need to reprovision the VM before starting it for the first time on the everRun system.
11. Click Import to begin importing the VM. When the transfer is complete, click Done to close the import wizard.
Note: Imported volumes begin to appear on the Volumes page of the everRun Availability Console while the import is still in progress. Do not attach or remove any of these imported volumes until the import window reports that the process is complete; otherwise, the import fails.
12. If applicable, use the Reprovision Virtual Machine wizard to allocate additional resources to the
VM, as described in
"Reprovisioning Virtual Machine Resources" on page 233 . Also, if you want to
When you are finished reprovisioning the VM, click Start to boot the VM.
13. Click Console to open the console of the VM and log on to the guest operating system.
14. For Windows-based VMs only, download and update the VirtIO drivers to the latest supported versions, as described in
"Updating the VirtIO Drivers (Windows-based VMs)" on page 218 . (The cor-
rect VirtIO drivers are already present in Linux-based VMs.)
Note: After updating the drivers, you may need to restart the guest operating system.
15. If necessary, update the network settings in the guest operating system.
After you verify that the new VM is functioning properly, the import process is complete; however, the ever-
Run system may continue to synchronize data between PMs to enable High Availability (HA) or Fault Tolerant (FT) operation.
Note: Your new VM and its associated volumes may be marked with warning symbols until the data has been synchronized and the VirtIO drivers are running.
Troubleshooting
If necessary, use the following information to resolve problems with the export or import process.
To clean up after a canceled or failed import
Page 204 of 483
Replacing a Virtual Machine from an OVF File
In the everRun Availability Console on the target system, remove the imported VM and any volumes associated with the imported VM.
To recover missing data volumes in the target VM
If your data volumes do not appear in the VM on the target everRun system after the import, you may need to manually restore the volumes, as follows: l
Shut down the VM, run the Reprovision Virtual Machine wizard, and verify that you have included the volumes on the Volumes page.
l
For Windows-based VMs, use Disk Management to bring data volumes online.
l
For Linux-based VMs, edit the /etc/fstab file to reflect the new device names for the storage devices. Device names may have shifted, for example, if volumes were not included in the import.
To recover missing network devices in the VM on the everRun system
If your network devices do not appear in the VM on the target everRun system after the import , you may need to manually restore them, as follows: l
Shut down the VM, run the Reprovision Virtual Machine wizard, and verify that you have included the networks on the Networks page.
l
For Linux-based VMs, reconfigure the network startup script to reflect the new device names for the network interfaces.
Related Topics
"Migrating From Avance or everRun MX Systems" on page 119
"Creating and Migrating Virtual Machines" on page 161
"Configuring Windows-based Virtual Machines" on page 217
"Configuring Linux-based Virtual Machines" on page 224
"Managing Virtual Machine Resources" on page 232
"Managing the Operation of a Virtual Machine" on page 227
Replacing a Virtual Machine from an OVF File
Page 205 of 483
everRun User's Guide
Replace a virtual machine (VM) from an Open Virtualization Format (OVF) file if you want to restore a
VM on your everRun system by overwriting the VM with a previous backup copy. (If you want to import a
VM from a different system, see the overview in
"Creating and Migrating Virtual Machines" on page 161
.)
Typically, importing a VM creates a new instance of the VM with unique hardware IDs. Restoring a VM creates an identical VM with the same SMBIOS UUID, system serial number, and MAC addresses, if provided in the VM image, that your guest operating system and applications may require for software licensing. The hardware ID, though, of the restored VM is unique. If an identical VM already exists on the everRun system, restoring the VM allows you to replace the VM and overwrite it with your previous copy.
You can restore a VM that already exists on an everRun system only if you have previously exported a VM
( "Exporting a Virtual Machine from an everRun System" on page 210
) or a VM snapshot ( "Exporting a
Snapshot" on page 258 ) to OVF and Virtual Hard Disk (VHD) files on a supported network share. Copy
these files to your management PC (or mount the network share), and then use the everRun Availability
Console on the target everRun system to restore the OVF and VHD files from your management PC.
Caution: Consider backing up your existing VM on the everRun system before overwriting and restoring it. If you export the VM or another snapshot to create the backup, ensure that you do not overwrite the OVF and VHD files that you want to restore.
Page 206 of 483
Replacing a Virtual Machine from an OVF File
Notes: l
The time required to restore a VM depends on the size and number of volumes in the source VM as well as network bandwidth. For example, transferring a VM with one
20 GB boot volume over a 1 Gb/s network may take about 30 minutes.
l
If you overwrite and restore an existing VM, the everRun system removes the existing
VM and its volumes, but the system does not remove any of the VM's snapshots or the volume containers in which the snapshots are stored. The volume containers continue to use storage space on your everRun system until you remove the VM's snapshots
(see
"Removing a Snapshot" on page 264
). If storage space is limited, you may want to remove the snapshots before starting the restore process to ensure that there will be enough storage space for the operation.
l
If you previously expanded the volume containers of your VM to allow enough space for snapshots, you may want to note the current size of each volume container before you overwrite and restore the VM. Because the everRun system creates all new volume containers for a restored VM and does not preserve the expanded container sizes, you need to manually expand the volume containers of the restored VM after the restore process is finished (see
"Expanding a Volume Container on the everRun System" on page 243 ).
l
If the everRun system switches from the primary PM to the secondary PM while restoring a VM, the restore process fails. This does not affect the continuous uptime of your system, but you must delete the incomplete VM and associated volumes on the ever-
Run system, and restore them again.
Prerequisite: Both PMs of the everRun system must be online for the restore process to function properly.
To overwrite and restore a VM on the everRun system
1. Export a VM or a VM snapshot from the source everRun system.
2. Copy the exported OVF and VHD files to the management PC that you use to run the everRun
Availability Console, or mount the export network share that contains these files.
3. Log on to the everRun Availability Console on the target everRun system.
Page 207 of 483
everRun User's Guide
4. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify that both
PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
5. On the Virtual Machines page (see
"The Virtual Machines Page" on page 100 ), select the VM that
you want to restore from your previous backup copy.
6. Click Restore to open the restore wizard.
7. Click Browse. In the file browser, locate the network share with the exported files. Select the .ovf
file that you want to restore, and click Restore.
8. When prompted, click Browse and select a .vhd file to include for each volume associated with the
VM.
9. Confirm that you will overwrite the existing VM and data and proceed by clicking Continue.
Caution: Restoring a VM overwrites all of its data and configuration details.
10. Review the information and make any desired edits, if necessary: n
Name, CPU, and Memory
Change the name of the virtual machine, edit the number of vCPUs, or allocate the total memory it can use.
n
Storage
Shows all of the volumes. Select the Create box for a volume to allocate a storage container for the volume on the everRun system (the boot volume is required). Select the
Restore Data box to import data for a volume from the VHD file.
If the target everRun system has more than one storage group, you can also select the storage group in which to create each volume. Ensure that you select a Destination group that
wizard cannot convert the sector size of a volume). Note that the boot volume must have a sector size of 512 B. You can select the sector size, either 4K or 512B, only for data disks.
n
Network
Page 208 of 483
Replacing a Virtual Machine from an OVF File
Displays all of the available networks. You can remove a network or add one that is not already allocated. A minimum of one network is required.
11. Optionally, clear the check box for Auto start Virtual Machine after restore if you need to reprovision the VM before starting it for the first time.
12. Click Restore to begin restoring the VM. When the transfer is complete, click Done to close the restore wizard.
Note: Restored volumes begin to appear on the Volumes page of the everRun Availability Console while the restore process is still in progress. Do not attach or remove any of these restored volumes until the restore window reports that the process is complete; otherwise, the restore process fails.
13. If applicable, use the Reprovision Virtual Machine wizard to allocate additional resources to the
VM, as described in
"Reprovisioning Virtual Machine Resources" on page 233 . Also, if you want to
When you are finished reprovisioning the VM, click Start to boot the VM.
After you verify that the restored VM is functioning properly, the restore process is complete; however, the everRun system may continue to synchronize data between PMs to enable High Availability (HA) or Fault
Tolerant (FT) operation.
Note: Your restored VM and its associated volumes may be marked with warning symbols until the data has been synchronized and the VirtIO drivers are running.
Troubleshooting
If necessary, use the following information to resolve problems with the restore process.
To clean up after a canceled or failed restore process
In the everRun Availability Console on the target system, remove the restored VM and any volumes associated with the restored VM.
Related Topics
"Creating and Migrating Virtual Machines" on page 161
"Managing Virtual Machine Resources" on page 232
Page 209 of 483
everRun User's Guide
"Managing the Operation of a Virtual Machine" on page 227
Exporting a Virtual Machine from an everRun System
Export a virtual machine (VM) to save an image of the VM to a network share. Exporting a VM from an ever-
Run system makes the VM image available for importing to another system or for importing back to the same everRun system to restore or duplicate the original VM. (You can directly export a VM from the ever-
Run system as described in this topic, or create and export a snapshot. For an overview of snapshots, see
"Managing Snapshots" on page 251 .)
You prepare for exporting a VM by creating a network share to store VM exports in your environment, either a Windows share (also known as a Common Internet File System (CIFS) share) or a Network File
System (NFS) share. After creating this share, you mount it in the host operating system of your everRun system as described in this topic. When you initiate an export in the everRun Availability Console, the everRun system saves the VM image to the network share as standard Open Virtualization Format (OVF) and Virtual Hard Disk (VHD) files.
Page 210 of 483
Exporting a Virtual Machine from an everRun System
Notes: l
For Linux-based VMs, before the exporting the VM, consider editing the
/etc/fstab file to comment out entries for data volumes and allow only the boot volume to mount.
Because Linux-based VMs may use different device names on another system, your new VM may boot into single-user mode if it cannot mount the volumes with their original device names. You can restore the
/etc/fstab entries in the new VM with the correct device names after the import process, as described below in Troubleshooting.
l
For Ubuntu-based VMs, you must edit the
/boot/grub/grub.cfg
file and change the gfxmode parameter to text
(for example, set gfxmode=text
) before exporting the VM; otherwise, the new VM's console may hang on another system. You can restore the original setting in the source VM after the migration.
l
Your source VM must be shut down during the export process. Consider scheduling a planned maintenance period for this process (or consider taking a snapshot that you can export at a later time, as described in
"Creating a Snapshot" on page 252
).
l
The time required for the export depends on the size and number of volumes in the source VM as well as network bandwidth. For example, transferring a VM with one
20 GB boot disk over a 1 Gb/s network may take about 30 minutes.
l
If you will continue to use the source VM after the export, remember to set a different
MAC address and IP address for the VM when you import it on the target system.
l
If the everRun system switches from the primary PM to the secondary PM during an export, the export process fails. This does not affect the continuous uptime of your system. You can delete the partially exported files from the export share and export the files again.
Prerequisites: l
You must shut down a VM before exporting it.
l
Both PMs of the everRun system must be online for the export process to function properly.
To create and mount an export share
Before you can export a VM, you must create and mount the network share to which the export(s)
Page 211 of 483
everRun User's Guide will be transferred, as follows:
1. Create a Windows/CIFS share or an NFS share in your environment where you can store
VM exports.
Ensure that you have enough storage space in the share for the VMs that you want to export. Also, set full read/write permissions on the export share to permit file transfers, or, for a Windows/CIFS share only, assign read/write permissions to a specific user on the system/domain that hosts the share. Record the share location and settings, which you will specify in a later step.
2. Log on to the everRun system with the everRun Availability Console.
3. On the Physical Machines page, make note of which PM is the primary node. In the list in the top pane, the primary node is marked as node n (primary).
4. Obtain the IP address of the primary node, if you do not already know it. For example, on the
Preferences page, click IP Configuration. Click the Node n IP tab for the primary node and record the IP Address value.
5. Use a secure shell ( ssh
) utility to log on to the host operating system (host OS) of the primary node of the everRun system, where you will mount the network share. Log on as the root user.
The next step shows how to use the ftxmnt script to automatically mount the export share. The script should work in most cases, but you can also manually mount the share by executing standard mount commands if needed.
Page 212 of 483
Exporting a Virtual Machine from an everRun System
Notes: n
If you manually mount the share in the host OS of the everRun system, you must create the mount point at
/mnt/ft-export
, where the export process expects to find it. (If you use the ftxmnt script, it automatically creates this mount point.) n
If you want the export mount to persist when you reboot the everRun system, manually add an entry to the
/etc/ftstab file in the host OS of the everRun system. (The ftxmnt script does not modify the
/etc/ftstab file.) n
You need to mount the export share only on the primary node of the ever-
Run system, but you can optionally add the mount to the
/etc/fstab file on both nodes so it is always available even if the primary node changes.
n
If you mount a Windows/CIFS share that requires a password, and the password changes after the mount, you need to unmount the share and mount it again with the new password; otherwise, the export may fail unexpectedly.
6. To automatically mount the share, execute the ftxmnt script and respond to the interactive prompts. For example, the following output shows how to mount a
Windows/CIFS share (\\192.168.0.111\ExportVMs) that is accessible by a specific user account:
[root@node0 /]#
ftxmnt
This script is meant to mount a Network Attached Storage location to use for exporting everRun virtual machines.
Enter Ctrl-C to exit
Enter n if you are mounting an nfs share, enter w if you are entering a windows share:
w
What is the IP address or the computer name of the file
Page 213 of 483
everRun User's Guide server?
192.168.0.111
What is the name of the share you wish to mount?
ExportVMs
Does this share require authentication? (y/n):
Respond
y
to the prompt above if the share requires authentication. When you respond
y
, the following prompts appear: n
What is your username?
Enter your
domain\username
.
n
Password for domain\username:
Enter your password.
If the share does not require authentication, type
n
and then respond to the following prompt:
If there is a guest account name, enter it here:
Type the guest account name, if it exists.
The following message appears:
Successfully mounted folder \\192.168.0.111\ExportVMs at path /mnt/ft-export/
7. Switch to the /mnt/ft-export directory in the everRun host OS and create a file to verify that the share is present and that you have read/write permissions. For example:
#
touch test
#
ls
test
Confirm that the file also appears in the share on the remote system. If the file is not present or the everRun host OS displays an error, verify your mount settings and permissions.
8. Remove the test file.
#
rm test
Later, you want to unmount the share after exporting your virtual machines, switch out of the
/mnt/ft-export directory and execute the umount command, as follows:
Page 214 of 483
Exporting a Virtual Machine from an everRun System
#
cd /
#
umount /mnt/ft-export
To prepare for exporting a VM (Windows-based VMs only)
1. Log on to the everRun system with the everRun Availability Console.
2. On the Virtual Machines page, select the VM to export.
3. Click Console to open the console of the VM and log on to the Windows guest operating system.
4. Ensure that all volumes are labeled accurately, as summarized in "Managing Windows
5. Run the Windows System Preparation Tool (
Sysprep
) to prepare the guest operating system for redeployment.
To export a VM from the everRun system
1. Log on to the everRun system with the everRun Availability Console.
2. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify
that both PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
3. On the Virtual Machines page (see
"The Virtual Machines Page" on page 100 ), select the
VM you want to export and click Shutdown. Wait for the VM to shut down.
4. With the VM selected, click Export to open the export wizard.
5. In the Export VM dialog box, type the path in /mnt/ft-export where you want the VM to be exported. For example, if you want the export process to create a new directory named ocean1 to store the OVF and VHD files, type ocean1
. If you want the export process to create the ocean1 directory inside an existing directory named TestVMs , type
TestVMs/ocean1
.
6. Select the volumes to include under Data Volumes to Export. (The boot volume is required.)
7. Click Export VM.
Page 215 of 483
everRun User's Guide
You can monitor the Export Status in the Summary tab for the VM that you are exporting. The export progress is reported as the percentage (%) completed. When the export is finished, the status changes to Export completed successfully.
The everRun system exports the VHD files (volumes) first, then it exports the OVF file. If you are monitoring the export share, you can confirm that the export is finished when the OVF file appears in the share.
After the export, if you want to import or restore the OVF and VHD files on an everRun system, see
"Importing an OVF File from an everRun 7.x System " on page 200
.
Troubleshooting
If necessary, use the following information to resolve problems with the export process.
To clean up after a canceled or failed export from the everRun system
Remove the VM files from the export folder or create a new folder for a subsequent export.
Related Topics
"Creating and Migrating Virtual Machines" on page 161
"Managing Virtual Machine Resources" on page 232
"Managing the Operation of a Virtual Machine" on page 227
Managing Windows Drive Labels
Label volumes in a Windows-based virtual machine to ensure that they are correctly mapped before you export the virtual machine or create a snapshot of it.
Caution: Ensure that each volume has a unique identifiable label before running Sysprep (to prepare for an export or snapshot). This process requires administrator privileges.
To set a label from the command prompt, type:
C:\>
label C:c-drive
To list and verify all volume labels, use the diskpart utility:
C:\>
diskpart
DISKPART>
list volume
...
Page 216 of 483
Configuring Windows-based Virtual Machines
DISKPART>
exit
After importing the virtual machine, use Disk Manager to reassign the drive letters. The labels you assigned before the export or snapshot will help to identify the drives. For instructions on reassigning drive letters on a Windows system, search for the Microsoft Support web site.
Related Topics
"Creating and Migrating Virtual Machines" on page 161
"Configuring Windows-based Virtual Machines" on page 217
"Managing Snapshots" on page 251
Configuring Windows-based Virtual Machines
After installing a Windows-based virtual machine, configure the additional resources and software necessary for production use, as described in: l
"Updating the VirtIO Drivers (Windows-based VMs)" on page 218
l
"Creating and Initializing a Disk (Windows-based VMs)" on page 220
l
"Installing Applications (Windows-based VMs)" on page 221
If you plan to create VM snapshots (see
"Managing Snapshots" on page 251
), consider installing the
QEMU guest agent and configuring the Microsoft Shadow Volume Copy Service (VSS), as described in: l
In addition, ensure that you configure the following settings: l
Change the time zone in the guest operating system to correspond to the time zone configured on
Network Time Protocol (NTP) is recommended for both the VM and the everRun system.
l
Disable hibernation (enabled by default in some cases) to prevent the guest operating system from going into a power-saving state.
l
Configure the power button action in the guest operating system to shut down the guest (and not to hibernate it) to allow the Shutdown VM button in the everRun Availability Console to work properly
(see
"Shutting Down a Virtual Machine" on page 227
).
Page 217 of 483
everRun User's Guide l
Configure the guest operating system to generate a crash dump file if the operating system crashes. Follow the instructions in the Microsoft article,
How to generate a complete crash dump file or a kernel crash dump file by using an NMI on a Windows-based system
(Article ID: 927069).
Follow the instructions in the More Information section.
Related Topics
"Managing Virtual Machines" on page 155
Updating the VirtIO Drivers (Windows-based VMs)
Update the Red Hat VirtIO drivers in your Windows-based virtual machines (VMs) to the latest supported versions to ensure the proper operation of your VMs. For example, you should update the VirtIO drivers after upgrading the everRun software (
"Upgrading everRun Software" on page 115 ) or after using the P2V
Run 7.x System" on page 171 ).
Notes: l
For proper operation, ensure that you download the VirtIO drivers from the everRun
Support page, as described in the following procedure. The support page contains a
VirtIO ISO file with versions of the VirtIO drivers that have been tested with the everRun software.
l
After updating the drivers, you may need to restart the guest operating system.
To update the VirtIO drivers in a Windows-based virtual machine
1. Download the VirtIO ISO file from the Downloads page at http://www.stratus.com/go/support/everrun .
a. On the Downloads page, click everRun (if it is not already displayed) and then select the appropriate version.
b. Scroll down to Drivers and Tools and then continue scrolling to everRun VirtIO Driver
Update.
c. Click the link to the appropriate file.
Ensure that you download the version of the VirtIO ISO file that matches the version of your ever-
Run system.
Page 218 of 483
Updating the VirtIO Drivers (Windows-based VMs)
2. If you want to verify the integrity of the ISO image, also download the associated fciv checksum file, and then download the Microsoft File Checksum Integrity Verifier (FCIV) executable file from the Microsoft Support web site. Save both files to the directory that contains the downloaded ISO file.
Open a command prompt. From the directory containing the ISO, executable, and verification files, type a command similar to the following to verify the ISO image: fciv –v –xml virtio-winn .
n .
nn .xml
If the command succeeds (that is, it returns the message All files verified successfully
), go to the next step. If the command fails, repeat the download.
3. Open the everRun Availability Console, create a VCD of the VirtIO ISO file, and insert the VCD into
"Creating a Virtual CD" on page 246
and "Inserting a Virtual CD" on page 248 ).
4. Open Device Manager in the guest operating system.
5. Expand Network adapters and locate the Red Hat VirtIO Ethernet Adapter. There may be more than one adapter present depending on the number of network interfaces in your VM.
If the Red Hat VirtIO Ethernet Adapter is not present, the VirtIO driver is not installed. Expand
Other devices and locate the unknown Ethernet Controller device. You will update the driver for this device.
6. Right click the Red Hat VirtIO Ethernet Adapter (or Ethernet Controller) and select Update
Driver Software. Click Browse my computer for the driver software, specify the location of the
VirtIO Ethernet driver (netkvm) for your guest operating system, and finish updating the driver. (For example, to update the driver in a Windows Server 2012 R2 guest, select the NetKVM\2k12R2\amd64\netkvm.inf file on the VirtIO VCD.)
Repeat the driver update for each additional Red Hat VirtIO Ethernet Adapter (or Ethernet Controller) device.
7. Expand Storage controllers and locate the Red Hat VirtIO SCSI controller. There may be more than one controller present depending on the number of volumes in your VM.
If the Red Hat VirtIO SCSI controller is not present, the VirtIO driver is not installed. Locate the unknown SCSI controller device. You will update the driver for this device.
Page 219 of 483
everRun User's Guide
8. Right-click the Red Hat VirtIO SCSI controller (or SCSI controller) and select Update Driver
Software. Click Browse my computer for the driver software, specify the location of the VirtIO
SCSI driver (viostor) for your guest operating system, and finish updating the driver. (For example, to update the driver in a Windows Server 2012 R2 guest, specify the viostor\2k12R2\amd64\viostor.inf file on the VirtIO VCD.)
Repeat the driver update for each additional Red Hat VirtIO SCSI (or SCSI controller) device.
Caution: Although the device name is the Red Hat VirtIO SCSI controller, you must select the storage driver file that is labeled viostor, and not vioscsi (if present).
Installing the vioscsi driver may crash your VM.
9. If you intend to use the QEMU guest agent, as described in "Installing the QEMU Guest Agent for
Application-Consistent Snapshots (Windows-based VMs)" on page 222 , also update the VirtIO
serial driver that is associated with the guest agent; otherwise, skip to step 11.
Expand System devices and locate the VirtIO Serial Driver. If the VirtIO Serial Driver is not present, expand Other devices and locate the unknown PCI Simple Communications Controller device. You will update the driver for this device.
10. Right-click the VirtIO Serial Driver and select Update Driver Software. Click Browse my computer for the driver software, specify the location of the VirtIO serial driver (vioser) for your guest operating system, and finish updating the driver. (For example, to update the driver in a Windows
Server 2012 R2 guest, specify the vioserial\2k12R2\amd64\vioser.inf file on the VirtIO VCD.)
11. If applicable, restart the guest operating system to load the updated drivers.
Related Topics
"Configuring Windows-based Virtual Machines" on page 217
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Creating and Initializing a Disk (Windows-based VMs)
Create and initialize a disk to prepare it for partitioning into volumes in a Windows-based virtual machine.
To create and initialize a disk in a Windows-based virtual machine
Page 220 of 483
Installing Applications (Windows-based VMs)
1. Use the everRun Availability Console to create a new volume in a storage group on the everRun system, as described in
"Creating a Volume in a Virtual Machine" on page 236 .
2. In the Windows guest operating system, open Disk Management or a similar utility.
3. Initialize the newly-added disk. (You may be prompted to do so automatically.)
4. Convert the disk to a dynamic disk.
5. Create one or more simple volumes on the disk.
6. Restart the Windows guest operating system.
See your Windows documentation for complete instructions.
Note: Because the everRun software already mirrors data at the physical level, volume redundancy is not required in the Windows guest operating system.
Related Topics
"Opening a Virtual Machine Console Session" on page 229
"Configuring Windows-based Virtual Machines" on page 217
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Installing Applications (Windows-based VMs)
Install an application in a Windows-based virtual machine by doing one of the following: l
Download the installation program to the guest operating system as an executable file or ISO file.
l
Mount a network drive that contains the installation program.
l
Create and insert a Virtual CD (VCD) that contains the installation program. See "Managing Virtual
Related Topics
"Opening a Virtual Machine Console Session" on page 229
"Configuring Windows-based Virtual Machines" on page 217
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Page 221 of 483
everRun User's Guide
Installing the QEMU Guest Agent for Application-Consistent Snapshots (Windows-based VMs)
Install the Quick EMUlator (QEMU) guest agent in your Windows-based guest operating system if you want to create application-consistent snapshots of your virtual machine (VM). For an overview of everRun snapshots, see
"Managing Snapshots" on page 251
.
Typically, while applications are running, they process transactions, open and write files, hold information in memory, and more. If you take a VM snapshot while your applications are still working, it is similar to restarting your system after a power outage. Although most modern file systems are designed to recover from this type of outage, it is possible that some data will be corrupted or lost in the process, especially while transaction-intensive applications are running. In this case, taking a snapshot without preparing your applications results in a crash-consistent snapshot, as if you took the snapshot after a crash or power outage.
Microsoft Windows provides the Volume Shadow Copy Service (VSS) that can inform the file system and your applications when they must temporarily quiesce or freeze their operations during a snapshot or backup. If your applications support VSS, the everRun software can signal your applications through the
QEMU guest agent and VSS to quiesce during a snapshot on your everRun system, thus ensuring an application-consistent snapshot.
Caution: Before installing the QEMU guest agent, contact your application vendor(s) to determine if they support Microsoft VSS and if any additional configuration steps are necessary to support VSS operations. You can create application-consistent snapshots only if your applications support VSS and the QEMU guest agent is properly installed and running.
Notes: l
By default, all snapshots are considered crash-consistent snapshots unless you install the QEMU guest agent and explicitly configure your applications to quiesce when signaled by Microsoft VSS.
l
When you install the QEMU guest agent, you may need to restart your VMs. If your
VMs are in use, schedule a maintenance period for this procedure.
To install the QEMU guest agent
Page 222 of 483
Installing the QEMU Guest Agent for Application-Consistent Snapshots (Windows-based VMs)
1. Log on to the everRun system with the everRun Availability Console.
2. Select a VM on the Virtual Machines page.
3. Click Console and log on to the Windows guest operating system.
4. To transfer the QEMU guest agent installer to your system, do one of the following: n
Open a web browser and download the installer from the Drivers and Tools section of the
Downloads page at http://www.stratus.com/go/support/everrun .
n
Mount a local network share that contains the installer and either copy it to your system or prepare to run it from the share.
5. Start the installer by double-clicking the icon. The QEMU Guest Agent Setup wizard is displayed.
6. Read the license information. If appropriate, click the check box next to I agree to the license terms and conditions.
7. Click Install to begin the software installation.
8. If Windows prompts that it cannot verify the publisher of the driver software, click Install to continue installing the software.
9. If prompted, click Restart to restart the guest operating system.
When Windows restarts, you may see a message indicating that the driver software was installed.
10. If prompted, click Restart to restart the guest operating system again.
To verify that the QEMU guest agent is properly installed and running
Open Services. For example, click Start and Run, then type services.msc and click Run. Verify that the following services are present and running: l
QEMU Guest Agent (always runs) l
QEMU Guest Agent VSS Provider (may run only during quiesce)
Open Device Manager. For example, click Start, Control Panel, Hardware, and Device Manager.
Verify that the following driver is installed and running: l
VirtIO Serial Driver (under System devices)
Related Topics
"Configuring Windows-based Virtual Machines" on page 217
"Creating and Migrating Virtual Machines" on page 161
Page 223 of 483
everRun User's Guide
"Managing the Operation of a Virtual Machine" on page 227
Configuring Linux-based Virtual Machines
After installing a Linux-based virtual machine, configure the additional resources and software necessary for production use, as described in: l
"Creating and Initializing a Disk (Linux-based VMs)" on page 224
l
"Installing Applications (Linux-based VMs)" on page 225
If you plan to create VM snapshots (see
"Managing Snapshots" on page 251
), consider installing the
QEMU guest agent, as described in: l
"Installing the QEMU Guest Agent for Application-Consistent Snapshots (Linux-based VMs)" on page 225
In addition, ensure that you configure the following settings: l
Disable hibernation (enabled by default in some cases) to prevent the guest operating system from going into a power-saving state.
l
Configure the power button action in the guest operating system to shut down the guest (and not to hibernate it) to allow the Shutdown VM button in the everRun Availability Console to work properly.
For the minimal server version of Ubuntu Linux, optionally install the acpid package to enable the Shutdown button. See
"Shutting Down a Virtual Machine" on page 227
.
l
Install the kexec-tools package and configure the guest operating system to generate a crash dump file if the system crashes.
l
For Ubuntu Linux guest operating systems, to prevent a problem where the VM console hangs in everRun Availability Console, edit the
/boot/grub/grub.cfg
file and change the gfxmode parameter to text (for example, set gfxmode=text ). If the VM console hangs
before you can set the parameter, see the troubleshooting information in "Opening a Virtual
Machine Console Session" on page 229 to resolve the issue.
For more information about these settings, see your Linux documentation.
Related Topics
"Managing Virtual Machines" on page 155
Creating and Initializing a Disk (Linux-based VMs)
Page 224 of 483
Installing Applications (Linux-based VMs)
Create and initialize a disk to make it available for storing data in a Linux-based virtual machine.
To create and initialize a disk in a Linux-based virtual machine
2. In the Linux-based virtual machine, use the volume management tool or edit files as needed to initialize and mount the volume. See your Linux documentation for complete instructions.
The disk device names for a Linux-based virtual machine are /dev/vda through /dev/vdh , not the standard
/dev/sda through
/dev/sdh
. The everRun virtual disk volumes appear in the guest operating system and are used as if they were physical disks.
Related Topics
"Opening a Virtual Machine Console Session" on page 229
"Configuring Linux-based Virtual Machines" on page 224
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Installing Applications (Linux-based VMs)
Install an application in a Linux-based virtual machine by doing one of the following: l
Download the installation package to the guest operating system as an executable file or ISO file.
l
Mount a network drive that contains the installation package.
l
Create and insert a Virtual CD (VCD) that contains the installation package. See "Managing Virtual
Related Topics
"Opening a Virtual Machine Console Session" on page 229
"Configuring Linux-based Virtual Machines" on page 224
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Installing the QEMU Guest Agent for Application-Consistent Snapshots (Linux-based VMs)
Page 225 of 483
everRun User's Guide
Install the Quick EMUlator (QEMU) guest agent in your Linux-based guest operating system if you want to create application-consistent snapshots of your virtual machine (VM). For an overview of everRun snapshots, see
"Managing Snapshots" on page 251 .
Typically, while applications are running, they process transactions, open and write files, hold information in memory, and more. If you take a VM snapshot while your applications are still working, it is similar to restarting your system after a power outage. Although most modern file systems are designed to recover from this type of outage, it is possible that some data will be corrupted or lost in the process, especially for transaction-intensive applications. In this case, taking a snapshot without preparing your applications results in a crash-consistent snapshot, as if you took the snapshot after a power outage.
If your applications support QEMU signaling, the everRun software can signal your applications through the QEMU guest agent to ensure that your applications quiesce or freeze during a snapshot on your ever-
Run system, thus ensuring an application-consistent snapshot.
Most Linux distributions already include a QEMU guest agent (usually in the qemu-guest-agent package). For information about installing and configuring the QEMU guest agent, see the documentation for your particular Linux distribution.
Caution: Before installing a QEMU guest agent, contact your application vendor(s) to determine if they support QEMU signaling and if any additional configuration steps are necessary to quiesce your applications. You can create application-consistent snapshots only if your applications support QEMU signaling and the QEMU guest agent is properly installed and running.
Notes: l
By default, all snapshots are considered crash-consistent snapshots unless you explicitly install the QEMU guest agent and configure your applications to quiesce when signaled by the everRun software.
l
When you install the QEMU guest agent, you may need to restart your VMs. If your
VMs are use, schedule a maintenance period for the installation.
Related Topics
"Configuring Linux-based Virtual Machines" on page 224
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Page 226 of 483
Managing the Operation of a Virtual Machine
Managing the Operation of a Virtual Machine
Manage the operation of a virtual machine as described in: l
"Starting a Virtual Machine" on page 227
l
"Shutting Down a Virtual Machine" on page 227
l
"Powering Off a Virtual Machine" on page 228
l
"Opening a Virtual Machine Console Session" on page 229
l
"Renaming a Virtual Machine" on page 231
l
"Removing a Virtual Machine" on page 231
Starting a Virtual Machine
Start a virtual machine (VM) to boot the guest operating system installed in VM.
To start a virtual machine
1. On the Virtual Machines page, select a VM.
2. Click Start.
Related Topics
"Shutting Down a Virtual Machine" on page 227
"Powering Off a Virtual Machine" on page 228
"Managing the Operation of a Virtual Machine" on page 227
Shutting Down a Virtual Machine
Shut down a virtual machine (VM) to begin an orderly shutdown of the guest operating system.
Note: You can shut down a VM with guest operating system commands. Some guests allow
(or can be configured to allow) you to shut down a VM using the everRun Availability Console.
To shut down a VM in everRun Availability Console
Page 227 of 483
everRun User's Guide
1. On the Virtual Machines page, select a VM.
2. Click Shutdown.
A warning message appears, asking you to confirm the shutdown. Click Yes to shutdown or No to discontinue the shutdown.
If the VM is not responding, you can also Power Off the VM to stop it without properly shutting down the guest operating system.
Shutting down a VM in the everRun Availability Console is similar to pressing the power button on a physical machine, which typically results in an orderly shutdown of the operating system. In some cases, you may need to explicitly enable this feature in the guest operating system. For example: l
For any guest, verify that the power button action is set to shut down the guest operating system and not to hibernate it. If you click Shutdown in the everRun Availability Console for a guest that is set to hibernate, the VM remains in a stopping state and never properly shuts down.
l
On some guests, the power button does not shut down the system unless a user is logged on to the operating system. You may be able to update security settings to enable the power button even in the absence of a login session.
l
On some minimal server versions of Ubuntu Linux, the acpid package that enables the power button is not included in the default installation. You can manually install this package to enable the power button.
See the documentation for your guest operating system to configure the behavior of the system power button, thus enabling the Shutdown button to work in the everRun Availability Console.
Related Topics
"Starting a Virtual Machine" on page 227
"Powering Off a Virtual Machine" on page 228
"Managing the Operation of a Virtual Machine" on page 227
Powering Off a Virtual Machine
Power off a virtual machine (VM) to stop it without properly shutting down guest operating system.
Page 228 of 483
Opening a Virtual Machine Console Session
Caution: Use the Power Off command only if the Shutdown command or guest operating system commands fail. Powering off a VM is similar to pulling the power cord, which may result in data loss.
To power off a virtual machine
1. On the Virtual Machines page, select a VM.
2. Click Power Off.
Related Topics
"Starting a Virtual Machine" on page 227
"Shutting Down a Virtual Machine" on page 227
"Managing the Operation of a Virtual Machine" on page 227
"Advanced Topics (Virtual Machines)" on page 265
Opening a Virtual Machine Console Session
Open a virtual machine (VM) console to display the console of the guest operating system running in the
VM.
The following procedure describes how to open a VM console in the everRun Availability Console, but you can also use a remote desktop application for this purpose.
To open a VM console
1. On the Virtual Machines page, select a VM.
2. Ensure that the VM is in a running state.
3. Click Console.
Troubleshooting
To resolve an issue where the VM console window does not open
Ask your network administrator to open ports 6900-6999 (inclusive).
To resolve an issue where the VM console window is blank
Verify that the VM is powered on and not in the process of booting. Also, click in the console window and press any key to deactivate the screen saver.
Page 229 of 483
everRun User's Guide
To resolve an issue where more than one VM console window is displayed and they are behaving erratically
Close all console windows and open only one console window.
To resolve an issue where the VM console window hangs on the everRun system
For Ubuntu-based VMs, the VM console hangs in the everRun Availability Console if you do not properly set the gfxmode parameter. In the guest operating system, edit the
/boot/grub/grub.cfg
file and change the gfxmode parameter to text (for example, set gfxmode=text
).
If the console hangs before you can set the parameter, do the following:
1. Restart the VM in the everRun Availability Console.
2. At the GRUB menu, press e to edit the grub command.
3. On the next screen, on the gfxmode line, change
$linux_gfx_mode to text so the line reads:
gfxmode text
4. Press Ctrl-x or F10 to boot the guest operating system.
5. To update the setting so it persists for each boot cycle, edit the
/boot/grub/grub.cfg
file and change the gfxmode parameter to text so the line reads:
set gfxmode=text
6. Save the
/boot/grub/grub.cfg
file.
To change the terminal type in a Linux-based VM if the console screen is unreadable
By default, the Linux operating system sets the
TERM variable to vt100-nav, which is not properly supported by the vncterm program, the basis for the VM console in everRun Availability Console. If you use anything other than the command line, the screen becomes unreadable. To resolve this issue, change the terminal type in the Linux guest operating system:
1. Open the inittab file in the guest operating system.
2. In the following line, replace vt100-nav with vt100 by deleting -nav at the end of the line.
The updated line appears as follows:
Page 230 of 483
Renaming a Virtual Machine
# Run gettys in standard runlevels co:2345:respawn:/sbin/agetty xvc0 9600 vt100
3. Save the inittab file.
Related Topics
"Starting a Virtual Machine" on page 227
"Shutting Down a Virtual Machine" on page 227
"Managing the Operation of a Virtual Machine" on page 227
Renaming a Virtual Machine
Rename a virtual machine (VM) to change its name as it appears on the Virtual Machines page.
If you need to change the host name of the guest operating system running in a VM, use guest operating system tools.
Prerequisite: To rename a VM, you must shut it down.
To rename a virtual machine
1. On the Virtual Machines page, select a VM.
2. Click Shutdown and wait for the VM to shut down.
3. Double-click the name of the VM.
4. Type the new name and press Enter.
Related Topics
"Removing a Virtual Machine" on page 231
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Removing a Virtual Machine
Remove a virtual machine (VM) to permanently delete it and optionally delete associated volumes from the everRun system.
Page 231 of 483
everRun User's Guide
Notes: l
When you remove a VM, any snapshots associated with the VM and the volume containers in which the snapshots are stored remain on the everRun system. To remove a
VM snapshot and all of its associated volume snapshots, see "Removing a Snapshot" on page 264 .
l
When all volume and volume snapshot contents have been removed from a volume container, the system automatically removes the container from the system, which frees up space in the storage group.
Prerequisite: Both PMs of the everRun system must be online to properly remove a VM. On the Physical Machines page of the everRun Availability Console, verify that both PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
To remove a virtual machine
1. On the Virtual Machines page, select a VM.
2. Click Shutdown.
3. When the VM has stopped, click Remove.
4. In the Remove Virtual Machine dialog box, activate the check box next to volumes that you want to delete. Clear the check box for volumes to save as archives or save for attachment to another
VM.
Caution: Make sure that you select the correct VM and volumes for removal. When you click Delete VM, these items are permanently removed.
5. Click Delete VM to permanently delete the VM and any selected volumes.
Related Topics
"Renaming a Virtual Machine" on page 231
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Managing Virtual Machine Resources
Page 232 of 483
Reprovisioning Virtual Machine Resources
Manage virtual machine resources to reconfigure the vCPUs, memory, storage, or network resources of an existing virtual machine.
To reconfigure virtual machine resources, use the Reprovision Virtual Machine wizard, as described in: l
"Reprovisioning Virtual Machine Resources" on page 233
To reconfigure virtual machine volumes, see the following task-specific topics: l
"Creating a Volume in a Virtual Machine" on page 236
l
"Attaching a Volume to a Virtual Machine" on page 238
l
"Detaching a Volume from a Virtual Machine" on page 239
l
"Removing a Volume from a Virtual Machine" on page 240
l
"Expanding a Volume Container on the everRun System" on page 243
l
"Expanding a Volume on the everRun System" on page 244
To recover virtual machine resources, freeing space for new volumes or virtual CDs, see: l
"Recovering Virtual Machine Resources" on page 245
Reprovisioning Virtual Machine Resources
Reprovision a virtual machine (VM) to change its allocation of virtual CPUs (vCPUs), memory, storage, or network resources.
Launch the Reprovision Virtual Machine wizard by clicking Config in the bottom pane of the Virtual
Machines page. The wizard steps you through the process of reallocating resources to the VM.
Prerequisites: l
Review the prerequisites and considerations for allocating vCPUs, memory, storage,
l
To reprovision a VM, you must shut down the VM.
To reprovision a virtual machine
Page 233 of 483
everRun User's Guide
1. Open the Virtual Machines page (see
"The Virtual Machines Page" on page 100
).
2. Select a VM and click Shutdown.
3. When the VM has stopped, click Config to display the Reprovision Virtual Machine wizard.
4. On the Name, Description, and Protection page: a. Type the Name and an optional Description for the VM as they will appear in the everRun
Availability Console.
b. Select the level of protection to use for the VM: o
Fault Tolerant (FT) o
High Availability (HA)
c. Click Next.
5. On the vCPUs and Memory page: a. Specify the number of vCPUs and the amount of Memory to assign to the VM. For more
"Planning Virtual Machine vCPUs" on page 156
b. If applicable, select the Keyboard Layout in Console to set the keyboard type for your country.
c. Click Next.
6. On the Volumes page, you can:
Notes: n
You cannot modify the VM boot volume, only data volumes n
To expand a volume container, see "Expanding a Volume Container on the ever-
n
Click Detach to disconnect a volume from a VM and keep it for future use.
n
Click Delete to permanently remove a volume from the everRunsystem.
n
Select an unattached volume from a pulldown menu (if displayed) and click Attach.
Page 234 of 483
Reprovisioning Virtual Machine Resources n
Add a new volume: a. Type the Name of the boot volume.
b. Type the Container Size and Volume Size of the volume in gigabytes (GB). The container size is the total size for the volume including extra space to store snapshots.
The volume size is the portion of the container that is available to the guest operating
c. Select the Storage Group for the volume, and, if applicable, select the Sector Size.
Ensure that you select a storage group that supports the sector size of the volume
(see
"Planning Virtual Machine Storage" on page 159 ). Note that the boot volume
must have a sector size of 512 B. You can select the sector size, either 4K or 512B, only for data disks.
d. If applicable, click Add New Volume to create a new data volume. (If the button is not visible, scroll down to the bottom of the wizard page.) Specify the parameters for the new volume.
e. If applicable, click Attach to connect a volume to a VM.
To continue, click Next.
7. On the Networks page, activate the check box for each shared network that you want to attach to the VM.
For each shared network that you attach, you can also optionally: n
Set a custom MAC address (for details, see "Assigning a Specific MAC Address to a Virtual
n
Set the State to Enabled or Disabled, which allows you to allow or block network traffic to the selected network.
For more information, see
"Planning Virtual Machine Networks" on page 161
. To continue, click
Next.
8. On the Configuration Summary page:
Page 235 of 483
everRun User's Guide
Caution: Make sure that any volumes marked for removal are correct. When you click
Finish, permanent data loss occurs on disks marked for removal.
a. Review the configuration summary. If you need to make changes, click Back.
b. To accept the VM as provisioned, click Finish.
9. Click Start to restart the VM.
10. For Windows-based VMs, if you changed the number of assigned virtual CPUs in a Windowsbased VM from 1 to n or or n to 1, after restarting the VM at the end of the re-provisioning process you must shut down and restart the VM a second time. This allows the VM to correctly reconfigure itself for Symmetric Multiprocessing (SMP). The VM displays odd behavior and is not usable until it is restarted.
Related Topics
"Managing Virtual Machine Resources" on page 232
"Planning Virtual Machine Resources" on page 156
"Managing Virtual Machines" on page 155
Creating a Volume in a Virtual Machine
Create a volume to attach a new, blank volume to a virtual machine (VM). (You can also attach an existing, unattached volume as described in
"Attaching a Volume to a Virtual Machine" on page 238
.)
Prerequisite: Before creating a volume for a VM, you must shut down the VM.
To create a new volume in a VM
1. Open the Virtual Machines page (see
"The Virtual Machines Page" on page 100
).
2. Select a VM and click Shutdown.
3. When the VM has stopped, click Config to display the Reprovision Virtual Machine wizard.
5. On the Volumes page, click Add a new volume. (If the button is not visible, scroll down to the bottom of the wizard page.)
Page 236 of 483
Creating a Volume in a Virtual Machine
6. Under To Be Created, do the following: a. Type the Name of the volume as it will appear in the everRun Availability Console.
b. Type the Container Size and Volume Size of the volume to create in gigabytes (GB). The container size is the total size for the volume including extra space to store snapshots. The volume size is the portion of the container that is available to the guest operating system.
For more information about allocating storage, see
"Sizing Volume Containers" on page 16
and
"Planning Virtual Machine Storage" on page 159
.
c. Select the Disk Image format: n
RAW — raw disk format n
QCOW2 — QEMU Copy On Write (QCOW2) format, which supports snapshots d. Select the Storage Group in which to create the volume, and, if applicable, select the
Sector Size.
Ensure that you select a storage group that supports the sector size of the volume that you want to create (see
"Planning Virtual Machine Storage" on page 159
). Note that the boot volume must have a sector size of 512 B. You can select the sector size, either 4K or 512B, only for data disks.
7. Click Next on each wizard page until the Configuration Summary page is displayed. Verify the configuration changes.
8. Click Finish to create the volume.
9. Start the VM and prepare the volume for use in the Windows or Linux guest operating system, as described in: n
"Creating and Initializing a Disk (Windows-based VMs)" on page 220
n
"Creating and Initializing a Disk (Linux-based VMs)" on page 224
Related Topics
"Detaching a Volume from a Virtual Machine" on page 239
"Removing a Volume from a Virtual Machine" on page 240
"Managing Virtual Machine Resources" on page 232
"Planning Virtual Machine Resources" on page 156
"Managing Virtual Machines" on page 155
Page 237 of 483
everRun User's Guide
Attaching a Volume to a Virtual Machine
Attach a volume to connect a currently unused volume to a virtual machine.
Note: If you attach a boot volume to a VM that already has a boot volume, the newly added volume is attached as a data volume. You might want to attach a volume in this manner to diagnose a boot problem or data corruption in another VM's boot volume. After using guest operating system tools to resolve the issue, detach the volume and reattach it to its original VM.
Prerequisite: Before attaching a volume to a virtual machine, you must shut down the virtual machine.
To attach a volume to a virtual machine
1. Ensure that the volume you want to attach is not in use by another virtual machine; otherwise, you cannot attach it. Open the Volumes page, locate the volume, and ensure that the value in the Used
By column is None.
2. Open the Virtual Machines page (see
"The Virtual Machines Page" on page 100
).
3. Select a VM and click Shutdown.
4. When the VM has stopped, click Config to display the Reprovision Virtual Machine wizard.
6. On the Volumes page, locate the pulldown menu next to the Add a new volume button. Select an unattached volume from the pulldown menu and click Attach.
(If the pulldown menu is not visible, scroll down to the bottom of the wizard page. The pulldown menu is displayed only if there are unattached volumes on the everRun system.)
7. Click Next on each wizard page until the Configuration Summary page is displayed. Verify the configuration changes.
8. Click Finish to attach the selected volume.
Related Topics
"Creating a Volume in a Virtual Machine" on page 236
"Detaching a Volume from a Virtual Machine" on page 239
Page 238 of 483
Detaching a Volume from a Virtual Machine
"Removing a Volume from a Virtual Machine" on page 240
"Managing Virtual Machine Resources" on page 232
"Planning Virtual Machine Resources" on page 156
"Managing Virtual Machines" on page 155
Detaching a Volume from a Virtual Machine
Detach a volume to disconnect it from a virtual machine and keep it for future use, or attach it to another virtual machine as described in
"Attaching a Volume to a Virtual Machine" on page 238 . (You can also per-
Notes: l
When you detach a volume from a VM, both the volume and its volume container exist separately from the VM. They remain on the system even if you remove the VM.
l
If you decide to remove the volume, and you also want to remove its volume container to reclaim space in the storage group, you must remove any snapshots stored in the volume container; otherwise, the volume container remains on the system. For more information, see
"Removing a Volume from a Virtual Machine" on page 240 .
l
If you detach a boot volume from a VM, you cannot boot the VM; however, you might want to detach the boot volume to diagnose a boot problem or data corruption in the volume. You can temporarily attach the boot volume to another VM as a data volume, as described in
"Attaching a Volume to a Virtual Machine" on page 238 . After using guest
operating system tools to resolve the issue, detach the volume and reattach it to its original VM.
Prerequisite: Before detaching a volume from a virtual machine, you must shut down the virtual machine.
To detach a volume from a virtual machine
1. Open the Virtual Machines page (see
"The Virtual Machines Page" on page 100
).
2. Select a VM and click Shutdown.
Page 239 of 483
everRun User's Guide
3. When the VM has stopped, click Config to display the Reprovision Virtual Machine wizard.
5. On the Volumes page, locate the volume to detach. (If the volume is not visible, scroll down on the wizard page.)
6. Click Detach beside the volume name to mark the volume for detachment.
Caution: Be careful to mark the correct volume to detach, avoiding any volumes that are currently in use.
7. Click Next on each wizard page until the Configuration Summary page is displayed. Verify the configuration changes.
8. Click Finish to detach the selected volume.
Related Topics
"Attaching a Volume to a Virtual Machine" on page 238
"Removing a Volume from a Virtual Machine" on page 240
"Managing Virtual Machine Resources" on page 232
"Planning Virtual Machine Resources" on page 156
"Managing Virtual Machines" on page 155
Removing a Volume from a Virtual Machine
Remove a virtual machine (VM) volume to permanently delete it from the everRun system. (You can also
Page 240 of 483
Removing a Volume from a Virtual Machine
Notes: l
If you remove a volume, and you also want to remove its volume container to reclaim space in the storage group, you must remove any volume snapshots stored in the volume container; otherwise, the container remains on the system. To remove a VM
snapshot and all of its associated volume snapshots, see "Removing a Snapshot" on page 264 .
l
When all volume and volume snapshot contents have been removed from a volume container, the system automatically removes the container from the system, which frees up space in the storage group.
Prerequisite: Before removing a volume attached to a virtual machine, you must shut down the virtual machine.
To remove a volume that is attached to a virtual machine
1. Open the Virtual Machines page (see
"The Virtual Machines Page" on page 100
).
2. Select a VM and click Shutdown.
3. When the VM has stopped, click Config to display the Reprovision Virtual Machine wizard.
4. Click Next on each wizard page until the Volumes page is displayed. (If applicable, see
"Reprovisioning Virtual Machine Resources" on page 233
to configure additional VM resources.)
5. On the Volumes page, locate the volume to delete. (If the volume is not visible, scroll down on the wizard page.)
6. Click Delete beside the volume name to mark the volume for deletion.
Caution: Be careful to mark the correct volume to remove, avoiding any volumes that are currently in use.
7. Click Next on each wizard page until the Configuration Summary page is displayed. Verify the configuration changes.
8. Click Finish to permanently delete the selected volume.
Page 241 of 483
everRun User's Guide
To remove an unattached volume
Caution: Before removing a volume, ensure that it is no longer needed by other administrators.
1. Open the Volumes page.
2. Select an unattached volume. (The VM column must read None, otherwise, the Remove button is not displayed.)
3. Click Remove.
Related Topics
"Detaching a Volume from a Virtual Machine" on page 239
"Attaching a Volume to a Virtual Machine" on page 238
"Managing Virtual Machine Resources" on page 232
"Planning Virtual Machine Resources" on page 156
"Managing Virtual Machines" on page 155
Renaming a Volume on the everRun System
Rename a volume on the everRun system to change its name as it appears on the Volumes page.
If you need to change the name of a disk or volume in the guest operating system running in a virtual machine, use guest operating system tools.
To rename a volume on the everRun system
1. Locate the volume on the Volumes page.
2. Double-click the name of the volume.
3. Specify the new name and press Enter.
Related Topics
"Creating a Volume in a Virtual Machine" on page 236
"Detaching a Volume from a Virtual Machine" on page 239
"Removing a Volume from a Virtual Machine" on page 240
"Managing Virtual Machine Resources" on page 232
Page 242 of 483
Expanding a Volume Container on the everRun System
"Planning Virtual Machine Resources" on page 156
"Managing Virtual Machines" on page 155
Expanding a Volume Container on the everRun System
Expand a virtual machine (VM) volume container to allocate more space in the container for snapshots or for the guest operating system volume. (To expand the portion of a volume container that is available to the guest operating system, see
"Expanding a Volume on the everRun System" on page 244
.)
You can expand the volume container, but you cannot reduce the size of a container. Use the following procedure to expand a volume container whether the VM is running or stopped. To estimate the amount of storage to allocate to a volume container, see
"Sizing Volume Containers" on page 16
.
Prerequisite: Ensure that both PMs of the everRun system are online; otherwise, the system cannot properly expand a volume container.
To expand a volume container
1. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify that both
PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
2. On the Volumes page (see
"The Volumes Page" on page 106 ), click Expand Container.
3. Next to Expand By, type the amount of storage space to add to the volume container (in gigabytes
(GB)). When you type the number, the dialog box displays the Expanded Container Size that will result if you complete the operation.
Note: Consider the Expand By entry carefully, because after expanding a container, you cannot undo the change or reduce the size of the volume container; you can only expand the volume further.
4. Click Expand Container to commit the change and expand the container. The dialog box displays the expansion progress and automatically closes when the operation is complete.
Related Topics
"Expanding a Volume on the everRun System" on page 244
"Creating a Volume in a Virtual Machine" on page 236
Page 243 of 483
everRun User's Guide
"Detaching a Volume from a Virtual Machine" on page 239
"Removing a Volume from a Virtual Machine" on page 240
"Managing Virtual Machine Resources" on page 232
"Planning Virtual Machine Resources" on page 156
"Managing Virtual Machines" on page 155
Expanding a Volume on the everRun System
Expand a virtual machine (VM) volume to allocate more space for programs and data in the guest operating system. Before expanding a VM volume, you may also need to expand its volume container, as described in
"Expanding a Volume Container on the everRun System" on page 243 , to ensure that the volume con-
tainer has enough space to expand the volume and store snapshots.
You can expand a volume, but you cannot reduce the size of a volume. Use the following procedure to expand a volume only when the VM is stopped.
Prerequisites: l
You must shut down the VM before expanding a volume that it contains.
l
Ensure that both PMs of the everRun system are online; otherwise, the system cannot properly expand a volume.
To expand a volume container
1. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify that both
PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
available space as the amount of space you want to add to the volume. If you also take snapshots, additional space is needed.
3. On the Virtual Machines page (see
"The Virtual Machines Page" on page 100 ), select the VM that
contains the volume that you want to expand. Ensure that the VM is stopped.
4. In the bottom pane, click the Volumes tab and select the volume that you want to expand. In the
Action column, click Expand Volume.
Page 244 of 483
Recovering Virtual Machine Resources
5. Next to Expand By, type the amount of storage space to add to the volume (in gigabytes (GB)).
When you type the number, the dialog box displays the Expanded Volume Size that will result if you complete the operation.
Note: Consider the Expand By entry carefully, because after expanding a volume, you cannot undo the change or reduce the size of the volume; you can only expand the volume further.
6. Click Expand Volume to commit the change and expand the volume. The dialog box displays the expansion progress and automatically closes when the operation is complete.
Related Topics
"Expanding a Volume Container on the everRun System" on page 243
"Creating a Volume in a Virtual Machine" on page 236
"Detaching a Volume from a Virtual Machine" on page 239
"Removing a Volume from a Virtual Machine" on page 240
"Managing Virtual Machine Resources" on page 232
"Planning Virtual Machine Resources" on page 156
"Managing Virtual Machines" on page 155
Recovering Virtual Machine Resources
To conserve storage space, remove VM resources when they are no longer needed. You may also need to immediately recover storage space when there is insufficient space for certain tasks, such as creating a volume or VCD.
To recover storage space, remove unused resources as described in the following topics: l
"Removing a Virtual Machine" on page 231
l
"Removing a Volume from a Virtual Machine" on page 240
l
"Removing a Virtual CD" on page 250
You can also remove unused snapshots from a VM to free space for new snapshots on an existing volume, but doing so does not recover storage space for new volumes or VCDs: l
"Removing a Snapshot" on page 264
Page 245 of 483
everRun User's Guide
Related Topics
"Managing Virtual Machine Resources" on page 232
"Planning Virtual Machine Resources" on page 156
"Managing Virtual Machines" on page 155
Managing Virtual CDs
Create and manage virtual CDs (VCDs) to make software installation media available to the virtual machines on your everRun system in ISO format.
A VCD is a read-only ISO image file that resides on a storage device of the everRun system. Use the Virtual CD Creation Wizard (in everRun Availability Console) to upload an existing ISO file, as described in
"Creating a Virtual CD" on page 246 .
After you create a VCD, you can boot from it to install a Windows or Linux guest operating system, or start a VM from a bootable recovery VCD. You can also insert a VCD into a running VM to install software applications.
Caution: When you insert a VCD into a running, fault-tolerant (FT) VM, it prevents the everRun software from migrating the VM to a different physical machine in the event of a failure. To restore fault-tolerant operation, unmount and eject the VCD as soon as you finish using it.
You manage VCDs as described in: l
"Creating a Virtual CD" on page 246
l
"Inserting a Virtual CD" on page 248
l
"Ejecting a Virtual CD" on page 248
l
"Booting from a Virtual CD" on page 249
l
"Renaming a Virtual CD" on page 250
l
"Removing a Virtual CD" on page 250
Creating a Virtual CD
Create a virtual CD (VCD) to make software installation media available to the virtual machines (VM) on your everRun system.
Page 246 of 483
Creating a Virtual CD
To create a VCD, use the Virtual CD Creation Wizard to upload or copy an ISO file to a storage device on the everRun system. Thereafter, you can boot from it (see
"Booting from a Virtual CD" on page 249
) to install a guest operating system or start a VM from a bootable recovery VCD. You can also insert a VCD into a running VM (see
"Inserting a Virtual CD" on page 248
) to install software applications.
Notes:
1. Each VCD consumes disk space in the storage group in which it is stored. Unless you use a VCD on a regular basis, remove it when it is no longer needed.
2. If you create a bootable VCD for installation, it must be a single CD or DVD. Multiple
CDs or DVDs are not supported.
To create a VCD
1. If necessary, create ISO files of any physical media for which you will create VCDs.
2. Open the Virtual CDs page in the everRun Availability Console.
3. Click Create VCD to open the Virtual CD Creation Wizard.
4. In the wizard, select a storage group with sufficient free space for the VCD.
5. Type a name for the VCD.
6. Select a source for the VCD: n
Upload ISO file uploads a file from your system running the everRun Availability Console.
Click Browse, select the ISO file on your system, and click Open.
n
Copy CD ISO from network source copies the file from a Web URL. Specify the URL of the ISO file.
7. Click Finish to upload or copy the ISO file from the specified source.
The Virtual CD Creation Wizard reports that the VCD has been successfully added, but transferring the image may take several more minutes depending on the source and size of the image.
You can determine the status of a VCD by checking the State column on the Virtual CDs page: l
A syncing icon ( ) indicates that the VCD is still being created.
l
A broken icon ( ) indicates that the VCD creation failed. Remove the VCD and try creating it
Page 247 of 483
everRun User's Guide again.
l
A normal icon ( ) indicates that the transfer is complete and that the VCD is ready to use.
Related Topics
"Inserting a Virtual CD" on page 248
"Ejecting a Virtual CD" on page 248
"Managing Virtual CDs" on page 246
"Creating and Migrating Virtual Machines" on page 161
Inserting a Virtual CD
Insert a virtual CD (VCD) in a virtual machine (VM) to access installation media when installing applic-
Caution: When you insert a VCD into a running, fault-tolerant (FT) VM, it prevents the everRun software from migrating the VM to a different physical machine in the event of a failure. To restore fault-tolerant operation, unmount and eject the VCD as soon as you finish using it.
To connect a VCD to a VM
1. If necessary, create a VCD (see
"Creating a Virtual CD" on page 246
) for the software installation media you need to access.
2. On the Virtual Machines page, select a VM.
3. In the bottom pane, click the CD Drives tab.
4. On the CD Drives tab, select a VCD from the pulldown menu.
5. Click Insert a CD to connect the VCD to the VM.
Related Topics
"Creating a Virtual CD" on page 246
"Ejecting a Virtual CD" on page 248
"Booting from a Virtual CD" on page 249
"Managing Virtual CDs" on page 246
Ejecting a Virtual CD
Page 248 of 483
Booting from a Virtual CD
Eject a virtual CD (VCD) to disconnect it from a virtual machine (VM). Ejecting a VCD allows you to insert another VCD into the VM. It also makes the VCD available for inserting into another VM.
To eject a VCD from a VM
1. Unmount the VCD from the guest operating system to ensure that it is not in use.
2. On the Virtual Machines page, select a VM.
3. Click the CD Drives tab in the lower frame.
4. On the CD Drives tab, click Eject CD.
Related Topics
"Creating a Virtual CD" on page 246
"Inserting a Virtual CD" on page 248
"Booting from a Virtual CD" on page 249
"Managing Virtual CDs" on page 246
Booting from a Virtual CD
Boot a virtual machine from a virtual CD (VCD) to install a guest operating system or to perform maintenance.
Before booting from a VCD, you must shut down the virtual machine.
To boot a virtual machine from a VCD
1. If necessary, create a VCD from a bootable CD/DVD (see
"Creating a Virtual CD" on page 246 ).
2. On the Virtual Machines page, select a virtual machine.
3. If the virtual machine is running, click Shutdown.
4. When the virtual machine status shows stopped, click Boot from CD in the lower pane.
5. Select the bootable VCD, then click Boot.
Note: A Windows-based virtual machine booted from a VCD boots as a hardware virtual machine (HVM), and it can access only the first three disk volumes.
Related Topics
"Creating a Virtual CD" on page 246
Page 249 of 483
everRun User's Guide
"Inserting a Virtual CD" on page 248
"Ejecting a Virtual CD" on page 248
"Managing Virtual CDs" on page 246
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Renaming a Virtual CD
Rename a virtual CD (VCD) to change its name as it appears on the Virtual CDs page.
To rename a VCD
1. Locate the VCD on the Virtual CDs page.
2. Double-click the name of the VCD.
3. Specify the new name and press Enter.
Related Topics
"Removing a Virtual CD" on page 250
"Inserting a Virtual CD" on page 248
"Ejecting a Virtual CD" on page 248
"Creating a Virtual CD" on page 246
"Managing Virtual CDs" on page 246
Removing a Virtual CD
Remove a virtual CD (VCD) to permanently delete it from the everRun system.
To remove a VCD
1. In the everRun Availability Console, click Virtual CDs.
2. Locate the VCD you want to remove in the list.
3. Ensure that the Can Remove column displays Yes for the VCD. If the value is No, the VCD is currently in use.
4. Select the VCD and click Remove in the lower panel.
Related Topics
Page 250 of 483
Managing Snapshots
"Renaming a Virtual CD" on page 250
"Inserting a Virtual CD" on page 248
"Ejecting a Virtual CD" on page 248
"Creating a Virtual CD" on page 246
"Managing Virtual CDs" on page 246
Managing Snapshots
Snapshots allow you to save an image of a virtual machine (VM) or of selected volumes on a VM at a particular point in time. You can use a snapshot to create a new VM on the same everRun system or you can export the snapshot to files on a network share for use on another everRun system.
Caution: Creating a snapshot results in the conversion of any RAW format volume to QCOW2 format, which may have performance implications for your system. You cannot convert the volumes back to RAW format; therefore, if you have a particular requirement for RAW format volumes, avoid using the snapshot feature.
Notes: l
You cannot revert the state of a VM to a snapshot; however, you can create a new VM from a snapshot or export files that you use to restore or duplicate the original VM.
l
When you create a snapshot, all volumes are selected, by default. You can, though, change the selection of individual volumes.
l
The boot volume is required for all snapshots.
You manage snapshots as described in: l
"Creating a Snapshot" on page 252
l
"Creating a Virtual Machine from a Snapshot" on page 256
l
"Exporting a Snapshot" on page 258
l
"Removing a Snapshot" on page 264
The everRun system's ability to take snapshots is enabled, by default. To disable or to re-enable the system's ability to take snapshots, see
"Disabling and Enabling Snapshots" on page 83 .
To view the snapshots that you have created in the everRun Availability Console:
Page 251 of 483
everRun User's Guide l
Open the Snapshots page (see
"The Snapshots Page" on page 105 )
l
On the Virtual Machines page (see
"The Virtual Machines Page" on page 100 ), click a VM and
click the Snapshots tab.
When you create a VM snapshot, the everRun system saves a snapshot image that includes any data that has changed in the VM since the previous snapshot, or, if no snapshots exist, since you originally created the VM. Because each snapshot contains only the changed data, some snapshots may take a small amount of storage space, and other snapshots may take more space depending on the level of VM activity and the amount of time that has passed since the previous snapshot.
Because snapshots are stored in the volume containers for each volume, ensure that you reserve enough storage space in the volume container for each volume you want to include in your VM snapshots, as described in
"Sizing Volume Containers" on page 16
. You can also remove older or obsolete snapshots to recover storage space.
You can create a snapshot of a VM whether the VM is running or shut down; however, if you want to create an application-consistent snapshot, where supported applications quiesce or freeze their operations to ensure data consistency, you must prepare your guest operating system as described in one of the following topics: l
l
"Installing the QEMU Guest Agent for Application-Consistent Snapshots (Linux-based VMs)" on page 225
Related Topics
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Creating a Snapshot
Create a snapshot to save an image of a virtual machine (VM) or of selected volumes on a VM at a particular point in time. You can use a snapshot to create a new VM on the same everRun system or you can export the snapshot to files on a network share for use on another everRun system. By default, the ever-
Run system's ability to take snapshots is enabled. To disable or to re-enable the system's ability to take snapshots, see
"Disabling and Enabling Snapshots" on page 83 . For an overview of snapshots, see
"Managing Snapshots" on page 251 .
Page 252 of 483
Creating a Snapshot
You can create a snapshot of a VM whether the VM is running or shut down; however, if you want to create an application-consistent snapshot, where supported applications quiesce or freeze their operations to ensure data consistency, you must prepare your guest operating system as described in one of the following topics: l
l
"Installing the QEMU Guest Agent for Application-Consistent Snapshots (Linux-based VMs)" on page 225
The number of snapshots you can create depends on the amount of storage space you have allocated in the volume container for each VM volume, as described in
"Sizing Volume Containers" on page 16 . If
Caution: Creating a snapshot results in the conversion of any RAW format volume to QCOW2 format, which may have performance implications for your system. You cannot convert the volumes back to RAW format; therefore, if you have a particular requirement for RAW format volumes, avoid using the snapshot feature.
Page 253 of 483
everRun User's Guide
Notes: l
For Linux-based VMs, if you want to create a snapshot of the VM to export to another system, consider editing the
/etc/fstab file to comment out entries for data volumes and allow only the boot volume to mount. Because Linux-based VMs may use different device names on another system, your new VM may boot into single-user mode if it cannot mount the volumes with their original device names. You can restore the
/etc/fstab entries in the new VM with the correct device names after the import process.
l
If you want to shut down the source VM while creating a snapshot, consider scheduling a planned maintenance period for this process.
l
When you create a snapshot, all volumes are selected, by default. You can, though, change the selection of individual volumes.
l
The boot volume is required for all snapshots.
l
If you want to use a snapshot to duplicate a VM, and you will continue to use the source
VM after the export, remember to set a different MAC address and IP address for the
VM when you import it on the target system.
l
If the everRun system switches from the primary PM to the secondary PM during the snapshot, the snapshot fails. This does not affect the continuous uptime of your system, but the snapshot is automatically deleted, and you need to start a new snapshot.
Prerequisite: Both PMs of the everRun system must be online for the snapshot process to function properly. If only one PM is online, the snapshot is written only to the online PM, and that same PM must be primary if you export the snapshot later.
To prepare for creating a snapshot (Windows-based VMs only)
1. If you want to create an application-consistent snapshot, ensure that the QEMU guest agent
is installed and running, as described in "Installing the QEMU Guest Agent for Application-
Consistent Snapshots (Windows-based VMs)" on page 222 .
2. Ensure that all volumes are labeled accurately, as summarized in "Managing Windows
Page 254 of 483
Creating a Snapshot
3. Run the Windows System Preparation Tool (
Sysprep
) if you need to prepare the guest operating system for redeployment.
To prepare for creating a snapshot (Linux-based VMs only)
If you want to create an application-consistent snapshot, ensure that the QEMU guest agent is
installed and running, as described in "Installing the QEMU Guest Agent for Application-Consistent
Snapshots (Linux-based VMs)" on page 225 .
To create a snapshot
1. Log on to the everRun system with the everRun Availability Console.
2. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify that both
PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
3. On the Virtual Machines page, select a VM.
4. With the VM selected, click the Snapshot button in the bottom pane.
5. In the Snapshot Virtual Machine dialog box, all volumes (under Volumes to Capture) are selected, by default. Deactivate the check box beside volumes that you do not want to capture in the snapshot. The boot volume is required for all snapshots.
Optionally, type a Snapshot Name and Description for the snapshot. The default Snapshot
Name for each new snapshot is the name of the VM, but you can type a more descriptive name.
(The snapshot name does not need to be unique.)
6. Click Create Snapshot. The snapshot begins, and the dialog box closes automatically.
Creating a snapshot typically takes a few seconds, but it may take longer depending on the level of
VM activity and the amount of time that has passed since the previous snapshot. You can determine the status of a snapshot by checking the State column on the Snapshots page: l
A broken icon ( ) indicates that a snapshot is still in progress, or that is written to only one node in the everRun system.
l
A normal icon ( ) indicates that a snapshot is complete.
Related Topics
Page 255 of 483
everRun User's Guide
"Managing Snapshots" on page 251
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Creating a Virtual Machine from a Snapshot
Create a virtual machine (VM) from a snapshot if you want to use a snapshot on your everRun system as
To create a VM from a snapshot, open the Snapshots page of everRun Availability Console, select a snapshot, and click Create VM. A wizard steps you through the process of creating the VM, as described in the following procedure.
Notes: l
When you create a snapshot that you intend to use as a source for a new VM, you must follow steps to prepare the guest operating system; otherwise, the VM image that you
create may not function as expected. For details, see "Creating a Snapshot" on page
l
When you create a VM from a snapshot, the original container size for each volume you include is not preserved. For example, if your source VM has a 20 GB boot volume in a
40 GB volume container, the new VM will have a 20 GB boot volume in a 20 GB volume container. If necessary, you can expand the volume containers for the new VM as described in
"Expanding a Volume Container on the everRun System" on page 243
.
l
To prevent conflicts with the source VM, the create VM wizard automatically assigns a new MAC address to each network interface in the new VM; however, you may need to manually update any IP addresses and host names.
Prerequisite: Ensure that both PMs of the everRun system are online; otherwise, the system cannot properly create the VM.
To create a new VM from a snapshot
Page 256 of 483
Creating a Virtual Machine from a Snapshot
1. Log on to the everRun system with the everRun Availability Console.
2. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify that both
PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
3. If you have not already done so, create a snapshot, as described in "Creating a Snapshot" on page
4. On the Snapshots page, select the snapshot to use as a source for the new VM.
Snapshots are usually in a normal state ( ) the State column. If a snapshot is broken ( ), it may indicate that one or more volumes in the snapshot are unavailable for the VM creation.
5. Click Create VM.
6. When prompted, type a new VM name and new volume names for the VM. The names must be unique on the everRun system.
7. Review the information and make any desired edits, if necessary: n
Name, CPU, and Memory
Change the name of the virtual machine, edit the number of vCPUs, or allocate the total memory it can use.
n
Storage
Shows all of the volumes. Select the Create box for a volume to allocate a storage container for the volume on the everRun system (the boot volume is required). Select the
Restore Data box to import data for a volume from the snapshot.
n
Network
Displays all of the available networks. You can remove a network or add one that is not already allocated. A minimum of one network is required.
8. Optionally, clear the check box for Auto start Virtual Machine if you need to reprovision the VM before starting it for the first time.
9. Click Create VM. When the process is complete, the wizard closes automatically.
10. If applicable, use the Reprovision Virtual Machine wizard to allocate additional resources to the
VM, as described in
"Reprovisioning Virtual Machine Resources" on page 233 . Also, if you want to
Page 257 of 483
everRun User's Guide
When you are finished reprovisioning the VM, click Start to boot the VM.
11. Click Console to open the console of the VM and log on to the guest operating system.
12. If necessary, update the network settings in the guest operating system.
Related Topics
"Managing Snapshots" on page 251
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Exporting a Snapshot
Export a snapshot to transfer a virtual machine (VM) image from an everRun system to a network share.
Exporting a snapshot makes the VM image available for importing to another system or for importing back to the same everRun system to restore or duplicate the original VM. (For an overview of snapshots, see
"Managing Snapshots" on page 251
. For additional VM migration/export methods, see "Creating and
Migrating Virtual Machines" on page 161 .)
You prepare for exporting snapshots by creating a network share to store VM exports in your environment, either a Windows share (also known as a Common Internet File System (CIFS) share) or a Network File
System (NFS) share. After creating this share, you mount it in the host operating system of your everRun system as described in this topic. When you initiate an export in the everRun Availability Console, the everRun system saves the VM image to the network share as standard Open Virtualization Format (OVF) and Virtual Hard Disk (VHD) files.
Page 258 of 483
Exporting a Snapshot
Notes: l
When you create a snapshot that you intend to export, you must follow steps to prepare the guest operating system; otherwise, the VM image that you create may not function as expected. For details, see
"Creating a Snapshot" on page 252 .
l
When you export a snapshot, you export a fully coalesced snapshot of the VM from that point in time, not only the changed data. If you want to create differential backups of a
VM, use a third-party backup solution.
l
When you export a snapshot to import a VM to another everRun system, the original container size for each volume you include is not preserved. For example, if your source VM has a 20 GB boot volume in a 40 GB volume container, the target VM will have a 20 GB boot volume in a 20 GB volume container. If necessary, you can expand the volume con-
l
The time required for the export depends on the size and number of volumes in the source VM as well as network bandwidth. For example, transferring a VM with one
20 GB boot disk over a 1 Gb/s network may take about 30 minutes.
l
If you will continue to use the source VM after the export, remember to set a different
MAC address and IP address for the VM when you import it on the target system.
l
If the everRun system switches from the primary PM to the secondary PM during an export, the export process fails. This does not affect the continuous uptime of your system. You can delete the partially exported files from your system running the everRun
Availability Console and export the files again.
Prerequisite: Both PMs of the everRun system must be online for the export process to function properly. You can export a snapshot from a single-node system only if all of the volume snapshots that you select to include in the export are present on the primary node, as displayed in the Export Snapshot dialog box. In most cases, snapshots are replicated on both nodes, but a snapshot may be unavailable if a node was offline when the snapshot was taken.
To create and mount an export share
Before you can export a snapshot, you must create and mount the network share to which the
Page 259 of 483
everRun User's Guide export(s) will be transferred, as follows:
1. Create a Windows/CIFS share or an NFS share in your environment where you can store
VM exports.
Ensure that you have enough storage space in the share for the VMs that you want to export. Also, set full read/write permissions on the export share to permit file transfers, or, for a Windows/CIFS share only, assign read/write permissions to a specific user on the system/domain that hosts the share. Record the share location and settings, which you will specify in a later step.
2. Log on to the everRun system with the everRun Availability Console.
3. On the Physical Machines page, make note of which PM is the primary node. In the list in the top pane, the primary node is marked as node n (primary).
4. Obtain the IP address of the primary node, if you do not already know it. For example, on the
Preferences page, click IP Configuration. Click the Node n IP tab for the primary node and record the IP Address value.
5. Use a secure shell ( ssh
) utility to log on to the host operating system (host OS) of the primary node of the everRun system, where you will mount the network share. Log on as the root user.
The next step shows how to use the ftxmnt script to automatically mount the export share. The script should work in most cases, but you can also manually mount the share by executing standard mount commands if needed.
Page 260 of 483
Exporting a Snapshot
Notes: n
If you manually mount the share in the host OS of the everRun system, you must create the mount point at
/mnt/ft-export
, where the export process expects to find it. (If you use the ftxmnt script, it automatically creates this mount point.) n
If you want the export mount to persist when you reboot the everRun system, manually add an entry to the
/etc/ftstab file in the host OS of the everRun system. (The ftxmnt script does not modify the
/etc/ftstab file.) n
You need to mount the export share only on the primary node of the ever-
Run system, but you can optionally add the mount to the
/etc/ftstab file on both nodes so it is always available even if the primary node changes.
n
If you mount a Windows/CIFS share that requires a password, and the password changes after the mount, you need to unmount the share and mount it again with the new password; otherwise, the export may fail unexpectedly.
6. To automatically mount the share, execute the ftxmnt script and respond to the interactive prompts. For example, the following output shows how to mount a
Windows/CIFS share (\\192.168.0.111\ExportVMs) that is accessible by a specific user account:
[root@node0 /]#
ftxmnt
This script is meant to mount a Network Attached Storage location to use for exporting everRun virtual machines.
Enter Ctrl-C to exit
Enter n if you are mounting an nfs share, enter w if you are entering a windows share:
w
What is the IP address or the computer name of the file
Page 261 of 483
everRun User's Guide server?
192.168.0.111
What is the name of the share you wish to mount?
ExportVMs
Does this share require authentication? (y/n):
Respond
y
to the prompt above if the share requires authentication. When you respond
y
, the following prompts appear: n
What is your username?
Enter your
domain\username
.
n
Password for domain\username:
Enter your password.
If the share does not require authentication, type
n
and then respond to the following prompt:
If there is a guest account name, enter it here:
Type the guest account name, if it exists.
The following message appears:
Successfully mounted folder \\192.168.0.111\ExportVMs at path /mnt/ft-export/
7. Switch to the /mnt/ft-export directory in the everRun host OS and create a file to verify that the share is present and that you have read/write permissions. For example:
#
touch test
#
ls
test
Confirm that the file also appears in the share on the remote system. If the file is not present or the everRun host OS displays an error, verify your mount settings and permissions.
8. Remove the test file.
#
rm test
Later, you want to unmount the share after exporting your virtual machines, switch out of the
/mnt/ft-export directory and execute the umount command, as follows:
Page 262 of 483
Exporting a Snapshot
#
cd /
#
umount /mnt/ft-export
To export a snapshot
1. Log on to the everRun system with the everRun Availability Console.
2. On the Physical Machines page (see
"The Physical Machines Page" on page 97 ), verify
that both PMs are in the running state and that neither PM is in maintenance mode or in the process of synchronizing.
4. On the Snapshots page, select the snapshot to export.
Snapshots are usually in a normal state ( ) the State column. If a snapshot is broken ( ), it may indicate that one or more volumes in the snapshot are unavailable for export. You can check volume availability in step 7.
5. Click Export.
6. In the Export Snapshot dialog box, type the path in /mnt/ft-export where you want the snapshot to be exported.
For example, if you want the export process to create a new directory named ocean1 to store the OVF and VHD files, type ocean1
. If you want the export process to create the ocean1 directory inside an existing directory named
TestVMs
, type
TestVMs/ocean1 .
7. Review the list of Captured Volumes and select the volumes to include in the export.
In most cases, the dialog box shows that All Captured Volumes are available for Export on node n
, the primary node. You can select any snapshots for export.
If one or more snapshots are unavailable on the primary node (usually because the node was offline when the snapshot was taken), the dialog box allows you to select only the available snapshots. If necessary, you can cancel the export, ensure that both nodes are in the running state , and create a new snapshot for export.
8. Click Export Snapshot. The export begins, and the dialog box closes automatically.
Page 263 of 483
everRun User's Guide
You can monitor the Export Status in the Summary tab for the snapshot that you selected. The export progress is reported as the percentage (%) completed. When the export is finished, the status changes to Export completed successfully.
The everRun system exports the VHD files (volumes) first, then it exports the OVF file. If you are monitoring the export share, you can confirm that the export is finished when the OVF file appears in the share.
After the export, if you want to import or restore the OVF and VHD files on an everRun system, see
"Importing an OVF File from an everRun 7.x System " on page 200
.
Troubleshooting
If necessary, use the following information to resolve problems with the export process.
To clean up after a canceled or failed export from the everRun system
Remove the VM files from the export folder or create a new folder for a subsequent export.
Related Topics
"Managing Snapshots" on page 251
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Removing a Snapshot
Remove a snapshot to permanently delete it from the everRun system.
Notes: l
When you remove a VM snapshot, you also remove all of its associated volume snapshots, which frees up storage space in the volume containers that contain those volume snapshots.
l
If you remove all volume and volume snapshot contents from a volume container, the system automatically removes the container from the system, which frees up space in the storage group.
To remove a snapshot
1. On the Snapshots page, select a snapshot to remove.
2. Click Delete.
Page 264 of 483
Advanced Topics (Virtual Machines)
Related Topics
"Managing Snapshots" on page 251
"Creating and Migrating Virtual Machines" on page 161
"Managing the Operation of a Virtual Machine" on page 227
Advanced Topics (Virtual Machines)
The following topics describe procedures and information for advanced users: l
"Assigning a Specific MAC Address to a Virtual Machine" on page 265
l
"Selecting a Preferred PM for a Virtual Machine" on page 267
l
"Changing the Protection Level for a Virtual Machine (HA or FT)" on page 267
l
"Configuring the Boot Sequence for Virtual Machines" on page 268
l
"Resetting MTBF for a Failed Virtual Machine" on page 269
l
"Locating a Dump File in a Virtual Machine" on page 270
Assigning a Specific MAC Address to a Virtual Machine
Assign a specific Media Access Control (MAC) address to a virtual machine (VM) if you need to override its default MAC address.
Page 265 of 483
everRun User's Guide
Warnings:
1. By default, the everRun software automatically assigns MAC addresses to the VMs.
Do not override the default settings unless you have specific requirements (for example, to support software applications that are licensed on a MAC-address basis).
2. If you change the Static System IP address, any MAC addresses automatically assigned to the VMs will change when the VMs reboot, because the everRun software generates MAC addresses for the VMs based on the system IP address. To prevent changes to the MAC address for a VM, set a persistent MAC address as described in the following procedure. Contact your network administrator to generate a valid
MAC address for your environment, and remember to update any firewall rules based on the new MAC address.
Prerequisite: Before modifying the MAC address for a virtual machine, you must shut down the VM.
To assign a specific MAC address to a VM
1. Open the Virtual Machines page (see
"The Virtual Machines Page" on page 100
).
2. Select a VM and click Shutdown.
3. When the VM has stopped, click Config to display the Reprovision Virtual Machine wizard.
5. On the Networks page, locate the network to modify and make a note of the current MAC address in case you need to restore it.
6. Type the new address in the MAC address column, or leave the text area blank to allow the ever-
Run software to automatically assign the MAC address.
7. Click Finish.
Related Topics
"Advanced Topics (Virtual Machines)" on page 265
"Managing Virtual Machine Resources" on page 232
"Managing the Operation of a Virtual Machine" on page 227
Page 266 of 483
Selecting a Preferred PM for a Virtual Machine
Selecting a Preferred PM for a Virtual Machine
Select a preferred physical machine to ensure that a virtual machine runs on a particular physical machine in the everRun system.
Note: By default, the system automatically balances the load of virtual machines over the two physical machines. Do not modify this setting unless you have specific load balancing requirements .
To select a preferred physical machine
1. On the Virtual Machines page, select a virtual machine.
2. In the bottom pane, click the Load Balance tab.
3. Choose your preference from the pulldown list and click Save.
Related Topics
"Advanced Topics (Virtual Machines)" on page 265
"Managing the Operation of a Virtual Machine" on page 227
Changing the Protection Level for a Virtual Machine (HA or FT)
You can change the protection level of guest VMs from high availability (HA) to fault tolerance (FT), or vice versa.
To change the protection level
1. On the Virtual Machines page, select a stopped VM (marked "stopped" in the Activity column).
(See
"Shutting Down a Virtual Machine" on page 227
for information about stopping a VM.)
2. In the bottom pane, click Config to open the Reprovision Virtual Machine wizard
3. On the Name, Description and Protection page, select the HA or FT button.
4. Continue clicking through the wizard pages to the last page. Press Finish and then OK (if the reconfiguration was successful).
Related Topics
"Modes of Operation" on page 11
(HA or FT)
"Advanced Topics (Virtual Machines)" on page 265
"Managing the Operation of a Virtual Machine" on page 227
Page 267 of 483
everRun User's Guide
Configuring the Boot Sequence for Virtual Machines
Configure the boot sequence of virtual machines to set the order in which guest operating systems and applications are started on the everRun system.
Determine the required boot sequence, then configure the boot settings for each virtual machine accordingly.
To set the boot sequence for a virtual machine
1. On the Virtual Machines page, select a virtual machine.
2. In the bottom pane, click the Boot Sequence tab.
3. Configure the boot settings, as described below.
4. Click Save.
The boot settings are as follows: l
Priority Group enables users to specify the order in which virtual machines boot after powering on the everRun system or after a failover, which requires restarting virtual machines. Some business solutions require specific virtual machines to be running before starting others. Group 1 is the highest priority and none is the lowest. The everRun software waits for the OS and Application
Start Time to elapse before starting virtual machines in the next priority group.
Boot sequence example:
VM Priority Group
OS and Application
Start Time
DNS
App
1
2
2 mins
30 secs
DB
Web
2
3
10 mins
0
1
2
3 everRun boots the DNS VM.
2 minutes after the DNS VM is started, everRun starts the App and DB servers in group 2.
10 minutes after the DB VM is started, everRun starts the Web VM in group 3.
Page 268 of 483
Resetting MTBF for a Failed Virtual Machine l
OS and Application Start Time should be set to the time it takes from starting the virtual machine until the guest operating system and applications are fully functional.
Related Topics
"Advanced Topics (Virtual Machines)" on page 265
"Managing the Operation of a Virtual Machine" on page 227
Resetting MTBF for a Failed Virtual Machine
Reset the mean time between failure (MTBF) counter for a virtual machine to attempt to restart a failed virtual machine.
If a virtual machine's guest OS crashes, everRun automatically restarts it, unless it has fallen below its
MTBF threshold. If the virtual machine is below the MTBF threshold, everRun leaves it in the crashed state. If necessary, you can reset the MTBF counter and restart the virtual machine.
Caution: Do not reset the MTBF counter unless instructed to do so by your authorized Stratus service representative, as doing so may affect the continuous uptime of your system.
Notes:
1. The Reset Device button is displayed only if the virtual machine falls below its MBTF threshold.
2. The Clear MTBF button is displayed only if the system software supporting a VM on one physical machine falls below its MBTF threshold.
To reset the MTBF counter for a virtual machine
1. On the Virtual Machines page, select a virtual machine.
2. Click Reset Device.
If the system software supporting a VM on one physical machine fails too often, perform the steps below to reset its MTBF counter.
To reset the MTBF counter for a VM on one physical machine
1. On the Virtual Machines page, select a virtual machine.
2. Click Clear MTBF.
Page 269 of 483
everRun User's Guide
Related Topics
"Advanced Topics (Virtual Machines)" on page 265
"Managing the Operation of a Virtual Machine" on page 227
"Creating a Diagnostic File" on page 87
Locating a Dump File in a Virtual Machine
Locate a dump file in a virtual machine (VM) if the VM has crashed and you need to collect the dump file for troubleshooting purposes.
To collect a dump file for your service representative l
For Windows-based VMs—Retrieve the file from C:\WINDOWS\MEMORY.DMP (by default) in the file system of the VM.
l
For Linux-based VMs—Retrieve the dump file from the
/var/crash directory (by default) in the file system of the VM.
If you cannot locate a dump file, ensure that you configured the guest operating system to generate a crash dump file when the operating system hangs: l
Windows-based VMs: Follow the instructions in the Microsoft article,
How to generate a complete crash dump file or a kernel crash dump file by using an NMI on a Windows-based system
(Article
ID: 927069). Follow the instructions in the More Information section.
l
Linux-based VMs: Install the kexec-tools package and enable crash dumps. For more information, see your Linux documentation.
Related Topics
"Advanced Topics (Virtual Machines)" on page 265
"Managing the Operation of a Virtual Machine" on page 227
"Creating a Diagnostic File" on page 87
Page 270 of 483
9
Chapter 9: Maintaining Physical Machines
You can maintain PMs in an everRun system by adding or replacing various components or even the entire
PM.
Determine what component needs to be replaced and then read the topic for the appropriate procedure: l
To add or replace PM components, see: n
"Adding or Replacing Hot-Swappable Components" on page 272
for hot-swappable components such as network cables, fans, and power supplies n
"Adding or Replacing Components That Are Not Hot-Swappable" on page 273
for components such as CPUs and memory or any other component that is not hot-swappable.
n
"Adding a New NIC" on page 274
for adding new network interface cards (NICs).
l
To replace a PM or a failed motherboard, NIC, or RAID controller, see "Replacing Physical
Machines, Motherboards, NICs, or RAID Controllers" on page 276 .
l
To replace a PM that is connected to external storage, see "Replacing a Failed Physical Machine
Connected to External Storage" on page 279 .
l
To upgrade both PMs in a running system, see "Upgrading Both Physical Machines In a Running
For information on disks, see
"Logical Disks and Physical Disks" on page 15 .
Page 271 of 483
everRun User's Guide
Physical Machine Hardware Maintenance Restrictions
When you replace physical machines (PMs), motherboards, or RAID controllers, you should ensure compatibility by complying with these restrictions: l
New PMs must have processors that are from the same processor family as the existing PM, in order to support live migration. If the processors in the new and existing PMs are from different processor families, you must stop the VMs to migrate them from the existing PM to the new PM.
l
CPUs on a replacement PM must be compatible with the CPUs on the original PM.
l
In the replacement PM, the quantity of the following resources must be the same or greater than in the original PM: n
Number of processor cores.
n
Total memory.
n
Total logical disk capacity.
n
Total number of network ports; each port must support, at a minimum, the speed of the existing ports, and all add-on NICs within a particular PM must have the same vendor/model number.
n
Total number of network ports; each port must support, at a minimum, the speed of the existing ports.
In addition, check
"System Requirements Overview" on page 24
for information about system hardware and software requirements before performing hardware maintenance on a PM, to confirm that the maintenance you are planning complies with any system restrictions.
Related Topics
"Maintenance Mode" on page 145
"Maintaining Physical Machines" on page 271
"The everRun Availability Console" on page 60
"Physical Machines and Virtual Machines" on page 9
"The Physical Machines Page" on page 97
Adding or Replacing Hot-Swappable Components
Page 272 of 483
Adding or Replacing Components That Are Not Hot-Swappable
Use this procedure to add or replace a component that is hot-swappable. Such components may include network cables, fans, and power supplies. In this procedure, the PM continues to run.
To add or replace a hot-swappable component
1. Determine which PM (node0 or node1) requires the component.
2. In the everRun Availability Console, click Physical Machines in the left-hand navigation panel.
3. Select the appropriate PM (node0 or node1) and then click Work On, which changes the PM’s
Overall State to Maintenance Mode and the Activity state to running (in Maintenance).
4. Follow vendor instructions for adding or replacing a hot-swappable component in the PM.
5. Select the repaired PM on the Physical Machines page. Click Finalize and then click OK.
If you add a cable to both PMs and if they are on the same subnet, everRun detects the connectivity and pairs the NICs in a newly created shared network. You have the option of renaming the newly created shared network on the network page.
Related Topics
"Maintenance Mode" on page 145
"Maintaining Physical Machines" on page 271
"The everRun Availability Console" on page 60
"Physical Machines and Virtual Machines" on page 9
"The Physical Machines Page" on page 97
Adding or Replacing Components That Are Not Hot-Swappable
Use this procedure to add or replace a component that is not hot-swappable. Such components may include CPUs and memory as well as fans and power supplies that are not hot-swappable.
In this procedure, you gracefully shut down a running PM.
Page 273 of 483
everRun User's Guide
To add or replace a component that is not hot-swappable
1. Determine which PM (node0 or node1) or if each PM requires the replacement component.
2. In the everRun Availability Console, click Physical Machines in the left-hand navigation panel.
3. Select the appropriate PM (node0 or node1) and then click Work On, which changes the PM’s
Overall State to Maintenance Mode and the Activity state to running (in Maintenance).
4. After the PM displays running (in Maintenance), click Shutdown and then OK.
5. Add or replace the component.
6. If you disconnected any network cables, reconnect them. Do not add cables to any new network ports in this step.
7. On the PM that is shutdown, press the power button. As the PM powers on, everRun also powers on and begins synchronizing the PM's storage ( appears).
8. On the Networks page, click the Fix button, if it is highlighted, which may occur when network cables have been moved on the upgraded PM.
9. Select the repaired PM on the Physical Machines page. Click Finalize and then click OK.
10. When synchronization is complete ( disappears), perform steps 3 through 9 for the other PM, if necessary.
Note: To avoid data loss, do not power down the primary PM while the disks are synchronizing.
Related Topics
"Maintenance Mode" on page 145
"Maintaining Physical Machines" on page 271
"The everRun Availability Console" on page 60
"Physical Machines and Virtual Machines" on page 9
"The Physical Machines Page" on page 97
Adding a New NIC
Page 274 of 483
Adding a New NIC
When adding new NICs, you must add NICs to both physical machines (PMs) and then cable the NICs to the appropriate switch on both sides in order to establish connectivity and to form one or more shared networks that you can then assign to VMs or use as A-links.
To add new NICs
Note: You can begin this procedure with node0 or node1 and then continue with the other node. The procedure below begins with node0 for simplicity.
1. In the everRun Availability Console, click Physical Machines in the left-hand navigation panel.
2. Perform the following for node0: a. Select the appropriate node and then click Work On.
b. After the node displays running (in Maintenance), click Shutdown and then OK.
c. Insert the new NIC in the desired slot.
d. Press the power button to power on the node.
Wait for the PM to boot and for the everRun Availability Console to display running as the
Activity state for the appropriate node under Physical Machines.
e. Click Finalize for and then click OK, which exits the node from maintenance mode.
Wait while storage synchronization completes ( disappears).
3. Perform Step 2 for node1.
In node1 insert the new NIC in the slot that corresponds to the slot where you inserted the new NIC in the PM that is node0 (Step c, above).
4. Connect network cables to the new NICs, as needed, and configure the new network as an A-Link or a business network. See
"Connecting Additional Networks" on page 56 .
5. Reconfigure and start any VMs that need to use the new networks. See "Managing Virtual
Related Topics
"Maintenance Mode" on page 145
Page 275 of 483
everRun User's Guide
"Maintaining Physical Machines" on page 271
"The Physical Machines Page" on page 97
"The Virtual Machines Page" on page 100
"Business and Management Network Requirements" on page 28
"General Network Requirements and Configurations" on page 27
Replacing Physical Machines, Motherboards, NICs, or RAID Controllers
You replace motherboards, NICs, RAID controllers, and a physical machine (PM) in an everRun system while the system is running. You can remove PMs to upgrade a PM or to replace a failed PM. You can replace motherboards, NICs, or RAID controllers. Several types of hardware faults can hang or crash a
PM in an everRun system, including a failure of the motherboard, CPU, mid-plane, or storage controller. (If
You remove a PM using the everRun PM Remove function, which deletes a PM from the everRun system’s database. The everRun system then waits while an additional PM completes the process of joining the system.
Maintenance Restrictions" on page 272 .
Warning: This procedure deletes all software you may have installed on the PM and all PM configuration information you may have entered before the replacement procedure. After you complete this procedure, you must manually re-install all your software and reconfigure the PM to match your original settings.
Page 276 of 483
Replacing Physical Machines, Motherboards, NICs, or RAID Controllers
Prerequisite: Obtain installation software for the everRun release that the PM has been running using one of the following methods: l
Download an install ISO from your authorized Stratus service representative.
l
Extract an install ISO into the current working directory from the most recently used upgrade kit by executing a command similar to the following ( x.x.x.x
is the release number and nnn is the build number): tar -xzvf everRun_upgrade-x.x.x.xnnn .kit *.iso
After you obtain the correct install ISO, save it or burn it to a DVD. See "Obtaining everRun
Prerequisites: If you are replacing a PM, prepare the new PM:
1. Configure networks. See
"Network Architecture Overview" on page 19 .
2. Configure storage. See
"Storage Requirements" on page 25
.
3. Connect power. See
.
4. Configure the firmware (BIOS or UEFI). See "Configuring Settings in the Firmware
To remove and replace a failed PM, motherboard, NIC, or RAID controller
1. In the everRun Availability Console, click Physical Machines in the left-hand navigation panel.
2. Select the appropriate PM (node0 or node1) and then click Work On, which changes the PM’s
Overall State to Maintenance Mode and the Activity state to running (in Maintenance).
3. After the PM displays running (in Maintenance), click Shutdown and then OK.
4. After the PM has shut down, click Remove (
) and respond appropriately to the confirmation message. An alert message appears if removal conditions are not met.
If you confirm that you want to remove the PM, the everRun software deletes the PM from the ever-
Run system, and displays a message that the system has successfully deleted the PM.
To replace the PM, continue with the steps below.
Page 277 of 483
everRun User's Guide
5. Manually power off the old PM.
6. Install the new PM or component. If you are replacing a motherboard, NIC, or RAID controller, do so now. If you are replacing the PM, disconnect and remove it now, and then install the new PM.
Check that a monitor and keyboard are connected to it.
7. Reconnect any network cables to their original positions. Check that Ethernet cables are connected from the new PM (or new NIC) to the network or directly to the running (primary) PM, if the two everRun system PMs are in close proximity. One Ethernet cable should connect from the first embedded port on the new PM or from a NIC port if the new PM does not have an embedded port.
8. Manually power on the PM. As the PM powers on, enter the firmware (BIOS or UEFI) setup utility, and set the Optical Drive as the first boot device.
9. Either mount the ISO image or insert the DVD into the PM.
10. At the Welcome screen, select Replace PM, Join system: Initialize data and press Enter.
Note: If necessary, see
"Installing Software on the Second PM" on page 51
for reference. Although that topic refers to the "second PM," in this instance, it applies to the replacement PM.
11. If any disk contains previously installed data, the following message appears and the system reboots (if no disk contains previously installed data, installation continues with the next step):
Rebooting because disks
XXX were erased.
When the reboot is complete, the boot menu reappears and you must continue with Step 10, above.
12. When prompted, respond to the Select interface for private Physical Machine connection, and then respond to the prompt Select interface for managing the system (ibiz0).
13. When prompted to configure ibiz0, select Automatic configuration via DHCP or Manual Configuration (Static Address). (The installation software configures priv0 automatically.)
14. When installation is complete, the PM ejects the install DVD (if used) and reboots.
15. As the PM boots up, the everRun Availability Console displays its activity on the Physical
Machines page. The Activity column displays the new PM as recovery (in Maintenance) and then running (in Maintenance).
16. Assign logical disks from the new PM to storage groups on the everRun system, as described in
Page 278 of 483
Replacing a Failed Physical Machine Connected to External Storage
"Assigning a Logical Disk to a Storage Group" on page 144 .
Notes: n
When the new PM joins the everRun system, the system automatically adds the secondary everRun system disk to the Initial Storage Group; however, the system does not assign any other logical disks from the new PM to existing storage groups.
n
If you assigned logical disks to the Initial Storage Group or other storage groups on the first PM, you must manually add matching logical disks from the new PM to the same storage groups; otherwise, the everRun system cannot fully synchronize.
17. When you are ready to bring the replacement PM online, click Finalize to exit maintenance mode.
Verify that both PMs return to the running state and that the PMs finish synchronizing. The initial synchronization may take minutes or hours depending on your configuration, including the amount of storage and the number of VMs.
18. Manually reinstall applications and any other host-level software and reconfigure the PM to match your original settings.
Related Topics
"Maintenance Mode" on page 145
"Maintaining Physical Machines" on page 271
"The everRun Availability Console" on page 60
"Physical Machines and Virtual Machines" on page 9
"The Physical Machines Page" on page 97
Replacing a Failed Physical Machine Connected to External Storage
You can replace a failed physical machine (PM) that is connected to external storage while the system is running. You begin by unmapping and deleting all LUNs on the external storage array that are mapped to the failed PM. After the failed PM is replaced, you need to update the lvm.conf
file, configure multipath, create new LUNs on the external storage systems, scan for new LUNs, configure initrd for multipath, and then place the LUNs in the proper storage group(s).
Page 279 of 483
everRun User's Guide
For detailed information, access the Knowledge Base to search for the article Replacing a Failed Physical
Machine Connected to External Storage
4298
). See "Accessing Knowledge Base Articles" on page
Related Topics
"Managing External Storage " on page 281
"Maintaining Physical Machines" on page 271
Upgrading Both Physical Machines In a Running System
Prerequisite: Before you upgrade to new physical machines,see "Physical Machine Hardware
Maintenance Restrictions" on page 272 .
To upgrade to new physical machines
1. Upgrade everRun software if required to support the new PM. See the everRun Release Notes and the help on the everRunUpgrade Kits page of the everRun Availability Console
3. Repeat for the second PM. The everRun software then migrates the VMs to the other PM.
4. If you added additional NIC ports, see
"Network Architecture Overview" on page 19
.
Related Topics
"Maintenance Mode" on page 145
"Maintaining Physical Machines" on page 271
"The everRun Availability Console" on page 60
"Physical Machines and Virtual Machines" on page 9
"The Physical Machines Page" on page 97
Page 280 of 483
10
Chapter 10: Managing External Storage
Manage external storage by performing these tasks: l
"Adding or Removing External Storage LUNs" on page 281
l
"Configuring External Storage in a Newly Installed Release 7.4.x System" on page 282
l
"Configuring Linux Multipathing" on page 283
l
"Removing External Storage Disks" on page 287
l
"Updating initrd for Multipath" on page 287
l
"Upgrading a System with External Storage from Release 7.3.4 to 7.4.x" on page 286
For information on maintaining and troubleshooting physical machines with external storage, see the following: l
"Recovering a Failed Physical Machine with External Storage " on page 152
l
"Replacing a Failed Physical Machine Connected to External Storage" on page 279
For general storage information, see: l
"External Storage" on page 17 .
l
"everRun Storage Architecture" on page 15
Adding or Removing External Storage LUNs
Use your storage array's software to map a new LUN to the everRun system or to remove a LUN.
However, everRun software does not automatically detect the addition or removal of external storage
LUNs. In order for everRun to recognize the changes, you must configure the host OS (CentOS):
Page 281 of 483
everRun User's Guide l
To add LUN0, you first remove LUNZ.
l
To add LUN1 (or greater), you issue lsscsi
, echo
, multipath
, and dracut commands.
l
To remove LUNs, you issue multipath
, echo
, and dracut commands.
For detailed information, access the Knowledge Base to search for the article Adding or Removing
External Storage (KB4299 ). See
"Accessing Knowledge Base Articles" on page 479 .
Related Topics
"Managing External Storage " on page 281
"Replacing a Failed Physical Machine Connected to External Storage" on page 279
Configuring External Storage in a Newly Installed Release 7.4.
x
System
After you install an everRun system, you can connect and configure external storage. everRun systems support Fibre Channel and iSCSI storage systems.
Prerequisites: Before performing the procedure below, you need to:: l
Install the system hardware and software. For information on installing the hardware, see the manufacturer's instructions. For information on installing the everRun software, see
"Software Installation" on page 34 .
l
If the external storage is Fibre Channel, you need to install the FC HBAs in each physical machine (PM) and map each HBA WWN properly to the SAN switches (if used) and the external storage array.
l
Physically connect the external storage according to the manufacturer's instructions.
To configure external storage in a newly installed Release 7.4.
x system
Perform the following steps on node0, first, and then on node1:
1. Edit the
/etc/lvm/lvm.conf
file, adding the boot disk and data disk(s) to the filter entry. The following steps are an example: a. Uncomment the filter entry.
b. Add the boot disk a/sda/ and any internal data disk(s) installed in the system to the filter
Page 282 of 483
Configuring Linux Multipathing entry. The following example is for a system with a data disk sdb
: filter = [ "a/sda/", "a/sdb/" ]
2. Configure multipath, as described in
"Configuring Linux Multipathing" on page 283
.
3. Configure external storage, as described in "Adding or Removing External Storage LUNs" on page
281 as well as the instructions provided by your external storage system vendor.
If the system is connected to iSCSI external storage, copy (or make note of) the new iSCSI
'iqn' from the PM you replaced and update the PM's host entry in the external storage array with the new
'iqn'
. You must perform this step before you can map the new LUNs to the new PM
4. Create new LUNs on the external storage array and map them to new PM.
5. Create new storage groups.
For example, if you map two LUNs, one 250 GB and one 750 GB, to the node, you could create the new storage groups StorageGroup_250GB and StorageGroup_750GB.
6. Rescan the node in order to discover new LUNs by issuing echo commands (for additional information, see
"Adding or Removing External Storage LUNs" on page 281
).
The following commands are examples: echo "- - -" > /sys/class/scsi_host/host1/scan echo "- - -" > /sys/class/scsi_host/host6/scan
After the scan, you can view the new LUNs in the everRun Availability Console by navigating to the
Storage tab of the Physical Machines page. See
"The Physical Machines Page" on page 97 .
7. Place the LUNs into the appropriate storage group (created in Step 5, above). For example, place the 250 GB LUN in StorageGroup_250GB.
Repeat this procedure on the other node.
Related Topics
"Managing External Storage " on page 281
"Replacing a Failed Physical Machine Connected to External Storage" on page 279
Configuring Linux Multipathing
Page 283 of 483
everRun User's Guide
You must configure the everRun system to use Linux multipathing if the system includes external storage.
Multipathing enables the system to provide multiple paths to external storage systems. When everRun software is installed, the device-mapper-multipath package is also installed. However, everRun software does not configure multipath. Follow the instructions provided in the CentOs documentation to configure multipath. See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/DM_
Multipath/ .
For everRun software to function properly, you must perform the required procedures below on both nodes after configuring multipath.
To set path_selector, blacklist drbd, and then set no_path_retry
1. Set up the initial
/etc/multipath.conf
file by issuing the following command: mpathconf --enable --user_friendly_names y --find_multipaths y
--with_multipathd y
2. Edit the /etc/multipath.conf
file, making the following changes: a. Add the entry path_selector "round-robin 0" to the defaults section, as in the following example.
## Use user friendly names, instead of using WWIDs as names.
defaults { user_friendly_names yes find_multipaths yes path_selector "round-robin 0"
} b. Add or modify the blacklist entry (at the end of the multipathd file) to include drbd
, so that the entry is identical to the following: blacklist { devnode "^(ram|zram|raw|loop|fd|md|dm-
|sr|scd|st|drbd)[0-9]*"
}
Page 284 of 483
Configuring Linux Multipathing c. Add the following devices entry just below the blacklist line: devices { device { vendor "DGC" product "VRAID" no_path_retry "0"
}
}
Note: The example shown above is for an EMC storage array. The values for vendor and product vary according to the manufacturer and model of your storage array.
d. Save the /etc/multipath.conf
file.
3. To restart multipathd and to ensure that it can start at boot time and is functioning properly, issue the following commands in the order given: systemctl restart multipathd systemctl enable multipathd systemctl status multipathd
4. To verify that no_path_retry is set to fail
, issue the following command: multipathd show config
The following sample lines appear at the end of output for an EMC VNX configuration: device { vendor "DGC" product "VRAID" product_blacklist "LUNZ" path_grouping_policy "group_by_prio"
Page 285 of 483
everRun User's Guide path_checker "emc_clariion" features "0" hardware_handler "1 emc" prio "emc" failback immediate rr_weight "uniform" no_path_retry "fail" retain_attached_hw_handler yes detect_prio yes
}
Related Topics
"Managing External Storage " on page 281
Upgrading a System with External Storage from Release 7.3.4 to 7.4.
x
Caution: The Qualify procedure will not allow an upgrade from everRun Release 7.3.4 to 7.4.0
on a system with external storage. You must call your Stratus service representative to enable the upgrade.
Upgrading from everRun Release 7.3.4 to Release 7.4.
x on a system with external storage requires additional steps before and after the software upgrade. For instance, before you begin the upgrade, you must first shutdown all VMs and delete all deployed VCDs. In addition, the upgrade includes updating initrd as well as modifying the multipath.conf
and lvm.conf
files for systems with Fibre Channel or iSCSI external storage. The upgrade for systems with iSCSI external storage also includes stopping and restarting the everrun-sim service, remapping LUNs, and using iscsiadmin for various tasks.
For the latest technical information, contact your Stratus service representative and refer to KB-4273.
Related Topics
"Managing External Storage " on page 281
"Upgrading everRun Software" on page 115
Page 286 of 483
Removing External Storage Disks
Removing External Storage Disks
To remove external storage disks, you need to unmap the LUN(s) from the external storage array, rescan the disks, delete the devices and the device nodes, issue dracut , and reboot the node, performing these tasks on node0 and node1. Finally, repair the disk(s).
For detailed information, access the Knowledge Base to search for the article Removing External Storage
Disks (KB4335 ). See
"Accessing Knowledge Base Articles" on page 479 .
Related Topics
"Managing External Storage " on page 281
"The Physical Machines Page" on page 97
Updating initrd for Multipath
For some external storage procedures, you need to update the initial RAM disk image ( initrd ) for multipath using dracut
.
For detailed information, access the Knowledge Base to search for the article Updating
initrd
for Multipath (KB4295 ). See
"Accessing Knowledge Base Articles" on page 479
.
Related Topics
"Managing External Storage " on page 281
Page 287 of 483
Part 2: Supporting Documents
See the following support documents for release information, and reference and troubleshooting information.
l
"everRun Release 7.4.0.0 Release Notes" on page 290
l
"everRun Command Line Interface Reference" on page 304
l
"System Reference Information" on page 472
l
11
Chapter 11: everRun Release 7.4.0.0 Release Notes
These Release Notes are for everRun release 7.4.0.0 (updated at 4:27 PM on 4/19/2017). See the following sections: l
Accessing Stratus Knowledge Base Articles
l
l
l
l
l
Notes: l
For the latest technical information and updates, please refer to the English version of the everRun User's Guide at the Downloads page at http://www.stratus.com/go/support/everrun and the Knowledge Base in the Stratus Customer Service
Portal at https://support.stratus.com
(see
Accessing Stratus Knowledge Base Articles
for more information).
l
For information about documentation changes that were made late in the release and may appear only on the StrataDOC web site, see
Accessing Stratus Knowledge Base Articles
Page 290 of 483
everRun User's Guide
The Stratus Customer Service Portal provides a searchable Knowledge Base with technical articles about all Stratus products, including everRun. In some cases, the Release Notes directly reference these
Knowledge Base articles (for example, KBnnnn
). You can access the Customer Service Portal and the
Knowledge Base articles by using your existing service portal credentials, or by creating a new user account, as follows.
To access the Knowledge Base
1. Log on to the Stratus Customer Service Portal at https://support.stratus.com
If needed, create a new account as follows: a. Click Register Account.
b. Enter your company email address and contact info, and click Register.
Your company email address must include a domain name (for example, stratus.com) for a company that is a registered customer of Stratus.
c. Click the link in the email that you receive from Stratus.
d. Enter a new password and finish configuring your account.
If you need assistance creating an account, contact your authorized Stratus service representative.
2. In the service portal, click Knowledge Base in the left pane.
3. In the Keyword Search box, enter keywords associated with the information you need, and then click Search.
To search for an article by its KBnnnn number, click Advanced Search. Next to Search by ID, type the article ID number ( nnnn ) and click Display.
New Features and Enhancements
New in everRun Release 7.4.0.0
l
Platform and Host OS Support n
Intel Broadwell processors (supported in Release 7.3.4.0 or higher) o
Intel Xeon E3-1XXX v4 o
Intel Xeon E5-1XXX v4
Page 291 of 483
New in everRun Release 7.4.0.0
o
Intel Xeon E5-2XXX v4 n
CentOS 7.2 host operating system l
Performance Improvements n
Page Modification Logging (PML) with Intel Broadwell processors n
4K sector disks l
Host OS Installation n
Unified Extensible Firmware Interface (UEFI) support n
Installation from USB device (for example, a thumb drive) n
PXE host installation n
Self-verifying checksum for installation ISO l
Host OS Upgrade n
Upgrade supported from Release 7.3.4.0 to 7.4.0.0 or higher n
Pre-upgrade check (Qualify button on Upgrade Kits page) l
Virtual machines n
Support for new guests o
Windows 10 o
RedHat/CentOS 6.7, 6.8, 7.1, and 7.2
o
Ubuntu 16.04
n
Support for 28 VMs (up to 8 of these can be FT VMs) n
ISO image repository for VM creation n
Console keyboard selection (English, German, Japanese) n
Expand volume size in everRun Availability Console n
Guest CD/DVD access n
Detach/reattach boot volumes for troubleshooting n
Copy a shutdown VM (without snapshot) n
Export a shutdown VM (without snapshot)
Page 292 of 483
everRun User's Guide l
Network n
Jumbo Frames on business networks n
Enable/disable network interfaces (AVCLI) l
Storage n
4K sector size for logical disks, storage groups, and VM data volumes n
Enable/disable storage devices (AVCLI) l everRun Availability Console n
Java eliminated from VM wizards n
Grayed-out buttons for inactive features n
Guest OS displayed in VM details n
Disk sync progress/direction on a per VM basis displayed in VM details l
Audit Log Updates n
Log VM events and new user creation n
Internationalized logs l e-Alerts n
Alternate SMTP port n
TLS encryption n
Include asset ID in e-Alerts l
Host Security n
HTTPS-only option n
IPTables port security option n
Active Directory improvements n
Host OS inactivity automatic logout l
Snapshots
Page 293 of 483
Features No Longer Supported in everRun Release 7.4
n
Individual volumes n
Enable/disable snapshots n
Create VM directly from snapshot l
P2V client n
Windows 8.x and Windows Server 2012 support n
HA guest targets n
Support for more than four volumes n
Storage group placement control on target system
Features No Longer Supported in everRun Release 7.4
l
One View Console l
Disaster Recovery and simplex everRun nodes l
Nagios
® monitoring solutions
Important Considerations
Upgrading From Previous Releases of everRun
Caution: Please contact Stratus Support for updated Upgrade instructions.
you must upgrade to Release 7.3.4.0 first, and then upgrade to Release 7.4.
The upgrade to everRun Release 7.4 requires no VM downtime unless your system has external storage, as summarized in
"Upgrading a System with External Storage from Release 7.3.4 to 7.4.x" on page 286 .
Caution: All PMs and VMs must be in good health prior to performing an upgrade of the ever-
Run software. Before starting an upgrade, examine the everRun Availability Console to verify that there are no alerts indicating PM or VM problems.
When upgrading to everRun Release 7.4, consider the following:
Page 294 of 483
everRun User's Guide l
One View Console and Disaster Recovery are not supported.
If your everRun system is registered with the One View Console, you must unmanage the system before upgrading. If your VMs are protected by Disaster Recovery, you must unprotect the VMs, and then unmanage the everRun system before upgrading. For information on completing these tasks, see the One View and Disaster Recovery online help.
l
Nagios monitoring solutions are not supported.
everRun Release 7.4 no longer supports Nagios monitoring which was a technology preview in everRun 7.3. Nagios add-ons are automatically removed during the upgrade process.
l
Upgrading everRun systems with external storage requires assistance from Stratus
Caution: The Qualify procedure will not allow an upgrade from everRun Release 7.3.4
to 7.4 on a system with external storage. You must contact Stratus Customer Service to enable the upgrade.
Upgrading to Release 7.4 on a system with external storage requires additional steps before and
after the software upgrade, as summarized in "Upgrading a System with External Storage from
Release 7.3.4 to 7.4.x" on page 286 . For example, you will need to shut down all VMs and delete all
deployed VCDs to begin the process. For the latest technical information, please contact your
Stratus service representative and refer to KB-4273. Also see
for information about other new and updated external storage topics.
Note: When adding or upgrading external storage attached to your everRun system, you must configure the everRun system to use Linux multipathing to provide redundant
paths to your external storage systems. See "Configuring Linux Multipathing" on page
l everRun Release 7.4 requires more disk space than previous releases everRun Release 7.4 requires more disk space than previous releases to accommodate changes for the host operating system. The amount of space required can be up to 10 GiB per logical system disk. To verify that your Release 7.3.4.0 system meets the upgrade requirements, upload the
Release 7.4 upgrade kit on the Upgrade Kits page of the everRun Availability Console. Uploading the kit gives you access to the Qualify button that you can click to run qualification checks. (Note
Page 295 of 483
Using 4K Disks for Better Performance that the Qualify button is available only in 7.3.4.0 or higher.) For more information about using the
Qualify button and upgrading your system, see
"Upgrading everRun Software" on page 115
.
l
Windows-based VMs require Red Hat VirtIO driver updates after upgrade.
After upgrading to Release 7.4, update the VirtIO drivers in your Windows-based VMs to the latest supported versions to ensure the proper operation of your VMs. Download and install the supported
Caution: RHEL 7.0 and CentOS 7.0 Virtual Machines must use kernel version 3.10.0-
123.8.1 or later. If using an earlier kernel version there is a risk that the VM may hang.
l
Any manually added RPMs or customized host OS configuration settings are lost.
The upgrade kit for Release 7.4 performs the upgrade by reinstalling the everRun software on each node and restoring any settings associated with everRun features and management; however, the upgrade does not preserve any supplementary packages (for example, Dell OpenManage) or customized settings (for example, SNMP monitoring) that you may have implemented. If applicable, make note of any customizations and manually restore them after the upgrade.
l
Any manually added IPtables port filtering changes are lost.
everRun Release 7.4 includes improved IPtables port filtering, which you manage in the everRun
Availability Console. As a result of the changes, upgrading will overwrite any settings you have manually entered in the host OS. If applicable, make note of any customizations and manually restore them after the upgrade. Use only the everRun Availability Console to configure IPtables filtering in Release 7.4 or higher.
Using 4K Disks for Better Performance everRun Release 7.4 or higher supports 4K sector size disks in native mode. Stratus recommends using
Do Not Update CentOS Host OS Directly From CentOS
Do not update the CentOS host OS of the everRun system directly from CentOS. Use only the CentOS release that is installed along with everRun software.
Optimizing Performance of A-Link Networks
Page 296 of 483
everRun User's Guide
Enabling jumbo frames on A-Link networks by changing their Ethernet frame MTU size from the default
1500 bytes to 9000 bytes may improve VM performance and reduce host processing overhead. See KB-
4262 for instructions.
Status of RAID Physical Disks Is Not Monitored everRun software does not monitor the state of physical disks in a RAID set. You must use the tools supplied by the RAID controller vendor to monitor the health and status of individual physical disks in a RAID set.
Other Important everRun Considerations
For important considerations about everRun systems, see "Important Physical Machine and Virtual
Machine Considerations" on page 476 .
Known Issues
Replacing an Existing Node Without First Removing It Fails
If you try to replace and initialize an existing node without first removing it from the everRun system, the
Machines, Motherboards, NICs, or RAID Controllers" on page 276 .
Avoid Removing a VM While Only One Node is Running
To avoid downtime, always ensure that both nodes are in the running state and that neither node is in maintenance mode or in the process of synchronizing before removing a VM.
If you remove a VM while one node is shut down in maintenance mode, the operation may stall with the error, "There was a problem deleting vm-name
." To correct the problem, you must restart the only running node.
Invalid VM Names Prevent Some VM Operations from Executing
The everRun Availability Console may improperly validate VM names to ensure that they meet the software requirements. If you are creating, reprovisioning, or renaming a VM with an unsuitable name, the operation may fail to execute.
To avoid any problems with VM operations, ensure that your VM names meet the following requirements:
Page 297 of 483
Windows 2008 (pre-R2) Guests May Crash l
A VM name can start only with a word or a number, and the name cannot include the special characters (for example, #, %, or $).
l
A VM name cannot use hyphenated prefixes like Zombie- or migrating-.
l
A VM name cannot be longer than 85 characters.
Windows 2008 (pre-R2) Guests May Crash
To avoid guest crashes, do not install Windows 2008 pre-R2 guests on everRun systems. For more information, see KB1912 .
Alert Status For a Failed Volume May Not Be Displayed Correctly
An alert indicating that a volume has failed on a specific node may have a Normal status indicator (green check mark) on the Alerts page even though the volume remains in a failed condition. In such a case, the
Repair Storage button will still be visible. Click it to move the volume to another logical disk.
everRun May Not Detect Reconnection of Management Network Cable
If you boot a PM while its management network (ibiz0) cable is disconnected and then you reconnect the cable after the PM is running, everRun may not detect that the cable has been reconnected. For more information, see KB4271 .
Information About PCI Devices May Not Be Displayed
Depending on a system's hardware configuration, information about PCI devices (and the storage attached to them) may not be displayed in the everRun Availability Console.
State of External Storage Not Reflected in Node's State
A PM's (node) state is not affected by the state of non-system dependent volumes (any volumes other than root, swap and shared.fs). As a result, external storage can be in a failed state and the node's state will not reflect that. To see the state of external storage, view the state of the VMs and volumes that are on external storage.
Resizing Logical Disks on External Storage Is Not Supported
You cannot extend an external storage LUN and resize the everRun logical disk it contains to use the additional space. If more disk space is needed, you must create a new, larger LUN on your external storage
system and then map it to the everRun system as described in "Adding or Removing External Storage
Page 298 of 483
everRun User's Guide
VMs May Not Boot If One Node is Removed From System
If you remove one PM from the system (by clicking Work On and then clicking Remove), do not place the remaining PM into maintenance and then bring it back into service by just using the Finalize button. Doing so will prevent all VMs from being able to boot. If you must place the remaining PM into maintenance mode, reboot it before you return it to service. See
"Rebooting a Physical Machine" on page 147
for details.
Removing Snapshots Temporarily Prevents Some VM Operations
When you remove a snapshot on an everRun system, the system must coalesce the snapshot by merging it with the next oldest snapshot. While the system is coalescing snapshots: l
A user cannot create a new snapshot in the everRun Availability Console. If you try, an error indicates that the system is busy.
l
A user cannot start the VM associated with the snapshot(s) if the VM is currently stopped. The
Start button is temporarily unavailable on the Virtual Machines page of the everRun Availability
Console.
l
A user cannot perform tasks that require the storage space occupied by the snapshot(s) until the coalescing operation is complete and the snapshot(s) are finally removed from the volume container. For example, this could prevent you from resizing a volume.
Avoid removing snapshots if you have an immediate need to perform any of these operations. After you remove a snapshot, wait at least 10-15 minutes before attempting any of these operations, or retry the operation if needed. You may need to wait much longer depending on the size of your volumes, the amount of
VM activity, and the number of snapshots you remove.
For information about how to monitor coalescing operations that are underway, see KB4272 .
Creation of Snapshots Results in Volume Conversion from RAW to QCOW2 Format
If you create and delete a snapshot of a volume that is currently in RAW format, the everRun software automatically converts the volume from RAW to QCOW2 format. The conversion is expected because snapshots require QCOW2 format, but consider that changing the volume format may have performance implications for certain VM loads. You cannot convert a volume from QCOW2 back to RAW format.
Page 299 of 483
Moving an everRun System to a Different Subnet
New features in everRun Release 7.4 or higher allow you to copy VMs and export VMs that are stopped without requiring a snapshot. If routine snapshots will not be required, consider these alternatives to retain
RAW format (and avoid growing the size of volume containers).
Moving an everRun System to a Different Subnet
If you need to configure the network of an everRun system to work on a different subnet (for example when shipping to another location or when reconfiguring network subnets), see KB4264 for instructions.
Enabling Log Files for the Windows QEMU Guest Agent May Cause VM Timeouts When Taking
Snapshots
When configuring the Windows QEMU guest agent, do not enable the option to save a log file during snapshots. If the QEMU guest agent attempts to create a log file during a snapshot, it may cause VSS timeouts that prevent the snapshot from completing.
Unsupported Network Adapter Card and Chip
Due to the issue outlined at http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=migr-
5093183 , everRun does not support the following network adapter card and chip: l
The Broadcom NetXtreme II Dual Port 10GBase-T Network Adapter, IBM part number 49Y7910 l
Any other NICs that use the Broadcom BCM57712 Ethernet hardware chip
Do Not Use the
ifdown
Command
Do not issue the ifdown command from an everRun physical machine's host OS to temporarily bring down a VM's business (ibiz x ) network connection. Doing so will disconnect the physical interface from its bridge and cause the VM to become unreachable over the network. Instead, use the ifconfig down command.
Documentation Updates
The following documentation changes were made late in the release: l
Updated firmware setup information to indicate that a system with UEFI firmware always boots
Page 300 of 483
everRun User's Guide l
l
Updated instructions for creating bootable USB installation media for the everRun software on Windows-based systems, see
"Creating Bootable USB Media" on page 37
l
Updated everRun installation procedures to describe the behavior if any disk contains previously
"Installing Software on the First PM" on page 45
and "Installing Software on the
l
Updated everRun upgrade procedure to describe disk space requirements and the new Qualify button, see
"Upgrading everRun Software" on page 115
l
New procedure for updating VirtIO drivers in Windows-based VMs, which has also been corrected
to show installation of the viostor driver instead of the vioscsi driver, see "Updating the VirtIO
Drivers (Windows-based VMs)" on page 218
l
Updated storage requirements to discuss the newly supported 4K sector size, see "Storage
l
Updated procedures to indicate that you must manually add matching logical disks to storage groups in a newly installed secondary or replacement node, see: n
"Converting an Avance Unit to an everRun 7.x System" on page 132
n
"Converting an everRun MX System to an everRun 7.x System" on page 122
n
"Replacing Physical Machines, Motherboards, NICs, or RAID Controllers" on page 276
l
New and updated external storage topics to describe procedures for everRun Release 7.4 or higher, see:
Note: In some cases, the contents of these topics have been moved to the Stratus
Knowledge Base. See the associated KBnnnn articles for detailed information.
n
"Adding or Removing External Storage LUNs" on page 281
(Updated, was "Configuring
External Storage") (Moved to KB4299 ) n
"Configuring External Storage in a Newly Installed Release 7.4.x System" on page 282
(New) n
"Configuring Linux Multipathing" on page 283
(Updated)
Page 301 of 483
Getting Help n
"Removing External Storage Disks" on page 287
(New) (Moved to KB4335 ) n
"Updating initrd for Multipath" on page 287
(New) (Moved to KB4295 ) n
"Upgrading a System with External Storage from Release 7.3.4 to 7.4.x" on page 286
(New)
(For the latest technical information, please contact your Stratus service representative and refer to KB-4273.) n
"Recovering a Failed Physical Machine with External Storage " on page 152
(New) (Moved to KB4300 ) n
"Replacing a Failed Physical Machine Connected to External Storage" on page 279
(New)
(Moved to KB4298 ) l
Updated information to explain that if you change the Static System IP address of the everRun sys-
tem, the automatically-generated MAC addresses of the VMs will also change, see "Configuring IP
Settings" on page 73 and "Assigning a Specific MAC Address to a Virtual Machine" on page 265
l
New
--detach-boot-volume and
--attach-boot-volume options for the avcli vm-reprovision command, see
l
Updated system limits to clarify that the maximum memory per FT or HA VM is 213.33 GB (and not
256 GB) due to management overhead, see "Virtual Machine Recommendations and Limits" on page 476
Getting Help
If you have a technical question about everRun software, you can find the latest technical information and online documentation at the Downloads page at http://www.stratus.com/go/support/everrun . You can also search the Knowledge Base in the Stratus Customer Service Portal at https://support.stratus.com.
If you are unable to resolve your questions with these online resources, and the system is covered by a service agreement, please contact everRun Customer Support or your authorized Stratus service representative. For information, see the everRun Support page at http://www.stratus.com/servicessupport/customer-support .
Page 302 of 483
12
Chapter 12: everRun Command Line Interface Reference
You can use the everRun command-line interface to control the system from a remote console. The following topics describe how to administer and use the command-line interface: l
"AVCLI Command Overview" on page 304
l
"AVCLI Command Descriptions" on page 316
AVCLI Command Overview
You can use the everRun command-line interface (AVCLI) to control the system from a remote console.
The following topics explain how to install the AVCLI client: l
l
"Installing the Linux Client" on page 305
l
"Installing the Windows Client" on page 306
The following topics explain how to use the AVCLI command interface: l
l
"Executing a Command" on page 307
l
"Using AVCLI Help" on page 308
The following topics are helpful for programmers using the AVCLI command interface: l
"AVCLI Error Status" on page 309
l
"XML Encapsulated Errors" on page 309
Page 304 of 483
everRun User's Guide l
l
"Asynchronous Command Delay" on page 310
l
"Output Formatting" on page 311
l
"AVCLI Exceptions" on page 315
Related Topics
"AVCLI Command Descriptions" on page 316
Prerequisites
Before you use AVCLI, these prerequisites apply: l
Verify that the client computer has Java Runtime Environment (JRE), version 1.6, update 14 or later, installed by typing: java –version
If the client computer already has this version of JRE installed, the output looks similar to this: java version "1.6.0_16" Java(TM) SE Runtime Environment
(build 1.6.0_16-b01) Java HotSpot(TM) Server VM (build
14.2-b01, mixed mode)
If the output shows that the client computer has an older version of JRE installed, download the correct version from http://www.java.com/en/download/manual.jsp
.
l
You need a valid username and password. The default username/password is admin
/ admin
.
AVCLI scripts embed the username/password, so use access control lists (ACLs) to safeguard your new credentials. AVCLI commands are encrypted using SSL.
Installing the Linux Client
To download the AVCLI client for Linux:
1. Download the Linux client: a. Go to the Downloads page at http://www.stratus.com/go/support/everrun .
b. On the Downloads page, click everRun (if it is not already displayed) and then select the appropriate version.
Page 305 of 483
Installing the Windows Client c. Scroll down to Drivers and Tools and then continue scrolling to everRun Command Line
Interface (AVCLI).
d. Select the RHEL (64-bit) avcli client and save the file.
2. Log on as the root user.
3. Add the directory
/usr/bin
, if it does not exist.
4. Install the client by typing: rpm -i avcli*.rpm
Your Linux system can contain only one copy of AVCLI at one time. If another version is already installed, you receive an error message similar to the following: file /usr/bin/avcli.bat from install of avcli-2.1.1-0 conflicts with file from package avcli-1.0-0 file
/usr/lib/ImportExportLibs.jar from install of avcli-2.1.1-0 conflicts with file from package avcli-1.0-0
If you receive the preceding message, remove the previous version of AVCLI by typing: rpm -e avcli-1.0-0
Then repeat step 4.
Installing the Windows Client
To download the AVCLI client for Windows:
1. Download the Windows client: a. Go to the Downloads page at http://www.stratus.com/go/support/everrun .
b. On the Downloads page, click everRun (if it is not already displayed) and then select the appropriate version.
c. Scroll down to Drivers and Tools and then continue scrolling to everRun Command Line
Interface (AVCLI).
d. Click Windows avcli client. Save the file.
2. Double-click avcli.msi
. Follow the onscreen instructions.
3. Click Run. When prompted, accept the EULA.
Page 306 of 483
everRun User's Guide
4. If prompted to remove a previous version of AVCLI, click
Start
>
All Programs
> everRun > Uninstall AVCLI . Then repeat steps 1- 3.
Using AVCLI
To use AVCLI: l
On Windows, click
Start Menu
>
All Programs
> everRun
>
Command Prompt
.
l
On Linux, type the avcli command, followed by one or more commands. For example:
# avcli -H localhost -u admin -p admin vm-info
Note: In the preceding example, typing the -H, -u, and -p options automatically saves the hostname, username, and password, respectively, so that subsequent commands do not require them. You can also create a shortcut to avoid the need to prefix all commands with the hostname, username, and password, as described in
"Executing a Command" on page 307
.
From the command line, use the help command to list all AVCLI commands or to display information for a specific command. See
"Using AVCLI Help" on page 308
.
Executing a Command
Commands must include the DNS name or IPv4 address of the everRun system. If you specify incorrect syntax, a message displays the correct syntax.
Create a shortcut to avoid the need to prefix all commands with the hostname, username, and password.
To create a shortcut:
Windows
The avcli command executes the batch file avcli.bat
in
%Program
Files%\everRun
. You can add login credentials to this file:
1. Open avcli.bat
with a text editor.
2. Search for this string:
-jar "%AVCLI_HOME%\avcli.jar"
3. Append login info. For example:
-jar "%AVCLI_HOME%\avcli.jar" –u admin –p admin –H everrun
Page 307 of 483
Using AVCLI Help
If you manage several everRun systems with the same username and password, specify the domain names of the individual systems in the command line:
$ avcli –H everrun1 node-info node0 or
$ avcli –H everrun2 node-info node0
Linux
Create an alias in your login .cshrc
file. For example: alias avcli='/usr/bin/avcli -u admin -p admin –H everrun'
In the example, avcli is the alias name, admin/admin is the username/password, and everRun is the everRun system’s domain name. You can then use this alias to log on and specify commands. For example, you could specify unit-info as follows:
$ avcli unit-info
Using AVCLI Help
This topic describes how to use AVCLI help.
Listing All Commands
To list all available AVCLI commands, type:
$ avcli help
The output follows:
[root@node0 zoneinfo]# avcli help
Usage: avcli [OPTION]... [COMMAND]
-u, --username username to login with
-p, --password password to login with
-H, --hostname hostname to login to
--log log file to capture debug information in
-x, --xml format output in XML
-V, --version display the version and exit
Page 308 of 483
everRun User's Guide
-h, --help display this message and exit
.
.
.
If you type a command that AVCLI does not recognize, AVCLI displays the preceding output.
Displaying Help for a Specific Command
To display help for a specific command, type:
$ avcli help command_name
For example, if you type:
$ avcli help vm-create
The output is:
Usage: avcli vm-create[--interfaces] [--shared-storage]
.
.
Create a new VM.
.
If you type a valid command with an invalid argument, AVCLI displays the same output as if you had specified help for the command.
AVCLI Error Status
AVCLI does not follow the Linux convention of returning 0 on successful execution and 1 for an error.
XML Encapsulated Errors
To display all errors as encapsulated XML suitable for processing with an XML parser, specify
-x on the command line.
The following example displays errors associated with a bad username/password:
$ avcli -x -H eagles -u admin -p foo node-info
The following example displays errors associated with a bad host address for the everRun system:
Page 309 of 483
Error Checking
$ avcli -x -H foo -u admin -p foo node-info foo
The following example attempts an operation using a nonexistent VM:
$ avcli -H eagles -x vm-delete eagles23
Cannot find a resource that matches the identifier eagles23.
Error Checking
To cleanly catch all errors while developing scripts, always specify output in XML format. This returns an error with any reply that does not return valid XML or any XML document with an error attribute.
The following example is from a PERL subroutine _cli that provides a shell for executing AVCLI commands. The code that checks for errors does a simple pattern match on
$stdout
.
my $error = 0
$error = 1 unless ($stdout =~ /xml version/);
$error = 1 if ($stdout =~ /\/);
If no error occurs,
$stdout is cast into a PERL hash using the standard PERL
XML::Simple
Library
. Otherwise, this error appears: unless ($error) { my $xs = XML::Simple->new();
$stdout_hash = $xs->XMLin($stdout,forceArray=>0); return 0;
} return 1;
Asynchronous Command Delay
Commands that invoke an action on the everRun system are called asynchronous because the command completes before the action completes. This allows for complex scripting.
If you want a command to complete inline before proceeding to the next command, create a simple script and use the
—wait option. For example:
Page 310 of 483
everRun User's Guide
$ cli -x -H eagles node-workon --wait node0
In this example, cli does not complete until VMs and the management port are failed over from node0 to node1, and node0 is in maintenance mode. Without the
—wait option, the command completes when acknowledged but before the resources are migrated.
Output Formatting
AVCLI can create user-friendly command output and program-friendly XML output.
User-Friendly Command Output
AVCLI output is formatted for easy readability. For example:
$ avance -u admin -p admin -H avance –x node-info node:
-> name : node0
-> id : host:o14
-> state: running
-> sub-state : nil
-> standing-state : maintenance
-> mode : maintenance
-> primary : false
-> manufacturer : Dell
-> model : Dell PowerEdge 2950
-> maintenance-allowed : true
-> maintenance-guest-shutdown : false
-> cpus : 8
-> memory : 4,288,675,840 virtual machines: node:
-> name : node1
Page 311 of 483
Program-Friendly XML Output
-> id : host:o406
-> state : running
-> sub-state : nil
-> standing-state : warning
-> mode : normal
-> primary : true
-> manufacturer : Dell
-> model : Dell PowerEdge 2950
-> maintenance-allowed : true
-> maintenance-guest-shutdown : true
-> cpus : 8
-> memory : 4,288,675,840 virtual machines: virtual machine:
-> name : eagles1
-> id : vm:o1836
Note: The output format of these commands may vary between releases.
Program-Friendly XML Output
You can create program-friendly XML output by using the
-x or
--xml global option. For example:
$ avcli -u admin -p admin -H localhost -x node-info
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<avance>
<node>
<name>node1</name>
<id>host:o55</id>
Page 312 of 483
everRun User's Guide
<state>running</state>
<sub-state/>
<standing-state>normal</standing-state>
<mode>normal</mode>
<primary>false</primary>
<manufacturer>Intel Corporation</manufacturer>
<model>S5520UR</model>
<maintenance-allowed>true</maintenance-allowed>
<maintenance-guest-shutdown>false</maintenance-guest-shutdown>
<cpus>2</cpus>
<memory>25706889216</memory>
<virtual-machines/>
</node>
<node>
<name>node0</name>
<id>host:o23</id>
<state>running</state>
<sub-state/>
<standing-state>normal</standing-state>
<mode>normal</mode>
<primary>true</primary>
<manufacturer>Intel Corporation</manufacturer>
<model>S5520UR</model>
<maintenance-allowed>true</maintenance-allowed>
<maintenance-guest-shutdown>false</maintenance-guest-shutdown>
Page 313 of 483
Program-Friendly XML Output
<cpus>2</cpus>
<memory>25706889216</memory>
<virtual-machines>
<virtual-machine>
<name>MyVM</name>
<id>vm:o6417</id>
</virtual-machine>
</virtual-machines>
</node>
</avance>
Note: The schema definition is maintained between releases.
If you do not specify –X or --XML and the command returns an error, a verbose message appears. For example:
$ cli -H eagles vm-delete eagles23
%Error: Cannot find a resource that matches the identifier eagles23. com.avance.yak.cli.exceptions.CommandLineException:
Cannot find a resource that matches the identifier eagles23.
at com.avance.yak.cli.ResourceDisambiguateServiceProvider.throwNo
nExistentResource(ResourceDisambiguateServiceProvider.java:56) at com.avance.yak.cli.ResourceDisambiguateServiceProvider.getReso
urceId(ResourceDisambiguateServiceProvider.java:81) at com.avance.yak.cli.Command.findResourceId(Command.java:80)
Page 314 of 483
everRun User's Guide at com.avance.yak.cli.CommandWithUnparsedAmbiguousResourcesInvoke
Each.execute
(CommandWithUnparsedAmbiguousResourcesInvokeEach.java:65) at com.avance.yak.cli.Command.execute(Command.java:194) at com.avance.yak.cli.CommandLine.execute(CommandLine.java:649) at
AVCLI Exceptions
If you do not specify –X or --XML and the command returns an error, a verbose message appears. For example:
$ cli -H eagles vm-delete eagles23
%Error: Cannot find a resource that matches the identifier eagles23. com.avance.yak.cli.exceptions.CommandLineException:
Cannot find a resource that matches the identifier eagles23.
at com.avance.yak.cli.ResourceDisambiguateServiceProvider.throwNo
nExistentResource(ResourceDisambiguateServiceProvider.java:56) at com.avance.yak.cli.ResourceDisambiguateServiceProvider.getReso
urceId(ResourceDisambiguateServiceProvider.java:81) at com.avance.yak.cli.Command.findResourceId(Command.java:80) at
Page 315 of 483
AVCLI Command Descriptions com.avance.yak.cli.CommandWithUnparsedAmbiguousResourcesInvoke
Each.execute
(CommandWithUnparsedAmbiguousResourcesInvokeEach.java:65) at com.avance.yak.cli.Command.execute(Command.java:194) at com.avance.yak.cli.CommandLine.execute(CommandLine.java:649) at com.avance.yak.cli.Program.main(Program.java:94)
AVCLI Command Descriptions
Click each heading to see the full list of AVCLI commands in that group.
Note: The Examples section for each command assumes that you have set up a command shortcut as described in
"Executing a Command" on page 307 .
Help
Basic System Information
"unit-eula-accept" on page 418
"unit-shutdown-cancel" on page 422
"unit-shutdown-state" on page 423
Page 316 of 483
everRun User's Guide
System Configuration
"callhome-disable" on page 331
System User Management
Page 317 of 483
"local-group-delete" on page 361
"local-group-edit" on page 362
"local-group-info" on page 363
"local-user-delete" on page 366
Managing Physical Machines
Page 318 of 483
AVCLI Command Descriptions
everRun User's Guide
Managing Alerts
Diagnostic Files
"diagnostic-create" on page 337
"diagnostic-delete" on page 338
"diagnostic-extract" on page 339
"diagnostic-fetch" on page 340
Network/Storage Information
"disk-move-to-group" on page 345
"image-container-info" on page 352
"image-container-resize" on page 355
"network-change-mtu" on page 378
"network-change-role" on page 379
"storage-group-info" on page 410
Creating Virtual CD/DVDs
Page 319 of 483
Managing Virtual Machines
"localvm-clear-mtbf" on page 370
"vm-boot-attributes" on page 427
"vm-create-from-snapshot" on page 438
"vm-network-disable" on page 446
"vm-network-enable" on page 447
"vm-snapshot-create" on page 458
"vm-snapshot-create-disable" on page 460
Page 320 of 483
AVCLI Command Descriptions
everRun User's Guide
"vm-snapshot-create-enable" on page 461
"vm-snapshot-delete" on page 462
"vm-snapshot-export" on page 463
"vm-snapshot-info" on page 465
"vm-volume-disable" on page 467
"vm-volume-enable" on page 468
Related Topics
"AVCLI Command Overview" on page 304
Page 321 of 483
ad-disable
Usage avcli ad-disable
Description
The ad-disable command disables Active Directory support.
ad-disable
Page 322 of 483
everRun User's Guide ad-enable
Usage avcli ad-enable
Description
The ad-enable command enables Active Directory support.
Page 323 of 483
ad-info
Usage avcli ad-info
Description
The ad-info command displays information about the Active Directory.
ad-info
Page 324 of 483
everRun User's Guide ad-join
Usage avcli ad-join --username name [--password password] domain
Description
The ad-join command joins the everRun system to the specified Active Directory domain and enables Active Directory support.
Options
--username name The user with rights to join to the specified domain.
--password domain password
The password of the user with rights to join to the specified domain. If you do not give the password, you are automatically prompted for it.
The name of the Active Directory domain to join.
Examples
$ avcli ad-join --username domain\administrator --password secret domain
$ avcli ad-join --username domain\administrator domain
Page 325 of 483
ad-remove ad-remove
Usage avcli ad-remove --username name [--password password] domain
Description
The ad-remove command removes the everRun system from the specified Active Directory domain and disables Active Directory support.
Options
--username name
The user with rights to remove the everRun system from the specified domain.
--password domain password
The password of the user with rights to remove the ever-
Run system from the specified domain. If you do not give the password, you are automatically prompted for it.
The name of the Active Directory domain from which the everRun system is to be removed.
Examples
$ avcli ad-remove --username domain\administrator --password secret domain
$ avcli ad-remove --username domain\administrator domain
Page 326 of 483
everRun User's Guide alert-delete
Usage avcli alert-delete [alerts... | purge]
Description
The alert-delete command deletes specific alerts or optionally, all alerts.
Options alerts
One or more alerts to be deleted.
purge
Delete all alerts.
Examples
$ avcli alert-delete alert:o10
$ avcli alert-delete alert:o10 alert:o11
$ avcli alert-delete purge
Page 327 of 483
alert-info
Usage avcli alert-info [alerts...]
Description
The alert-info command displays information about all alerts or only those specified.
Options alerts
The alert information to be displayed.
alert-info
Page 328 of 483
everRun User's Guide audit-export
Usage avcli audit-export
Description
The audit-export command exports all of the audit logs.
Page 329 of 483
audit-info audit-info
Usage avcli audit-info [number-of-audit-logs]
Description
The audit-info command displays either the last 50 audit logs or the specified number of audit logs.
Options number-of-audit-logs The number of audit logs to display. The default value is 50.
Examples
$ avcli audit-info
$ avcli audit-info 25
Page 330 of 483
everRun User's Guide callhome-disable
Usage avcli callhome-disable
Description
The callhome-disable command disables call home.
Page 331 of 483
callhome-enable
Usage avcli callhome-enable
Description
The callhome-enable command enables call home.
callhome-enable
Page 332 of 483
everRun User's Guide callhome-info
Usage avcli callhome-info
Description
The callhome-info command displays information about call home.
Page 333 of 483
datetime-config datetime-config
Usage avcli datetime-config date time [timezone]
Description
The datetime-config command sets the date, time, and time zone on everRun systems.
Options date
The date, formatted as
YYYY
-
MM
-
DD
.
time timezone
The time, formatted as HH : MM : SS, in a 24-hour format.
The time zone. By default, it is the currently configured time zone.
You can specify the following values for timezone .
Africa/Cairo Africa/Casablanca Africa/Harare
Africa/Nairobi Africa/Lagos
Africa/Windhoek
Africa/Monrovia
America/Adak America/Anchorage
America/Buenos_Aires America/Asuncion
America/Caracas
America/Bogota
America/Chicago America/Chihuahua
America/Godthab America/Cuiaba America/Denver
America/Goose_Bay America/Grand_Turk America/Guyana
America/Halifax America/Havana
America/Los_Angeles America/Managua
America/Mexico_City America/Miquelon
America/Indianapolis
America/Manaus
America/Montevideo
Page 334 of 483
everRun User's Guide
America/New_York
America/Regina
America/St_Johns
Asia/Amman
Asia/Bangkok
Asia/Bishkek
Asia/Damascus
Asia/Hong_Kong
America/Noronha
America/Santiago
America/Tijuana
Asia/Baghdad
Asia/Beijing
Asia/Calcutta
Asia/Dhaka
Asia/Irkutsk
Asia/Kabul
Asia/Katmandu
Asia/Novosibirsk
Asia/Seoul
Asia/Kamchatka
Asia/Krasnoyarsk
Asia/Rangoon
Asia/Singapore
Asia/Tashkent
Asia/Tokyo
Asia/Tbilisi
Asia/Vladivostok
Asia/Yekaterinburg Asia/Yerevan
Atlantic/Cape_Verde Atlantic/Stanley
America/Phoenix
America/Sao_Paulo
America/Winnipeg
Asia/Baku
Asia/Beirut
Asia/Colombo
Asia/Gaza
Asia/Jerusalem
Asia/Karachi
Asia/Magadan
Asia/Riyadh
Asia/Taipei
Asia/Tehran
Asia/Yakutsk
Atlantic/Azores
Australia/Adelaide
Australia/Brisbane Australia/Darwin Australia/Hobart
Australia/Lord_Howe Australia/Melbourne Australia/Perth
Australia/Sydney
Etc/GMT+10
Etc/GMT
Etc/GMT+11
Etc/GMT+1
Etc/GMT+12
Page 335 of 483
datetime-config
Etc/GMT+2
Etc/GMT+5
Etc/GMT+8
Etc/GMT-10
Etc/GMT-13
Etc/GMT-3
Etc/GMT-6
Etc/GMT-9
Europe/Berlin
Europe/Kaliningrad
Europe/Moscow
Europe/Sarajevo
Pacific/Chatham
Pacific/Guam
Pacific/Tongatapu
Etc/GMT+3
Etc/GMT+6
Etc/GMT+9
Etc/GMT-11
Etc/GMT-14
Etc/GMT-4
Etc/GMT-7
Europe/Athens
Europe/Helsinki
Europe/London
Europe/Paris
Japan
Pacific/Easter
Pacific/Marquesas
Etc/GMT+4
Etc/GMT+7
Etc/GMT-1
Etc/GMT-12
Etc/GMT-2
Etc/GMT-5
Etc/GMT-8
Europe/Belgrade
Europe/Istanbul
Europe/Minsk
Europe/Samara
Pacific/Auckland
Pacific/Fiji
Pacific/Norfolk
Examples
$ avcli datetime-config 2010-12-31 6:03:10
$ avcli datetime-config 2010-12-31 20:09:22 America/New_York
Page 336 of 483
everRun User's Guide diagnostic-create
Usage avcli diagnostic-create [minimal | medium | stats | full]
Description
The diagnostic-create command creates a new diagnostic of the specified type.
Options minimal The smallest diagnostic (approximately 2 to 10 MB).
medium
A medium diagnostic (approximately 10 MB).
full A large diagnostic (approximately 60 MB).
Page 337 of 483
diagnostic-delete
Usage avcli diagnostic-delete diagnostics...
Description
The diagnostic-delete command deletes the specified diagnostic files.
Options diagnostics
One or more diagnostic files to be deleted.
diagnostic-delete
Page 338 of 483
everRun User's Guide diagnostic-extract
Usage avcli diagnostic-extract diagnostics.zip...
Description
The diagnostic-extract command extracts the specified diagnostic files.
Options diagnostics
One or more diagnostic files to be extracted.
Page 339 of 483
diagnostic-fetch diagnostic-fetch
Usage avcli diagnostic-fetch [--file name] diagnostics...
Description
The diagnostic-fetch command downloads the specified diagnostics to the current directory. If the diagnostic's status is busy, diagnostic-fetch waits for the diagnostic to complete and then downloads it. The default diagnostic file name is diagnostictype
name
_
YYYYMMDD
_
HHMMSS
.zip
: l type : The type of diagnostic: minimal, medium, stats, full.
l name : The name of the everRun system, as displayed by unit-info
.
l
YYYY : The year the diagnostic was created.
l
MM:
The month the diagnostic was created.
l
DD
: The day of the month the diagnostic was created.
l
HH : The hour the diagnostic was created.
l
MM : The minute the diagnostic was created.
l
SS : The second the diagnostic was created.
Options diagnostics One or more diagnostic files to be downloaded.
--file name
The name of the file written to the current directory. This option is valid if only one diagnostic is downloaded.
--extract Extract the downloaded diagnostic files.
Examples
$ avcli diagnostic-fetch buggrab:o10
$ avcli diagnostic-fetch --file buggrab.zip buggrab:o10
$ avcli diagnostic-fetch buggrab:o10 buggrab:o11 buggrab:o12
Page 340 of 483
everRun User's Guide diagnostic-info
Usage avcli diagnostic-info diagnostics...
Description
The diagnostic-info command displays information about all diagnostics or only about those specified.
Options diagnostics One or more diagnostic files about which to display information.
Page 341 of 483
dialin-disable
Usage avcli dialin-disable
Description
The dialin-disable command disables dial-in.
dialin-disable
Page 342 of 483
everRun User's Guide dialin-enable
Usage avcli dialin-enable
Description
The dialin-enable command enables dial-in.
Page 343 of 483
dialin-info
Usage avcli dialin-info
Description
The dialin-info command displays information about dial-in configuration.
dialin-info
Page 344 of 483
everRun User's Guide disk-move-to-group
Usage avcli disk-move-to-group disk... storage-group
Description
The disk-move-to-group command moves one or more logical disks to a storage group.
Options disk
One or more disks to be moved.
storage-group A storage group.
Page 345 of 483
ealert-config ealert-config
Usage avcli ealert-config [--ssl] [--tls] [--port port] [--sender
sender] [--username username] [--password password] --host
host recipients...
Description
The ealert-config command configures e-Alert support in everRun systems. If you do not provide a user name, the command assumes that authentication is not required to access the
SMTP server. If you provide a user name but not a password, the command prompts you for the password.
Options
--ssl
Use SSL when communicating with the SMTP server.
You can specify this option only if --tls is not specified.
--tls
Use TLS when communicating with the SMTP server(s).
You can specify this option only if
--ssl is not specified.
--port port
Use this port number to connect to the SMTP server.
--sender sender
--username
--password
--host recipients host username password
Send email from this sender (name or IP address).
Use this name for authentication on the specified SMTP host.
Use this password for authentication on the specified
SMTP host.
The DNS or IP address of the SMTP server.
The list of email addresses to receive eAlert emails; required only when e-Alerts are enabled.
Page 346 of 483
everRun User's Guide
Examples
The following command configures email alerts to use the SMTP server mail.my-domain.com
and to send alerts to the recipient [email protected]
:
$ avcli ealert-config --host mail.my-domain.com [email protected]
The following command configures email alerts to use the SMTP server mail.my-domain.com
and to send alerts the recipients [email protected]
:
$ avcli ealert-config --host mail.my-domain.com [email protected] [email protected]
The following command configures email alerts to use the protocol SSL and the SMTP server mail.mydomain.com
, and to send alerts to the recipient [email protected]
, using the username admin and the password secret for authentication:
$ avcli ealert-config --ssl --username admin --password secret
--host mail.my-domain.com [email protected]
The following command configures email alerts to use the protocol SSL and the SMTP server mail.mydomain.com
, and to send alerts to the recipient [email protected]
, using the username admin and no password for authentication:
$ avcli ealert-config --ssl --username admin --host mail.mydomain.com [email protected]
The following command configures email alerts to send alerts from the sender [email protected]
, using the protocol TLS on port 587 and the SMTP server mail.my-domain.com
, and to send alerts to the recipient [email protected]
, using the username admin and no password for authentication:
$ avcli ealert-config --tls --port 587 --sender [email protected] --username admin --password secret --host mail.my-domain.com [email protected]
Page 347 of 483
ealert-disable
Usage avcli ealert-disable
Description
The ealert-disable command disables e-Alert.
ealert-disable
Page 348 of 483
everRun User's Guide ealert-enable
Usage avcli ealert-enable
Description
The ealert-enable command enables e-Alert.
Page 349 of 483
ealert-info
Usage avcli ealert-info
Description
The ealert-info command displays information about the e-Alert configuration.
ealert-info
Page 350 of 483
everRun User's Guide help
Usage avcli help [command] [-all]
Description
The help command provides help about a specific command or lists all AVCLI commands.
Options
-all Display detailed information for all commands.
Examples
To display general command usage and a list of all commands for which help provides information:
$ avcli help
To display information about a specific command ( storage-info
, in this example):
$ avcli help storage-info
To display detailed information about all commands for which help provides information:
$ avcli help -all
Page 351 of 483
image-container-info image-container-info
Usage image-container-info [image-container]
Description
The image-container-info command displays information about all image containers
(also known as volume containers ) or optionally, about only the specified image containers. Specifically, the command displays information about the portion of the image container that is available to the guest operating system.
Options image-container
The name of the image container. If you do not provide this argument, the command displays information about all image containers.
Examples
$ avcli image-container-info image-container:
-> name : root
-> id : imagecontainer:o58
-> hasFileSystem : false
-> isLocal : true
-> size : 21,479,030,784
-> size-used : 21,479,030,784
-> storage-group : none image-container:
-> name : root
-> id : imagecontainer:o31
-> hasFileSystem : false
Page 352 of 483
everRun User's Guide
-> isLocal : true
-> size : 21,479,030,784
-> size-used : 21,479,030,784
-> storage-group : none image-container:
-> name : swap
-> id : imagecontainer:o36
-> hasFileSystem : false
-> isLocal : true
-> size : 2,151,677,952
-> size-used : 2,151,677,952
-> storage-group : none image-container:
-> name : swap
-> id : imagecontainer:o66
-> hasFileSystem : false
-> isLocal : true
-> size : 2,151,677,952
-> size-used : 2,151,677,952
-> storage-group : none image-container:
-> name : shared.fs_image_container
-> id : imagecontainer:o77
-> hasFileSystem : false
-> isLocal : false
Page 353 of 483
-> size : 1,073,741,824
-> size-used : 1,073,741,824
-> storage-group : none image-container:
-> name : win7_ent_x86_32_sp1
-> id : imagecontainer:o1360
-> hasFileSystem : false
-> isLocal : false
-> size : 2,684,354,560
-> size-used : 2,684,354,560 storage-group:
-> name : Initial Storage Group
-> id : storagegroup:o21 image-container:
-> name : boot-chom1
-> id : imagecontainer:o1690
-> hasFileSystem : true
-> isLocal : false
-> size : 42,949,672,960
-> size-used : 37,787,627,192 storage-group:
-> name : Initial Storage Group
-> id : storagegroup:o21
Page 354 of 483 image-container-info
everRun User's Guide image-container-resize
Usage image-container-resize --new-size size image-container
Description
The image-container-resize command increases the size of the image container; specifically, the portion that is available to the guest operating system. (An image container , also known as a volume container , is a system-wide container that holds volumes and snapshots.) You might want to increase the image container's size if you need to take snapshots and the container lacks sufficient free space to do so.
Options
--new-size size
The new image-container size. By default, size is in megabytes, but you can specify standard qualifiers (for example,
KB, K, MB, M, GB, or G).
image-container
The name of the image container.
Examples
$ avcli image-container-resize --new-size 40G boot-chom1
Page 355 of 483
kit-delete
Usage avcli kit-delete kit...
Description
The kit-delete command deletes the specified kits.
Options kit
One or more upgrade kits to be deleted.
kit-delete
Page 356 of 483
everRun User's Guide kit-info
Usage avcli kit-info [kit...]
Description
The kit-info command displays information about all kits (the default) or only the specified kits.
Options kit One or more upgrade kits about which to display information.
Page 357 of 483
license-info
Usage avcli license-info
Description
The license-info command displays information about the license.
license-info
Page 358 of 483
everRun User's Guide license-install
Usage avcli license-install license-file
Description
The license-install command installs the specified license file.
Options license-file
The file containing the license-key definitions.
Examples
$ avcli license-install avance.key
Page 359 of 483
local-group-add local-group-add
Usage avcli local-group-add --name name --permissions permission-
type
Description
The local-group-add command adds a new local user group. Only users with the role Administrator (the group admin
) can execute this command. Users with the role Platform Admin (the group platform_admin
) or Read Only (the group read-only
) cannot execute this command.
Options
--name name
Local group name.
--permissions permission-type
Local group permissions, in the form of a comma-separated list.
Examples
$ avcli local-group-add --name unprivileged_users -permissions ADD_USER
Page 360 of 483
everRun User's Guide local-group-delete
Usage avcli local-group-delete groups...
Description
The local-group-delete command deletes the specified local user groups. You cannot delete default groups ( admin
, platform_admin
, read_only
). Only users with the role
Administrator (the group admin
) can execute this command. Users with the role Platform Admin
(the group platform_admin
) or Read Only (the group read-only
) cannot execute this command.
Options groups
Local user groups.
Examples
$ avcli local-group-delete unprivileged_users
Page 361 of 483
local-group-edit local-group-edit
Usage avcli local-group-edit [--name] [--permissions] group-name-or-
sid
Description
The local-group-edit command edits an existing local user group. You cannot edit default groups ( admin
, platform_admin
, read_only
). Only users with the role Administrator
(the group admin
) can execute this command. Users with the role Platform Admin (the group platform_admin ) or Read Only (the group read-only ) cannot execute this command.
Options
--name name
New local group name.
--permissions group-name-or-sid permission-type
Local group permissions, in the form of a comma-separated list.
The name or security ID.
Examples
$ avcli local-group-edit --name privileged_users --permissions
ADD_USER unprivileged_users
Page 362 of 483
everRun User's Guide local-group-info
Usage avcli local-group-info [groups...]
Description
The local-group-info command displays information about all local user groups, or only those specified.
Options groups Local user groups.
Page 363 of 483
local-user-add local-user-add
Usage avcli local-user-add --username name --realname name --email
address [--password password] [--new-password password] [--
local-groups groups] [--permissions permission-types]
Description
The local-user-add command adds a new local user to the everRun system. If the user's password is not given, the user is automatically prompted for it. The user is prompted twice to verify that the password was entered correctly. Only users with the role Administrator (the group admin ) can execute this command. Users with the role Platform Admin (the group platform_ admin
) or Read Only (the group read-only
) cannot execute this command.
Options
--username name everRun local user name.
--password password
--new-password password
Boolean flag that indicates whether the user should be prompted for a new password.
Specify the password as a command-line option instead of being prompted in the same way as --password .
The user's real name.
--realname name
--email address
--local-groups
--permissions groups permission-types
The user's email address.
Local groups for the user to join, in the form of a comma-separated list.
Local user permissions, in the form of a comma-separated list.
Examples
Page 364 of 483
everRun User's Guide
$ avcli local-user-add --username bsmith --realname "Bob
Smith" --email [email protected] --password secret --localgroups admin
$ avcli local-user-add --username bsmith --realname "Bob
Smith" --email [email protected] --local-groups users1,users2
--permissions ADD_USER,UPDATE_USER
Page 365 of 483
local-user-delete local-user-delete
Usage avcli local-user-delete users...
Description
The local-user-delete command deletes the specified local users. Only users with the role Administrator (the group admin
) can execute this command. Users with the role Platform
Admin (the group platform_admin
) or Read Only (the group read-only
) cannot execute this command.
Options users One or more local users.
Examples
$ avcli local-user-delete afjord
$ avcli local-user-delete afjord bsmith tkirch
Page 366 of 483
everRun User's Guide local-user-edit
Usage avcli local-user-edit user [--username name] [--realname
name] [--email address]
[--password password] [--new-password
password] [--local-groups groups] [--permissions permission-
types] user-name-or-sid
Description
The local-user-edit command edits an existing user. If you do not give the
--password option, the password is not changed. If you give the --password option, the command prompts the user twice to verify that the password was entered correctly. Only users with the role Administrator (the group admin
) can execute this command. Users with the role Platform Admin (the group platform_admin
) or Read Only (the group read-only
) cannot execute this command.
Options
--username name
The user name to assign.
--password password
--new-password password
Boolean flag that indicates whether the user should be prompted for a new password.
Specify the password as a command-line option instead of being prompted in the same way as
--password
.
--realname name
--email address
--local-groups
--permissions groups permission-types
The user's real name.
The user's email address.
Local groups for the user to join, in the form of a comma-separated list.
Local user permissions, in the form of a comma-separated list.
Page 367 of 483
local-user-edit group-name-or-sid
The name or security ID.
Examples
$ avcli local-user-edit --email [email protected] bsmith
$ avcli local-user-edit --realname "Robert Smith" --email [email protected] bsmith
$ avcli local-user-edit --email [email protected] --localgroups read_only --permissions ADD_USER,UPDATE_USER bsmith
$ avcli local-user-edit --password bsmith
$ avcli local-user-edit --new-password secret bsmith
Page 368 of 483
everRun User's Guide local-user-info
Usage avcli local-user-info [user...]
Description
The local-user-info command displays information about all users (by default) or only about the specified users.
Options user One or more users about which to display information.
Page 369 of 483
localvm-clear-mtbf localvm-clear-mtbf
Usage avcli localvm-clear-mtbf
Description
The localvm-clear-mtbf command brings half of a VM back into service after it has been removed from service for failing too many times.
Page 370 of 483
everRun User's Guide media-create
Usage avcli media-create [--storage-group storage] [--name name]
url...
Description
The media-create command loads an ISO image into an everRun system from the specified
URL.
Options
--storage-group group
The storage volume to carve from. If you do not specify this option, the storage group with the most free space is automatically selected.
--name url
--wait name
The name of the carved volume. If you do not specify this option, the name is determined from the URL.
The URL where the ISO file is located.
Wait for the ISO(s) to be created.
Examples avcli media-create --storage-group Pool-0001 --name cd.iso
http://hostname/cd.iso
avcli media-create http://hostname/cd.iso
avcli media-create http://hostname/cd1.iso
http://hostname/cd2.iso
Page 371 of 483
media-delete
Usage avcli media-delete media...
Description
The media-delete command deletes the specified media.
Options media
The media to be deleted.
media-delete
Page 372 of 483
everRun User's Guide media-eject
Usage avcli media-eject [--cdrom name] [vm...]
Description
The media-eject command ejects media from the specified virtual machines.
Options
--cdrom name
The CD-ROM device to eject. This value is optional if the VM has only a single CD-ROM device.
vm The name of the VM containing the media to be ejected.
Page 373 of 483
media-import media-import
Usage avcli media-import [--storage-group storage] [--name name] [-throttle] [--silent] file...
Description
The media-import command loads an ISO image into an everRun system from the specified file.
Options
--storage-group group
The storage volume to carve from. If you do not specify this option, the shared storage with the most free space is automatically selected.
--name name
--throttle
The name of the carved volume. If you do not specify this option, the name is determined from the file. This option is valid only if one ISO is specified.
Slow down the import/export operation. Valid values are: l none
: Do not use throttling. This is the default value.
l low
: Slow down by about 25%.
l medium
: Slow down by about 50%.
l high
: Slow down by about 75%.
--silent file
Suppress output.
The file(s) containing an ISO image.
Examples avcli media-import --storage-group Pool-0001 --name cd.iso
cd.iso
avcli media-import cd.iso
Page 374 of 483
everRun User's Guide avcli media-import cd1.iso cd2.iso
Page 375 of 483
media-info media-info
Usage avcli media-info [media...]
Description
The media-info command displays information about all media, or optionally, only the specified media.
Options media The media about which to display information.
Page 376 of 483
everRun User's Guide media-insert
Usage avcli media-insert --iso [--cdrom] [vm...]
Description
The media-insert command allows you to insert media into the specified virtual machines.
Caution: When you insert a VCD into a running, fault-tolerant (FT) VM, it prevents the everRun software from migrating the VM to a different physical machine in the event of a failure. To restore fault-tolerant operation, unmount and eject the VCD as soon as you finish using it.
Options
--iso name
--cdrom vm name
The ISO image to insert.
The CD-ROM device to insert. This value is optional if the VM has only a single CD-ROM device.
The name of the VM into which the media is to be inserted.
Page 377 of 483
network-change-mtu network-change-mtu
Usage avcli network-change-mtu name size
Description
The network-change-mtu command changes the MTU size of the specified network (an A-
Link or business network, including the biz0 network) on everRun systems.
Options name The name of the network size The MTU size. Valid values are 1500 - 9000.
To change the MTU of business link, perform the following steps:
1. Shut down the VM and issue network-change-mtu .
2. Boot the guest and change the guest MTU after rebooting. If you do not change the guest
MTU, the guest continues to use the previously set MTU.
To change the MTU of an A-Link, perform the following steps:
1. Issue network-change-mtu
.
2. Cycle a node through maintenance mode, which enables the node to acquire the new MTU
(the AX TCP sessions disconnect and reestablish after both nodes are back online).
Examples
3. Repeat the step above on the second node.
The following commands change the MTU size on the A-Link priv0 .
$ avcli network-change-mtu priv0 4000
$ avcli network-change-mtu priv0 9000
The following commands change the MTU size on the business network network0
, sometimes known as biz0.
$ avcli network-change-mtu network0 4000
$ avcli network-change-mtu network0 9000
Page 378 of 483
everRun User's Guide network-change-role
Usage avcli network-change-role networks... role
Description
The network-change-role command changes the role of the specified network to the specified role.
Options networks One or more networks whose role is to be changed.
role The new role. Specify either business or a-link
.
Page 379 of 483
network-info network-info
Usage avcli network-info [networks...]
Description
The network-info command displays information about all shared networks, or optionally, about only the specified networks.
Options networks
One or more networks.
Output
The following example shows the settings for four networks, including the default MTU value of 1500 for A-
Links.
avcli network-info shared network:
-> name
-> id
: sync_2003
: sharednetwork:o2334
-> fault-tolerant : ft
-> role : a-link
-> bandwidth : 10 Gb/s
: 1500 -> mtu shared network:
-> name
-> id
: network0
: sharednetwork:o64
-> fault-tolerant : ft
-> role
-> bandwidth
-> mtu
: business
: 1 Gb/s
: 1500
Page 380 of 483
everRun User's Guide shared network:
-> name : sync_2004
-> id : sharednetwork:o2333
-> fault-tolerant : ft
-> role : a-link
-> bandwidth
-> mtu shared network:
: 10 Gb/s
: 1500
-> name
-> id
: priv0
: sharednetwork:o65
-> fault-tolerant : ft
-> role : private
-> bandwidth
-> mtu
: 1 Gb/s
: 1500
Page 381 of 483
node-add
Usage avcli node-add [--wait]
Description
The node-add command adds a PM to an everRun system.
Options
--wait
-w
Wait for the command to complete.
node-add
Page 382 of 483
everRun User's Guide node-cancel
Usage avcli node-cancel pm
Description
The node-cancel command cancels a PM that is being imaged.
Options pm
The PM to cancel.
Page 383 of 483
node-config-prp node-config-prp
Usage avcli node-config-prp --nic1 adapter --nic2 adapter node
Description
The node-config-prp command configures a PRP adapter on the specified PM with two physical adapters.
You must run this command twice: once to configure the adapter on the first PM, and once to configure the adapter on the second PM.
Options
--nic1 adapter
The name of a physical adapter.
--nic2 adapter node
The name of a physical adapter.
The PM containing the PRP adapter to be configured.
Examples
$ avcli node-config-prp --nic1 eth0 --nic2 eth1 node0
Page 384 of 483
everRun User's Guide node-delete
Usage avcli node-delete pm [--wait]
Description
The node-delete command deletes a PM.
Options pm
The PM to be deleted. It must be in maintenance mode.
--wait
-w
Wait for the command to complete.
Page 385 of 483
node-delete-prp node-delete-prp
Usage avcli node-delete-prp --name adapter node
Description
The node-delete-prp command deletes a PRP adapter on the specified PM.
You must run this command twice: once to delete the adapter on the first PM, and once to delete the adapter on the second PM.
Options
--name adapter The name of the adapter to delete.
node The PM containing the adapter to delete.
Examples
$ avcli node-delete-prp --name ad0 node0
Page 386 of 483
everRun User's Guide node-info
Usage avcli node-info [pm...]
Description
The node-info command displays information about all PMs (by default) or only about the specified PMs.
Options pm The PM about which to display information.
Page 387 of 483
node-poweroff
Usage avcli node-poweroff pm [--wait]
Description
The node-poweroff command powers off the specified PM.
Options pm
The PM to be powered off.
--wait
-w
Wait for the command to complete.
node-poweroff
Page 388 of 483
everRun User's Guide node-poweron
Usage avcli node-poweron pm [--wait]
Description
The node-poweron command powers on the specified PM.
Options pm
The PM to be powered on.
--wait
-w
Wait for the command to complete.
Page 389 of 483
node-reboot
Usage avcli node-reboot pm [--wait]
Description
The node-reboot command reboots the specified PM.
Options pm
The PM to reboot.
--wait
-w
Wait for the command to complete.
node-reboot
Page 390 of 483
everRun User's Guide node-recover
Usage avcli node-recover [--wipe] pm [--wait]
Description
The node-recover command recovers the specified PM.
Options pm
The PM to recover.
--wipe
Wipe the disks off the PM prior to recovery.
--wait
-w
Wait for the command to complete.
Page 391 of 483
node-shutdown
Usage avcli node-shutdown [--force] [--wait] pm
Description
The node-shutdown command shuts down the specified PM.
Options
--force
-f
Override the shutdown warning.
--wait
-w pm
Wait for the command to complete.
The PM to shut down.
node-shutdown
Page 392 of 483
everRun User's Guide node-workoff
Usage avcli node-workoff pm [--wait]
Description
The node-workoff command takes the specified PM out of maintenance mode.
Options pm
The PM to remove from maintenance mode.
--wait
-w
Wait for the command to complete.
Page 393 of 483
node-workon
Usage avcli node-workon pm
Description
The node-workon command places the specified PM in maintenance mode.
Options pm
The PM to place into maintenance mode.
node-workon
Page 394 of 483
everRun User's Guide ntp-config
Usage avcli ntp-config servers...
Description
The ntp-config command enables and configures NTP support using the specified list of servers.
Options servers The list of servers to configure.
Examples
$ avcli ntp-config 1.2.3.4
$ avcli ntp-config 1.2.3.4 2.4.6.8
Page 395 of 483
ntp-disable
Usage avcli ntp-disable
Description
The ntp-disable command disables NTP in your everRun system.
ntp-disable
Page 396 of 483
everRun User's Guide ova-info
Usage avcli ova-info filename.ova...
Description
The ova-info command displays information about the specified OVA files.
Options filename
.ova
One or more OVA files.
Page 397 of 483
ovf-info
Usage avcli ovf-info filename.ovf...
Description
The ovf-info command displays information about the specified OVF files.
Options filename
.ovf
One or more OVF files.
ovf-info
Page 398 of 483
everRun User's Guide owner-config
Usage avcli owner-config [--email address] [--name name] [--phone
number]
Description
The owner-config command configures the everRun system's owner information.
Options
--email address The owner's email address.
--name name
--phone number
The owner's name.
The owner's phone number.
Examples
$ avcli owner-config --email "Bob Smith" --email [email protected] --phone 800-555-1234
$ avcli owner-config --phone 800-555-1234
Page 399 of 483
owner-info owner-info
Usage avcli owner-info
Description
The owner-info command displays information about the owner of the everRun system.
Page 400 of 483
everRun User's Guide pm-clear-mtbf
Usage avcli pm-clear-mtbf
Description
The pm-clear-mtbf command clears a PM's MTBF from the user interface.
Page 401 of 483
proxy-config proxy-config
Usage avcli proxy-config --port name [--username name] [--password
password] host
Description
The proxy-config command configures the everRun system to use a proxy server. If you do not specify a user name, AVCLI assumes that authentication is not required to access the proxy server. If you specify a user name but not a password, you are prompted for the password.
Options
--port number
The port number.
--username name
The user's name.
--password password
The user's password.
host The host name.
Examples
$ avcli --port 8080 proxy.my-domain.com
$ avcli --port 8080 --username user --password secret proxy.my-domain.com
$ avcli --port 8080 --username user proxy.my-domain.com
Page 402 of 483
everRun User's Guide proxy-disable
Usage avcli proxy-disable
Description
The proxy-disable command disables proxy.
Page 403 of 483
proxy-enable
Usage avcli proxy-enable
Description
The proxy-enable command enables proxy.
proxy-enable
Page 404 of 483
everRun User's Guide proxy-info
Usage avcli proxy-info
Description
The proxy-info command displays information about the proxy configuration.
Page 405 of 483
snmp-config snmp-config
Usage avcli snmp-config [--enable-requests] [--enable-traps] [--port
number] [--community name] [--recipients recipient ...] [--
recipients-v1 recipient-v1 ...]
Description
The snmp-config command configures SNMP for use in an everRun system.
Options
--enable-requests
Enable SNMP requests. If you do not specify the option, requests are disabled.
--enable-traps
--community name
Enable SNMP traps. If you do not specify the option, traps are disabled.
The name of the SNMP community.
--port number
--recipients recipient ...
The port to use for SNMP. The default is 162.
The list of hosts to which to send traps using
SNMP version 2c; required only when traps are enabled and no
--recipients-v1 are listed.
--recipients-v1 recipientv1 ...
The list of hosts to which to send traps using
SNMP version 1; required only when traps are enabled and no
--recipients are listed.
Examples
The following example enables SNMP requests, and then traps and sends them to host1 and host2 using SNMP version 2c, and to snmp.my-domain.com
and snmp2.mydomain.com
using SNMP version 1.
Page 406 of 483
everRun User's Guide
$ avcli snmp-config --enable-requests --enable-traps -recipients host1 host2 --recipients-v1 snmp.my-domain.com
snmp2.my-domain.com
The following example disables SNMP requests, enables traps, and sends them to localhost using SNMP version 2c.
$ avcli snmp-config --enable-traps --community public -recipients localhost
Page 407 of 483
snmp-disable
Usage avcli snmp-disable
Description
The snmp-disable command disables SNMP.
snmp-disable
Page 408 of 483
everRun User's Guide snmp-info
Usage avcli snmp-info
Description
The snmp-info command displays information about SNMP configuration.
Page 409 of 483
storage-group-info storage-group-info
Usage avcli storage-group-info [--disks] [--volumes] [storage-
group...]
Description
The storage-group-info command displays information about all storage groups, or optionally, only about those specified.
Options
--disks Show the logical disks belonging to a storage group.
--volumes storage-group
Show the volumes using a storage group.
One or more storage groups about which to display information.
Page 410 of 483
everRun User's Guide storage-info
Usage avcli storage-info [--disks] [--volumes] [storage-group...]
Description
The storage-info command displays information about all storage groups, or optionally, only about those specified.
Options
--disks
Show the logical disks belonging to a storage group.
--volumes storage-group
Show the volumes using a storage group.
One or more storage groups about which to display information.
Page 411 of 483
timezone-config
Usage avcli timezone-config timezone
Description
The timezone-config command sets the time zone.
Options timezone
The time zone.
Examples
$ avcli timezone-config America/New_York timezone-config
Page 412 of 483
everRun User's Guide timezone-info
Usage avcli timezone-info
Description
The timezone-info command displays the list of configurable time zones.
Page 413 of 483
unit-avoid-bad-node unit-avoid-bad-node
Usage avcli unit-avoid-bad-node true|false|reset
Description
By default, VMs automatically return to a node that has returned to service after the node has recovered from a recent failure or was in maintenance mode. In some situations, you may want to verify that the node is healthy before VMs return to it. To prevent VMs from automatically returning to such nodes, set the migration policy. To do so, use the unit-avoid-bad-node command or see
"Configuring the Migration Policy" on page 81
.
The unit-avoid-bad-node command enables or disables the ability of VMs to automatically return to a node that has recently failed or been in maintenance mode. If the node is healthy, issue unit-avoid-bad-node reset to re-enable VMs to automatically return to it.
If you issue this command with no option, the command checks if the setting is enabled or disabled, and displays yes or no values for
Feature enabled
,
Keeping VMs on last good node
, and
Awaiting reset signal
. The following output is an example:
Avoid automatically moving VMs back to a node that recovered after a failure:
-> Feature enabled : yes
-> Keeping VMs on last good node : yes
-> Awaiting reset signal : yes
Options true
Enables VMs to automatically return to a node that has returned to service. .
false reset
Disables VMs from automatically returning to a node that has returned to service.
Enables VMs held on the last good node to return to a healthy node recently returned to service.
Page 414 of 483
everRun User's Guide unit-change-ip
Usage avcli unit-change-ip --cluster-address IP_address [--static]
[--prefix prefix] [--node0-address IP_address] [--node0gateway IP_address] [--node1-address IP_address] [--node1gateway IP_address] [--dns-servers server_address ...]
Description
The unit-change-ip command changes the IP configuration of the management network for the everRun system specified by --cluster-address IP_address .
Options
--cluster-address IP_
address
The IP address of the everRun system.
--static
Explicitly sets the values, if specified, for
-prefix, --node0-address
,
--node0gateway , --node1-address , --node1gateway
, and
--dns-servers
; otherwise,
DHCP sets these values (except
--clusteraddress
).
--prefix prefix
The size of the network prefix. Values, in bits, are 8
(Class A),
16
(Class B), and
24
(Class-C).
--node0-address IP_
address
--node0-gateway IP_
address
--node1-address IP_
address
The IP address of node0.
The IP address of the node0 gateway.
The IP address of node1.
Page 415 of 483
unit-change-ip
--node1-gateway IP_
address
The IP address of the node1 gateway.
[--dns-servers server_
address ...]
One or two DNS server(s). The first IP address is for the primary DNS server. The second (optional)
IP address is for the secondary DNS server.
Examples avcli unit-change-ip --cluster-address 10.92.179.54
avcli unit-change-ip --cluster-address 10.92.179.54 --static -
-prefix 16 --node0-address 10.92.179.154 --node0-gateway
10.92.0.1 --node1-address 10.92.179.156 --node1-gateway
10.92.0.1 --dns-servers 134.111.24.250 134.111.24.251
Page 416 of 483
everRun User's Guide unit-configure
Usage avcli unit-configure
Description
The unit-configure command configures the everRun system. The command implements the initial configuration of an everRun system, as executed by the Portal Restart Required window that appears after entering network information when logging on to the everRun Availability
mode.
Page 417 of 483
unit-eula-accept
Usage avcli unit-eula-accept [--deny]
Description
The unit-eula-accept command accepts or denies the EULA.
Options
--deny Deny acceptance of the EULA.
unit-eula-accept
Page 418 of 483
everRun User's Guide unit-eula-reset
Usage avcli unit-eula-reset
Description
The unit-eula-reset command resets the EULA acceptance state on an everRun system.
Page 419 of 483
unit-info
Usage avcli unit-info
Description
The unit-info command displays information about the specified everRun system.
unit-info
Page 420 of 483
everRun User's Guide unit-shutdown
Usage avcli unit-shutdown
Description
The unit-shutdown command shuts down an everRun system.
Page 421 of 483
unit-shutdown-cancel unit-shutdown-cancel
Usage avcli unit-shutdown-cancel
Description
The unit-shutdown-cancel command cancels a pending shutdown for an everRun system.
Page 422 of 483
everRun User's Guide unit-shutdown-state
Usage avcli unit-shutdown-state
Description
The unit-shutdown-state command returns the everRun system's shutdown state.
Page 423 of 483
unit-synced unit-synced
Usage avcli unit-synced [--wait]
Description
The unit-synced command returns true if the everRun system is synchronized between all
PMs; otherwise, it returns false.
Options
--wait
-w
Wait for the command to complete.
Page 424 of 483
everRun User's Guide vm-ax-disable
Usage avcli vm-ax-disable --name name --nodes nodes
Description
The vm-ax-disable command disables the VM's AX on selected PMs.
Options
--name name
The name of a VM.
--nodes nodes The PM(s) to disable.
Examples
Disable AX on node1 for a VM named MyVM.
$ avcli vm-ax-disable --name MyVM --nodes node1
Page 425 of 483
vm-ax-enable vm-ax-enable
Usage avcli vm-ax-enable --name name --nodes nodes
Description
The vm-ax-enable command enables the VM's AX on selected PMs.
Options
--name name
The name of a VM.
--nodes nodes The PM(s) to enable.
Examples
Enable AX on node0 and node1 for a VM named MyVM.
$ avcli vm-ax-enable --name MyVM --nodes node0 node1
Page 426 of 483
everRun User's Guide vm-boot-attributes
Usage avcli vm-boot-attributes --priority priority --applicationstart-time minutes [vm...]
Description
The vm-boot-attributes command sets the boot attributes for the specified VMs.
Options
--priority priority The boot priority; values are 1 to 1000.
--application-start-time minutes vm
The estimated start time of the VM and application, in minutes. The minimum value is one minute.
One or more VMs whose boot attributes are being set.
Examples
$ avcli vm-boot-attributes --priority 1 --application-starttime 1 vm1
$ avcli vm-boot-attributes --priority 1 --application-starttime 1 vm:o100
Page 427 of 483
vm-cd-boot vm-cd-boot
Usage avcli vm-cd-boot --iso iso [--wait] [vm...]
Description
The vm-cd-boot command starts the specified VMs and boots from the specified ISO image.
Options
--iso iso
The ISO image to boot.
--wait vm
Wait for the VM to boot.
One or more VMs that are being started.
Examples
$ avcli vm-cd-boot --iso MyISO vm1
$ avcli vm-cd-boot --iso MyISO vm:o100
$ avcli vm-cd-boot --iso MyISO --wait vm1
Page 428 of 483
everRun User's Guide vm-copy
Usage avcli vm-copy --source-vm source --name name [--description
description] [--cpu number] [--memory memory] [--availability
level] [--copy-volumes volumes] [--add-volumes volumes] [--
keep-volumes volumes] [--interfaces networks] [--storage-group
group] [--vnc-keyboard-layout keyboard] [--no-auto-start]
Description
The vm-copy command copies a VM from the specified VM. If any parameter is not specified, the corresponding value from the source VM is used.
Options
--source-vm source The name or ID of the source VM.
--name name
--description description
--cpu number
--memory memory
--availability level
The name of the VM to create.
The description for the new VM.
The number of virtual CPUs to assign to the VM.
The amount of memory, in megabytes, to assign to the
VM.
The availability level, high availability ( ha
) or fault tolerant ( ft
).
--copy-volumes volumes
The list of volumes to copy to the new VM. Specify volumes by configuration name or ID, boot volume first.
To copy all of the volumes from the source VM to the new VM with the default values, keep this parameter as blank.
A volume is made up of five components, separated by commas:
Page 429 of 483
--add-volumes volumes vm-copy l
Volume name or ID of the source volume; required.
l
Storage-group name or ID from which to carve storage.
l
Volume name of the new volume.
l
Volume disk image format (raw or qcow2).
l
Sector size of the volume (512 or 4096).
n
The sector size is in bytes (B), 512 B by default.
n
If the sector size of the storage group is
512 B, the sector size of the volume must be 512 B.
n
If the sector size of the storage group is in
4096 B (4 kB), both 512 B and 4096 B are supported as the sector size of the volume.
n
The boot volume must be presented with
512 B as the sector size.
The list of volumes to attach to this VM. A volume is made up of five components, separated by commas: l
Size of the volume; required.
By default, the volume size is specified in megabytes, but you can use standard qualifiers such as KB, MB, GB, and TB.
l
Storage-group name or ID from which to carve storage.
l
Volume name.
l
Volume disk image format (raw or qcow2).
Page 430 of 483
everRun User's Guide
--keep-volumes
--interfaces
--vnc-keyboardlayout keyboard volumes networks
--storage-group
--no-auto-start group l
Sector size of the volume (512 or 4096).
The idle volumes to be attached to the new VM. Specify a volume either by name or ID.
The list of networks to attach to the VM. Specify a network only once. The attached network must not be private.
The storage group from which to carve the VM volumes. If you do not specify this value, the storage group with the most free space is automatically selected. (If the storage group is configured with 4 kB sectors, ensure that the guest OS supports the 4 kB sector size.
The keyboard layout to assign to the VM. Valid options are English ( en-us
), German ( de
), or Japanese ( ja
).
The default value is en-us
.
If set, the VM is not started after the copy has finished.
Examples
Copy a VM named vm:o2046 to a new vm called new_vm_name and retain all of the original settings.
$ avcli vm-copy --source-vm vm:o2046 --name new_vm_name
Copy a VM named vm_source to a new high availability VM named vm_copy with 2 CPUs and
1,024 MB of memory. Copy the boot volume volume:o7652 to the storage group storagegroup:o129 with the new name vm_source_vol0_bootable_copy , image type of qcow2, and sector size of 512 B. Copy the volume volume:o7749 with the default values. Also, create a new volume named vm_copy_add_new1 with size 20GB to storagegroup:o1090 and set the image type to qcow2 and sector size to 4 kB.
Page 431 of 483
vm-copy
$ avcli vm-copy --source-vm vm_source --name vm_copy --cpu 2 -
-memory 1024 --availability ha --copy-volumes volume:o7652,storagegroup:o129,vm_source_vol0_bootable_ copy,qcow2,512 volume:o7749 --add-volumes
20GB,storagegroup:o1090,vm_copy_add_new1,qcow2,4096
Copy a VM named vm_source to a new high availability VM named new_vm_name with 2
CPUs and 1,024 MB of memory. Copy the boot volume boot_volume to the
Initial-
Storage-Group with the new name boot_volume_copy and the image type of raw. Copy the volume volume:o10158 with the default values. Create a new volume named volume_ new1 with size 20GB to storagegroup:o71 and set the image type to qcow2 and sector size to 4 kB. Attach two idle volumes, volume_idle and volume:o19656
. In addition, configure network interfaces network0 and sharednetwork:o61
, set the default storage group to storagegroup:o71
, set the keyboard layout as de
, and prevent the VM from automatically starting upon creation.
$ avcli vm-copy --source-vm vm_source --name new_vm_name --cpu
2 --memory 1024 --availability ha --copy-volumes boot_ volume,Initial-Storage-Group,boot_volume_copy,raw volume:o10158 --add-volumes 20GB,storagegroup:o71,volume_ new1,qcow2,4096 --keep-volumes volume_idle volume:o19656 -interfaces network0 sharednetwork:o61 --storage-group storagegroup:o71 --vnc-keyboard-layout de --no-auto-start
Page 432 of 483
everRun User's Guide vm-create
Usage avcli vm-create --name name --cpu number --memory memory -cdrom cd-name | --kickstart template | --remote-file-path path
[--remote-type type] [--remote-username username] [--remotepassword password] --availability level [--interfaces
networks] [--disabled-interfaces networks] [--storage-group
group] [--vnc-keyboard-layout keyboard] --volumes volumes [--
wait]
Description
The vm-create command creates a new VM.
Options
--name name
The name of the VM to create.
--cpu number
The number of virtual CPUs to assign to the VM.
--memory
--cdrom memory cd-name
The amount of memory, in megabytes, to assign to the VM.
The CD-ROM from which you initially boot the VM.
You cannot specify this option with
--kickstart or
--remote-file-path
.
--kickstart template
--remote-file-path
--remote-type type path
The kickstart template to use when booting the VM.
You cannot specify this option with --cdrom or -remote-file-path
.
A remote ISO repository to use when booting the VM.
You cannot specify this option with
--cdrom or
-kickstart .
The type of remote ISO repository specified in the
--
Page 433 of 483
vm-create
--remote-username name userremote-file-path option. Valid options are samba or nfs .
The user account to specify for access to the remote
ISO repository specified in the
--remote-filepath option. Required for samba repositories.
--remote-password password
The user password to specify for access to the remote ISO repository specified in the --remotefile-path option. Required for samba repositories.
--availability level
The availability level, high availability ( ha
) or fault tolerant ( ft
).
--interfaces networks
--storage-group group
The list of networks to attach to the VM. Specify a network only once. The attached network must not be private.
--disabled-interfaces networks
A list of networks to attach to the VM, but which should not be enabled. Specify a network only once.
The attached network must not be private.
The storage group to use to carve VM volumes from.
If you do not specify this value, the storage group with the most free space is automatically selected.
--vnc-keyboard-layout keyboard
The keyboard layout to assign to the VM. Valid options are English ( en-us
), German ( de
), or Japanese ( ja
). The default value is en-us
.
--volumes volumes
List of volumes to attach to this VM. A volume is made up of five components, separated by commas:
Page 434 of 483
everRun User's Guide l
Size of the volume; required.
By default, the volume size is specified in megabytes, but you can use standard qualifiers such as KB, MB, GB, and TB.
l
Storage-group name or ID from which to carve storage.
l
Volume name.
l
Volume disk image format (raw or qcow2).
l
Sector size of the volume (512 or 4096).
n
The sector size is in bytes (B), 512 B by default.
n
If the sector size of the storage group is
512 B, the sector size of the volume must be 512 B.
n
If the sector size of the storage group is in 4096 B (4 kB), both 512 B and 4096 B are supported as the sector size of the volume.
n
The boot volume must be presented with 512 B as the sector size.
--wait
-w
Wait for the command to complete.
Examples
Create a HA VM named vm001 with a CPU, 512 MB of memory, a 1,024 MB volume, and that is attached to network0. Connect a remote ISO from an NFS share.
$ avcli vm-create --name vm001 --cpu 1 --memory 512 \
--remote-file-path 134.111.24.224:/developer/windows_7.iso
\
Page 435 of 483
vm-create
--remote-type nfs --availability ha --interfaces network0
--volumes 1024
Create a HA VM named vm001 with a CPU, 512 MB of memory, a 1,024 MB volume, and that is attached to network0. Connect a remote ISO from a Samba share.
$ avcli vm-create --name vm001 --cpu 1 --memory 512 -remote-file-path //134.111.31.228/Users/TEST/windows.iso -
-remote-type samba \
--remote-username TEST --remote-password abc123 -availability ha --interfaces network0 --volumes 1024
Create a HA VM named vm001 with a CPU, 512 MB of memory, a 1,024 MB volume, and that is attached to network0
.
$ avcli vm-create --name vm001 --cpu 1 --memory 512 -cdrom linux.iso \
--availability ha --interfaces network0 --volumes 1024
Create a FT VM named vm001 with a CPU, 512 MB of memory, a 1,024 MB volume, and that is attached to network0
. Then allocate storage from
Pool-0001 for the volume.
$ avcli vm-create --name vm001 --cpu 1 --memory 512 -cdrom linux.iso \
--availability ft --interfaces network0 --volumes 1024 \
--storage-group Pool-0001
Create a HA VM named vm001 with a CPU, 512 MB of memory, a 1,024 MB volume, and that is attached to network0
. Then allocate storage from
Pool-0001 for the volume. The volume is named vm001_vol0
.
$ avcli vm-create --name vm001 --cpu 1 --memory 512 -cdrom linux.iso \
--availability ha --interfaces network0 --volumes
1024,Pool-0001,vm001_vol0
Page 436 of 483
everRun User's Guide
Create a FT VM named vm001 with a CPU and 512 MB of memory, and that is attached to network0 and network1. Create two volumes, where the first is 10 GB and the second is 50 GB. Allocate storage for these volumes from
Pool-0001 and
Pool-0002
, respectively.
$ avcli vm-create --name vm001 --cpu 1 --memory 512 -cdrom linux.iso \
--availability ft --interfaces network0 network1 \
--volumes 10GB,Pool-0001 50GB,Pool-0002
Create a HA VM based on a kickstart template.
$ avcli vm-create --name vm001 --cpu 1 --memory 512 -kickstart template:o81 \
--availability ha --interfaces network0 --volumes 10GB
Create a HA VM with a CPU, 1024 MB of memory, a 20 GB qcow2-format bootable volume named vm001_volu_boot, a 1,024 MB data volume named vm001_volu_data with 4096 B sector size, and that is attached to network0.
--cdrom CentOS-6.7-x86_64-minimal.iso --availability ha -interfaces network0 \
--volumes 20GB,Pool-0001,vm001_volu_boot,qcow2 1024,Pool-
0002,\ vm001_volu_data,qcow2,4096
Page 437 of 483
vm-create-from-snapshot vm-create-from-snapshot
Usage avcli vm-create --vm-snapshot-oid oid [--name name] [--cpu
number] [--memory memory] [--availability level] [--interfaces
networks] [--storage-group group] [--volumes volumes] [--
volume-prefix prefix] [--no-auto-start]
Description
The vm-create-from-snapshot command creates a new VM from a VM snapshot.
Options
--vm-snapshot-oid oid
The vm snapshot OID from which to create the VM.
--name name
The name of the VM to create.
--cpu number
--memory memory
--availability
--interfaces
--volumes volumes level networks
--storage-group group
The number of virtual CPUs to assign to the VM.
The amount of memory, in megabytes, to assign to the
VM.
The availability level, high availability ( ha
) or fault tolerant
( ft ).
The list of networks to attach to the VM. Specify a network only once. The attached network must not be private.
The storage group from which to carve the VM volumes. If you do not specify this value, the storage group with the most free space is automatically selected. (If the storage group is configured with 4 kB sectors, ensure that the guest OS supports the 4 kB sector size.
Restrict the included volumes to those specified; oth-
Page 438 of 483
everRun User's Guide
--volume-prefix prefix erwise, all volumes will be created. Specify volumes by configuration name or ID, boot volume first.
Adds the specified prefix to the beginning of the newly imported volume names to prevent conflicts with existing volumes on the system. For example, if a source volume is ocean_boot
, and you specify
--volumeprefix new
, the imported volume would be newocean_boot .
If set, the VM is not started after creation has finished.
--no-auto-start
Examples
$ avcli vm-create-from-snapshot --vm-snapshot-oid vmsnapshot:o41963 --name vm001
$ avcli vm-create-from-snapshot --vm-snapshot-oid vmsnapshot:o41963 --name vm001 --availability ha --interfaces network0 --volumes centos-boot centos-data --volume-prefix minimal
$ avcli vm-create-from-snapshot --vm-snapshot-oid vmsnapshot:o41963 --name vm001 --availability ha --interfaces network0 net_143 --storage-group initial-group --volumes centos-boot centos-data --volume-prefix minimal --no-autostart
Page 439 of 483
vm-delete vm-delete
Usage avcli vm-delete [--volumes volumes] [--wait] vm...
Description
The vm-delete command deletes the specified VMs, and optionally, the volumes attached to the VMs.
Options
--volumes volumes
Delete the volumes attached to the VM.
--wait
-w vm
Wait for the command to complete.
One or more VMs to be deleted.
Examples avcli vm-delete vm1 avcli vm-delete --volumes vm1 avcli vm-delete --volumes vm1 vm2
Page 440 of 483
everRun User's Guide vm-export
Usage avcli vm-export [--path pathname] [--volumes volumes] [--wait]
[--force] vm-name
Description
The vm-export command exports a VM in OVF/VHD format to the directory specified by pathname . The command first exports VHD files, followed by the OVF file. When the OVF file appears in pathname , the export is complete.
Note: Before you can start an export, you must mount a target Windows/CIFS or NFS share
Options
--path
--wait
--force vm-name pathname
--volumes name
A pathname relative to the export mount point to where the exported OVF is written.
Restrict the exported volumes to those specified; otherwise, all volumes will be created. Specify volumes by configuration name or ID, boot volume first.
Wait for the export operation to complete. Specify this option to view the export progress.
Force the VM to be exported, even if it is still running.
Specify the name of the VM to be exported.
Examples
$ avcli vm-export --path exports/excalibur1 excalibur1
$ avcli vm-export --volumes volume:o1345 volume:o1389 --path exports/excalibur1 excalibur1
Page 441 of 483
vm-import vm-import
Usage avcli vm-import --archive filename.ova [--no-auto-start] [-cpu number] [--memory size] [--name vm-name] [--storage-groups
groups] [--interfaces networks] [--remap-volumes] [--volumes
volumes] [--volume-prefix prefix] [--data] [--force] [--
silent] [--dry-run] [--throttle] [--use-https] [--protectionlevel level]
Description
The vm-import command imports a VM from an OVA or OVF VM archive file.
Options
--archive filename
.ova
The OVA or OVF file archive to import.
--no-auto-start
--cpu number
--memory
--name size vm-name
--storage-groups
--interfaces groups networks
Do not start the VM after the import has finished.
The number of CPUs to assign to the VM. This defaults to the value in the archive.
The size of memory, in megabytes, to assign to the VM.
This defaults to the value in the archive.
The name to assign to the VM. This defaults to the value in the archive.
The list of storage groups to use for allocating the VM's volumes. By default, all available storage groups are used. Allocation occurs in a round-robin fashion.
The list of shared networks to assign to the VM's interfaces. By default, values in the archive or available shared networks are assigned.
Page 442 of 483
everRun User's Guide
--remap-volumes
--volumes
--volume-prefix prefix
--data
--force
--silent
--dry-run volumes
--throttle
First attempt to remap all volumes to the shared-mirrors as defined in the archive, after that the --volumes and
--storage-groups rules are in effect.
Import only these volumes. By default, all available volumes from the OVF are imported.
Adds the specified prefix to the beginning of the newly imported volume names to prevent conflicts with existing volumes on the system. For example, if a source volume is ocean_boot
, and you specify
-volume-prefix new
, the imported volume would be new-ocean_boot
.
Import data only for the specified volumes.
When the OVF file is missing the isBootable flag
(a known issue for Windows XP), assume that the VHD pointed to by OVF is the bootable one.
Suppress output.
Show the interface to the shared network and volumeto-storage-group assignments without actually importing or restoring a VM.
Slow down the import/export operation. Valid values are: l none
: Do not use throttling. This is the default value.
l low : Slow down by about 25%.
l medium : Slow down by about 50%.
l high : Slow down by about 75%.
Page 443 of 483
vm-import
--use-https
--protection-level level
Use secure HTTPS transport instead of the default streaming method (HTTP transport). Streaming over
HTTPS provides slower performance than HTTP but is much more secure.
The protection level to assign to the VM. Valid options are
HA and
FT
(default).
Examples
$ avcli vm-import --archive vm1.ova
$ avcli vm-import --archive vm1.ovf
$ avcli vm-import --name myVM --throttle low --archive vm1.ovf
$ avcli vm-import --cpu 2 --memory 1024 --archive vm1.ovf
$ avcli vm-import --interfaces network0 network1 --archive vm1.ovf
$ avcli vm-import --remap-volumes --archive vm1.ovf
$ avcli vm-import --storage-groups sm-0000 sm-0001 --archive vm1.ovf
$ avcli vm-import --volumes boot_vol vol3 --data vol3 -archive vm1.ovf
$ avcli vm-import --name myVM --protection-level HA --archive vm1.ovf
Page 444 of 483
everRun User's Guide vm-info
Usage avcli vm-info [vm...]
Description
The vm-info command displays information about all VMs, or optionally, about specific VMs.
Options vm
One or more VMs for which to display information.
Examples
$ avcli vm-info
$ avcli vm-info vm1
$ avcli vm-info vm1 vm:o100
Page 445 of 483
vm-network-disable vm-network-disable
Usage avcli vm-network-disable --name name --nodes nodes --networks
networks
Description
The vm-network-disable command disables a VM's networks on selected nodes.
Options
--name name The name of a VM.
--nodes nodes
--networks networks
The PM(s) on which to disable the networks.
The networks to disable.
Examples
Disable net2 on node1 for a VM named MyVM.
$ avcli vm-network-disable --name MyVM --nodes node1 \
--networks net2
Page 446 of 483
everRun User's Guide vm-network-enable
Usage avcli vm-network-enable --name name --nodes nodes --networks
networks
Description
The vm-network-enable command enables a VM's networks on selected nodes.
Options
--name name The name of a VM.
--nodes nodes
--networks networks
The PM(s) on which to enable the networks.
The networks to enable.
Examples
Enable net2 on node1 for a VM named MyVM.
$ avcli vm-network-enable --name MyVM --nodes node1 \
--networks net2
Page 447 of 483
vm-poweroff vm-poweroff
Usage avcli vm-poweroff [vm...] [--wait]
Description
The vm-poweroff command powers off the specified VMs.
Options vm
One or more VMs to power off. Specify a VM either by name or
ID.
--wait
-w
Wait for the command to complete.
Examples
$ avcli vm-poweroff vm1
$ avcli vm-poweroff vm1 vm2
$ avcli vm-poweroff vm1 vm:o100
Page 448 of 483
everRun User's Guide vm-poweron
Usage avcli vm-poweron [vm...] [--wait]
Description
The vm-poweron command powers on the specified VMs.
Options vm
One or more VMs to power on. Specify a VM either by name or ID.
--wait
-w
Wait for the command to complete.
Examples
$ avcli vm-poweron vm1
$ avcli vm-poweron vm1 vm2
$ avcli vm-poweron vm1 vm:o100
Page 449 of 483
vm-reprovision vm-reprovision
Usage avcli vm-reprovision --name name [--new-name name] [-description "description"] [--cpu number] [--memory size] [-addVolumes volumes] [--deleteVolumes volumes] [--keepVolumes
volumes] [--interfaces networks] [--vnc-keyboard-layout
keyboard] [--detach-boot-volume] [--attach-boot-volume name]
Description
The vm-reprovision command reprovisions the specified VM.
Options
--name name
Specify the VM to reprovision. Reprovision only one VM at a time. Specify a VM either by name or ID.
--new-name name Specify a new name for the VM.
--description
" description "
Specify a description for the VM.
--cpu number
--memory size
--addVolumes volumes
The number of virtual CPUs. This defaults to the VM's current amount.
The size of memory, in megabytes. This defaults to the
VM's current amount.
The list of volumes to attach to this VM. A volume is made up of five components, separated by commas: l
Size of the volume; required.
By default, the volume size is specified in megabytes, but you can use standard qualifiers such as
KB, MB, GB, and TB.
l
Storage-group name or ID from which to carve stor-
Page 450 of 483
everRun User's Guide
--interfaces
--vnc-keyboardlayout keyboard networks age.
l
Volume name.
l
Volume disk image format (raw or qcow2).
l
Sector size of the volume (512 or 4096).
n
The sector size is in bytes (B), 512 B by default.
n
If the sector size of the storage group is 512
B, the sector size of the volume must be 512
B.
n
If the sector size of the storage group is in
4096 B (4 kB), both 512 B and 4096 B are supported as the sector size of the volume.
n
The boot volume must be presented with 512
B as the sector size.
--deleteVolumes volumes
The list of volume(s) that are currently attached to the specified VM to be deleted. Specify a volume either by name or
ID.
--keepVolumes volumes
The list of volume(s) that are currently attached to the specified VM to be kept attached to the VM. If you specify a volume that is currently attached but not specified in this list, the volume is detached (not destroyed) from the VM.
Specify a volume either by name or ID.
The list of networks to attach to the VM. Specify a network only once. The attached network must not be private.
The keyboard layout to assign to the VM. Valid options are
English ( en-us
), German ( de
), or Japanese ( ja
). The default value is en-us
.
Page 451 of 483
vm-reprovision
--detach-boot-volume Detaches the VM's boot volume.
--attach-bootvolume name
Specify the name of a new boot volume for this VM. If the
VM already has an attached boot volume, you must also specify
--detach-boot-volume
; otherwise, the command fails.
Examples
$ avcli vm-reprovision --cpu 2 --name vm1
$ avcli vm-reprovision --cpu 2 --name vm:o100
$ avcli vm-reprovision --cpu 2 --memory 2048 --name vm:o100
Reprovision a VM named vm001 that has a CPU, 512 MB of memory, a 1,024 MB volume and is attached to network0, and then allocate storage from
Pool-0001 for the volume. The volume is named vm001_vol0
.
$ avcli vm-reprovision --cpu 1 --memory 512 --interfaces network0 \
--addVolumes 1024,Pool-0001,vm001_vol0 --name vm1
Reprovision VM vm1
, and then delete the volumes volume:o411
, data-vm1
, and datavm2 associated with it.
vm1 data-vm2 --name vm1
Reprovision VM vm1 with the new data volume data-1-7
, delete volume volume:o1043
, keep volumes volume:o1 , volume:o2 , volume:o4 , and attach network interfaces sharednetwork:o129 and sharednetwork:o130
.
2500,storagegroup:o54,data-1-7 --deleteVolumes volume:o1043 --keepVolumes volume:o1 volume:o2 volume:o4 -
-interfaces sharednetwork:o129 sharednetwork:o130 --name vm1
Page 452 of 483
everRun User's Guide
Reprovision VM vm1 with the same parameters from the previous example. Also rename the VM vm2 and add a description.
$ avcli vm-reprovision --cpu 3 --memory 3359 --addVolumes
2500,storagegroup:o54,data-1-7,qcow2 --deleteVolumes volume:o1043 --keepVolumes volume:o1 volume:o2 volume:o4 -
-interfaces sharednetwork:o129 sharednetwork:o130 --name vm1 --new-name vm2 --description "This is the vm description"
Reprovision VM vm001 with two CPUs, 2048 MB of memory, one new data volume vm001_ data1 in qcow2 format with 4 kB sector size, and keep volume o7517
.
$ avcli vm-reprovision --cpu 2 --memory 2048 --addVolumes
20GB,storagegroup:o1090,vm001_data1,qcow2,4096 -keepVolumes volume:o7517 --name vm001
Swap two VMs' boot disks.
Detach boot volume:
$ avcli vm-reprovision --detach-boot-volume --name p56xen4
Switch boot volume:
$ avcli vm-reprovision --detach-boot-volume --attach-bootvolume boot-p56xen4 --name p56xen8
Attach a detached boot volume to a different VM:
$ avcli vm-reprovision --attach-boot-volume boot-p56xen8 -
-name p56xen4
Page 453 of 483
vm-restore vm-restore
Usage avcli vm-restore --archive filename.ova [--no-auto-start][-cpu number][--memory size][--name vm-name][--storage-groups
groups][--interfaces networks][--volume-prefix prefix][--data]
[--silent][--dry-run] [--throttle][--use-https]
Description
The vm-restore command restores a VM from an OVA or OVF file.
Options
--archive filename
.ova
The OVA or OVF file archive to restore.
--no-auto-start
--cpu number
--memory
--name size vm-name
--storage-groups
--interfaces networks
--volume-prefix groups prefix
Do not start the VM after the restore has finished.
The number of CPUs to assign to the VM. This defaults to the value in the archive.
The size of memory, in megabytes, to assign to the
VM. This defaults to the value in the archive.
The name to assign to the VM. This defaults to the value in the archive.
The list of storage groups to use for allocating the
VM's volumes. By default, all available storage groups are used. Allocation occurs in a round-robin fashion.
The list of shared networks to assign to the VM's interfaces. By default, values in the archive or available shared networks are assigned.
Adds the specified prefix to the beginning of the
Page 454 of 483
everRun User's Guide
--data
--silent
--dry-run
--throttle
--use-https newly imported volume names to prevent conflicts with existing volumes on the system. For example, if a source volume is ocean_boot
, and you specify
--volume-prefix new
, the imported volume would be new-ocean_boot
.
Restore data only for the specified volumes.
Suppress output.
Show the interface to the shared network and volume-to-storage-group assignments without actually restoring a VM.
Slow down the operation. Valid values are: l none
: Do not use throttling. This is the default value.
l low
: Slow down by about 25%.
l medium
: Slow down by about 50%.
l high
: Slow down by about 75%.
Use secure HTTPS transport instead of the default streaming method (HTTP transport). Streaming over
HTTPS provides slower performance than HTTP but is much more secure.
Examples
$ avcli vm-restore --archive vm1.ova
$ avcli vm-restore --archive vm1/vm1.ovf
$ avcli vm-restore --name myVM --throttle low --archive vm1.ovf
$ avcli vm-restore --cpu 2 --memory 1024 --archive vm1.ovf
Page 455 of 483
vm-restore
$ avcli vm-restore --interfaces network0 network1 --archive vm1.ovf
$ avcli vm-restore --storage-groups sm-0000 sm-0001 --archive vm1.ovf
$ avcli vm-restore --data vol1 vol3 --archive vm1.ovf
Page 456 of 483
everRun User's Guide vm-shutdown
Usage avcli vm-shutdown [vm...][--wait]
Description
The vm-shutdown command shuts down the specified VMs.
Options vm
One or more VMs to shut down. Specify a VM either by name or ID.
--wait
-w
Wait for the command to complete.
Examples
$ avcli vm-shutdown vm1
$ avcli vm-shutdown vm1 vm2
$ avcli vm-shutdown vm1 vm:o100
Page 457 of 483
vm-snapshot-create vm-snapshot-create
Usage avcli vm-snapshot-create [--volumes | --no-data][-description] [--desire] [--require] vm-name
Description
The vm-snapshot-create command creates a VM snapshot.
Two snapshot consistency levels are supported: l
Crash consistency : The restored data is in the same state that it would have been if the system had crashed at the exact moment that the snapshot was taken. A crash-consistent snapshot does not capture the contents of memory or any pending I/O operations.
l
Application consistency : Before the snapshot is taken, cooperating applications are briefly frozen so that transactions are complete, buffers flushed, files closed, and so on. This ensures that cooperating applications start from a consistent state. This is the highest level of consistency.
Options
--volumes |
--no-data
The names of volumes to include in the snapshot. By default, all volumes are included in the snapshot unless you specify
-volumes with individual volume names or you specify
--nodata
. If you specify
--no-data
, no volumes are included in the snapshot. These arguments are mutually exclusive.
--description The user-specified description for this snapshot.
--desire
--require
The highest consistency level to attempt in order to declare the snapshot a success. If this attempt fails, attempts are made at successively lower levels (but no lower than the level specified by
--require
). Values are crash and application
(the default value).
The minimum consistency level needed to declare the snapshot a
Page 458 of 483
everRun User's Guide success. Values are crash and application (the default value).
The VM's ID.
vm-name
Examples
$ avcli vm-snapshot-create --volumes volume:o100 volume:o101 vm1
Page 459 of 483
vm-snapshot-create-disable vm-snapshot-create-disable
Usage avcli vm-snapshot-create-disable
Description
The vm-snapshot-create-disable command disables the system's ability to create snapshots. By default, the system's ability to create snapshots is enabled. Only users with the role
Administrator (the group admin
) can execute this command. Users with the role Platform Admin
(the group platform_admin
) or Read Only (the group read-only
) cannot execute this command.
Examples
$ avcli -H localhost -u admin -p password vm-snapshot-createdisable
Page 460 of 483
everRun User's Guide vm-snapshot-create-enable
Usage avcli vm-snapshot-create-enable
Description
The vm-snapshot-create-enable command enables the system's ability to create snapshots. By default, the system's ability to create snapshots is enabled. Only users with the role
Administrator (the group admin
) can execute this command. Users with the role Platform Admin
(the group platform_admin
) or Read Only (the group read-only
) cannot execute this command.
Examples
$ avcli -H localhost -u admin -p password vm-snapshot-createenable
Page 461 of 483
vm-snapshot-delete vm-snapshot-delete
Usage avcli vm-snapshot-delete snapshot...
Description
The vm-snapshot-delete command deletes the specified snapshots.
Options snapshot
One or more snapshots of the VM. Specify a snapshot by ID.
Examples
$ avcli vm-snapshot-delete vmsnapshot:o100 vmsnapshot:o101
Page 462 of 483
everRun User's Guide vm-snapshot-export
Usage avcli vm-snapshot-export [--wait][--silent][--volumes volumes]
--path pathname snapshot
Description
The vm-snapshot-export command exports a VM in OVF/VHD format to the directory specified by pathname . The command first exports VHD files, followed by the OVF file. When the OVF file appears in pathname , the export is complete.
Note: Before you can start an export, you must mount a target Windows/CIFS or NFS share
(from another system) in the everRun host operating system. For details, see "Exporting a
Options
--wait
--silent
--volumes
--path snapshot volumes pathname
Wait for the export operation to complete. Specify this option to view the export progress.
Suppress progress output.
Restrict the exported volumes to those specified; otherwise, all volumes will be created. Specify volumes by configuration name or ID, boot volume first.
A pathname relative to the export mount point to where the exported OVF is written.
The name of the snapshot to export.
Examples
Export a snapshot with all captured volumes:
$ avcli vm-snapshot-export --path exports/ex1 ex1
Export a snapshot with just one captured volume:
Page 463 of 483
vm-snapshot-export
$ avcli vm-snapshot-export --volumes boot-ex1 --path exports/ex1 ex1
Page 464 of 483
everRun User's Guide vm-snapshot-info
Usage avcli vm-snapshot-info [snapshot...]
Description
The vm-snapshot-info command displays information about all snapshots, or optionally, only about those specified.
Options snapshot One or more snapshots of the VM. Specify a snapshot either by name or ID.
Page 465 of 483
vm-unlock vm-unlock
Usage avcli vm-unlock [vm...]
Description
The vm-unlock command unlocks the specified VMs. For example, VM import operations set the lock to prevent a VM from being started or modified while the operation is occurring. If an operation fails unexpectedly, leaving the VM locked, use this command to unlock that VM.
Options vm One or more VMs to unlock. Specify a VM either by name or ID.
Examples
$ avcli vm-unlock vm1
$ avcli vm-unlock vm:o100
Page 466 of 483
everRun User's Guide vm-volume-disable
Usage avcli vm-volume-disable --name name --nodes nodes --volumes
volumes
Description
The vm-volume-disable command disables a VM's volumes on selected nodes.
Options
--name name The name of a VM.
--nodes nodes
--volumes volumes
The PM(s) on which to disable the volumes.
The volumes to disable.
Examples
Disable abba1-data and volume:o2249 on node1 for a VM named MyVM.
$ avcli vm-volume-disable --name MyVM --nodes node1 \
--volumes abba1-data volume:o2249
Page 467 of 483
vm-volume-enable vm-volume-enable
Usage avcli vm-volume-enable --name name --nodes nodes --volumes
volumes
Description
The vm-volume-enable command enables a VM's volumes on selected nodes.
Options
--name name The name of a VM.
--nodes nodes
--volumes volumes
The PM(s) on which to enable the volumes.
The volumes to enable.
Examples
Enable volume:o2249 on node1 for a VM named MyVM.
$ avcli vm-volume-enable --name MyVM --nodes node1 \
--volumes volume:o2249
Page 468 of 483
everRun User's Guide volume-info
Usage avcli volume-info [volume...]
Description
The volume-info command displays information about all volumes, or optionally, only about those specified.
Options volume A volume about which to display information.
Page 469 of 483
volume-resize volume-resize
Usage avcli volume-resize --new-size size volume
Description
The volume-resize command resizes a volume. The image container (also known as a volume container ) must be large enough to allow this. You must stop the VM before specifying this command.
Options
--new-size size
The new volume size. By default, size is in megabytes, but you can specify standard qualifiers (for example, KB, K, MB, M, GB, or G).
volume The volume to be resized.
Examples
# avcli volume-resize --new-size 79G boot-airplane1
Page 470 of 483
13
Chapter 13: System Reference Information
See the following topics for reference information l
"Compatible Guest Operating Systems" on page 472
l
"Physical Machine System Requirements" on page 473
l
"Important Physical Machine and Virtual Machine Considerations" on page 476
l
"Accessing Knowledge Base Articles" on page 479
Compatible Guest Operating Systems
The following are compatible as guest operating systems for virtual machines (VMs) running on everRun systems.
Operating System Version
Microsoft Windows Server 2012 (Foundation, Essentials, Standard,
Datacenter)
64-bit, 64-bit R2
Microsoft Windows Small Business Server 2011 (Standard, Essential, Premium Add-On)
64-bit
Windows Server 2008 (Web, Small Business, Standard, Enterprise,
Datacenter)
32-bit, 64-bit R2 only
Windows Server 2003 (Enterprise) 32-bit R2 SP2
1
Page 472 of 483
everRun User's Guide
Operating System
Microsoft Windows 10 Desktop
Microsoft Windows 8.1 Desktop Enterprise)
Microsoft Windows 8 Desktop (Enterprise)
Microsoft Windows 7 Desktop
Red Hat Enterprise Linux 7 (Workstation, Server)
Red Hat Enterprise Linux 6 (Workstation, Server)
CentOS 7
CentOS 6
SUSE Linux Enterprise Server
Ubuntu
Version
64-bit
64-bit
64-bit
32-bit, 64-bit
Red Hat 7.0, 7.1, 7.2 (all 64bit)
Red Hat 6.4, 6.5, 6.6, 6.7, 6.8
(all 64-bit)
CentOS 7.0, 7.1, 7.2 (all 64bit)
CentOS 6.4, 6.5, 6.6, 6.7, 6.8
(all 64-bit)
SLES 11 SP3 64-bit
12.04, 13.10, 14.04, 16.04 (all
64-bit)
For specific installation and migration procedures, see "Creating a New Windows Server 2003 Virtual
Machine" on page 167 and "Migrating a Windows Server 2003 VM to an everRun 7.x System" on page
Physical Machine System Requirements
The following table presents the minimum and maximum capacities of the listed devices for physical machines running on everRun systems.
Page 473 of 483
Physical Device Minimum
Intel Xeon E5-
1 XXX v2 Processor
Intel Xeon E5-
1 XXX v3 Processor
Intel Xeon E5-
1 XXX v4 Processor
Intel Xeon E5-
2XXX Processor
Intel Xeon E5-
2 XXX v2 Processor
CPUs:
Intel
®
Xeon
®
E3-
1
XXX
Processor
Intel Xeon E3-
1
XXX v2 Processor
Intel Xeon E3-
1 XXX v3 Processor
Intel Xeon E3-
1 XXX v4 Processor
Intel Xeon E5-
1 XXX Processor
1 2
Physical Machine System Requirements
Maximum Tested Architected Notes
No Practical
Limit
Maximum of 2 physical
CPUs supported in one physical machine (PM)
of an everRun system.
Page 474 of 483
everRun User's Guide
Physical Device Minimum
Intel Xeon E5-
2 XXX v3 Processor
Intel Xeon E5-
2 XXX v4 Processor
Number CPU
Sockets per
Physical
Machine
Physical
Memory
1
8 GB
Internal Disk
Count per Physical Machine
2
Total Disk Capacity
36 GB
Management
ENET Ports
1
Maximum Tested Architected Notes
2
384 GB
24
9.4 TB
1
A-Link ENET
Ports
1 on each PM 8 on each PM
Business ENET
1 20
No Practical
Limit
Maximum of 2 physical sockets supported in one PM of an everRun system.
No Practical
Limit
No Practical
Limit
Minimum 2 drives per
PM for FT. VM disks/volumes are replicated on both PMs.
No Limit
1 1 per system required.
2 recommended. No
VM can have more than
2. Maximum of 8 (for 4 or more guests).
Can be shared with Man-
Page 475 of 483
Important Physical Machine and Virtual Machine Considerations
Physical Device Minimum
Ports
Quorum Servers 0
Maximum Tested Architected Notes agement link.
2
Important Physical Machine and Virtual Machine Considerations
For optimal implementation of physical machines and virtual machines, be aware of the configuration maximums and requirements described in the following sections: l
"Physical Machine System Requirements" on page 473
l
"Virtual Machine Recommendations and Limits" on page 476
l
"Combined Virtual Machine Maximums" on page 478
l
"Important Considerations" on page 478
Virtual Machine Recommendations and Limits
Virtual machines (VMs) require certain
and have and
for memory, networks, and storage.
Recommended Number of CPU Cores
The number of cores recommended for everRun workloads depends upon the number of vCPUs in each
VM and the types of the VMs as described below:
Item Number of Physical Threads
Fixed system overhead (host and system management) 2
Each FT guest with n vCPUs n + 2 (typical)
Each HA guest with n vCPUs n + 1 (typical)
Note: A non-hyperthreaded physical CPU core can handle 1 physical thread. A hyper-threaded physical CPU core can handle 2 physical threads.
Page 476 of 483
everRun User's Guide
The actual number of required threads depends upon the workload. The guidelines above should cover most workloads. Since any given workload may require fewer or more threads, it’s good practice to test and characterize your specific workload.
Examples
A single 4-vCPU FT guest typically requires: l
2 threads for host/system management l
6 threads for guest n
8 threads total (a single socket 4-core hyper-threaded system)
Four 5-vCPU FT guests typically require: l
2 threads for host/system management l
7 threads for first guest l
7 threads for second guest l
7 threads for third guest l
7 threads for fourth guest n
30 threads total (a dual socket 8-core hyper-threaded system)
Virtual Machine Limits
For systems with many or large virtual machines (VMs), configure everRun with 10 Gb sync links, and for the everRun software itself, 4 vCPUs and 4096 MB. Refer to the Preferences -> Systems Resources page in the everRun Availability Console for instructions on setting the everRun system resources to the maximum.
The following table lists everRun system VM limits.
Item Limits
Maximum VCPUs per FT VM
Maximum VCPUs per HA VM
Maximum Memory per FT VM
20
20
213.33 GB
Page 477 of 483
Combined Virtual Machine Maximums
Item
Maximum Memory per HA VM
Maximum Availability Links per VM 2
Maximum Virtual Networks per VM 20
Limits
213.33 GB
Maximum Storage Volumes per VM 12
Guest Volume Size Tested up to 2.2 TB. Maximum supported size is 16 TB.
Max. Snapshots per VM 16 (72 total per system)
Combined Virtual Machine Maximums
The following table presents the combined maximums of virtual machines (VMs) and virtual NICs that can run on everRun systems.
Virtual Device Maximum
Total FT VMs
Total VMs (FT and HA combined)
Total Virtual Network Interface cards (NICs)
8
28
20
Important Considerations
Note the following important considerations.
Feature Comment everRunSystem Disk
Recommended minimum configuration for physical machines: l
One logical volume protected by RAID1, RAID 5, RAID 6, or RAID 10 or
Page 478 of 483
everRun User's Guide
Feature
USB CD/DVD Drive
Direct-Attach Tape Drives
Console Connectivity
SSD Support
Comment l
Two non-RAID or RAID 0 volumes.
When using multiple volumes per RAID set, the RAID set should set a type that provides redundancy, such as RAID1, RAID5, or
RAID10.
USB CD/DVD drives are supported on all platforms for everRun installation.
Access to direct-attach tape drives by the guests is not supported. Stratus recommends using network-attach tape drives.
Each PM's text console is available for a CentOS operating system. However, VGA mode is not supported; that is, the PM must be at run-level 3 and cannot run at run-level 5. See "System Management" below.
everRun supports solid state drives according to the storage controller vendor specifications.
everRun system management does not work at run-level 5.
System Management
Accessing Knowledge Base Articles
The Stratus Customer Service Portal provides a searchable Knowledge Base with technical articles about all Stratus products, including everRun. In some cases, the online Help directly references these
Knowledge Base articles (for example, KBnnnn ). You can access the Customer Service Portal and Knowledge Base by using your existing service portal credentials, or by creating a new user account, as follows.
To access the Knowledge Base
1. Log on to the Stratus Customer Service Portal at https://support.stratus.com
.
If needed, create a new account as follows:
Page 479 of 483
Accessing Knowledge Base Articles a. Click Register Account.
b. Enter your company email address and contact info, and click Register.
Your company email address must include a domain name (for example, stratus.com) for a company that is a registered customer of Stratus.
c. Click the link in the email that you receive from Stratus.
d. Enter a new password and finish configuring your account.
If you need assistance creating an account, contact your authorized Stratus service representative.
2. In the service portal, click Knowledge Base in the left pane.
3. In the Keyword Search box, enter keywords associated with the information you need, and then click Search.
To search for an article by its KBnnnn number, click Advanced Search. Next to Search by ID, type the article ID number ( nnnn ) and click Display.
Related Topics
"Supporting Documents" on page 289
Page 480 of 483
14
Chapter 14: SNMP
Simple Network Management Protocol (SNMP) is a standard protocol for receiving alarms, sending traps, and monitoring system status. SNMP draws upon system-defining information that is stored in hierarchically configured management information bases (MIBs).
To configure an everRun system to use SNMP, see
"Configuring SNMP Settings" on page 91 .
You can download a copy of the MIB file from the Drivers and Tools section of the Downloads page at http://www.stratus.com/go/support/everrun .
Page 482 of 483
advertisement
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project