December 2024

The rolling database upgrade is the way to reduce the downtime during the database upgrade. And you can perform rolling database upgrade with several different method, which include manual task or script, and you can also use DBMS_ROLLING package. When you perform rolling database upgrade using DBMS_ROLLING, it simplifies the overall database upgrade process, which include init, build, start, upgrade, switchover, and finish. So many of these steps can be simplified using DBMS_ROLLING package. Now suppose that you want to perform database rolling upgrade using this package and in the primary database, there is the Oracle GoldenGate capture process running. So whenever you perform transactions on the primary database, the GoldenGate capture continuously capture changes. And also you have a standby database. And this got to be physical standby database, eventually converted to transient logical standby database as part of a rolling database upgrade. So we’re going to upgrade transient logical standby database first. During the upgrade of transient logical standby database, users can connect to a primary database to continue to work. And the Oracle GoldenGate capture process also can be up and running without having any downtime. But as part of a switchover, so let’s say we already completed the upgrade operation for the transient logical standby database, so it’s time to switch over to be able to upgrade original primary database. The question is, how do you handle Oracle GoldenGate capture process? Prior to 23ai, you had to start and then you had to take care of the work of GoldenGate capture process that was running on primary manually. But with the Oracle Database 23ai, when we perform switchover operation, the replication of Oracle GoldenGate capture structure, that’s automatic as part of DBMS_ROLLING switchover. And also, in addition, it provide a support for an Application Continuity and also support for transient Application Continuity. So as you can see, when the roles are changed because of metadata, replication can be replicated to the transient logical standby database. The Oracle GoldenGate capture process also can be failover to the primary database, new primary database automatically. . We can use this feature for the database release upgrade and also for the complex maintenance tasks, and emergency apply of nonrolling patches.

In Oracle Database 23ai, the Oracle RAC two-stage rolling patch provides a framework where such patches that include data dictionary changes can be applied in a rolling fashion and enabled after the patch has been applied to the last instance without requiring downtime to apply a patch. This feature splits the patching operation between applying binary changes at the software level and SQL changes at the database level. During phase 1, patch is applied to all instances, but the fix is not enabled. When you look at the example in the slide, the example shows a full node RAC database, where 23.3.1 software version is installed across all four nodes. When you apply patches with Oracle RAC two-stage rolling patch strategy, we apply patch one node at a time. While patches are being applied in a node, all the other instances running in the remaining servers still can access the Oracle Database because patch will be applied. However, until patch is applied in the last node, the fix is not enabled, thus users can access the database. So we’re going to apply patch in the first node first. So users disconnected and user can reconnect to one of the three surviving and remaining servers. And once the patch is applied, the user can reconnect to database instance running on instance 1. And by doing so we can apply patches at software level in the second server and also third server and the first server. On completion of phase 1, fix is enabled through SQL statement. So we’re going to run alter system enable rac two_stage rolling update all. So before running this command, the binary that is activated is a 23.3.1 even after the patch is applied. But after you run all the system enable rac two_stage rolling update all, this is the time when the fix is enabled. So this software version is updated. So this feature helps to reduce the planned downtime. Reducing the need to take the database instance down also improves the performance as the workloads are not subject to rewarming the cache after instance restart. So this is a nice feature. The feature significantly reduces the number of nonrolling patches.

