InfoScale™ 9.0 Virtualization Guide - Linux
- Section I. Overview of InfoScale solutions used in Linux virtualization
- Overview of supported products and technologies
- About InfoScale support for Linux virtualization environments
- About KVM technology
- Overview of supported products and technologies
- Section II. Implementing a basic KVM environment
- Getting started with basic KVM
- InfoScale solutions configuration options for the kernel-based virtual machines 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
- 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 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
- Section V. Reference
- Appendix A. Troubleshooting
- Appendix B. Sample configurations
- Appendix C. Where to find more information
- Appendix A. Troubleshooting
How to implement physical to virtual migration (P2V)
Migrating data from a physical server to a virtualized guest, the LUNs are first physically connected to the host, and then the LUNs are mapped in KVM from the host to the guest.
This use case procedure is very similar to the server consolidation use case and the procedures are quite similar. Physical to virtual migration is the process used to achieve server consolidation.
This use case requires Storage Foundation HA or Storage Foundation Cluster File System HA in the KVM host and Storage Foundation in the KVM guest. For setup information:
See Installing InfoScale in a KVM environment.
The options are as follows:
If InfoScale products are installed on both the physical server and the virtual host, identifying the LUNs which need mapping is made easy. Once the LUNs are connected to the virtual host, 'vxdisk - o alldgs list' can be used to identify the devices in the disk group which require mapping.
If InfoScale products are not installed on the virtual host and the physical server is a Linux system, the devices which need mapping can be identified by using the device IDs on the physical server.
To implement physical to virtual migration with Storage Foundation in the host and guest (KVM-only)
- Find the Linux device IDs of the devices which need mapping.
# vxdg list diskgroup
- For each disk in the disk group:
# vxdmpadm getsubpaths dmpnodename=device # ls -al /dev/disk/by-id/* | grep subpath
If Storage Foundation is not installed on the host, before decommissioning the physical server, identify the LUNs which require mapping by using the devices serial numbers. The LUNs can be mapped to the guest using the persistent "by-path" device links.
To implement physical to virtual migration if Storage Foundation is not installed in the host (KVM-only)
- On the physical server, identify the LUNs which must be mapped on the KVM host using the udevadm command.
- Map the LUNs to the virtualization host.
The udev database can be used to identify the devices on the host which need to be mapped.
# udevadm info --export-db | grep '/dev/disk/by-path' | \ cut -d' ' -f4 /dev/disk/by-path/pci-0000:05:00.0-fc-0x5006016239a01884-lun-1 /dev/disk/by-path/pci-0000:05:00.0-fc-0x5006016239a01884-lun-2
Map the LUNs to the guest. As there are multiple paths in this example, the paths sym-link can be used to ensure consistent device mapping for all four paths.
# virsh attach-disk guest1 \ /dev/disk/by-path/pci-0000:05:00.0-fc-0x5006016239a01884-lun-1 \ vdb # virsh attach-disk guest1 \ /dev/disk/by-path/pci-0000:05:00.0-fc-0x5006016239a01884-lun-2 \ vdc
- Verify that the devices are correctly mapped to the guest. The configuration changes can be made persistent by redefining the guest.
# virsh dumpxml guest1 > /tmp/guest1.xml # virsh define /tmp/guest1.xm
To implement physical to virtual migration with Storage Foundation in the guest and host (KVM-only)
- Map the LUNs to the virtualization host.
- On the virtualization host, identify the devices which require mapping. For example, the devices with the disk group data_dg are mapped to guest1.
# vxdisk -o alldgs list |grep data_dg 3pardata0_1 auto:cdsdisk - (data_dg) online 3pardata0_2 auto:cdsdisk - (data_dg) online
- Map the devices to the guest.
# virsh attach-disk guest1 /dev/vx/dmp/3pardata0_1 vdb Disk attached successfully # virsh attach-disk guest1 /dev/vx/dmp/3pardata0_2 vdc Disk attached successfully
- In the guest, verify that all devices are correctly mapped and that the disk group is available.
# vxdisk scandisks # vxdisk -o alldgs list |grep data_dg 3pardata0_1 auto:cdsdisk - (data_dg) online 3pardata0_2 auto:cdsdisk - (data_dg) online
- In the virtualization host make the mapping persistent by redefining the guest:
# virsh dumpxml guest1 > /tmp/guest1.xml # virsh define /tmp/guest1.xml
To use an InfoScale Volume Manager (VxVM) volume as a boot device when configuring a new virtual machine
- Follow the recommended steps in your Linux virtualization documentation to install and boot a VM guest.
When requested to select managed or existing storage for the boot device, use the full path to the VxVM storage volume block device, for example /dev/vx/dsk/boot_dg/bootdisk-vol.
- If using the virt-install utility, enter the full path to the VxVM volume block device with the --disk parameter, for example, --disk path=/dev/vx/dsk/boot_dg/bootdisk-vol.