Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 6 additions & 7 deletions modules/migrating-to-virt.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,6 @@
[id="migrating-to-virt_{context}"]
= Migrating to {VirtProductName}

[role="_abstract"]
To migrate virtual machines from an external provider such as {vmw-first}, {rh-openstack-first}, Red Hat Virtualization, or another {product-title} cluster, use the {mtv-first}. You can also migrate Open Virtual Appliance (OVA) files created by {vmw-full}.

[NOTE]
Expand All @@ -15,12 +14,12 @@ To migrate virtual machines from an external provider such as {vmw-first}, {rh-o
====

.Prerequisites
* The {mtv-full} Operator link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{mtv-version}/html/installing_and_using_the_migration_toolkit_for_virtualization/installing-the-operator_mtv#installing-the-operator_mtv[is installed].
* The {mtv-full} Operator is installed.

.Procedure

* link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{mtv-version}/html/installing_and_using_the_migration_toolkit_for_virtualization/migrating-vmware#adding-source-provider_vmware[Migrate virtual machines from {vmw-first}].
* link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{mtv-version}/html/installing_and_using_the_migration_toolkit_for_virtualization/migrating-osp_ostack#adding-source-provider_ostack[Migrate virtual machines from {rh-openstack-first}].
* link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{mtv-version}/html/installing_and_using_the_migration_toolkit_for_virtualization/migrating-rhv_rhv#adding-source-provider_rhv[Migrate virtual machines from Red Hat Virtualization].
* link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{mtv-version}/html/installing_and_using_the_migration_toolkit_for_virtualization/migrating-virt_cnv#adding-source-provider_cnv[Migrate virtual machines from {VirtProductName}].
* link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{mtv-version}/html/installing_and_using_the_migration_toolkit_for_virtualization/migrating-ova_ova#adding-source-provider_ova[Migrate virtual machines from OVA files created by {vmw-full}].
* Migrate virtual machines from {vmw-first}.
* Migrate virtual machines from {rh-openstack-first}.
* Migrate virtual machines from Red Hat Virtualization.
* Migrate virtual machines from {VirtProductName}.
* Migrate virtual machines from OVA files created by {vmw-full}.
2 changes: 1 addition & 1 deletion modules/virt-attaching-vm-secondary-network-cli.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -56,5 +56,5 @@ $ oc apply -f example-vm.yaml
+
[NOTE]
====
When running {VirtProductName} on {ibm-z-name} using OSA, RoCE, or HiperSockets interfaces, you must register the MAC address of the device. For more information, see link:https://www.ibm.com/docs/en/linux-on-systems?topic=choices-osa-interface-traffic-forwarding[OSA interface traffic forwarding] (IBM documentation).
When running {VirtProductName} on {ibm-z-name} using OSA, RoCE, or HiperSockets interfaces, you must register the MAC address of the device. For more information, see "OSA interface traffic forwarding" in the IBM documentation.
====
2 changes: 1 addition & 1 deletion modules/virt-creating-and-exposing-mediated-devices.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ As an administrator, you can create mediated devices and expose them to the clus
* You installed the {oc-first}.
* You enabled the Input-Output Memory Management Unit (IOMMU) driver.
* If your hardware vendor provides drivers, you installed them on the nodes where you want to create mediated devices.
** If you use NVIDIA cards, you link:https://docs.nvidia.com/datacenter/cloud-native/openshift/latest/openshift-virtualization.html[installed the NVIDIA GRID driver].
** If you use NVIDIA cards, you installed the NVIDIA GRID driver.

// [IMPORTANT]
// ====
Expand Down
2 changes: 1 addition & 1 deletion modules/virt-supported-custom-video-devices.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ Configuring a custom video device allows you to specify different video devices,
====
Custom video device support is a Technology Preview feature only. Technology Preview features are not supported with Red{nbsp}Hat production service level agreements (SLAs) and might not be functionally complete. Red{nbsp}Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red{nbsp}Hat Technology Preview features, see link:https://access.redhat.com/support/offerings/techpreview/[Technology Preview Features Support Scope].
For more information about the support scope of Red{nbsp}Hat Technology Preview features, see "Technology Preview Features Support Scope".
====

Using a custom video device provides several advantages:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ The `wasp-agent` component is deployed automatically if `memoryOvercommitPercent
====
Swap resources can be only assigned to virtual machine workloads (VM pods) of the `Burstable` Quality of Service (QoS) class. VM pods of the `Guaranteed` QoS class and pods of any QoS class that do not belong to VMs cannot swap resources.

For descriptions of QoS classes, see link:https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/[Configure Quality of Service for Pods] (Kubernetes documentation).
For descriptions of QoS classes, see "Configure Quality of Service for Pods" in the Kubernetes documentation.

Using `spec.domain.resources.requests.memory` in the VM manifest disables the memory overcommit configuration. Use `spec.domain.memory.guest` instead.
====
Expand Down
2 changes: 1 addition & 1 deletion modules/virt-virtio-limitations.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ Each VirtIO interface uses one of the limited Peripheral Connect Interface (PCI)

[NOTE]
====
The actual number of slots available for hot plugging also depends on the machine type. For example, the default PCI topology for the q35 machine type supports hot plugging one additional PCIe device. For more information on PCI topology and hot plug support, see the link:https://libvirt.org/pci-hotplug.html[libvirt documentation].
The actual number of slots available for hot plugging also depends on the machine type. For example, the default PCI topology for the q35 machine type supports hot plugging one additional PCIe device. For more information on PCI topology and hot plug support, see the libvirt documentation.
====

If you restart the VM after hot plugging an interface, that interface becomes part of the standard network interfaces.
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ include::modules/virt-NUMA-prereqs.adoc[leveloffset=+1]
[role="_abstract"]
VM owners can enable NUMA with `ComputeExclusive` (CX) instance types, which are specifically designed for high-performance, compute-intensive workloads, and are configured to use NUMA features.

For information about creating VMs using a CX instance type, see xref:../../../virt/creating_vm/virt-creating-vms-from-instance-types.adoc#virt-creating-vms-from-instance-types[Creating virtual machines from instance types].
For information about creating VMs using a CX instance type, see "Creating virtual machines from instance types".

include::modules/virt-numa-check-config.adoc[leveloffset=+1]

Expand All @@ -41,5 +41,8 @@ include::modules/virt-NUMA-limitations.adoc[leveloffset=+1]

include::modules/virt-NUMA-live-migration.adoc[leveloffset=+1]

[role="_additional-resources"]
== Additional resources
[id="additional-resources_{virt-NUMA-topology}"]
* xref:../../../virt/creating_vm/virt-creating-vms-from-instance-types.adoc#virt-creating-vms-from-instance-types[Creating virtual machines from instance types]
* xref:../../../scalability_and_performance/using-cpu-manager.adoc#using-cpu-manager_topology-manager-policies[Topology Manager policies]
Original file line number Diff line number Diff line change
Expand Up @@ -16,10 +16,17 @@ By default, the `queueCount` value, which is derived from the domain XML, is det
Enabling `virtio-net` multi-queue does not offer significant improvements when the number of vNICs in a guest instance is proportional to the number of vCPUs.
====

[id="known-limitations_{context}"]
[id="virt-about-multi-queue-_{context}"]
== Known limitations

* Message signaled interrupt (MSI) vectors are still consumed if `virtio-net` multi-queue is enabled in the host but not enabled in the guest operating system by the administrator.
* Each `virtio-net` queue consumes 64 KiB of kernel memory for the `vhost` driver.
* Starting a VM with more than 16 CPUs results in no connectivity if `networkInterfaceMultiqueue` is set to `true`. ("CNV-16107").

include::modules/virt-enabling-multi-queue.adoc[leveloffset=+1]

[role="_additional-resources"]
[id="additional-resources_{virt-about-multi-queue}"]
== Additional resources

* link:https://issues.redhat.com/browse/CNV-16107[CNV-16107]
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ toc::[]
[role="_abstract"]
In {VirtProductName}, compute resources assigned to virtual machines (VMs) are backed by either guaranteed CPUs or time-sliced CPU shares.

Guaranteed CPUs, also known as CPU reservation, dedicate CPU cores or threads to a specific workload, which makes them unavailable to any other workload. Assigning guaranteed CPUs to a VM ensures that the VM will have sole access to a reserved physical CPU. xref:../../../virt/managing_vms/advanced_vm_management/virt-dedicated-resources-vm.adoc#virt-dedicated-resources-vm[Enable dedicated resources for VMs] to use a guaranteed CPU.
Guaranteed CPUs, also known as CPU reservation, dedicate CPU cores or threads to a specific workload, which makes them unavailable to any other workload. Assigning guaranteed CPUs to a VM ensures that the VM will have sole access to a reserved physical CPU. Enable dedicated resources for VMs to use a guaranteed CPU.

Time-sliced CPUs dedicate a slice of time on a shared physical CPU to each workload. You can specify the size of the slice during VM creation, or when the VM is offline. By default, each vCPU receives 100 milliseconds, or 1/10 of a second, of physical CPU time.

Expand All @@ -28,4 +28,5 @@ include::modules/virt-setting-cpu-allocation-ratio.adoc[leveloffset=+1]
[role="_additional-resources"]
[id="additional-resources_{context}"]
== Additional resources
* xref:../../../virt/managing_vms/advanced_vm_management/virt-dedicated-resources-vm.adoc#virt-dedicated-resources-vm[Enable dedicated resources for VMs]
* link:https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/[Pod Quality of Service Classes]
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ You can use the NVIDIA GPU Operator to provision worker nodes for running GPU-ac

[NOTE]
====
The NVIDIA GPU Operator is supported only by NVIDIA. For more information, see link:https://access.redhat.com/solutions/5174941[Obtaining Support from NVIDIA] in the Red Hat Knowledgebase.
The NVIDIA GPU Operator is supported only by NVIDIA. For more information, see "Obtaining Support from NVIDIA" in the Red Hat Knowledgebase.
====

include::modules/about-using-gpu-operator.adoc[leveloffset=+2]
Expand Down Expand Up @@ -57,4 +57,5 @@ include::modules/virt-assigning-vgpu-vm-web.adoc[leveloffset=+2]
[role="_additional-resources"]
[id="additional-resources_{context}"]
== Additional resources
* link:https://access.redhat.com/solutions/5174941[Obtaining Support from NVIDIA]
* link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-troubleshooting-enabling_intel_vt_x_and_amd_v_virtualization_hardware_extensions_in_bios[Enabling Intel VT-X and AMD-V Virtualization Hardware Extensions in BIOS]
Original file line number Diff line number Diff line change
Expand Up @@ -21,11 +21,12 @@ endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]

You can configure remediating nodes by installing the Self Node Remediation Operator or the Fence Agents Remediation Operator from the software catalog and enabling machine health checks or node remediation checks.

For more information on remediation, fencing, and maintaining nodes, see the link:https://docs.redhat.com/en/documentation/workload_availability_for_red_hat_openshift/24.3[Workload Availability for Red Hat OpenShift] documentation.
For more information on remediation, fencing, and maintaining nodes, see the "Workload Availability for Red Hat OpenShift" documentation.

ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
[role="_additional-resources"]
[id="additional-resources_{context}"]
== Additional resources
* link:https://docs.redhat.com/en/documentation/workload_availability_for_red_hat_openshift/24.3[Workload Availability for Red Hat OpenShift]
* xref:../../../virt/nodes/virt-eviction-strategies.adoc#virt-delete-failed-node-vm-failover_virt-eviction-strategies[Delete a failed node to trigger virtual machine failover]
endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[]
39 changes: 29 additions & 10 deletions virt/managing_vms/virt-accessing-vm-ssh.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -10,21 +10,21 @@ toc::[]
[role="_abstract"]
You can use SSH to securely access your virtual machines (VMs) from the command line. To set up your SSH configuration, use one of the following methods:

* xref:../../virt/managing_vms/virt-accessing-vm-ssh.adoc#using-virtctl-ssh_virt-accessing-vm-ssh[`virtctl ssh` command]
* "`virtctl ssh` command"
+
You create an SSH key pair, add the public key to a VM, and connect to the VM by running the `virtctl ssh` command with the private key.
+
You can add public SSH keys to {op-system-base-full} 9 VMs at runtime or at first boot to VMs with guest operating systems that can be configured by using a cloud-init data source.

* xref:../../virt/managing_vms/virt-accessing-vm-ssh.adoc#virt-using-virtctl-port-forward-command_virt-accessing-vm-ssh[`virtctl port-forward` command]
* "`virtctl port-forward` command"
+
You add the `virtctl port-foward` command to your `.ssh/config` file and connect to the VM by using OpenSSH.

* xref:../../virt/managing_vms/virt-accessing-vm-ssh.adoc#using-services-ssh_virt-accessing-vm-ssh[Service]
* "Service"
+
You create a service, associate the service with the VM, and connect to the IP address and port exposed by the service.

* xref:../../virt/managing_vms/virt-accessing-vm-ssh.adoc#using-secondary-networks-ssh_virt-accessing-vm-ssh[Secondary network]
* "Secondary network"
+
You configure a secondary network, attach a virtual machine (VM) to the secondary network interface, and connect to the DHCP-allocated IP address.

Expand Down Expand Up @@ -125,7 +125,7 @@ include::modules/virt-creating-service-virtctl.adoc[leveloffset=+3]

.Next steps

After you create a service with `virtctl`, you must add `special: key` to the `spec.template.metadata.labels` stanza of the `VirtualMachine` manifest. See xref:../../virt/managing_vms/virt-accessing-vm-ssh.adoc#virt-creating-service-cli_virt-accessing-vm-ssh[Creating a service by using the command line].
After you create a service with `virtctl`, you must add `special: key` to the `spec.template.metadata.labels` stanza of the `VirtualMachine` manifest. See "Creating a service by using the command line".

include::modules/virt-creating-service-cli.adoc[leveloffset=+3]

Expand All @@ -141,16 +141,16 @@ You can configure a secondary network, attach a virtual machine (VM) to the seco
Secondary networks provide excellent performance because the traffic is not handled by the cluster network stack. However, the VMs are exposed directly to the secondary network and are not protected by firewalls. If a VM is compromised, an intruder could gain access to the secondary network. You must configure appropriate security within the operating system of the VM if you use this method.
====

See the link:https://access.redhat.com/articles/6994974#networking-multus[Multus] and link:https://access.redhat.com/articles/6994974#networking-sriov[SR-IOV] documentation in the link:https://access.redhat.com/articles/6994974[{VirtProductName} Tuning & Scaling Guide] for additional information about networking options.
See the "Multus" and "SR-IOV" documentation in the "{VirtProductName} Tuning & Scaling Guide" for additional information about networking options.

.Prerequisites

ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
* You configured a secondary network such as xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-connecting-vm-to-linux-bridge[Linux bridge] or xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#virt-connecting-vm-to-sriov[SR-IOV].
* You created a network attachment definition for a xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-creating-linux-bridge-nad-web_virt-connecting-vm-to-linux-bridge[Linux bridge network] or the SR-IOV Network Operator created a xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#nw-sriov-additional-network_virt-connecting-vm-to-sriov[network attachment definition] when you created an `SriovNetwork` object.
* You configured a secondary network such as "Linux bridge" or "SR-IOV".
* You created a network attachment definition for a "Linux bridge network" or the SR-IOV Network Operator created a "network attachment definition" when you created an `SriovNetwork` object.
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
* You configured a xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[secondary network].
* You configured a "secondary network".
* You created a network attachment definition.
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]

Expand All @@ -161,6 +161,25 @@ include::modules/virt-connecting-secondary-network-ssh.adoc[leveloffset=+2]
ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
[NOTE]
====
You can also xref:../../virt/vm_networking/virt-accessing-vm-secondary-network-fqdn.adoc#virt-accessing-vm-secondary-network-fqdn[access a VM attached to a secondary network interface by using the cluster FQDN].
You can also "access a VM attached to a secondary network interface by using the cluster FQDN".
====
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]

[role="_additional-resources"]
[id="additional-resources_{virt-accessing-vm-ssh}"]
== Additional resources

* xref:../../virt/managing_vms/virt-accessing-vm-ssh.adoc#using-virtctl-ssh_virt-accessing-vm-ssh[`virtctl ssh` command]
* xref:../../virt/managing_vms/virt-accessing-vm-ssh.adoc#virt-using-virtctl-port-forward-command_virt-accessing-vm-ssh[`virtctl port-forward` command]
* xref:../../virt/managing_vms/virt-accessing-vm-ssh.adoc#using-services-ssh_virt-accessing-vm-ssh[Service]
* xref:../../virt/managing_vms/virt-accessing-vm-ssh.adoc#using-secondary-networks-ssh_virt-accessing-vm-ssh[Secondary network]
* xref:../../virt/managing_vms/virt-accessing-vm-ssh.adoc#virt-creating-service-cli_virt-accessing-vm-ssh[Creating a service by using the command line]
* link:https://access.redhat.com/articles/6994974#networking-multus[Multus]
* link:https://access.redhat.com/articles/6994974#networking-sriov[SR-IOV]
* link:https://access.redhat.com/articles/6994974[{VirtProductName} Tuning & Scaling Guide]
* xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-connecting-vm-to-linux-bridge[Linux bridge]
* xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#virt-connecting-vm-to-sriov[SR-IOV]
* xref:../../virt/vm_networking/virt-connecting-vm-to-linux-bridge.adoc#virt-creating-linux-bridge-nad-web_virt-connecting-vm-to-linux-bridge[Linux bridge network]
* xref:../../virt/vm_networking/virt-connecting-vm-to-sriov.adoc#nw-sriov-additional-network_virt-connecting-vm-to-sriov[network attachment definition]
* xref:../../virt/vm_networking/virt-connecting-vm-to-ovn-secondary-network.adoc#virt-connecting-vm-to-ovn-secondary-network[secondary network]
* xref:../../virt/vm_networking/virt-accessing-vm-secondary-network-fqdn.adoc#virt-accessing-vm-secondary-network-fqdn[access a VM attached to a secondary network interface by using the cluster FQDN]
Loading