Local Rolling Database Maintenance. Starting with Oracle Database 23ai, you can apply rolling patches locally for Oracle Real Application Clusters and Oracle RAC One Node deployment. It’s very similar to single-server rolling database maintenance, but this feature is used for the multinode RAC environment. So let’s take a look at how it works. So let’s assume a two-node RAC database example. So we have host A and host B, and CDB1 instance running out of host A, CDC2 instance running out of host B. When we perform our place patching, we install the software in a new home and then we apply patch. Once patch operation is complete with the local rolling database maintenance, we can start new home from a new instance out of a new home, while the original instance is still running out of original home. So at one point, on host A, we’re going to have two instances, one from original home and the other instance out of a new home. Once everything is ready, services and instances, the services and sessions are moved to new instance running out of a new home. And once the sessions are moved, then the original instance is stopped. And same thing happened on host B. So we install the new version of the software or we install or patch the software in a new home and then start a new instance out of a new home, in this example, CDB2/4. And then sessions are moved to new home, the original instance is stopped. Local database maintenance provides uninterrupted database availability during maintenance activities such as patching for Oracle RAC and Oracle RAC One Node databases. This significantly improves the availability of your databases without causing extra workload on other cluster nodes. So let’s take a look at examples. First, you download Oracle Database installation image file and extract the image file into new Oracle home directory. And from the new Oracle home directory, start OUI and apply required release update. And then perform software installation. So it is installing the patched software in a new home. And then we’re going to run SRVCTL modify database command with a -localrolling option. This is to enable local rolling to create a new rec instance. So as soon as you run this command, new instances are created but stopped. For example, if you have a two-node rec database in the first node, the new instance is created but stopped. In the second node, a new instance is created but stopped. And then we’re going to transfer Oracle RAC and Oracle RAC One Node database and PDBs and services from the old Oracle home to the new Oracle home. And this is the step to start the instances out of a new home and then transfer services, the PDBs, the services to new instances and then stop original instances and that’s by SRVCTL transfer instance. And now you’re going to verify database configuration changes. And the output of a server control configure database command, it should show new instance names for the database.

Servers leaving or joining a cluster resulting a reconfiguration that is essentially a synchronization event to recover all the changes made by the failed instance. Oracle RAC has reduced the time, the sessions wait on this event during reconfiguration. In Oracle RAC 23ai, smart reconfiguration reduces the impact of a service disruption from both planned and unplanned operations, utilizing several features, such as Recovery Buddy and PDB and service isolation and smooth reconfiguration, resulting in a faster reconfiguration than previous releases. So we’re going to take a look at some of the features introduced in previous releases, and then we’re going to get into smooth reconfiguration that was introduced in 23ai. Let’s review global resource management.  One user makes a connection to one of the RAC instances, and user can submit SQL statement requesting a set of blocks. In order to catch database blocks, the buffers must be allocated and also master metadata must be allocated to be able to describe changes to those buffers. An internal algorithm is used to decide which instance should contain the master metadata structure for that entity. In our example, the master metadata structure are distributed across instance 1 and instance 2. During the instance startup, this information on the master metadata structure for the entity has persisted in the data dictionary and reused during instance startup. And also the global resources are managed for unplanned instance crash and also planned service relocation as well. Now, let’s review PDB and service isolation. Let’s assume, there are three PDBs– PDB1, PDB2, PDB3. PDB1 is running on instance 1 and PDB2 is running on instance 1, instance 2, and instance 3. And also PDB3, it is available in instance 2 and instance 3. So when you make any changes to PDB1, then the metadata structure owned by PDB1 is only available in instance 1. When you make any changes to PDB3, the master metadata structure for PDB3 will be distributed across the instances where PDB3 is up and running. In this example, in instance 2 and instance 3. So let’s take a look at RAC reconfiguration. The PDB in RAC embodiment is reconfigured only needed if PDB1 is open on instance 2 as an example. So, for example, originally, PDB1 was available on instance 1. When you start PDB1 even in instance 2, the master metadata is redistributed across instance 1 and instance 2. And also if CDB 2 goes up, then what will happen? All the PDBs that were running out of instance 2 are no longer available. So the master metadata that was kept in instance 2 must be redistributed across surviving instances, in this example, instance 1 and instance 2. And impact is isolated to the affected PDBs only if the PDB is unaffected when CDB instance crashes. And also PDB1 is open on instance 2, or fourth instance is brought up. So these cases, the impact is only isolated at the PDB level. The PDB and service isolation. This is a feature that is used for CDB, and this is an enhancement from the service-oriented buffer cache access. And this feature improves performance by reducing distributed lock manager operations for services not offered in all PDB instances. The next topic is Buddy Recovery for reconfiguration. The Recovery Buddy feature is a feature that reduces the waiting time during reconfiguration. In prior releases, Oracle RAC instances identified and recovered the changes made by the failed instance by reading the redo logs. So, for example, for instance 1, PDB1 goes down. In order to recover blocks, the heavily modified on PDB1, one of the surviving instances must access the redo log file owned by PROD 1 and then identify blocks to be recovered. So that’s in a physical I/O. And it is a time-consuming operation. With the Recovery Buddy feature, we can reduce this I/O because of in-memory log and also because of Recovery Buddy concept. So, for example, in the three-node direct database,  we actually assign the Buddy Recovery for each instance. For example, PDB1 is a Recovery Buddy of PROD 3, and also PROD 2 is a Recovery Buddy of a PROD 1, PROD 3 is a Recovery Buddy of PROD 2. So which means that when you make any changes to the blocks in instance 1, PROD 1, then changes will be captured directly in PROD 1 but also the same changes will be maintained in the Recovery Buddy memory. So in-memory log. And same thing– when you make any changes to PROD 2, this change will be maintained not only locally but also in the Buddy Recovery instance as well. So here’s an example. So we connect to instance 1 and request the blocks like this and then make changes. So we make changes like this. Now, when you make any changes to PROD 1, these changes are maintained in PROD 1 but also the same change is maintained in the Recovery Buddy instance. So if PROD 1 goes down, instead of having access to online redo log file owned by Prod 1, we can directly access to in-memory log preserved in the Recovery Buddy instance and then read it to identify blocks to be recovered. So once we identify blocks to be recovered and apply changes, then it recover. So this feature reduces the time required for reconfiguration. Smooth reconfiguration. Smooth reconfiguration of Oracle Real Application Clusters instance reduces brownout time during cluster reconfiguration. So here’s an example. Suppose that you run srvctl command to stop instance, in the previous version, as soon as you run srvctl stop instance command, your instance is just stopped. And also until the metadata that was kept in the stop instance is redistributed, your database was frozen for that amount of time until global resources are recovered. However, in 23ai, we changed the algorithm slightly. So you request a stop instance. However, instead of stopping instance immediately, we perform the resource remastering operation first. So we distribute the metadata before performing stopping of an instance. So after redistributing instance, then we’re going to actually shut down instance. So when you actually look at the differences between version 19c, for example, and then 23ai, we slightly change the order, and that reduced the time required for the cluster reconfiguration. So in 19c, as soon as you issue stop instance command, srvctl stop instance, your instance must be killed and stopped. And then the global resource must be remastered. So for a short amount of time, your database wasn’t able to perform any activities. However, in 23ai, when user requests the srvctl stop instance, instead of stopping an instance, we remaster the resource first. And then after the resources are remastered, then we could actually shut down instance. That reduces reconfiguration time. So this feature it distributes resource coordinator. So resource coordinator is same as the master resource, the owner, or the resource master. So same terminology. So we call it now resource coordinator, before shutting down instances for planned maintenance....

