Veritas InfoScale™ 8.0 Virtualization Guide - Linux
- Section I. Overview of Veritas InfoScale Solutions used in Linux virtualization
- Overview of supported products and technologies
- Overview of the Veritas InfoScale Products Virtualization Guide
- About Veritas InfoScale Solutions support for Linux virtualization environments
- About Kernel-based Virtual Machine (KVM) technology
- About the RHEV environment
- Virtualization use cases addressed by Veritas InfoScale products
- About virtual-to-virtual (in-guest) clustering and failover
- Overview of supported products and technologies
- Section II. Implementing a basic KVM environment
- Getting started with basic KVM
- Creating and launching a kernel-based virtual machine (KVM) host
- RHEL-based KVM installation and usage
- Setting up a kernel-based virtual machine (KVM) guest
- About setting up KVM with Veritas InfoScale Solutions
- Veritas InfoScale Solutions configuration options for the kernel-based virtual machines environment
- Dynamic Multi-Pathing in the KVM guest virtualized machine
- Dynamic Multi-Pathing in the KVM host
- Storage Foundation in the virtualized guest machine
- Enabling I/O fencing in KVM guests
- Storage Foundation Cluster File System High Availability in the KVM host
- Dynamic Multi-Pathing in the KVM host and guest virtual machine
- Dynamic Multi-Pathing in the KVM host and Storage Foundation HA in the KVM guest virtual machine
- Cluster Server in the KVM host
- Cluster Server in the guest
- Cluster Server in a cluster across virtual machine guests and physical machines
- Installing Veritas InfoScale Solutions in the kernel-based virtual machine environment
- Installing and configuring Cluster Server in a kernel-based virtual machine (KVM) environment
- Configuring KVM resources
- Getting started with basic KVM
- Section III. Implementing Linux virtualization use cases
- Application visibility and device discovery
- About storage to application visibility using Veritas InfoScale Operations Manager
- About Kernel-based Virtual Machine (KVM) virtualization discovery in Veritas InfoScale Operations Manager
- About Red Hat Enterprise Virtualization (RHEV) virtualization discovery in Veritas InfoScale Operations Manager
- About Microsoft Hyper-V virtualization discovery
- Virtual machine discovery in Microsoft Hyper-V
- Storage mapping discovery in Microsoft Hyper-V
- Server consolidation
- Physical to virtual migration
- Simplified management
- Application availability using Cluster Server
- About application availability options
- Cluster Server In a KVM Environment Architecture Summary
- VCS in host to provide the Virtual Machine high availability and ApplicationHA in guest to provide application high availability
- Virtual to Virtual clustering and failover
- I/O fencing support for Virtual to Virtual clustering
- Virtual to Physical clustering and failover
- Recommendations for improved resiliency of InfoScale clusters in virtualized environments
- Virtual machine availability
- Virtual machine availability for live migration
- Virtual to virtual clustering in a Red Hat Enterprise Virtualization environment
- Virtual to virtual clustering in a Microsoft Hyper-V environment
- Virtual to virtual clustering in a Oracle Virtual Machine (OVM) environment
- Disaster recovery for virtual machines in the Red Hat Enterprise Virtualization environment
- About disaster recovery for Red Hat Enterprise Virtualization virtual machines
- DR requirements in an RHEV environment
- Disaster recovery of volumes and file systems using Volume Replicator (VVR) and Veritas File Replicator (VFR)
- Configure Storage Foundation components as backend storage
- Configure VVR and VFR in VCS GCO option for replication between DR sites
- Configuring Red Hat Enterprise Virtualization (RHEV) virtual machines for disaster recovery using Cluster Server (VCS)
- Multi-tier business service support
- Managing Docker containers with InfoScale Enterprise
- About managing Docker containers with InfoScale Enterprise product
- About the Cluster Server agents for Docker, Docker Daemon, and Docker Container
- Managing storage capacity for Docker containers
- Offline migration of Docker containers
- Disaster recovery of volumes and file systems in Docker environments
- Limitations while managing Docker containers
- Application visibility and device discovery
- Section IV. Reference
- Appendix A. Troubleshooting
- Troubleshooting virtual machine live migration
- Live migration storage connectivity in a Red Hat Enterprise Virtualization (RHEV) environment
- Troubleshooting Red Hat Enterprise Virtualization (RHEV) virtual machine disaster recovery (DR)
- The KVMGuest resource may remain in the online state even if storage connectivity to the host is lost
- VCS initiates a virtual machine failover if a host on which a virtual machine is running loses network connectivity
- Virtual machine start fails due to having the wrong boot order in RHEV environments
- Virtual machine hangs in the wait_for_launch state and fails to start in RHEV environments
- VCS fails to start a virtual machine on a host in another RHEV cluster if the DROpts attribute is not set
- Virtual machine fails to detect attached network cards in RHEV environments
- The KVMGuest agent behavior is undefined if any key of the RHEVMInfo attribute is updated using the -add or -delete options of the hares -modify command
- RHEV environment: If a node on which the VM is running panics or is forcefully shutdown, VCS is unable to start the VM on another node
- Appendix B. Sample configurations
- Appendix C. Where to find more information
- Appendix A. Troubleshooting
Implementing live migration for virtual machine availability
A virtual machine (VM) can be migrated from one host to another host. This migration can be a live migration or pause migration. You can initiate the migration using:
The virsh migrate command or virt-manager console in case of Kernel-based Virtual Machine (KVM) environment
RHEV-M web interface in case of Red Hat Enterprise Virtualization (RHEV) environment
The Cluster Server (VCS) hagrp -migrate operation (the hagrp -migrate command initiates live migration only)
If virtual machine migration is initiated outside VCS (either using the virsh commands or the RHEV-M web interface), VCS monitors the migrated guest and can detect the migration process. VCS changes the resource state according to the virtual machine state, i.e. if the guest is live-migrated from one host to another host, the associated KVMGuest resource is brought online on the host where the guest is migrated and on the source node the KVMGuest resource state is reported as OFFLINE (Intentional OFFLINE).
For the KVM environment, Veritas recommends the use of CVM and CFS for live migration where a virtual image needs to be simultaneously accessible on a source and destination node.
See Sample configuration in a KVM environment.
Cluster Server (VCS) has introduced a new migrate operation for initiating service group migration. The KVMGuest agent has implemented a "migrate" entry point to initiate virtual machine migration in KVM and RHEV environment. You can initiate a virtual machine live migration using the hagrp -migrate command.
The syntax for the command is:
#hagrp -migrate service_group_name -to destination_node_name
To verify the password-less SSH requirement for live migration
- Validate password-less SSH by executing following command on source system:
# virsh "connect qemu+ssh://destination_node/system; list"
If this command asks for a password, then password-less SSH is not set between source and destination node.
If proper output is returned, then password-less SSH is set properly.
To configure VCS to initiate virtual machine migration
- To prepare for initiating a virtual machine live migration using hagrp -migrate command, you must configure the PhysicalServer attribute (system level) of VCS using following command:
# hasys -modify sys_name PhysicalServer physical_server_name
For example:
# haconf -makerw # hasys -modify sys_name PhysicalServer "'hostname'"
The PhysicalServer name is used while initiating the migration.
- If PhysicalServer attribute is not configured, then the target node name passed to the migrate entry point is used for initiating the migration.
The KVMGuest Agent migrate entry point:
For the KVM environment: Agent uses the virsh migrate command to initiate virtual machine migration.
For the RHEV environment: Agent uses REST APIs to initiate virtual machine migration. It also checks whether the virtual machine migration is allowed or not.
Note:
When a virtual machine is configured for disaster recovery, the virtual machine cannot be migrated across sites.
See Sample configurations for a Red Hat Enterprise Virtualization (RHEV) environment.