November 21, 2024

OLVM Engine Host Pre-requisites….

So let’s  understand the prerequisites that are needed for engine installation. Before I can install an engine, I should have a host machine that is preconfigured and installed with a minimal install of Oracle Linux 8.5 or it can be installed with Unbreakable Enterprise Kernel Release 6, Unbreakable Enterprise Kernel Release 7, or anything that is similar with Red Hat Compatible Kernel. So these are the basic prerequisites, or requirements you could say, for installing your Oracle Linux Virtualization Manager engine host, or engine machine. The other important thing is the processor. The processor is very much important. It should be 64-bit x86 CPU, with hardware virtualization support enabled in that particular machine. It should be supporting Intel VT-x or AMD-V. And these technologies are essential for effectively managing your virtual machine. There are other requirements like the memory, the disk space, and the network requirements, which we’ll be discussing as we go further in the module. And the other important thing that you should have is your Linux operating system should be enabled with the following channels, which are listed in the table. You should enable it with BaseOS Latest, AppStream, KVM AppStream, oVirt 44, which is for version 4.4, oVirt 44 Extras, and the Gluster AppStream. So these are the required channels that should be enabled on your Oracle Linux Virtualization Manager. And for configuring the VDSM on the host, the host should have one extra channel that should be enabled, which is called as UEKR7. So these are the prerequisites for installing your engine. And based on these prerequisites, you can continue installation. But again, there is something which is called as deployment sizes. So for different deployments, Oracle has categorized different sizes that you should follow as recommended from Oracle systems. So let’s try to see why do we require to have different deployment sizes and why does the deployment size matter. So when we talk about deployment size, the first thing that comes into picture is the resource allocation. So deployment size matters based on resource allocation. So matching the deployment size to your needs will make sure that you allocate resources efficiently– like, a small firm will avoid wasting money on excess hardware, while a large institution has the resources it needs for peak performance. So depending on the type of organization and type of deployments that you’re having, you will go for allocating the resources. Then we have got the next step, which is called performance optimization. So each development size helps optimize performance based on your workload. It can be a small deployment, which might focus on testing environments, or it can be a large deployment, which are geared towards high-demand applications for transaction processing or any kind of queryable data. So depending on that– depending on the performance requirements– you decide on the size, what is the deployment size you want to use. The other categorization that is important for deciding on deployment size is the scalability. That is, knowing your deployment size helps you plan for future growth. The next important point here is the cost management. The cost management will help you in choosing the right size, which helps you in managing the cost. So small deployments keep expenses low, which is avoiding unnecessary hardware and operational cost, while large deployments can justify the higher cost with the need for higher performance and reliability. So these are the four different characteristics that defines what is the best suited deployment size that I need to select on. As we go further in the slides, we’ll be discussing on what are the recommendations and what is the minimal requirement for these different deployment sizes. So if you look at the hardware requirements, Oracle has categorized hardware requirements based on the sizes. So based on the deployment sizes we have, we have categorized them into three different size allocation, like small. And then we have got large, and we have got the medium size. So we have got different deployment sizes– small deployment, medium deployment, and the large deployment. So small deployments are ideal for test environments or small businesses or departments within a large organization which wants to use the virtualization. So they provide a cost-effective solution for managing a limited number of virtual machines. Whereas, when we talk about the medium deployments, they are suitable for medium-sized businesses or large departments within organizations. The size, balance, cost and the performance will be defining the options or resources for the moderate number of virtual machines and the host. Then we have got the large deployments are designed for enterprise environments that can be actually used for deploying enterprise-level deployments or production-level deployments that can be configured by using these large deployments with extensive virtualization needs. So based on this, we have got different sets of hardware requirements. So you can decide what level of deployment you want to do– small, large, or medium deployment. Then, when we come down to the idea of each of these, let’s try to see where they are useful. Let’s talk about each individual hardware requirement and see where they are useful for us. We have got the small deployment. If you look at the small deployment– so this particular deployment is useful for setups with 1 to 5 KVM hosts and up to 50 virtual machines. You will need about 16 gigabytes of memory, with four virtual CPUs and 50 GB of disk space to configure it. So these are the recommendations for a small deployment. Minimum requirement is lesser than the recommended values. So we can see 64-bit two core CPUs, or you can say two core CPUs, 4 GB, and 25 GB, which is the local writable hard disk space. That is enough for minimum values for a small deployment. But recommended, or a good sizing recommendation, is to use four cores, 16 GB or greater memory space, and 50 GB or greater for local writable hard disk. Now, let’s try to see what is the importance of this particular small deployment. So imagine you’re running a small software development firm, with around 10 developers. They need a virtualized environment for testing their applications on different operating systems. A small deployment would be perfect. You might start with a three host, each powerful enough to run multiple virtual machines, and set up around 30 virtual machines for various testing environments. So this kind of scenario can be used as a choice for deploying a small deployment size. Now, let’s get into the next level, which is the medium level. In medium-level deployment, this is actually used for setups with five to 50 hosts. So it can accommodate from five hosts to 50 hosts, and it can take up to 50 to 500 virtual machines. And the requirements here are increased– eight core CPUs, 32 GB or greater available RAM, and 100 GB or greater for local writable disks. The importance of this is think about a medium-sized health care organization. They need a robust virtualization environment to handle patient data, various departmental applications. So a medium deployment would fit well. You might have 20 hosts spread across departments– if you’re having different departments– billing department, you’ve got patient records, you have got radiology department or X-ray departments– so you can have different connections spread across these departments. It can accommodate up to 500 virtual machines for different applications and services. So the medium can be used in these type of scenarios where the utilization is at a medium level. Let’s talk about the next deployment size, which is called a large deployment size. This is for setups with 50 to 200 host environments that can be connected to your virtual machine, with over 500 to around 2,000 virtual machines. And recommended is 64 GB or greater of available system RAM, with 16 cores or greater CPUs that should be allocated, and at least 200 GB of writable disk space. So this becomes your large deployment. And this is a recommendation from Oracle that, if you are using these options, then it is termed as a large deployment. Consider a large financial institution. They need a highly reliable and scalable virtualized environment for their trading platforms. So customer databases, internal service environments, a large deployment here might involve 100 hosts distributed across multiple data centers for redundancy and high availability architectures, supporting around, let’s say, 1,500 virtual machines, running various critical applications on those virtual machines. So this is actually the different deployment sizes and where you can utilize these different deployment sizes. So depending on your needs and requirements, you can decide on whether you want to go with a small deployment, a medium deployment, or a large deployment.

