Procedure

1. Click the Help icon ? in the menu bar on the header of the OpenShift Container Platform web console.
2. Select Quick Starts. You can filter the list of tours by entering the keyword virtual in the Filter field.

1. Delete the HyperConverged CR.
2. Delete the OpenShift Virtualization Operator.
3. Delete the openshift-cnv namespace.
4. Delete the OpenShift Virtualization custom resource definitions (CRDs).

Procedure

1. Delete the HyperConverged custom resource:

   $ oc delete HyperConverged kubevirt-hyperconverged -n openshift-cnv

   Copy code to clipboard

2. Delete the OpenShift Virtualization Operator subscription:

   $ oc delete subscription hco-operatorhub -n openshift-cnv

   Copy code to clipboard

3. Delete the OpenShift Virtualization ClusterServiceVersion resource:

   $ oc delete csv -n openshift-cnv -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv

   Copy code to clipboard

4. Delete the OpenShift Virtualization namespace:

   $ oc delete namespace openshift-cnv

   Copy code to clipboard

5. List the OpenShift Virtualization custom resource definitions (CRDs) by running the oc delete crd command with the dry-run option:

   $ oc delete crd --dry-run=client -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv

   Copy code to clipboard

   Example output:

   customresourcedefinition.apiextensions.k8s.io "cdis.cdi.kubevirt.io" deleted (dry run)
   customresourcedefinition.apiextensions.k8s.io "hostpathprovisioners.hostpathprovisioner.kubevirt.io" deleted (dry run)
   customresourcedefinition.apiextensions.k8s.io "hyperconvergeds.hco.kubevirt.io" deleted (dry run)
   customresourcedefinition.apiextensions.k8s.io "kubevirts.kubevirt.io" deleted (dry run)
   customresourcedefinition.apiextensions.k8s.io "networkaddonsconfigs.networkaddonsoperator.network.kubevirt.io" deleted (dry run)
   customresourcedefinition.apiextensions.k8s.io "ssps.ssp.kubevirt.io" deleted (dry run)
   customresourcedefinition.apiextensions.k8s.io "tektontasks.tektontasks.kubevirt.io" deleted (dry run)

   Copy code to clipboard

6. Delete the CRDs by running the oc delete crd command without the dry-run option:

   $ oc delete crd -l operators.coreos.com/kubevirt-hyperconverged.openshift-cnv

   Copy code to clipboard

Procedure

1. Create a new virtual server instance in IBM Cloud at Content from cloud.ibm.com is not included.Virtual Server for Classic to be the Bastion server. This instance is used to run the installation and provide environment services.

2. Change the default properties of the new virtual server instance to the following values. Use the provided defaults for all other values.

   • Type of virtual server: Public
   • Operating system: CentOS
   • Your public SSH RSA key
3. Note the private VLAN and subnet the virtual server instance is assigned to at Content from cloud.ibm.com is not included.VLANs.

4. Provision 6 bare-metal nodes in IBM Cloud at Content from cloud.ibm.com is not included.Bare metal server provision. Use the following values when provisioning the nodes:

   • Domain: A subdomain you can add records to.
   • Quantity: 6
   • Location: The same location as the virtual server instance.
   • Storage disks: RAID 1
   • Network Interface: Private
   • Private VLAN: The same as noted for the virtual server instance.
5. Confirm all nodes are provisioned and ready at Content from cloud.ibm.com is not included.Device list.
6. Rename the control plane nodes to control0-<domain-name>, control1-<domain-name>, and control2-<domain-name>. Replace <domain-name> with the domain used when provisioning the nodes.
7. Rename the compute nodes to compute0-<domain-name>, compute1-<domain-name>, and compute2-<domain-name>. Replace <domain-name> with the domain used when provisioning the nodes.
8. Configure the Bastion virtual server instance as a default network gateway.