What is Oracle ASM scrubbing? Oracle ASM scrubbing is a feature that enhances availability and reliability by seeking out rarely accessed the data and fixing logical corruptions automatically. You can perform on-demand based scrubbing by using altered disk group scrub command. And you can run this command at ASM disk group level by running all the disk group and scrub option. And it is also possible to scrub at the disk level. The second command you see the scrub disk and the disk name to specify the disk– will be scanned to identify logical corruptions. And it’s also possible to scrub at the file level, like a third example. All the disk group data scrub file, and then this is to scrub the specified file. And we can also add additional options along with the scrub option. If you want to stop ongoing scrub operation, you can run all the disk group with a scrub stop option. And this feature was available prior to 23ai, so what you knew in 23ai. With the introduction of Oracle Database 23ai is now possible to scrub individual extents or a range of extent. Previously, ASM scrubbing was only available on file levels or disk level and disk group level. When compared to the scrubbing the entire file in 23ai, you can specify extent. You can scrub specific extent set to reduce scrubbing turnaround time. It improves the data availability and also minimizes the performance impact. It’s possible to perform the extent-based scrubbing by using same command alter disk group scrub, but with the additional option. So when you look at the first command all to disk group scrub file and block number 10 and count to three. So what it does is this command identifies block number 10. And from that, check the three blocks. So block number 10 and 11 and 12. And identify extent that contain data blocks and then scrub. So the extent-based scrubbing instead of scrubbing entire file, we can specify specific blocks. Then the command automatically identify extent that contain blocks you specified. So it will dramatically reduce the turnaround time. It will also possible to scrub multiple groups of a data blocks. So you can add a block and count the combination multiple times. So in the example, in the second bullet, we specify the block number 50 and count to 10 and block number 1,024 count to 70, meaning that identify block number 50 and then count 10 blocks from that. And then identify block number 1,024 and identify 70 blocks from the block number 1,024. And then once blocks are identified and check the extent that contain data blocks. So extent-based scrubbing will be performed based on those extent that contain blocks you specified. So it dramatically improves the performance.

