diff --git a/source/guides/coriolis-getting-started.md b/source/guides/coriolis-getting-started.md index e3832f1..5ad87eb 100644 --- a/source/guides/coriolis-getting-started.md +++ b/source/guides/coriolis-getting-started.md @@ -106,7 +106,7 @@ For further information, please check **[Coriolis Licensing](coriolis-license.md
  • Red Hat OpenShift VirtualizationRed Hat OpenShift Virtualization
  • Red Hat VirtualizationRed Hat Virtualization (legacy RHV)
  • StackITStackIT
    • -
  • SUSE VirtualizationSUSE Virtualization
    • +
  • SUSE VirtualizationSUSE Virtualization
  • SUSE Linux (KVM)SUSE Linux (KVM)
  • VMware vSphereVMware vSphere
  • Virtuozzo Hybrid InfrastructureVirtuozzo Hybrid Infrastructure (VHI)
    • @@ -188,7 +188,7 @@ For more information regarding each supported platform, please check the corresp
  • Nutanix AHV
  • StackIT
  • SUSE Virtualization
    • -
  • SUSE Linux (KVM)
    • +
  • SUSE Linux (KVM)
    • diff --git a/source/platforms/index.md b/source/platforms/index.md index f52a39f..760f02a 100644 --- a/source/platforms/index.md +++ b/source/platforms/index.md @@ -19,6 +19,7 @@ proxmox-as-a-destination-cloud microcloud-lxd-as-a-destination-cloud kubevirt-harvester-as-a-destination-cloud suse-linux-kvm-target-platform +suse-linux-kvm-sap-hana-target-platform stackit-as-a-source-cloud stackit-as-a-destination-cloud cloudstack-as-a-destination-cloud diff --git a/source/platforms/suse-linux-kvm-sap-hana-target-platform.md b/source/platforms/suse-linux-kvm-sap-hana-target-platform.md new file mode 100755 index 0000000..df4f592 --- /dev/null +++ b/source/platforms/suse-linux-kvm-sap-hana-target-platform.md @@ -0,0 +1,190 @@ +# SUSE Linux (KVM) as a destination cloud (SAP HANA SKU) + +SAP HANA workloads require a separate licensing model and endpoint, which +provide SAP HANA-specific configuration options needed to meet performance, +support, and compliance requirements. + +See the [**basic SKU documentation**](./suse-linux-kvm-target-platform.md) +before getting started. + +```{note} +The SAP HANA SKU may also be used for other instances that require advanced +features. +``` + +## Configuration options + +The SAP HANA endpoint uses the same `[libvirt_migration_provider]` section +as the [**basic SKU**](./suse-linux-kvm-target-platform.md#configuration-options). +The options below are the advanced settings from the SAP provider: huge pages, +NUMA pinning, guest clock and timers, vhostmd, raw disk passthrough, and +disk-controller passthrough. + +`hugepage_size`, `numa_node_count`, `allocate_entire_numa_nodes`, and +`enable_vhostmd` can also be set per transfer in the target environment. +When a transfer does not set them, they fall back to the values in this section. + +```ini +[libvirt_migration_provider] + +# Configure replica instances to use huge pages of the given size (KB). +# Note that the huge pages must be preallocated. The possible size depends +# on the host CPU architecture, 2MB and 1GB being the most common values on +# x86-64. If unset, the VMs will not use huge pages. The VM memory capacity +# must be a multiple of the hugepage size. +hugepage_size = 0 + +# The amount of NUMA nodes to use for the VM. If set to 0, no explicit NUMA +# topology will be defined. If set to a positive value, the VM CPUs and +# memory will be spread across the given number of host NUMA nodes, pinning +# VM CPUs to unused host CPUs. +numa_node_count = 0 + +# Allocate the specified amount of host NUMA nodes entirely to the VM, +# regardless of the number of source VM vCPUs. +allocate_entire_numa_nodes = false + +# Value for the Libvirt attribute. Set to 'none' to +# disable CPU compatibility checks, or 'partial' / 'full' as required by +# your environment. +cpu_check = none + +# A list of host CPUs that will not be used by pinned VM vCPUs. +# +# Contains comma separated ranges of CPUs in Libvirt format. +# +# Example: 1-4,^3,5 +# +# In this example, CPUs 1,2,4 and 5 will be reserved. +# reserved_cpus = + +# Number of memory pages to reserved per host NUMA node. +# +# Each entry will contain comma separated key:value pairs describing the +# NUMA node ID, the page size in KB and the number of reserved pages. +# +# Example: +# +# reserved_memory_pages = node:0,size:2048,count:64 +# reserved_memory_pages = node:0,size:4,count:10485760 +# reserved_memory_pages = node:1,size:1048576,count:2 +# reserved_memory_pages = node:1,size:4,count:10485760 +# +# In this example we're reserving 10GB of memory using standard 4K page +# size on both NUMA nodes, 2 GB of memory in 1GB pages on NUMA node 1 and +# 128MB of memory in 2MB pages on NUMA node 0. +# reserved_memory_pages = + +# Defines the NUMA scheduling strategy. If enabled, the scheduler will +# favor NUMA nodes that are more loaded. If disabled, we'll try to spread +# the resources across NUMA nodes, favoring nodes that are less loaded. +# pack_numa_nodes = false + +# Clock offset for replica VMs. Accepted values are 'utc' and 'localtime'. +# When unset (the default), the provider picks 'localtime' for Windows +# guests and 'utc' for all other OS types. +# clock_offset = + +# VM timer configuration. Each entry is a set of comma-separated key:value +# pairs describing one timer. Windows guests additionally get a hypervclock +# timer appended unless one is already listed. +# Example: +# cpu_timers = name:rtc,tickpolicy:catchup +# cpu_timers = name:pit,tickpolicy:delay +# cpu_timers = name:hpet,present:no +# cpu_timers = + +# Attach the vhostmd metrics image as a read-only block device to replica +# instances. This exposes KVM host metrics to workloads such as SAP HANA via +# the vm-dump-metrics utility. Requires vhostmd to be running on the Libvirt +# host and the metrics disk at vhostmd_device_path to exist. +enable_vhostmd = false + +# Path to the vhostmd metrics disk on the Libvirt host. The file disk in the +# domain XML will use this path as its source. Only used when enable_vhostmd +# is True. +vhostmd_device_path = /dev/shm/vhostmd0 + +# Specifies how pinned sibling CPUs should be defined in the Libvirt domain +# configuration. +# +# If sibling CPU floating is enabled, the VM vCPU will be allowed to float +# between sibling host CPUs. +# +# +# +# +# If sibling CPU floating is disabled, the VM vCPU will be pinned to a +# single host CPU. +# +# +# ` as parameter. diff --git a/source/platforms/suse-linux-kvm-target-platform.md b/source/platforms/suse-linux-kvm-target-platform.md index 8c628fe..f9dcd2b 100644 --- a/source/platforms/suse-linux-kvm-target-platform.md +++ b/source/platforms/suse-linux-kvm-target-platform.md @@ -11,7 +11,11 @@ When using SUSE Linux as a KVM-based virtualization platform, Coriolis integrate Coriolis connects to the libvirt service through **SSH**(TCP/22) on each SUSE Linux KVM host to perform the operations required during migration workflows. In this design, each SUSE Linux KVM host must expose a functional libvirt endpoint that Coriolis can reach and authenticate against. -**Note:** Migration to SUSE Linux on KVM applies to standard virtual machines only. SAP HANA workloads require a separate licensing model and endpoint, which provide SAP HANA-specific configuration options needed to meet performance, support, and compliance requirements. +```{note} Migration to SUSE Linux on KVM applies to standard virtual machines only. SAP HANA workloads require a separate licensing model and endpoint, which provide SAP HANA-specific configuration options needed to meet performance, support, and compliance requirements. + +See the [**SAP HANA SKU document**](./suse-linux-kvm-sap-hana-target-platform.md) +for more details. +``` ### Endpoint connection parameters @@ -197,3 +201,116 @@ sqlite_database_file = /opt/coriolis/libvirt_provider_db.sqlite # Attach a persistent TPM device to replica instances. add_tpm_device = true ``` + +## Libvirt host prerequisites + +### Storage pool + +The provider relies on Libvirt storage pools, allowing it to transparently use +a variety of storage backends: local directory, Ceph, LVM, etc. + +Note that the minion VM image is expected to reside in a "directory" +storage pool. To speed up minion VM deployments, the provider will create QCOW2 +images pointing to the specified image. + +Create a directory storage pool like so: + +```bash +pool_name=local-dir-pool +pool_path=/var/lib/libvirt/local-dir-pool + +sudo virsh pool-define-as \ + --name $pool_name \ + --type dir \ + --target $pool_path + +sudo mkdir -p $pool_path +sudo chown -R libvirt-qemu:kvm $pool_path +sudo chmod 755 $pool_path +sudo virsh pool-start $pool_name +sudo virsh pool-autostart $pool_name +``` + +Then copy the desired minion image to that directory. When initiating transfers, +the user will be prompted to select an image from that location. + +### Networks + +The minion VM network is expected to have DHCP enabled and be accessible from +the appliance side. + +This example uses the `br1` bridge, which must be pre-configured: + +```bash +cat > br1-network.xml < + br1-network + + + +EOF + +virsh net-define br1-network.xml +virsh net-start br1-network +virsh net-autostart br1-network +``` + +### SR-IOV + +The Libvirt Coriolis provider can assign SR-IOV VFs to replica instances. + +Follow this guide to configure a `hostdev` Libvirt network, which can then +be passed to Coriolis transfers. + +#### Host configuration + +First, enable SR-IOV and VT-d in the BIOS configuration. + +Then add the following to the list of kernel parameters to allow VM passthrough +devices: + +```text +intel_iommu=on iommu=pt +``` + +Some devices may not be mapped correctly and also require the following: + +```text +pci=realloc pci=assign-busses +``` + +Preallocate the desired number of VFs: + +```bash +echo 8 > /sys/class/net/p1p1/device/sriov_numvfs +``` + +To make the VFs persistent, consider using a Systemd service or Netplan +configuration, depending on the Linux distribution. + +#### Libvirt network + +Libvirt networks can be configured to expose SR-IOV VFs to the connected VMs. + +Set the forward mode to `hostdev` and enable `managed` mode to automatically +pick a VF. Then specify the desired PF to expose. + +```bash +cat > vfio-p1p1-network.xml < + vfio-p1p1 + + + + +EOF + +virsh net-define vfio-p1p1-network.xml +virsh net-start vfio-p1p1 +virsh net-autostart vfio-p1p1 +``` + +#### Guest configuration + +The migrated VM needs to include the according VF interface drivers, which +can be handled through user scripts during OS morphing.