9. Configure DHCP by editing /etc/dhcp/dhcpd.conf on the Bastion virtual server instance. For example:

   # Set DNS name and DNS server's IP address or hostname
   option domain-name  <dns_domain_name>;
   option domain-name-servers  <dns_ip_addresses>;
   
   # Declare DHCP Server
   authoritative;
   
   # The default DHCP lease time
   default-lease-time <default_lease_value>;
   
   # Set the maximum lease time
   max-lease-time <max_lease_value>;
   
   # Set Network address, subnet mask and gateway
   
   subnet <subnet_ip_address> netmask <subnet_mask> {
     # Range of IP addresses to allocate
     range dynamic-bootp <dynamic_boot_lower_address> <dynamic_boot_upper_address>;
     # Provide broadcast address
     option broadcast-address <broadcast_ip_address>;
     # Set default gateway
     option routers <default_gateway_ip_address>;

   Copy code to clipboard

   where:

   <dns_domain_name>

   Specifies the default domain name for DNS clients.

   <dns_ip_addresses>

   Specifies a comma-separated list of DNS server IP addresses.

   <default_lease_value>

   Specifies the default number of seconds a client keeps an assigned address.

   <max_lease_value>

   Specifies the maximum number of seconds a client keeps an assigned address.

   <subnet_ip_address>

   Specifies the start of the subnet IP address range.

   <subnet_mask>

   Specifies the subnet mask of the subnet IP address range.

   <broad_ip_address>

   Specifies the broadcast IP address to use when to use sending a message to every device on the subnet.

   <default_gateway_ip_address>

   Specifies the default gateway of the subnet.

10. Restart DHCP on the Bastion virtual server instance:

    $ systemctl restart dhcpd

    Copy code to clipboard

11. Enable IP forwarding on the Bastion virtual server instance:

    $ sysctl -w net.ipv4.ip_forward=1

    Copy code to clipboard

12. Verify IP forwarding is enabled on the Bastion virtual server instance:

    $ sysctl -p /etc/sysctl.conf

    Copy code to clipboard

13. Restart the network service on the Bastion virtual server instance:

    $ service network restart

    Copy code to clipboard

14. Verify if firewalld is enabled on the Bastion virtual server instance:

    $ firewall-cmd --state

    Copy code to clipboard

15. If the firewalld service is not enabled on the Bastion virtual server instance, enable the service:

    $ systemctl enable firewalld

    Copy code to clipboard

16. Start the firewalld service:

    $ systemctl start firewalld

    Copy code to clipboard

17. Add network address translation (NAT) rules to the firewalld service:

    $ firewall-cmd --add-masquerade --permanent

    Copy code to clipboard

18. Restart the firewalld service:

    $ firewall-cmd --reload

    Copy code to clipboard

Procedure

1. Log in to the Assisted Installer service.

2. Create a new cluster. The new cluster has the following properties:

   • Cluster name: The name used to identify the cluster under the base domain.
   • Base domain: The domain used to provision the bare-metal nodes.
3. Click Next.
4. Click Generate Discovery ISO.
5. Provide your public SSH RSA key when prompted.
6. Copy and save the generated wget command for the ISO file. This will be used later to connect to the cluster nodes.

7. Install Samba server on the Bastion virtual server instance:

   $ dnf install samba

   Copy code to clipboard

8. Enable Samba server on the Bastion virtual server instance:

   $ systemctl enable smb --now

   Copy code to clipboard

9. Configure NAT rules for the Samba server:

   $ firewall-cmd --permanent --zone=FedoraWorkstation --add-service=samba
   $ firewall-cmd --reload

   Copy code to clipboard

10. Configure a root user password:

    $ sudo smbpasswd -a root

    Copy code to clipboard

11. Create a share directory:

    $ mkdir <share_directory>

    Copy code to clipboard

    Replace <share_directory> with the share directory name.

12. Navigate to the share directory and download the Assisted Installer ISO file using the generated wget command.

Procedure

1. Edit /etc/samba/smb.conf to use the following configuration:

   [global]
         log level = 3
             workgroup = SAMBA
             security = user
   
             passdb backend = tdbsam
   
             printing = cups
             printcap name = cups
             load printers = yes
             cups options = raw
   
         server min protocol = NT1
         ntlm auth = yes
   
   [share]
         comment = ISO Files
         path = /root/share
         browseable = yes
         public = no
         read only = no
         directory mode = 0555
         valid users = root

   Copy code to clipboard
   Note

   For a more detailed example of the smb.conf file, see the smb.conf.example file in the same directory.

2. Save the file.

3. Verify the new Samba configuration:

   $ testparm

   Copy code to clipboard

4. Restart the Samba service:

   $ systemctl restart smb

   Copy code to clipboard

5. Verify that the Samba service is running and active:

   $ systemctl status smb

   Copy code to clipboard

6. Configure SSL VPN access to IBM Cloud:

   1. Perform the procedure at Content from cloud.ibm.com is not included.Getting started with IBM Cloud Virtual Private Networking in the IBM Cloud documentation.
   2. Download and install the MotionPro SSL VPN client.

   3. Connect to the appropriate IBM Cloud endpoint:

      $ sudo MotionPro --host $<vpn_endpoint> --user $<vpn_username> --passwd $<vpn_password>

      Copy code to clipboard

      where:

      <vpn_endpoint>

      Specifies the appropriate SSL VPN endpoint.

      <vpn_username>

      Specifies the SSL VPN user name you configured.

      <vpn_password>

      Specifies the SSL VPN password you configured.

      Note

      Connecting to the IBM Cloud SSL VPN disconnects you from any open VPN connections.

Procedure

1. For each bare-metal server, perform the following tasks:

   1. Access the server using the IPMI console.

      Note

      The IP address and credentials for IPMI console access is available in the Remote management section for each server.

   2. Mount the Assisted Installer ISO file with the following attributes:

      • Virtual Media: CD-ROM Image
      • Share host: The private IP address of the Bastion server.
      • Path to image: The location of the Assisted Installer ISO file.
      • User: root
      • Password: The root user password you configured.
   3. Click Save and Mount.
   4. Verify the ISO mounted successfully.
   5. Restart the server by selecting Remote Control → Power Control → Reset Server → Perform Action.
2. Return to the Assisted Installer service.
3. Select the Install OpenShift Virtualization and Install OpenShift Data Foundation checkboxes in the Assisted Installer options.

4. Select a role for each host.

   Note

   The cluster consists of 3 control plane and 3 compute nodes.

5. Wait for the Assisted Installer interface to indicate each node is ready.
6. Click Next.
7. Select Cluster Managed Network.
8. Select the API VIP and Ingress VIP checkboxes to obtain them from DHCP or leave them unchecked to enter static values.
9. Click Install.

10. For each bare-metal server, perform the following tasks:

    1. Access the server using the IPMI console.

       Note

       The IP address and credentials for IPMI console access is available in the Remote management section for each server.

    2. Select Virtual Media → CD-Rom Image.
    3. Click Unmount.
    4. Select Remote Control → Power Control → Reset Server → Perform Action to restart the server.
11. Locate the Cluster Credentials section of the installation summary.

12. Perform the following tasks in the Cluster Credentials section:

    1. Download the kubeconfig file.
    2. Save the kubeadmin password.
13. Install haproxy on the Bastion virtual server instance.

14. Configure haproxy for your environment. The following is an example configuration:

    #---------------------------------------------------------------------
    # Example configuration for a possible web application.  See the
    # full configuration options online.
    #
    #   https://www.haproxy.org/download/1.8/doc/configuration.txt
    #
    #---------------------------------------------------------------------
    
    #---------------------------------------------------------------------
    # Global settings
    #---------------------------------------------------------------------
    global
      # to have these messages end up in /var/log/haproxy.log you will
      # need to:
      #
      # 1) configure syslog to accept network log events.  This is done
      # by adding the '-r' option to the SYSLOGD_OPTIONS in
      # /etc/sysconfig/syslog
      #
      # 2) configure local2 events to go to the /var/log/haproxy.log
      #   file. A line like the following can be added to
      #   /etc/sysconfig/syslog
      #
      # local2.*                    /var/log/haproxy.log
      #
      log       127.0.0.1 local2
    
      chroot    /var/lib/haproxy
      pidfile   /var/run/haproxy.pid
      maxconn   4000
      user      haproxy
      group     haproxy
      daemon
    
      # turn on stats unix socket
      stats socket /var/lib/haproxy/stats
    
      # utilize system-wide crypto-policies
      #ssl-default-bind-ciphers PROFILE=SYSTEM
      #ssl-default-server-ciphers PROFILE=SYSTEM
    
    #---------------------------------------------------------------------
    # common defaults that all the 'listen' and 'backend' sections will
    # use if not designated in their block
    #---------------------------------------------------------------------
    defaults
      mode                  tcp
      log                   global
      option                httplog
      option                dontlognull
      option http-server-close
      option forwardfor     except 127.0.0.0/8
      option                redispatch
      retries               3
      timeout http-request  10s
      timeout queue         1m
      timeout connect       10s
      timeout client        1m
      timeout server        1m
      timeout http-keep-alive 10s
      timeout check         10s
      maxconn               3000
    #---------------------------------------------------------------------
    # main frontend which proxys to the backends
    #---------------------------------------------------------------------
    
    frontend api
      bind <api_ip_address>:<api_port>
      default_backend controlplaneapi
    
    frontend apiinternal
      bind <apiinternal_ip_address>:<apiinternal_port>
      default_backend controlplaneapiinternal
    
    frontend secure
      bind <frontend_secure_ip_address>:<frontend_secure_port>
      default_backend secure
    
    frontend insecure
      bind <frontend_insecure_ip_address>:<frontend_insecure_port>
      default_backend insecure
    
    #---------------------------------------------------------------------
    # static backend
    #---------------------------------------------------------------------
    
    backend controlplaneapi
      balance source
      server api <controlplaneapi_ip_address>:<controlplaneapi_port> check
    
    backend controlplaneapiinternal
      balance source
      server api <controlplaneapiinternal_ip_address>:<controlplaneapiinternal_port> check
    
    backend secure
      balance source
      server ingress <backend_secure_ip_address>:<backend_secure_port> check
    
    backend insecure
      balance source
      server ingress <backend_insecure_ip_address>:<backend_insecure_port> check

    Copy code to clipboard

    where:

    <api_ip_address>:<api_port>

    Specifies the front end IP address and port used by the Kubernetes API server.

    <apiinternal_ip_address>:<apiinternal_port>

    Specifies the front end IP address and port used for internal cluster management.

    <frontend_secure_ip_address>:<frontend_secure_port>

    Specifies the front end IP address and port used for HTTPS traffic for hosted applications.

    <frontend_insecure_ip_address>:<frontend_insecure_port>

    Specifies the front end IP address and port used for HTTP traffic for hosted applications.

    <controlplaneapi_ip_address>:<controlplaneapi_port>

    Specifies the back end IP address and port used by the Kubernetes API server.

    <controlplaneapiinternal_ip_address>:<controlplaneapiinternal_port>

    Specifies the back end IP address and port used for internal cluster management.

    <backend_secure_ip_address>:<backend_secure_port>

    Specifies the back end IP address and port used for HTTPS traffic for hosted applications.

    <backend_insecure_ip_address>:<backend_insecure_port>

    Specifies the back end IP address and port used for HTTP traffic for hosted applications.

    Note

    Replace the example values with values applicable to your network configuration.

15. Save the haproxy configuration.

16. Configure two DNS Address records (A records) for the subdomain that are externally available over the Internet:

    <bastion_public_ip_address> api.<cluster_name>.<cluster_domain>
    <bastion_public_ip_address> *.apps..<cluster_name>.<cluster_domain>

    Copy code to clipboard

    where:

    <bastion_public_ip_address>

    Specifies the externally available IP address of the Bastion virtual server instance.

    <cluster_name>

    Specifies the name assigned to the cluster.

    <cluster_domain>

    Specifies the domain assigned to the cluster.

Verification

1. Perform the following tasks to verify cluster access using command line access:

   1. Set your environment with the kubeconfig file:

      $ export KUBECONFIG=<kubeconfig_file_path>

      Copy code to clipboard

      where:

      <kubeconfig_file_path>

      Specifies the path to the downloaded kubeconfig file.

   2. Check cluster node status:

      $ oc get nodes

      Copy code to clipboard
      Note

      The command output should show all nodes as Ready in the STATUS column and the ROLES column should show that control plane and compute nodes are present.

   3. Check the cluster version:

      $ oc get clusterversion

      Copy code to clipboard
      Note

      The command output should say Condition: Available.

2. Perform the following tasks to verify cluster access using the web console:

   1. Paste the access URL provided by Assisted Installer into your web browser.

      Note

      By default, clusters use self-signed certificates. This may cause your browser to display a message that says Connection not private or a similar warning. You can close this warning and continue.

   2. Navigate to the URL.
   3. Log in to the cluster with the username kubeadmin and the kubeadmin password provided in the Cluster Credentials section.

Procedure

1. Edit the object in your default editor by running the following command:

   $ oc edit <resource_type> <resource_name> -n openshift-cnv

   Copy code to clipboard
2. Save the file to apply the changes.

Procedure

1. Go to Virtualization → Overview.
2. On the Settings tab, click Cluster.
3. Expand General settings and SSH configuration.
4. Set SSH over LoadBalancer service to on.

Procedure

1. Configure the route to the external host by running the following command:

   $ oc create route reencrypt <route_name> -n openshift-cnv \
       --insecure-policy=Redirect \
       --hostname=<host_name_or_address> \
       --service=cdi-uploadproxy

   Copy code to clipboard

   where:

   <route_name>

   Specifies the name to assign to this custom route.

   <host_name_or_address>

   Specifies the fully qualified domain name or IP address of the external host providing image upload access.

2. Run the following command to annotate the route. This ensures that the correct Containerized Data Importer (CDI) CA certificate is injected when certificates are rotated:

   $ oc annotate route <route_name> -n openshift-cnv \
       operator.cdi.kubevirt.io/injectUploadProxyCert="true"

   Copy code to clipboard

   where:

   <route_name>

   Specifies the name of the route you created.

Procedure

1. In the OpenShift Container Platform web console, go to Virtualization → Checkups.
2. Go to the Self validation tab.
3. Click Run checkup.
4. Configure settings for the test that you want to run.
5. Optional: You can enable a dry run test by clicking Advanced settings and then toggling the Dry run button.

6. Click Run. The Self validation checkup details page is displayed.

   You can observe the self validation checkup running in real time. The test can take several hours to complete.

7. After the test is complete, you can view high-level results in the Self validation checkup details page, including the names of any failing tests.
8. Optional: You can download detailed results as a ZIP file by clicking Download results in the Self validation checkup details page.

Procedure

1. Edit the KubeletConfig CR to add the required cpuManagerPolicy and cpuManagerPolicyOptions configurations:

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   # ...
   cpuManagerPolicy: static
   cpuManagerPolicyOptions:
     full-pcpus-only: true
   kubeReserved:
     cpu: "1"
   # ...

   Copy code to clipboard
   • You must set the cpuManagerPolicy: static policy to enable exclusive CPU allocation. This setting is a prerequisite for configuring the cpuManagerPolicyOptions settings.
   • You must set the full-pcpus-only: true policy option so that the static CPU Manager policy only allocates full physical cores.
   • You must reserve 1 CPU for the system by setting cpu: "1" in the kubeReserved settings. This ensures that the cluster remains stable, by requiring that the system’s core functions always have access to the CPU that they need to work correctly.

2. Run the following command to apply the changes to the KubeletConfig CR:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

Verification

1. To verify the deployment of wasp-agent, run the following command:

   $ oc rollout status ds wasp-agent -n openshift-cnv

   Copy code to clipboard

   If the deployment is successful, the following message is displayed:

   Example output:

   daemon set "wasp-agent" successfully rolled out

   Copy code to clipboard

2. To verify that swap is correctly provisioned, complete the following steps:

   1. View a list of worker nodes by running the following command:

      $ oc get nodes -l node-role.kubernetes.io/worker

      Copy code to clipboard

   2. Select a node from the list and display its memory usage by running the following command:

      $ oc debug node/<selected_node> -- free -m

      Copy code to clipboard

      Replace <selected_node> with the node name.

      If swap is provisioned, an amount greater than zero is displayed in the Swap: row.

      Table 5.2. Example output

      	total	used	free	shared	buff/cache	available
      Mem:	31846	23155	1044	6014	14483	8690
      Swap:	8191	2337	5854

3. Verify the OpenShift Virtualization memory overcommitment configuration by running the following command:

   $ oc -n openshift-cnv get HyperConverged/kubevirt-hyperconverged -o jsonpath='{.spec.higherWorkloadDensity}{"\n"}'

   Copy code to clipboard

   Example output:

   {"memoryOvercommitPercentage":150}

   Copy code to clipboard

   The returned value must match the value you had previously configured.

Procedure

1. Revert the memory overcommitment configuration by running the following command:

   $ oc -n openshift-cnv patch HyperConverged/kubevirt-hyperconverged \
     --type='json' \
     -p='[{"op": "remove", "path": "/spec/higherWorkloadDensity"}]'

   Copy code to clipboard

2. Delete the MachineConfig that provisions swap memory by running the following command:

   $ oc delete machineconfig 90-worker-swap

   Copy code to clipboard

Procedure

1. Open the HyperConverged CR by running the following command:

   $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv

   Copy code to clipboard

2. Edit the spec.certConfig fields as shown in the following example. To avoid overloading the system, ensure that all values are greater than or equal to 10 minutes. Express all values as strings that comply with the Content from golang.org is not included.golang ParseDuration format.

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
     namespace: openshift-cnv
   spec:
     certConfig:
       ca:
         duration: 48h0m0s
         renewBefore: 24h0m0s
       server:
         duration: 24h0m0s
         renewBefore: 12h0m0s

   Copy code to clipboard
   • The value of ca.renewBefore must be less than or equal to the value of ca.duration.
   • The value of server.duration must be less than or equal to the value of ca.duration.
   • The value of server.renewBefore must be less than or equal to the value of server.duration.

3. Apply updates to the HyperConverged CR by running the following command:

   $ oc apply -f <filename>.yaml

   Copy code to clipboard

   For example:

   $ oc apply -f kubevirt-hyperconverged.yaml

   Copy code to clipboard

Procedure

1. Run the following command:

   $ oc get csv -n openshift-cnv

   Copy code to clipboard

2. Review the output, checking the PHASE field. For example:

   VERSION  REPLACES                                        PHASE
   4.9.0    kubevirt-hyperconverged-operator.v4.8.2         Installing
   4.9.0    kubevirt-hyperconverged-operator.v4.9.0         Replacing

   Copy code to clipboard

3. Optional: Monitor the aggregated status of all OpenShift Virtualization component conditions by running the following command:

   $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv \
     -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'

   Copy code to clipboard

   A successful upgrade results in the following output:

   ReconcileComplete  True  Reconcile completed successfully
   Available          True  Reconcile completed successfully
   Progressing        False Reconcile completed successfully
   Degraded           False Reconcile completed successfully
   Upgradeable        True  Reconcile completed successfully

   Copy code to clipboard

Procedure

1. In the web console, navigate to Virtualization → Catalog.

   The InstanceTypes tab opens by default.

   Note

   When configuring a downward-metrics device on an IBM Z® system that uses a VM preference, set the spec.preference.name value to rhel.9.s390x or another available preference with the format *.s390x.

2. Heterogeneous clusters only: To filter the bootable volumes using the options provided, click Architecture.

3. Select either of the following options:

   • Select a suitable bootable volume from the list. If the list is truncated, click the Show all button to display the entire list.

     Note

     The bootable volume table lists only those volumes in the openshift-virtualization-os-images namespace that have the instancetype.kubevirt.io/default-preference label.

     • Optional: Click the star icon to designate a bootable volume as a favorite. Starred bootable volumes appear first in the volume list.

   • Click Add volume to upload a new volume or to use an existing persistent volume claim (PVC), a volume snapshot, or a containerDisk volume. Click Save.

     Logos of operating systems that are not available in the cluster are shown at the bottom of the list. You can add a volume for the required operating system by clicking the Add volume link.

     In addition, there is a link to the Create a Windows bootable volume quick start. The same link appears in a popover if you hover the pointer over the question mark icon next to the Select volume to boot from line.

     Immediately after you install the environment or when the environment is disconnected, the list of volumes to boot from is empty. In that case, three operating system logos are displayed: Windows, RHEL, and Linux. You can add a new volume that meets your requirements by clicking the Add volume button.

4. Click an instance type tile and select the resource size appropriate for your workload. You can select huge pages for Red Hat-provided instance types of the M and CX series. Huge page options are identified by names that end with 1gi.

5. Optional: Choose the virtual machine details, including the VM’s name, that apply to the volume you are booting from:

   • For a Linux-based volume, follow these steps to configure SSH:

     1. If you have not already added a public SSH key to your project, click the edit icon beside Authorized SSH key in the VirtualMachine details section.

     2. Select one of the following options:

        • Use existing: Select a secret from the secrets list.

        • Add new: Follow these steps:

          1. Browse to the public SSH key file or paste the file in the key field.
          2. Enter the secret name.
          3. Optional: Select Automatically apply this key to any new VirtualMachine you create in this project.
     3. Click Save.

   • For a Windows volume, follow either of these set of steps to configure sysprep options:

     • If you have not already added sysprep options for the Windows volume, follow these steps:

       1. Click the edit icon beside Sysprep in the VirtualMachine details section.
       2. Add the Autoattend.xml answer file.
       3. Add the Unattend.xml answer file.
       4. Click Save.

     • If you want to use existing sysprep options for the Windows volume, follow these steps:

       1. Click Attach existing sysprep.
       2. Enter the name of the existing sysprep Unattend.xml answer file.
       3. Click Save.

6. Optional: If you are creating a Windows VM, you can mount a Windows driver disk:

   1. Click the Customize VirtualMachine button.
   2. On the VirtualMachine details page, click Storage.
   3. Select the Mount Windows drivers disk checkbox.
7. Optional: Click View YAML & CLI to view the YAML file. Click CLI to view the CLI commands. You can also download or copy either the YAML file contents or the CLI commands.
8. Click Create VirtualMachine.