 Hello. My name is John Her and I'm a senior software engineer at Red Hat. Today I'll be demonstrating how to easily install an OpenShift cluster on a single physical server. I will install a single node OpenShift cluster and the OpenShift virtualization operator. This operator will enable the ability to run virtual machines on this cluster. Before installing the cluster, I configure DNS to resolve four entries to the cluster and its domain. The four names I create are an entry for the server, I will use snow for the server name, api, api-int and a wildcard DNS entry for apps. For example, my cluster is called fern and it's on the example.org domain. I will call my hostname snow spelled sno so snow.fern.example.org resolves to an IP address that will be assigned by DHCP to the server. Also api.fern.example.org api-int.fern.example.org and the wildcard apps.fern.example.org all point to the same IP as the server. The wildcard matches any name followed by apps.fern.example.org and resolves it to the IP of the cluster. Configuring DHCP and DNS is out of scope of this video demonstration so please see the documentation for more information. I am using the assisted installer at cloud.redhat.com to easily install the cluster. I open cloud.redhat.com in a browser and log into the console. I then navigate to the OpenShift clusters. Once the page loads, I select assisted installer clusters from the kebab menu. Since I have no existing clusters, I am prompted to create one. I provide my cluster's name, fern, and set the base domain to example.org. The OpenShift version to install should automatically set to the latest version provided by the assisted installer. I select that I want to install a single node OpenShift cluster or snow for short. On the next screen, I select the box to instruct the installer to install OpenShift virtualization. Selecting this will save some steps after installation. As a note, when installing OpenShift virtualization, the assisted installer requires a second hard drive that will be used for storing virtual machine data. To add a physical host to the cluster, I select add host. There are two types of ISO images that can be created. A full image, this image contains everything needed during installation, and a minimal image. This image is a slimmed down version of the ISO, and the installer will download extra files during installation. I specify an SSH public key that I have already created. This is optional, but it allows me to SSH into the nodes in case of any issues during installation. The installer creates a discovery ISO. This image is used to discover the host and its features, and report them to the installer. After the ISO image is generated, it can be downloaded using a browser and the discovery ISO URL, or by using the WGIT command. Both of these are provided. The server has a management card that can mount an image that is provided by a web page as a virtual CD-ROM. So I will use the WGIT command to download the image to a local web server. Now the image is available and I can power on the server. I will use IPMI tool to power on the server remotely. The server boots the image. Please note, booting the server takes longer than what is shown here, as I am using the power of modern technology to fast forward through space and time to speed things up a little. Once the server is booted, the login screen shows the interface information. We can see the server has the correct IP address. A few minutes after booting, the server appears in the assisted installer console. This takes a few minutes while the discovery image is gathered information about the server. Once the server appears in the console, it will move from a discovering state to a ready state. Once the state is ready, the host can be selected and we can continue. The installer needs to know which discovered subnet the cluster will be using for connections. This cluster only has one subnet connected, so the choice is easy. The host shows that it fails validation and cannot be used. Clicking the link displays which validations fail. These particular validations are failing because the subnet was just selected and the discovery has not had time to gather the information. After a few minutes, these resolve and the state changes to ready. Please note, if the system did not have a second hard drive, it would show up as a failed validation since the assisted installer requires a second hard drive when installing OpenShift Virtualization. After the state changes to ready, the installation can begin. The next screen shows the information entered and the status of any validations. Since everything looks correct, the cluster can be installed. The next screen shows the installation progress. The installation will go through various stages before it completes. And again, we've been in space and time to make this go a bit faster. For reference, it took about 35 minutes for the system I am using to finish installing after this point. Once the status changes to installing, the screen will show the kubiconfig file is available to be downloaded. The file provided now is a kubiconfig file that does not allow Ingress into the cluster. At the end of the installation, a kubiconfig file will be available that allows Ingress connections into the cluster. During the installation, the server will reboot a few times. Once the status of the installation becomes finalizing, the correct kubiconfig file and the password for the kubiadmin user will become available. Both of these need to be saved. Exporting the kubiconfig variable to point to the kubiconfig file allows command line access into the cluster as the kubiadmin user. The cluster console can be logged into using the kubiadmin account and password. The URL for the console was available at the end of the assisted installer screen. Since the cluster uses self-signed certificates by default, the browser will prompt to trust the certificates. Looking at the installed operators tab shows the OpenShift virtualization operator is installed and the cluster is capable of running virtual machines. Storage classes are automatically created by the assisted installer, but none are set as the default storage class. Let's set the snow storage storage class to be default. This is done by adding the storage class dot kubernetes.io slash is-default-class annotation to the storage class and setting it to true. Once a default storage class is defined, boot source images for the virtual machine templates will start downloading. This will only populate with the images that are available and known to the cluster. It may take a few minutes for the process to start. After the boot source images are downloaded, creating a virtual machine is easy. Let's create a simple virtual machine using the Red Hat Enterprise Linux 8 template. We will create it in the default namespace and allow SSH to connect into the virtual machine by selecting the Expose SSH access checkbox. We can specify an SSH public key that will be placed inside the virtual machine. The virtual machine will only allow passwordless SSH access by default. If an SSH key is not specified, the VM can only be logged into using its console. Selecting remember authorized SSH key will save the key and it will be made available for any other VMs that are created by this user. Various customizations can be made to the virtual machine, but we will make only one. I usually like to create a password for the virtual machine that I can easily remember. This allows me to easily sign into the virtual machine's console if desired. If a password is not set, a random password is generated and can be found in the YAML file for the virtual machine. The virtual machine is being created and its disks are being provisioned. Once the virtual machine is provisioned and started, the console will become available. The SSH command used to connect to the virtual machine is provided on the virtual machine's details page. I added the option to specify my SSH identity file to the command. Please note that each virtual machine will have a specific port in the cluster for the SSH connection. We have now connected to the virtual machine from outside the cluster. I have included a few links to help you get started on your OpenShift virtualization journey. Please read the documentation for more information on the great capabilities of OpenShift virtualization. I hope you have enjoyed watching my short video demonstration as much as I have enjoyed creating it. You can see how easily it is to deploy a single node OpenShift cluster that can run both containers and virtual machines. Perfect for development or running in small locations.