Continue reading...

OLVM Administration Consoles…..

In the world of Oracle Linux Virtualization Manager, three essential portals stand ready to assist you in every aspect of managing your virtual environment. They are the administration portal, VM portal, and the monitoring portal. Let us start with the administration portal. Let’s picture the administration portal as a nerve center of your virtual infrastructure. Accessible through any web browser, the administrators can wield the power tools to oversee, create, maintain every component of their virtual ecosystem. Within this portal, we can create and manage virtual infrastructures. From defining intricate network configurations, to managing storage domains, administrators have full control over the foundational elements that support their virtual environment. Installation and management of hosts. Whether it’s setting up new hosts or fine tuning existing ones, administrators can efficiently manage the entire life cycle of their host, ensuring they operate at peak performance. Creation and management of logical entities. By creating and managing data centers and clusters, administrators can organize resources effectively, optimizing the resource allocation, enhancing the scalability. Creation and management of virtual machines. From creation to fine tuning, administrators can manage every aspect of their virtual machines, tailoring them to meet the specific workload requirements. User and permission management. Ensuring secure access and proper delegation of responsibilities is crucial to the administration portal. Administrator can manage user accounts and permissions with ease, maintaining a robust security posture. Now let’s talk about the next portal, which is the VM portal. The VM portal is specially designed to cater to users who primarily engage with virtual machines within the Oracle Linux Virtualization Manager environment. It serves as a user friendly interface, offering a seamless experience for accessing virtual machines and conducting fundamental management tasks, like creating, editing, and removing virtual machines, or stopping, starting, and migrating virtual machines, all with minimal effort. Within the VM portal, users are greeted with a comprehensive overview of their virtual machines. This dashboard-like interface allows users to perform various actions, providing them with a holistic view and control over their virtualized assets. Users can initiate a range of operations, including starting, stopping, editing, configuring, and accessing detailed information about each virtual machine. The capabilities available to users within the VM portal are determined and managed by system administrators. Administrators have the authority to delegate additional administrative tasks to users based on the roles and responsibilities. These delegated tasks may encompass creating, modifying, or removing virtual machines, allowing users to customize their virtualized environments to meet specific requirements, managing virtual disks and network interfaces, enabling users to configure storage, networking and setting the networks according to their needs, leveraging snapshots to create in time backups of virtual machines, facilitating quick recovery and rollback to previous states in case of unforeseen issues. Furthermore, the VM portal will also facilitate direct connections to virtual machines through VNC clients. And these clients provide users with a familiar desktop-like environment, enhancing the user experience by enabling seamless interactions with their virtual machines. The choice of protocol can be VNC or Spice for connecting to a virtual machine, which can be determined by the administrators during the virtual machine creation process. Now let’s talk about the next type of portal, which is the monitoring portal. So the monitoring portal is a powerful tool with Oracle Linux Virtualization Manager that empowers administrators with comprehensive monitoring capabilities. With a suit of advanced tools and virtualization at their disposal, administrators can effectively monitor the health and performance of their virtualized infrastructure by closely tracking key metrics and swiftly identifying potential issues. Administrators can make informed decisions to optimize performance and reliability, ensuring smooth operations across the board. Furthermore, the Linux Virtualization Manager offers enhanced reporting and monitoring capabilities through seamless integration with Grafana, a leading open source analytics platform. This integration provides administrators with access to a wealth of insightful data stored in the engine data warehouse. With Grafana, administrators can create customized dashboards tailored to their specific monitoring needs. Now, these custom dashboards will act as centralized, offering a real time visibility into critical resources and performance metrics across the virtualized environment. Administrators can effortlessly track key indicators, for example, CPU utilization, memory usage, storage capacity, or network throughput, enabling proactive monitoring and rapid response to potential issues. The Grafana initiative interface and robust visualization tools allow administrators to craft dashboards that provide comprehensive insights at a glance, whether it’s monitoring the health of individual hosts, or tracking the performance of virtual machines, or even analyzing the trends over time. So with Grafana and Linux Virtualization Manager gets empowered for administrators to make data driven decisions and ensure optimal operations of their virtual infrastructure. The cockpit web interface, which is actually a valuable tool that empowers users to monitor the resources of a KVM host and perform various administrative tasks. Cockpit needs to be installed and activated separately to leverage its functionality. Once installed, users can use this cockpit web interface in multiple ways, and they can access these cockpit web interfaces through administration portal or by establishing a direct connection to the host. By utilizing the cockpit web interface, users can gain insight into crucial metrics such as CPU usage, memory utilization, disk space, and network activity of the KVM host. This gives the real time monitoring capability, which allows administrators to stay informed about the health and performance of their virtualized environment. The flexibility of accessing this cockpit web interface from either the administration portal or directly connecting to the host offers a user’s convenience and accessibility. Whether users prefer a centralized management approach through the administration portal or they can have a direct hands-on approach by connecting to the host, cockpit provides a seamless experience for monitoring and managing your KVM host in Oracle Linux Virtualization Manager. Now let’s come down to understanding the virtual machine consoles. So you’ve got two options for providing graphical consoles to your virtual machines. One is virtual network computing, which is also called as VNC, and the remote desktop protocol, which is the RDP. These consoles allow you to work and interact directly with your virtual machine, just as you would with your physical machines. Now, if you opt with VNC or the remote viewer, you can access the console using either the remote viewer application or the VNC client. To use a locally installed remote viewer application, you can install it via your package manager or download it from the Virtual Machine Manager. And for a browser based console clients, it is very much important that the certificate authorities should be copied or installed inside your browser. You can get the certificate authority certificate by navigating to your engines or host address with the certificate address, or you can download it from your administration portal login page. For RDP, which is remote desktop, it is available exclusively for Windows environment. To use RDP, you need to access virtual machines from windows machines with Microsoft Remote Desktop application installed. Additionally, you must set up remote sharing on the virtual machine and configure the firewall to allow remote desktop connections before connecting to a Windows virtual machine using RDP.

Continue reading...

OLVM Databases….

Let’s try to understand the databases provided inside Oracle Linux Virtualization Manager. There are two PostGreSQL databases in play. The first one named engine is created as part of the engine configuration process. And if you choose to install the ovirt_engine DWH package, a second database called ovirt_engine_history is created. The engine database is where the persistent information about the Oracle Linux Virtualization Manager environment is stored. This includes details about its configuration, current state, and performance metrics. It continuously collects historical configuration information and statistical metrics updating them every minute. On the other hand, the orvit_engine_history database serves as a management history database. It stores historical configuration information and statistical metrics for data centers, clusters, and hosts. This data can be accessed by any application that needs historical insights into your virtualization environment. Now, here is an interesting feature that is both history and engine databases can be run on a remote host. This helps reduce the load on the engine host enhancing performance and scalability. But remember, it’s essential note to remember that running these databases on remote host is currently in technology preview feature, meaning it’s still under development and may have limitations.

Continue reading...