Let’s take a look at cluster health to monitor enhancement in Oracle database 23ai. Autonomous Health Framework Repository is a repository that stores the information collected by various components such as Cluster Health Monitor, Cluster Health Advisor, Fleet Patching and Provisioning, and Oracle Clusterware. So all these components collect information and store that information in a repository and that is called the autonomous health framework repository. There is a changes to this repository, starting with the Oracle Database 23ai, the use of Grid Infrastructure Management Repository, which we used to call GIMR is de-supported. Instead in Oracle Database 23ai uses a directory on the local file system, and that is one change to this area. And let’s take a look at related information. So review of a cluster health monitor and cluster health advisor. And these are the components of a great infrastructure. When you look at cluster health monitor first– and this component persists the collected operating system metrics on their directory in Oracle base, which is a metric repository. And this repository is auto-managed on the local file system. And you can change the location and size of this repository. And also, know the view samples are continuously written to this repository, not in the GIMR, but the local file system-based the repository. And the data is saved in the JSON format. And historical data is auto-archived into hourly zip files and also archive the files are automatically purged once the default retention limit, which is the 200 megabyte is reached. So one thing that you have to know in 23ai GIMR is de-supported instead, local file system repository is used and that repository is auto-managed. Let’s take a look at another component, Cluster Health Advisor. And this component continuously monitor cluster nodes and RAC databases for performance and availability issues to provide early warnings of a problems before they become critical. You can think about this as an ADDM, ADDM in the database level. So it collects database information along with all the OS metrics information and analyze it and give you recommendations. Oracle Cluster Health Advisor support the monitoring of a two critical subsystems of Oracle Real Application Cluster. First, Oracle Database. Second, the database hosts the system. Now, especially in 23ai, CHA Cluster Health Monitoring, Cluster Health Advisor, it can monitor not only container database, but also pluggable database as well. So we can leverage the PDB level data as well to get better idea and better information. And all analysis in research and diagnostics, and corrective actions, and metric evidence, these are all stored in the file system-based repository. OK. So another new features in Oracle Database 23ai. Cluster Health Monitor introduces a new diagnostic feature that identifies critical component events that indicate pending or actual failures and also provide recommendations for corrective actions. For example, RDBMS or GIPC and CSS, and all the other components as well that running in the same cluster. You can the generate event that indicate any type of failures. And once event that describes failures created, and they can be sent over to Cluster Health Monitor. Prior to Oracle Database 23ai, CHM was responsible to collect information up to that point, especially OS metrics. In 23ai in addition to OS metrics, CHM also can receive the event sent by various component, like a RDBMS and also CSS, GIPC, and so on. And also in addition, CHM can work with the new component, which called the CHM diagnostic component. So it can ask a CHM diagnostic component to review event and then make a recommendations. And when possible, take action as well. And these are all the enhanced in the diagnostic area. So if something goes bad in the cluster and the cluster component can create event to describe this failure, CHM can receive this event and work with the cluster health to monitor diagnostic component to generate the recommendations. And when possible, to take action. So all in actions and recommendations stores in the file system-based repository. And also, admins are notified that through the component such as Oracle Trace File Analyzer. Improving robustness and reliability of Oracle Database hosting infrastructure is a critical business requirement for enterprises. This improved the ability to detect and correct at the first failure, and the self-healing autonomously delivers value by improving business continuity. So that’s a big improvement in 23ai. Now, let’s take a look at new Oracle cluster monitor command that is related to the new diagnostic component. The first command is the Oracle cluster monitor CHM diagnostic description. And this is to get a detailed description of all supported events and actions. And we can also run Oracle cluster monitor CHM diagnostic with a query option. This is the query of the CHM diagnostic event actions sent by various component and generate an HTML or text report. It’s also possible to run Oracle cluster monitor CHM diagnostic collect. And then you add additional options like a last 1.5 hours and then out directory. So where to create the output. So this is to collect all event actions data generated by CHM diagnostics into the specified output directory location.

