InfoScale™ 9.0 Virtualization Guide - Linux
- Section I. Overview of InfoScale solutions used in Linux virtualization
- Overview of supported products and technologies
- Overview of the InfoScale Virtualization Guide
- About InfoScale support for Linux virtualization environments
- About KVM technology
- About InfoScale deployments in OpenShift Virtualization environments
- About InfoScale deployments in OpenStack environments
- Virtualization use cases addressed by InfoScale
- 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 InfoScale solutions
- InfoScale solutions configuration options for the kernel-based virtual machines environment
- Dynamic Multi-Pathing in the KVM guest virtualized machine
- DMP in the KVM host
- SF in the virtualized guest machine
- Enabling I/O fencing in KVM guests
- SFCFSHA in the KVM host
- DMP in the KVM host and guest virtual machine
- DMP in the KVM host and SFHA in the KVM guest virtual machine
- VCS in the KVM host
- VCS in the guest
- VCS in a cluster across virtual machine guests and physical machines
- Installing InfoScale in a KVM environment
- Installing and configuring VCS in a kernel-based virtual machine (KVM) environment
- Configuring KVM resources
- Getting started with basic KVM
- Section III. Implementing InfoScale an OpenStack environment
- Section IV. Implementing Linux virtualization use cases
- Application visibility and device discovery
- 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
- 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 Hyper-V environment
- Virtual to virtual clustering in an OVM environment
- Multi-tier business service support
- Managing Docker containers with InfoScale Enterprise
- About managing Docker containers with InfoScale Enterprise
- 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
- Section V. Reference
- Appendix A. Troubleshooting
- InfoScale logs for CFS configurations in OpenStack environments
- UDID mismatch in a CFS cluster in an OpenStack environment
- Troubleshooting virtual machine live migration
- 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
- Appendix B. Sample configurations
- Appendix C. Where to find more information
- Appendix A. Troubleshooting
VirtIO disk drives
VirtIO is an abstraction layer for paravirtualized hypervisors in Kernel-based Virtual Machine (VM) technology. Unlike full virtualization, VirtIO requires special paravirtualized drivers running in each VM guest. VirtIO provides support for many devices including network devices and block (disk) devices. Using VirtIO to export block devices to a host allows files, VxVM volumes, DMP meta-nodes, SCSI devices or any other type of block device residing on host to be presented to the VM guest. When SCSI devices are presented to a VM guest using VirtIO, in addition to simple reads and writes, SCSI commands such as SCSI inquiry commands can be performed allowing VxVM in the guest to perform deep device discovery. Running VxVM and DMP in the host and the VM guest provides for consistent naming of SCSI devices from the array, to the host through to the VM guest.
InfoScale 9.0 supports VirtIO SCSI devices and VirtIO block devices with Linux KVM. virtio-scsi is a new virtual SCSI HBA interface. It is the foundation of an alternative storage implementation for virtual machines, replacing virtio-blk on Red Hat Enterprise Linux (RHEL) with improved scalability and providing standard SCSI command set support.
VirtIO features:
Dynamically adding devices:
VirtIO disk devices can be both added and removed from a running VM guest dynamically, without the need of a reboot.
VirtIO limitations:
Disk caching:
When disks are exported to the VM guest with the cache enabled, the VxVM configuration changes may get cached on the KVM host and not be applied to the disks. When disks are shared between more than one VM guest, such a configuration change is not visble from other VM guest systems than the one which made the change. To avoid potential configuration conflict, caching the host must be disabled (cache=no) while exporting the disks.
SCSI Commands:
SCSI devices that are presented as VirtIO devices to a VM guest support a limited subset of the SCSI command set. The KVM hypervisor blocks the restricted commands.
PGR SCSI-3 Reservations:
PGR SCSI-3 reservations are not supported on VirtIO block devices. To use SCSI-3 PR operations inside the KVM guest operating system, Arctera recommends that you use virtio-scsi to export SCSI devices to the guest. This limitation is applicable to releases prior to RHEL 6.4.
DMP Fast Recovery with SCSI devices:
DMP Fast Recovery bypasses the normal VirtIO read/write mechanism, performing SCSI commands directly against the device. If DMP Fast Recovery is used within the VM guest, caching in the host must be disabled (cache=none), to avoid data integrity issues.
Thin Reclamation:
Thin reclamation is not supported on VirtIO devices. The 'WRITE-SAME' command is blocked by the hypervisor. This limitation may be removed in future releases of Linux.
Resizing devices:
Linux does not support online disk resizing of VirtIO devices. To re-size a VirtIO device the VM guest must be fully shut down and re-started. Support for online re-sizing of block devices is under evaluation for Linux.
Maximum number of devices:
virtio-blk currently has a per-guest limitation of 32 devices. This device limitation includes all VirtIO devices, such as network interfaces and block devices. The device limitation is a result of the current VirtIO implementation where each device acts as a separate PCI device. virtio-scsi solves this limitation by multiplexing numerous storage devices on a single controller. Each device on a virtio-scsi controller is represented as a logical unit, or LUN. The LUNs are grouped into targets. The device limit per target is much larger; each device can have a maximum of 256 targets per controller and 16,384 logical units per target. You can use virtio-scsi instead of virtio-blk to use more than 32(28) disk devices inside the KVM guest.
VxFS:
In a KVM environment under heavy I/O load, data corruption may occur on VxFS file systems created on LUNs attached as VirtIO block devices. Please refer Red Hat Support Case #00945974 for more details: