Skip to content
Merged
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
1 change: 1 addition & 0 deletions modules/con_virt-about-kubevirt-redfish.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -8,5 +8,6 @@

[role="_abstract"]
KubeVirt Redfish is a Redfish-compatible API that exposes virtual machines (VMs) managed by {VirtProductName} on {product-title}.

You can use the same Redfish automation patterns you use for physical baseboard management controllers (BMCs) to manage VM power and inventory.
The primary use case is deploying virtualized control plane clusters, where the control plane nodes run as VMs on an existing {VirtProductName} cluster.
4 changes: 2 additions & 2 deletions modules/virt-NUMA-topology-disabling-hotplugs.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,6 @@
= Disabling the hot plug capability for VMs

[role="_abstract"]
_Hot plugging_ is the ability to dynamically add resources such as memory or CPU to a VM while it is running. Default {VirtProductName} hot plug multipliers can cause VMs to request an excessive number of sockets. For example, if your VM requests 10 sockets, the default hot plug behavior multiplies this by 4, which means that the total request is 40 sockets. This can exceed the recommended CPUs supported by the Kernel-based Virtual Machine (KVM), which can cause deployment failures.

You can keep VM resource requests aligned with NUMA and optimize performance for resource-intensive workloads by disabling the VM's default hot plug capability.

_Hot plugging_ is the ability to dynamically add resources such as memory or CPU to a VM while it is running. Default {VirtProductName} hot plug multipliers can cause VMs to request an excessive number of sockets. For example, if your VM requests 10 sockets, the default hot plug behavior multiplies this by 4, which means that the total request is 40 sockets. This can exceed the recommended CPUs supported by the Kernel-based Virtual Machine (KVM), which can cause deployment failures.
2 changes: 1 addition & 1 deletion modules/virt-supported-ssp-tasks.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@
= Supported virtual machine tasks

[role="_abstract"]
The following table shows the supported tasks.
Automate virtual machine (VM) provisioning and management in your CI/CD workflows with {pipelines-shortname} tasks designed for virtualization. These tasks allow you to create, configure, and manipulate VMs and their disks as part of your automated deployment pipelines, streamlining VM lifecycle management.

.Supported virtual machine tasks
[cols="1,1",options="header"]
Expand Down
2 changes: 0 additions & 2 deletions virt/managing_vms/virt-managing-vms-openshift-pipelines.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -7,8 +7,6 @@ include::_attributes/common-attributes.adoc[]
toc::[]

[role="_abstract"]
Automate virtual machine (VM) provisioning and management in your CI/CD workflows with {pipelines-shortname} tasks designed for virtualization. These tasks allow you to create, configure, and manipulate VMs and their disks as part of your automated deployment pipelines, streamlining VM lifecycle management.

{pipelines-title} is a Kubernetes-native CI/CD framework that allows developers to design and run each step of the CI/CD pipeline in its own container.

By using {pipelines-shortname} tasks and the example pipeline, you can do the following:
Expand Down
8 changes: 6 additions & 2 deletions virt/vm_networking/virt-configuring-physical-networks.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,13 +2,17 @@
include::_attributes/common-attributes.adoc[]
[id="configuring-physical-networks"]
= Configuring physical networks

:context: configuring-physical-networks

toc::[]

[role="_abstract"]
As an OpenShift administrator, you can create or configure a physical network in the {product-title} web console without using the node network configuration policy (NNCP) page. The *Physical networks* page is available when the NMState console plugin is installed. When you use the *Physical networks* page in the web console, the NNCP is generated automatically. If you need more flexibility or require complex settings, use the NNCP page.
As an {product-title} administrator, you can create or configure a physical network in the {product-title} web console without using the node network configuration policy (NNCP) page.

[NOTE]
====
The *Physical networks* page is available when the NMState console plugin is installed. When you use the *Physical networks* page in the web console, the NNCP is generated automatically. If you need more flexibility or require complex settings, use the NNCP page.
====

include::modules/creating-a-physical-network.adoc[leveloffset=+1]
include::modules/expanding-a-physical-network.adoc[leveloffset=+1]
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ include::_attributes/common-attributes.adoc[]
toc::[]

[role="_abstract"]
You can connect a VM to an OVN-Kubernetes custom secondary overlay network. A layer 2 topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes Container Network Interface (CNI) plugin uses the Geneve (Generic Network Virtualization Encapsulation) protocol to create an overlay network between nodes. You can use this overlay network to connect VMs on different nodes, without configuring any additional physical networking infrastructure.
You can connect a virtual machine (VM) to an OVN-Kubernetes custom secondary overlay network. You can use this overlay network to connect VMs on different nodes, without configuring any additional physical networking infrastructure.

ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
[NOTE]
Expand All @@ -16,6 +16,8 @@ An OVN-Kubernetes secondary network is compatible with the multi-network policy
====
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]

A layer 2 topology connects workloads by a cluster-wide logical switch. The OVN-Kubernetes Container Network Interface (CNI) plugin uses the Geneve (Generic Network Virtualization Encapsulation) protocol to create an overlay network between nodes.

To configure an OVN-Kubernetes layer 2 secondary network and attach a VM to that network, perform the following steps:

. Define the secondary network
Expand Down
5 changes: 1 addition & 4 deletions virt/vm_networking/virt-hot-plugging-network-interfaces.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -7,13 +7,10 @@ include::_attributes/common-attributes.adoc[]
toc::[]

[role="_abstract"]
ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
You can add or remove secondary network interfaces without stopping your virtual machine (VM). {VirtProductName} supports hot plugging and hot unplugging for secondary interfaces that use bridge binding and the VirtIO device driver.
endif::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]


ifndef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[]
You can add or remove secondary network interfaces without stopping your virtual machine (VM). {VirtProductName} supports hot plugging and hot unplugging for secondary interfaces that use bridge binding and the VirtIO device driver. {VirtProductName} also supports hot plugging secondary interfaces that use SR-IOV binding. To hot plug or hot unplug a secondary interface, you must have permission to create and list `VirtualMachineInstanceMigration` objects.
{VirtProductName} also supports hot plugging secondary interfaces that use SR-IOV binding. To hot plug or hot unplug a secondary interface, you must have permission to create and list `VirtualMachineInstanceMigration` objects.

[NOTE]
====
Expand Down