Let’s talk about the networks. So use bond network interfaces with the OLVM. So OLVM supports bond network interfaces which enable the aggregation of multiple physical network interfaces into a single logical bond. And this aggregation enhances network reliability and throughput by providing redundancy and load balancing across bonded interfaces. It can also work with using VLANs to separate different traffic types. I can use virtual local area networks which are used in OLVM to segment and isolate different types of network traffic within the virtualized environments. The VLANs allow administrators to logically partition a physical network into multiple virtual networks, each identified by unique VLAN IDs. VLAN is assigned directly to the physical interface. And these VLANs can be directly assigned to a physical network interface. This means that administrators can configure VLAN tagging directly on the physical network interface cards, which are termed as NICs. Each VLAN tag interface can then handle traffic specific to its assigned VLAN, facilitating the network segmentation and management. So based on these network configurations, OLVM also works with something called as logical network. So each logical network is playing a critical role in ensuring efficient and secure operations of virtualized environments, like the management network is dedicated to handling communication between Oracle Linux Virtualization Manager and the hypervisor host. And this network is essential for tasks that are related to administration monitoring and maintenance. Then we have got one more logical network that is created, which is called the VM network. And this VM network is used for communication between virtual machines within the virtualized environments, like guest-to-guest communication or internet access, which provides VMs with access to external networks or internal services, which facilitates communication with internal services and resources. We’ve also got the next level of networks which are called as display networks, which is used for handling remote displays and graphical outputs from virtual machines. This network is particularly important for scenarios where graphical desktop environments or applications running inside VMs need to be accessed remotely, like using the remote desktop access, which enables administrators or users to connect to VM desktops or applications using remote desktop protocols, which is termed as RDPs for Windows, or virtual console access. It provides access to virtual machine consoles for management and troubleshooting purpose. We have also got networks which are related to migration. The migration network is a dedicated network to facilitate live migration of virtual machines between hypervisor host, without disrupting their operations. So it helps you in data transfers, live migration, and resource optimization. In the networks, when we create the resources, we also need to configure something called as MAC address. So MAC address can be defined by using something called as MAC address pools. The MAC address pool is actually defined inside your virtualized environments by defining specific ranges for each cluster. It ensures efficient allocation and utilization of MAC addresses and supports scalability across multiple clusters. And it facilitates network management practices that enhance overall system reliability and security. A MAC address pool is specified for each cluster. And MAC address pools are more efficient with memory allocations. The same MAC address pool can be used by shared multiple clusters, or you can use the same MAC address by multiple different clusters. And the MAC address pool assigns the next available MAC address to the allocation. When a VM is created within OLVM, the MAC address pool assigns the next available MAC address from the specified range for the particular cluster. This automate assignments ensures that each VM receives a unique MAC address without conflicts. If the MAC addresses, as we said, can be shared across multiple different clusters, the MAC address pool can be configured across multiple clusters. And this allows administrators to optimize MAC address allocation across different segments of their virtualized environments. Now let’s see how we can configure a MAC address. You can do that by getting into the administration menu of your administration portal and selecting MAC address pool. And then using this and selecting MAC address pool, you can go for adding the MAC address pool list. There’s a default MAC address pool that is pre-created for you. You can still add new MAC address pools. When you click on the Add MAC address pool, it opens the new MAC address pool where you’ll provide the name of the MAC address pool. You will allow the options of MAC address ranges. You specify the from range, the to range, defining the MAC address references, which will give you the calculated value of how many MAC addresses are generated for this particular pool. And then you can use this pool by multiple clusters to assign MAC addresses to the virtual machines.

Storage Pool Manager plays a crucial role in managing storage domains within a data center. It ensures metadata integrity and providing mechanisms for automatic failovers and prioritizations. The SPM enhances the reliability, performance, and manageability of the storage infrastructure. So let’s try to see what are the usage of the Storage Pool Manager. It is a role given to a host in the data center to manage its storage domains. It’s a central role in the storage management. The SPM is responsible for managing the storage domain within a data center. It handles all metadata operations for the storage domain, which ensures data consistency and integrity. The SPM role helps you in managing snapshots, handling virtual machine disk allocations, and performing storage-related administrative tasks. The manager moves the SPM role to a different host if the SPM host encounters problems accessing that storage. So there is a process of SPM failover mechanism that happens. There are automatic reassignment of the SPM role that occurs. So if the host that is currently assigned the SPM role encounters a issue, like it’s losing access to the storage or the OLVM manager will– is not able to identify that host that is existing or it’s lost the communication– so under that scenarios, the OLVM manager will automatically move the SPM role to another suitable host. And this failure mechanism ensures continuous availability and management of storage domains, reducing the risk of downtime due to storage access problems. Only one host can be the SPM in the data center at one time to ensure the metadata integrity. It is influenced by the SPM priority. So each host in the data center can be assigned an SPM priority, which influences the likelihood of that host being the selected member or selected host for the SPM role. The SPM priority is a configurable setting that you can do inside your host management. So for every host, you can set up the priority for that particular option. So SPM priority settings can be defined at the host. You can alter the host, and the likelihood of the host being assigned the SPM role depends on the priority setting that you have done to that particular host. And a host with high SPM priority will be assigned the SPM role before a host with a low SPM priority. In the next slide, we’ll be seeing about how to set up the priority of the SPM manually. So let’s try to get into setting the SPM priority. You’ll edit the host and the storage that you define. So you’ll go to the host, and you’ll edit your host. And the SPM properties or the SPM properties of the host, you can define the SPM priority settings. So SPM priority settings can be configured as low, high, or normal. So SPM priorities in Oracle Virtualization Manager will help you in defining different levels. So you have got the SPM priority levels that can be categorized to your host, which can be high priority, normal, low. Or I don’t want to include this host as a SPM role host, so I can set it as never. So these are the priorities, and these will help you in specifying which host will get the SPM role. The highest priority will always be having the SPM role assigned to them. We have also got VDSM, which is also termed as Virtual Desktop and Server Manager. In Virtual Desktop Server Manager, we have got the VDSM, which is a vital component, which actually bridges the gap between the OLVM engine and the physical virtual resources on the KVM host. So you can manage and monitor the physical resources by using the VDSM, and it’s actually helping you getting the critical statistics and logs. The VDSM ensures that smooth operations like high availability, optimized performance of the virtual environments, is carried on. So let’s try to see the Virtual Desktop. The Virtual Desktop and Server Manager service is actually acting like an agent on the host. So it manages and monitor your physical resources, and it manages and monitor your virtual machine running on the host. It is a daemon on the VM host and communicates with the engine to help you in managing and monitoring the physical resources, like it helps you in resource allocation. So VDSM is responsible for managing the physical resources of the host, including the CPU, memory, storage, and network interfaces. It makes sure that the resources are efficiently allocated to virtual machines as and when needed. It also does the hardware monitoring with the physical health of the hardware. Checking for issues such as overheating, hardware failures, or performance bottlenecks, this can help in maintaining the reliability and performance of the host. It also goes in for optimization, where it optimizes the use of physical resources by dynamically adjusting allocations based on the current load and requirements of the virtual machine. It manages and monitors the virtual machines running on the host. So it also implements the life cycle of your virtual manager or your virtual machine. So basically, it is trying to give you handling of the complete life cycle of the virtual machines on the host, like creating of the virtual machines, starting, stopping, pausing, and deleting the virtual machines. It gives you the performance monitoring of your virtual environments, like it monitors the performance of running VMs, collecting data on the CPU usage, memory consumptions, network activities. And this data can help you in identifying performance issues and optimizing your VM operations. It is also responsible for resource scheduling. It schedules VM operations to ensure optimal performance and resource utilization. It gathers statistics and collects logs. So basically, the VDSM gathers a wide range of statistics and metrics from both the host and the VMs. This includes the data related to performance, the statistics of the resource usage, and the operational metrics. It collects and manages the logs related to the host and VM operations, which are crucial for troubleshooting, auditing, and ensuring compliance and organizational policies. Now let’s get down to the virtual machines. So OLVM being based on the KVM hypervisor and leveraging the Oracle Linux distribution, it integrates virtualization capabilities with management features to streamline virtual machine deployments, management of virtual machines and performance optimizations of the virtual machines. The virtual machines can be created either for Linux or Windows operating systems. The OLVM allows you to create virtual machines running various flavors of Linux, leveraging Oracle Linux on other compatible distributions. It also helps you in creating Windows-based virtual machines with Windows operating system, providing flexibility for both Linux and Windows environments. It helps in cloning from templates, can be cloned from an existing template in the VM portal. So you can define a template, and you can clone multiple virtual machines using the template. It imports an Open Virtual Appliance file into your environment. It also helps you in importing the OVA files into and from your environments. And it also gives you the options to configure multiple instance types, where you’ve also got some default instance types that are pre-allocated and created with the installation.

Let’s try to understand the hosts in OLVM. We have got few major physical hosts that exist inside your Oracle Linux Virtualization Manager. The first one is the engine host. The engine host provides you with the administration tools. It’s a central management component and it runs the OLVM engine and it consists of interfaces for administering and for managing your virtual environments. The OLVM engine can be used for managing your clusters, host, storage, virtual machines, networking, and other aspects of the virtual infrastructure. And it provides the features related to different structures like reporting, enabling administrators to track performance and health of the virtual environments. So an engine by itself is a separate physical host on which you install the it engine utility, which is actually used for managing the complete virtualized environment. Then we have got the KVM host, which is capable of hosting virtual machines. The engine registers the KVM hosts which are actually capable of hosting your virtual machine. So virtual machine deployments and features or managing of these virtual machines all is done through your KVM host. It’s a physical machine which is actually hosted environment machine, which is registered with your engine. And OLVM can manage Multiple Oracle Linux KVM hosts. A single engine Can manage multiple hosts. As we have seen earlier, a single engine powered engine can manage multiple data centers. Each data center can have multiple clusters and, each cluster can have multiple hosts. So if you want to work with the host, these are the options which are available. So if you look at your administration portal page, you go to your compute, and inside the compute, you’ll select the host, and inside the host, you’ll get a list of available hosts that have been configured under that particular listing of your engine. So you can see all the host. And if you look at the table that describes the host available for you, it gives you the name of the host, the host name or the IP address, the cluster name to which it belongs, and the data center to which it belongs. And you can also view the virtual machines and the memory used by that particular host. So active virtual machines and the memory being utilized. Other than that, to manage the host, we need to select the host and go to the menu options or the buttons which are provided, like the New button to create a new host or register a new host, edit an existing host, installation like reinstall the host, host console to access the host console, Copy host networks, if we want to select the host networks and register it with some other host, I can use the copy host networks. The important button there is the management button. The management button helps you in managing the host, which gives you the options to convert your host into maintenance mode, get the options like activate the host if it’s inactive, refresh the capabilities to upgrade or update the information of the host, manage the power, that is power management, restart, stop, or start the host, you can go with accessing with SSH management, you can restart, stop, and you can select as SVM, you can convert this host to be a part of your storage pool management SVM role and then configure local storage. So if you want to configure a local storage on the KVM host. I can select the KVM host and make it as a local storage host. But the host should be in maintenance mode. So to manage the host, we have got the Manage button, to which we can manage multiple actions that can be performed on the host. Once you have created a new host or registered the host, you learn how to register a host in module number 4, where we’ll be talking about the host installation. So in chapter 4, you’ll be discussing on how to register the host. But once the host is registered, you get a detailed page of the host. The detailed page of the host describes multiple properties of the single host. So it gives you a number of virtual machines running over it. What are the network interfaces configured, what are the host devices, permissions, affinity labels, errata, and the events. It also gives you the commands to manage the host from the details page. So you have got the Edit button to edit your host, management button, installation button, and to access the host console. So these are the buttons, which are available for you to manage your host. Now coming down to the affinity label. Like last time, you have seen the affinity rules that we can configure in the cluster. Now we have also seen can configure affinity labels in the cluster, which can be used with the affinity rules. You can also have host affinity labels. Host affinity labels are used to influence the placement and behavior of virtual machines in relation to specific host within a cluster. These labels provide a way to group host together based on certain criteria and enforce policies that dictate how VMs interact with these groups. If I’m talking about the host affinity labels, they are custom tags. Affinity labels help in organizing and managing hosts more efficiently by creating logical grouping. It is basically used to enforce policies that define how VMs should interact with the host. It improves resource utilization and it supports high availability and fault tolerance if you have configured the affinity labels.