Announcing the Harvester v1.2.0 Release

Tuesday, 19 September, 2023

Ten months have elapsed since we launched Harvester v1.1 back in October of last year. Harvester has since become an integral part of the Rancher platform, experiencing substantial growth within the community while gathering valuable user feedback along the way.

Our dedicated team has been hard at work incorporating this feedback into our development process, and today, I am thrilled to introduce Harvester v1.2.0!

With this latest release, Harvester v1.2.0 expands its capabilities, providing a comprehensive infrastructure solution for your on-premises workloads. Whether you are managing virtual machines (VMs), cloud-native workloads, or anything in between, Harvester offers a unified interface that delivers unmatched flexibility in the market.

Let’s dive into some of the standout features accompanying the Harvester v1.2.0 release:

BareMetal Cloud Native Workload Support (Experimental)

From the outset, our vision centred on supporting users in their on-premises Kubernetes deployments. Although Harvester initially focused on virtualization technology, we swiftly recognized the evolving landscape where Kubernetes and its ecosystem were driving the commoditization of virtualization.

This realization prompted us to pivot our mission toward developing HCI software that both streamlines traditional virtual machine management whilst empowers users to accelerate their journey towards a modern cloud-native infrastructure. To achieve this, we enhanced Harvester’s capabilities, ensuring robust support for Kubernetes clusters running on VMs created by Harvester, complete with built-in CSI and Cloud Provider integration.

Our community embraced this direction, as it effectively addressed critical Kubernetes challenges like resource isolation and multi-tenancy. However, as Harvester’s popularity soared, we began receiving requests to support Kubernetes operations in edge locations. In these scenarios, small teams often manage local clusters, emphasizing minimal overhead and the seamless coexistence of container workloads alongside virtual machines. Many environments hosting specialized VM workloads sought the possibility of running container workloads directly on the Harvester host or bare-metal cluster.

After careful consideration, we realized this concept deviated slightly from our original target. Nevertheless, thanks to Kubernetes’ foundational role in Harvester, we found a way to extend our scope and accommodate these demands.

With the introduction of Harvester v1.2.0, we proudly unveil the BareMetal Cloud-Native Workload Support feature. Initially launched as an experimental offering, this feature empowers Harvester v1.2.0 to collaborate seamlessly with Rancher v2.7.6 and later versions, enabling direct container workload operations on the Harvester host (bare metal) cluster. You can learn more about activating this feature in our Harvester documentation.

Once enabled, users can effortlessly integrate Harvester host clusters with other Kubernetes clusters, facilitating seamless interaction between deployed container workloads and Harvester’s virtual machine workloads. Please be aware that there are currently some limitations which we’ve detailed here.

Image 1: Feature flag enabled in Rancher UI

Rancher Manager vcluster Add-On (Experimental)

Since the inception of Harvester the need to integrate with Rancher Manager for users was evident. There was no need to duplicate features like authentication, authorization, or CI/CD, as Rancher Manager already excelled in these areas. Additionally, Rancher Manager’s expertise in multi-cluster management could efficiently oversee multiple Harvester clusters.

However, a new challenge arose: we needed to accomodate users who didn’t require a centrally managed Rancher server. Some users managed operations across different sites and teams and had no interest in a unified Rancher server overseeing all Harvester clusters, while others still needed Rancher Manager’s functionalities.

The current Harvester iteration includes an embedded Rancher Manager for internal cluster management, prompting the Harvester engineering team to explore how to maximize its use. After collaborative consultations with the Rancher engineering team, it became evident that deploying workloads on the local cluster would not be feasible due to the Harvester BareMetal cluster’s role as the local cluster for the embedded Rancher.

As a solution, we turned to a relatively new open-source initiative called vcluster to facilitate Rancher Manager’s deployment on top of the Harvester host cluster. There are two advantages created for users with this solution. Firstly there is the reduced overhead and improvement in operational efficiency when compared to traditional booting the workload as a virtual machine, and secondly the deployment experience mirrors that of a Helm chart commonly aligned with cloud-native container workloads.

The Rancher Manager add-on operates on top of the Harvester cluster and has the potential to govern it. It grants full access within the Rancher Manager add-on essentially gives administrative rights over both the Harvester cluster and Rancher Manager. Operators can now take this utility consolidation into consideration when defining roles and permissions within Rancher Manager.

You can enable the Rancher Manager cluster add-on here.

Image 2: Rancher vcluster add on in Harvester

Image 3: Rancher Manager integrated with Harvester clusters

Third-Party Storage for Non-Root Disks in Harvester

Harvester, as HCI software, prioritizes storage as a core element. However, we’ve noticed that many customers already have central storage appliances in their data centers. They appreciate Harvester but find it challenging to retrofit their existing servers with SSD/NVMe drives without fully utilizing their storage appliances. This has been a significant concern for our customers.

The good news is that Harvester’s Kubernetes foundation allows us to support alternative storage solutions, provided they are Kubernetes-compatible through the Container Storage Interface (CSI).

With Harvester 1.2.0, users can now seamlessly integrate their own CSI drivers with their storage appliances, as detailed here. We are actively collaborating with multiple storage vendors for certification, so stay tuned for upcoming announcements!

It’s important to note that, currently, third-party storage support is limited to non-root disks, typically those not originating from images. This limitation exists because Harvester still relies on Longhorn for VM image management, which enables essential features like image uploads and quick VM creation from existing images, enhancing the overall Harvester user experience. Our future steps involve exploring ways to integrate Longhorn with storage appliances for image management.

Enhanced Cloud Provider and Load Balancer Support

From the outset, we recognized the importance of load balancing in Harvester. Many virtualization providers lacked the ability to seamlessly integrate load balancing within the Kubernetes Cloud Provider driver. We believed that this feature would greatly benefit users, even in on-premises deployments. Consequently, we integrated a Cloud Provider driver into Harvester’s guest clusters from the beginning.

Over the past year, we’ve received substantial feedback on our initial Cloud Provider implementation. Two primary requirements stood out: users wanted load balancing services customized for each guest cluster, rather than a Harvester-wide IP pool, and they also desired load balancing services for their VMs.

Harvester 1.2.0 introduces our new load balancing service, offering users the ability to:

  • Designate IP pools for each guest cluster network (pending confirmation for those using VLAN networks).
  • Configure Load Balancer-as-a-Service for their VMs, enabling integration with multiple LB providers.

To delve into the details of this service and learn how to deploy it, visit this link. Additionally, please review the backward compatibility notice before proceeding with the upgrade of your Kubernetes cluster.

Hardware Management – Out of Band IPMI Integration and Error Detection

As Harvester operates directly on bare metal servers, comprehensive server management is crucial. Operators require real-time insights into hardware functionality, immediate alerts for potential hardware errors, and advanced notification if a disk replacement is needed in the near future.

In version 1.2.0, we’re introducing an enhanced bare metal hardware management feature. We’ve integrated out-of-band connection for Harvester to IPMI endpoint servers, enabling Harvester to directly retrieve hardware error information and promptly notify administrators. Additionally, in this release, Harvester gains node lifecycle management capabilities.

To enable this feature, please refer to the instructions provided here.

Furthermore, Harvester v1.2.0 brings several highly requested features:

  • New Installation Method: We’ve introduced a streamlined installation process for users working with bare metal cloud providers, detailed here.
  • SRIOV VF Support: Enhance network performance with SRIOV VF support, described here.
  • Footprint Reduction Options: Users can now choose to enable or disable logging and monitoring components to customize their Harvester installation, as outlined here.
  • Increased Pod Limitation: We’ve increased the pod limitation for Harvester nodes to 200, allowing better utilization of computing resources provided by bare metal servers.
  • Emulated TPM 2.0: Improved support for Windows virtual machines with added Emulated TPM 2.0 support.

We invite you to start exploring and using Harvester v1.2.0. You can share your feedback with us through our Slack channel or GitHub.

Note: If you’re using USB for installation, please follow the instructions here and use the USB-specific ISO for Harvester v1.2.0 installation.

Harvester 1.1.0: The Latest Hyperconverged Infrastructure Solution

Wednesday, 26 October, 2022

The Harvester team is pleased to announce the next release of our open source hyperconverged infrastructure product. For those unfamiliar with how Harvester works, I invite you to check out this blog from our 1.0 launch that explains it further. This next version of Harvester adds several new and important features to help our users get more value out of Harvester. It reflects the efforts of many people, both at SUSE and in the open source community, who have contributed to the product thus far. Let’s dive into some of the key features.  

GPU and PCI device pass-through 

The GPU and PCI device pass-through experimental features are some of the most requested features this year and are officially live. These features enable Harvester users to run applications in VMs that need to take advantage of PCI devices on the physical host. Most notably, GPUs are an ever-increasing use case to support the growing demand for Machine Learning, Artificial Intelligence and analytics workloads. Our users have learned that both container and VM workloads need to access GPUs to power their businesses. This feature also can support a variety of other use cases that need PCI; for instance, SR-IOV-enabled Network Interface Cards can expose virtual functions as PCI devices, which Harvester can then attach to VMs. In the future, we plan to extend this function to support advanced forms of device passthrough, such as vGPU technologies.  

VM Import Operator  

Many Harvester users maintain other HCI solutions with a various array of VM workloads. And for some of these use cases, they want to migrate these VMs to Harvester. To make this process easier, we created the VM Import Operator, which automates the migration of VMs from existing HCI to Harvester. It currently supports two popular flavors: OpenStack and VMware vSphere. The operator will connect to either of those systems and copy the virtual disk data for each VM to Harvester’s datastore. Then it will translate the metadata that configures the VM to the comparable settings in Harvester.   

Storage network 

Harvester runs on various hardware profiles, some clusters being more compute-optimized and others optimized for storage performance. In the case of workloads needing high-performance storage, one way to increase efficiency is to dedicate a network to storage replication. For this reason, we created the Storage Network feature. A dedicated storage network removes I/O contention between workload traffic (pod-to-pod communication, VM-to-VM, etc.) and the storage traffic, which is latency sensitive. Additionally, higher capacity network interfaces can be procured for storage, such as 40 or 100 GB Ethernet.  

Storage tiering  

When supporting workloads requiring different types of storage, it is important to be able to define classes or tiers of storage that a user can choose from when provisioning a VM. Tiers can be labeled with convenient terms such as “fast” or “archival” to make them user-friendly. In turn, the administrator can then map those storage tiers to specific disks on the bare metal system. Both node and disk label selectors define the mapping, so a user can specify a unique combination of nodes and disks on those nodes that should be used to back a storage tier. Some of our Harvester users want to use this feature to utilize slower magnetic storage technologies for parts of the application where IOPS is not a concern and low-cost storage is preferred.

In summary, the past year has been an important chapter in the evolution of Harvester. As we look to the future, we expect to see more features and enhancements in store. Harvester plans to have two feature releases next year, allowing for a more rapid iteration of the ideas in our roadmap. You can download the latest version of Harvester on Github. Please continue to share your feedback with us through our community slack or your SUSE account representative.  

Learn more

Download our FREE eBook6 Reasons Why Harvester Accelerates IT Modernization Initiatives. This eBook identifies the top drivers of IT modernization, outlines an IT modernization framework and introduces Harvester, an open, interoperable hyperconverged infrastructure (HCI) solution.

Managing Harvester with Terraform 

Thursday, 22 September, 2022

Today, automation and configuration management tools are critical for operation teams in IT. Infrastructure as Code (IaC) is the way to go for both Kubernetes and more traditional infrastructure. IaC mixes the great capabilities of these tools with the excellent control and flexibility that git offers to developers. In such a landscape, tools like Ansible, Salt, or Terraform become a facilitator for operations teams since they can manage cloud native infrastructure and traditional infrastructure using the IaC paradigm. 

Harvester is an HCI solution based on Linux, KubeVirt, Kubernetes and Longhorn. It mixes the cloud native and traditional infrastructure worlds, providing virtualization inside Kubernetes, which eases the integration of containerized workloads and VMs. Harvester can benefit from IaC using tools like Terraform or, since it is based in Kubernetes, using methodologies such as GitOps with solutions like Fleet or ArgoCD. In this post, we will focus on the Terraform provider for Harvester and how to manage Harvester with Terraform.  

If you are unfamiliar with Harvester and want to know the basics of setting up a lab, read this blog post: Getting Hands-on with Harvester HCI. 

Environment setup 

To help you follow this post, I built a code repository on GitHub where you can find all that is needed to start using the Harvester Terraform provider. Let’s start with what’s required: a Harvester cluster and a KubeConfig file, along with a Terraform CLI installed on your computer, and finally, a git CLI. In the git repo, you can find all the links and information needed to install all the software and the steps to start using it. 

Code repository structure and contents 

When your environment is ready, it is time to review the repository structure and its contents and review why we created it that way and how to use it. 


Fig. 1 – Directory structure 

The first file you should check is It contains the Harvester provider definition, which version we want to use and the required parameters. It also describes the Terraform version needed for the provider to work correctly. 


Fig. 2 – 

The file is also where you should provide the local path to the KubeConfig file you use to access Harvester. Please note that the release of the Harvester module might have changed over time; check the module documentation first and update it accordingly. In case you don’t know how to obtain the KubeConfig, you can download it easily from the UI in Harvester.  


Fig. 3 – Download Harvester KubeConfig 

At this point, I suggest checking the Harvester Terraform git repo and reviewing the example files before continuing. Part of the code you are going to find below comes from there.  

The rest of the .tf files we are using could be merged into one single file since Terraform will parse them together. However, having separate files, or even folders, for all the different actions or components to be created is a good practice. It makes it easier to understand what Terraform will create. 

The files and terraform.tfvars are present in git as an example in case you want to develop or create your own repo and keep working with Terraform and Harvester. Most of the variables defined contain default values, so feel free to stick to them or provide your own in the tfvars file. 

The following image shows all the files in my local repo and the ones Terraform created. I suggest rechecking the .gitignore file now that you understand better what to exclude. 


Fig. 4 – Terraform repo files 

The Terraform code 

We first need an image or an ISO to provision a VM, which the VM will use as a base. In, we will set up the code to download an image for the VM and in we’ll define the parameter values; in this case, an openSUSE cloud-init ready image in qcow2 format. 


Fig. 5 – and 

Now it’s time to check, which defines a standard Harvester network without further configuration. As I already had networks created in my Harvester lab, I’ll use a data block to reference the existing network; if a new network is needed, a resource block can be used instead. 


Fig. 6 – and 

This is starting to look like something, isn’t it? But the most important part is still missing… Let’s analyze the file 

There we define the VM that we want to create on Harvester and all that is needed to use the VM. In this case, we will also use cloud-init to perform the initial OS configuration, setting up some users and modifying the default user password. 

Let’s review file content. The first code block we find starts calling the harvester_virtualmachine function from the Terraform module. Using this function, we assign a name to this concrete instantiation as openSUSE-dev and define the name and tags for the VM we want to provision. 


Fig. 7 – VM name 

Note the depends_on block at the beginning of the virtual machine resource definition. As we have defined our image to be downloaded, that process may take some time. With that block, we instruct Terraform to put the VM creation on hold until the OS Image is downloaded and added to the Images Catalog within Harvester. 

Right after this block, you can find the basic definition for the VM, like CPU, memory and hostname. Following it, we can see the definition of the network interface inside the VM and the network it should connect to. 



Fig. 8 –CPU, memory, network definition and network variables 

In the network_name parameter, we see how we call the module and the network defined in the file. Please, remember that Harvester is based in KubeVirt and runs in Kubernetes, so all the standard namespace isolation rules apply here and that’s why a namespace attribute is needed for all the objects we’ll be creating (images, VMs, networks, etc.)

Now it’s time for storage. We define two disks, one for the OS image and one for empty storage. In the first one, we will use the image depicted in, and in the second one, we will create a standard virtio disk. 



Fig. 9 – VM disks and disk variables 

These disks will end up being Persistent Volumes in the Kubernetes cluster deployed inside a Storage Class defined in Longhorn. 


Fig. 10 – Cloud-init configuration 

Lastly, we find a cloud-init definition that will perform configurations in the OS once the VM is booted. There’s nothing new in this last block; it’s a standard cloud-init configuration. 

The VM creation process 

Once all the setup of the .tf files is done, it is time to run the Terraform commands. Remember to be in the path where all the files have been created before executing the commands. In case you are new to Terraform like I was, it is a good idea to investigate the documentation or go through the tutorials on the Hashicorp website before starting this step.  

The first command is terraform init. This command will check the dependencies defined in, download the necessary modules and review the syntaxis of the .tf files. If you receive no errors, you can continue creating an execution plan. The plan will be compared to the actual situation and to previous states, if any, to ensure that only the missing pieces compared with what we defined in the .tf files are created or modified as needed. Terraform, like other tools, use an idempotent approach, so we want to reach a concrete state.  

My advice for creating the execution plan is to use the command terraform plan -out FILENAME so the plan will be recorded in that file, and you can review it. At this point, nothing has been created or modified yet. When the plan is ready, the last command will be terraform apply FILENAME; FILENAME is the plan file previously created. This command will start making all the changes defined in the plan. In this case, it downloads the OS image and then creates the VM. 


Fig. 11 – Image download process 


Fig. 12 – VM starting 

Remember that I used an existing network, otherwise, creating a network resource would have been necessary. We wait for a couple of minutes, and voila! Our VM is up and running. 


Fig. 13 – VM details 

In the picture above, we can see that the VM is running and has an IP, the CPU and memory are as we defined and the OS image is the one specified in the file. Also, the VM has the tag defined in and a label describing that the VM was provisioned using Terraform. Moving down to the Volumes tab, we’ll find the two disks we defined, created as PVs in the Kubernetes cluster. 


Fig. 14 – VM volumes 


Fig. 16 – VM disks (PVC) 

Now the openSUSE VM is ready to use it! 


Fig. 17 – openSUSE console screen 

If you want to destroy what we have created, run terraform destroy. Terraform will show the list of all the resources that will be destroyed. Write yes to start the deletion process. 


In this post, we have covered the basics of the Harvester Terraform provider. Hopefully, by now, you understand better how to use Terraform to manage Harvester, and you are ready to start making your own tests.  

If you liked the post, please check the SUSE and Rancher blogs, the YouTube channel and SUSE & Rancher Community. There is a lot of content, classes and videos to improve your cloud native skills. 

What’s Next:

Want to learn more about how Harvester and Rancher are helping enterprises modernize their stack speed? Sign up here to join our Global Online Meetup: Harvester on October 26th, 2022, at 11 AM EST.

Tags: ,,,, Category: Rancher Longhorn Comments closed

Comparing Hyperconverged Infrastructure Solutions: Harvester and OpenStack

Wednesday, 10 August, 2022


The effectiveness of good resource management in a secure and agile way is a challenge today. There are several solutions like Openstack and Harvester, which handles your hardware infrastructure as on-premise cloud infrastructure. This allows the management of storage, compute, and networking resources to be more flexible than deploying applications on single hardware only.

Both OpenStack and Harvester have their own use cases. This article describes the architecture, components, and differences between them to clarify what could be the best solution for every requirement.

This post analyzes the differences between OpenStack and Harvester from different perspectives: infrastructure management, resource management, deployment, and availability.

Cloud management is about managing data center resources, such as storage, compute, and networking. Openstack provides a way to manage these resources and a dashboard for administrators to handle the creation of virtual machines and other management tools for networking and storage layers.

While both Harvester and OpenStack are used to create cloud environments, there are several differences I will discuss.

According to the product documentation, OpenStack is a cloud operating system that controls large pools of compute, storage and networking resources throughout a data center. These are all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface.

Harvester is the next generation of open source hyperconverged infrastructure (HCI) solutions designed for modern cloud native environments. Harvester also uses KubeVirt technology to provide cloud management with the advantages of Kubernetes. It helps operators consolidate and simplify their virtual machine workloads alongside Kubernetes clusters.


While OpenStack provides its own services to create control planes and configures the infrastructure provided, Harvester uses the following technologies to provide the required stacks:

Harvester is installed as a node operating system using an ISO or a pxe-based installation, which uses RKE2 as a container orchestrator on top of SUSE Linux Enterprise Server to provide distributed storage with Longhorn and virtualization with Kubevirt.


Whether your environment is in production or in a lab setting, API use is far-reaching— for programmatic interactions, automations and new implementations.

Throughout each of its services, OpenStack provides several APIs for its functionality and provides storage, management, authentication and many other external features. As per the documentation, the logical architecture gives an overview of the API implementation.

In the diagram above, you can see the APIs a productive Openstack provides in bold.

Although OpenStack can be complex, it allows a high level of customization.

Harvester, in the meantime, uses Kubernetes for virtualization and Longhorn for storage, taking advantage of their APIs and allowing a high level of customization from the containerized architecture perspective. It can also be extended through the K8s CustomResourceDefinitions, which expands and migrates easier.

At the networking level, Harvester only supports VLAN through bridges and NIC bounding. Switches and advanced network configurations are outside the scope of Harvester.

OpenStack can provide multiple networking for advanced and specialized configurations.



OpenStack provides several services on bare metal servers, such as installing packages and libraries, configuring files, and preparing servers to be added to OpenStack.

Harvester provides an ISO image preconfigured to be installed on bare metal servers.

Just install or pxe-install the image, and the node will be ready to join the cluster. This adds flexibility to scale nodes quickly and securely as needed.

Node types

OpenStack’s minimum architecture requirements consist of two nodes: a controller node to manage the resources and provide the required APIs and services to the environment and a compute node to host the resources created by the administrator. The controller nodes will maintain their roles supported in a production architecture.

Harvester nodes are interchangeable. It can be deployed in all-in-one mode, and the same node serving as a controller will act as compute node. This makes Harvester an excellent choice to consider for Edge architecture.

Cluster management

Harvester is fully integrated with Rancher, making adding and removing nodes easy. There is no need to preconfigure new compute nodes or handle the workloads since Rancher manages the cluster management.

Harvester can start in a single node (also known as all-in-one), where the node serves as a compute and a single node control plane. Longhorn, deployed as part of Harvester, provides the storage layer. When the cluster reaches three nodes, Harvester will reconfigure itself to provide High Availability features without disruption; the nodes can be promoted to the control plane or demoted as needed.

In OpenStack, roles (compute, controller, etc.) are locked since the node is being prepared to be added to the cluster.


Harvester leverages Rancher for authentication, authorization, and cluster management to handle the operation. Harvester integration with Rancher provides an intuitive dashboard UI where you can manage both at the same time.

Harvester also provides monitoring, managed with Rancher since the beginning. Users will see the metrics on the dashboard, shown below:

The dashboard also provides a single source of truth to the whole environment.



In Harvester, storage is provided by Longhorn as a service running on the compute nodes, so Longhorn scales easily with the rest of the cluster as new nodes are added. There is no need for extra nodes for storage. There is also no need to have external storage controllers to communicate between the control plane, compute, and storage nodes. Storage is distributed along the Harvester nodes from the view of the VMs (there is no local storage), and it also supports backups to NFS or S3 buckets.



Harvester is a modern, powerful cloud-based HCI solution based on Kubernetes, fully integrated with Rancher, that eases the deployment, scalability and operations.

While Harvester only supports NIC bounding and VLAN (bridge) methods, more networking modes will be added.

For more specialized network configurations, OpenStack is the preferred choice.

Want to know more?

Check out the resources!

You can also check this in-depth SUSECON session delivered by my colleague Guang Yee:

Harvester is open source — if you want to contribute or check what is going on, visit the Harvester github repository

Managing Your Hyperconverged Network with Harvester

Friday, 22 July, 2022

Hyperconverged infrastructure (HCI) is a data center architecture that uses software to provide a scalable, efficient, cost-effective way to deploy and manage resources. HCI virtualizes and combines storage, computing, and networking into a single system that can be easily scaled up or down as required.

A hyperconverged network, a networking architecture component of the HCI stack, helps simplify network management for your IT infrastructure and reduce costs by virtualizing your network. Network virtualization is the most complicated among the storage, compute and network components because you need to virtualize the physical controllers and switches while dividing the network isolation and bandwidth required by the storage and compute. HCI allows organizations to simplify their IT infrastructure via a single control pane while reducing costs and setup time.

This article will dive deeper into HCI with a new tool from SUSE called Harvester. By using Kubernetes’ Container Network Interface (CNI) mechanisms, Harvester enables you to better manage the network in an HCI. You’ll learn the key features of Harvester and how to use it with your infrastructure.

Why you should use Harvester

The data center market offers plenty of proprietary virtualization platforms, but generally, they aren’t open source and enterprise-grade. Harvester fills that gap. The HCI solution built on Kubernetes has garnered about 2,200 GitHub stars as of this article.

In addition to traditional virtual machines (VMs), Harvester supports containerized environments, bridging the gap between legacy and cloud native IT. Harvester allows enterprises to replicate HCI instances across remote locations while managing these resources through a single pane.

Following are several reasons why Harvester could be ideal for your organization.

Open source solution

Most HCI solutions are proprietary, requiring complicated licenses, high fees and support plans to implement across your data centers. Harvester is a free, open source solution with no license fees or vendor lock-in, and it supports environments ranging from core to edge infrastructure. You can also submit a feature request or issue on the GitHub repository. Engineers check the recommendations, unlike other proprietary software that updates too slowly for market demands and only offers support for existing versions.

There is an active community that helps you adopt Harvester and offers to troubleshoot. If needed, you can buy a support plan to receive round-the-clock assistance from support engineers at SUSE.

Rancher integration

Rancher is an open source platform from SUSE that allows organizations to run containers in clusters while simplifying operations and providing security features. Harvester and Rancher, developed by the same engineering team, work together to manage VMs and Kubernetes clusters across environments in a single pane.

Importing an existing Harvester installation is as easy as clicking a few buttons on the Rancher virtualization management page. The tight integration enables you to use authentication and role-based access control for multitenancy support across Rancher and Harvester.

This integration also allows for multicluster management and load balancing of persistent storage resources in both VM and container environments. You can deploy workloads to existing VMs and containers on edge environments to take advantage of edge processing and data analytics.

Lightweight architecture

Harvester was built with the ethos and design principles of the Cloud Native Computing Foundation (CNCF), so it’s lightweight with a small footprint. Despite that, it’s powerful enough to orchestrate VMs and support edge and core use cases.

The three main components of Harvester are:

  • Kubernetes: Used as the Harvester base to produce an enterprise-grade HCI.
  • Longhorn: Provides distributed block storage for your HCI needs.
  • KubeVirt: Provides a VM management kit on top of Kubernetes for your virtualization needs.

The best part is that you don’t need experience in these technologies to use Harvester.

What Harvester offers

As an HCI solution, Harvester is powerful and easy to use, with a web-based dashboard for managing your infrastructure. It offers a comprehensive set of features, including the following:

VM lifecycle management

If you’re creating Windows or Linux VMs on the host, Harvester supports cloud-init, which allows you to assign a startup script to a VM instance that runs when the VM boots up.

The custom cloud-init startup scripts can contain custom user data or network configuration and are inserted into a VM instance using a temporary disc. Using the QEMU guest agent means you can dynamically inject SSH keys through the dashboard to your VM via cloud-init.

Destroying and creating a VM is a click away with a clearly defined UI.

VM live migration support

VMs inside Harvester are created on hosts or bare-metal infrastructure. One of the essential tasks in any infrastructure is reducing downtime and increasing availability. Harvester offers a high-availability solution with VM live migration.

If you want to move your VM to Host 1 while maintaining Host 2, you only need to click migrate. After the migration, your memory pages and disc block are transferred to the new host.

Supported VM backup and restore

Backing up a VM allows you to restore it to a previous state if something goes wrong. This backup is crucial if you’re running a business or other critical application on the machine; otherwise, you could lose data or necessary workflow time if the machine goes down.

Harvester allows you to easily back up your machines in Amazon Simple Storage Service (Amazon S3) or network-attached storage (NAS) devices. After configuring your backup target, click Take Backup on the virtual machine page. You can use the backup to replace or restore a failed VM or create a new machine on a different cluster.

Network interface controllers

Harvester offers a CNI plug-in to connect network providers and configuration management networks. There are two network interface controllers available, and you can choose either or both, depending on your needs.

Management network

This is the default networking method for a VM, using the eth0 interface. The network configures using Canal CNI plug-ins. A VM using this network changes IP after a reboot while only allowing access within the cluster nodes because there’s no DHCP server.

Secondary network

The secondary network controller uses the Multus and bridge CNI plug-ins to implement its customized Layer 2 bridge VLAN. VMs are connected to the host network via a Linux bridge and are assigned IPv4 addresses.

IPv4 addresses’ VMs are accessed from internal and external networks using the physical switch.

When to use Harvester

There are multiple use cases for Harvester. The following are some examples:

Host management

Harvester dashboards support viewing infrastructure nodes from the host page. Kubernetes has HCI built-in, which makes live migrations, like Features, possible. And Kubernetes provides fault tolerance to keep your workloads in other nodes running if one node goes down.

VM management

Harvester offers flexible VM management, with the ability to create Windows or Linux VMs easily and quickly. You can mount volumes to your VM if needed and switch between the administration and a secondary network, according to your strategy.

As noted above, live migration, backups, and cloud-init help manage VM infrastructure.


Harvester has built-in monitoring integration with Prometheus and Grafana, which installs automatically during setup. You can observe CPU, memory, storage metrics, and more detailed metrics, such as CPU utilization, load average, network I/O, and traffic. The metrics included are host level and specific VM level.

These stats help ensure your cluster is healthy and provide valuable details when troubleshooting your hosts or machines. You can also pop out the Grafana dashboard for more detailed metrics.


Harvester is the HCI solution you need to manage and improve your hyperconverged infrastructure. The open source tool provides storage, network and computes in a single pane that’s scalable, reliable, and easy to use.

Harvester is the latest innovation brought to you by SUSE. This open source leader provides enterprise Linux solutions, such as Rancher and K3s, designed to help organizations more easily achieve digital transformation.

Get started

For more on Harvester or to get started, check the official documentation.

Build a lightweight private cloud with Harvester, K3s, and Traefik Proxy

Tuesday, 17 May, 2022

Cloud native technologies are so compelling they’re changing the landscape of computing everywhere – including on-premises. And while it would be convenient if you were deploying into a greenfield situation, that’s rarely reality.

Enter Harvester, the open source hyperconverged infrastructure (HCI) solution designed to easily unify your virtual machine (VM) and container infrastructure operations. And with Harvester, K3s and Traefik Proxy (installed as the ingress controller with K3s) we want to show you how to build an on-premises, lightweight private cloud with ease.

Join us on Wed, May 25th for this Traefik Labs hosted online meetup to explore Harvester, K3s, Kubevirt, Longhorn and Traefik Proxy as the building blocks to a modern, lightweight private cloud.

Register today!

Getting Hands on with Harvester HCI

Monday, 2 May, 2022

When I left Red Hat to join SUSE as a Technical Marketing Manager at the end of 2021, I heard about Harvester, a new Hyperconverged Infrastructure (HCI) solution with Kubernetes under the hood. When I started looking at it, I immediately saw use cases where Harvester could really help IT operators and DevOps engineers. There are solutions that offer similar capabilities but there’s nothing else on the market like Harvester. In this blog, I’ll give an overview of getting started with Harvester and what you need for a lab implementation.­


First, let me bring you up to speed on Harvester. This HCI solution from SUSE takes advantage of your existing hardware with cutting edge open source technology, and, as always with SUSE, offers flexibility and freedom without locking you in with expensive and complex solutions.

Figure 1 shows, at a glance, what Harvester is and the main technologies that compose it.


Fig. 1 – Harvester stack 


The base of the solution is the Linux operating system. Longhorn provides lightweight and easy-to-use distributed block storage system for Kubernetes — in this case for the VMs running on the cluster. RKE2 provides the Kubernetes layer where KubeVirt runs, providing virtualization capabilities using KVM on Kubernetes. The concept is simple: like in Kubernetes, there are pods running in a cluster. The big difference is that there are VMs inside those pods. 

To learn more about the tech under the hood and technical specs, check out this blog post from Sheng Yang introducing Harvester technical details.

The lab

I set up a home lab based on a Slimbook One node with an AMD Ryzen 7 processor, with 8 cores and 16 threads, 64GB of RAM and 1TB NVMe SSD — this is twice the minimum requirements for Harvester. In case you don’t know Slimbook, it is a brand focused on hardware oriented for Linux and open source software. You’ll need an ethernet connection for Harvester to boot, so if you don’t have a dedicated switch to connect your server, just connect it to the router from your ISV.


Fig. 2 – Slimbook One 


The installation

The installation was smooth and easy since Harvester ships as an appliance. Download the ISO image and install it on a USB drive or use PXE for the startup. In this process, you’ll be asked some basic questions to configure Harvester during the installation process. 

Fig. 3 – ISO Install


As part of the initial set up you can create a token that can be used later to add nodes to the cluster. Adding more nodes to the cluster is easy; you just start another node with the appliance and provide the token so the new node can join to the Kubernetes cluster. This is similar for what you do with RKE2 and K3s when adding nodes to a cluster. After you provide all the information for the installation process, you’ll have to wait approximately 10 minutes for Harvester to finish the set up. The Harvester configuration is stored as a yaml file and can be sourced from a URL during the installation to make the installation repeatable and easy to keep on a git repository.


Once the installation is finished, on the screen you’ll see the IP/DNS to connect Harvester and whether Harvester is ready or not. Once ready, you can log into the UI using the IP/DNS. The UI is very similar to Rancher and gives you the possibility to use a secure password in the first login. 


Fig. 4 – Harvester installation finished & ready screen 


The first login and dashboard

When you log in for the first time, you’ll see that it is easy to navigate.  Harvester benefits from a clean UI; it’s easy to use and completely oriented toward virtualization users and operators. Harvester offers the same kind of experience that IT operators would expect of a virtualization platform like oVirt. 


Fig. 5 – Harvester dashboard 


The first thing you’ll find once logged in is the dashboard, which allows you to see all the basic information about your cluster, like hosts, VMs, images, cluster metrics and VM metrics. If you navigate down the dashboard, you’ll find an event manager that shows you all the events segregated by kind of object.


When you dig further into the UI, you´ll find not only the traditional virtualization items but also Kubernetes options, like managing namespaces. When we investigate further, we find some namespaces are already created but we can create more in order to take advantage of Kubernetes isolation. Also, we find a fleet-local namespace which gives us a clue about how Kubernetes objects are managed inside the local cluster. Fleet is a GitOps-based deployment engine created by Rancher to simplify and improve cluster control. In the Rancher UI it’s referred to as ‘Continuous Deployment.’

Creating your first VM

Before creating your first VM you need to upload the image you’ll use to create it.  Harvester can use qcow2, raw and ISO images which can be uploaded from the Images tab using a URL or importing them from your local machine. Before uploading the images, you have the option to select which namespace you want them in, and you can assign labels (yes, Kubernetes labels!) to use them from the Kubernetes cluster. Once you have images uploaded you can create your first VM.

The VM assistant feels like any other virtualization platform out there: you select CPU, RAM, storage, networking options, etc. 


Fig. 6 – VM creation


However, there are some subtle differences. First, you must select a namespace where to deploy the VM, and you have the possibility to see all the VM options as yaml code. This means your VMs can be defined as managed as code and integrated with Fleet. This is a real differentiator from more traditional virtualization platforms. Also, you can select the node where the VM will be running, use the Kubernetes scheduler to place the VM on the best node, apply scheduling rules or select specific nodes that do not support live migration. Finally, there is the option to use containers alongside VMs in the same pod; the container image you select is a sidecar for the VM. This sidecar container is added as a disk from the Harvester UI. Cloud config is supported out of the box to configure the VMs during the first launch as you could expect from solutions like OpenStack or oVirt. 


Finding Kubernetes concepts on a virtualization solution might be a little awkward at the beginning. However, finding things like Grafana, namespace isolation and sidecar containers in combination with a virtualization platform really helps to get the best of both worlds. As far as use cases where Harvester can be of use, it is perfect for the Edge, where it takes advantage of the physical servers you already have in your organization since it doesn’t need a lot of resources to run. Another use case is as an on-prem HCI solution, offering a perfect way to integrate VMs and containers in one platform. The integration with Rancher offers even more capabilities. Rancher provides a unified management layer for hybrid cloud environments, offering central RBAC management for multi-tenancy support; a single pane of glass to manage VMs, containers and clusters; or deploying your Kubernetes clusters in Harvester or on most of the cloud providers in the market. 

We may be in a cloud native world now, but VMs are not going anywhere. Solutions like Harvester ease the integration of both worlds, making your life easier. 

To get started with Harvester, head over to the quick start documentation. 

You can also access this informative on-line session which provides a comprehensive recap of all the essential details needed to evaluate Harvester in your very own local environment:

Join the SUSE & Rancher community to learn more about Harvester and other SUSE open source projects.




Technical Insights of Harvester 1.0

Tuesday, 21 December, 2021

Exactly one year ago, we announced the alpha availability of the project Harvester, an open Source Hypercoverged Infrastructure solution. During this last year, the team has been working hard on developing the project and we brought you the beta release of v0.2.0 and v0.3.0. Throughout the last year, we’ve received many queries from our users and the community, asking when Harvester will be in production.  

Now finally, after a year, we’re excited to present Harvester v1.0, the first general availability release of Harvester!  

Why Harvester?

Harvester is an open source alternative to traditional proprietary hyperconverged infrastructure software. Harvester is built on top of cutting-edge open source technologies, including Kubernetes, KubeVirt and Longhorn.  

Even though Harvester is built on top of Kubernetes, we’ve designed Harvester to be easy to understand, install and operate. Users don’t need to understand anything about Kubernetes to start using Harvester and can experience all the benefits of Kubernetes by using a standalone Harvester cluster.  

If you’re already familiar with Kubernetes and want to have a central place to manage all your Kubernetes and VM workloads, Harvester’s unique value is its integration with Rancher. With Rancher v2.6.3, users can manage all the Harvester clusters, local or remote, by using the new Virtualization Management feature. Also, it’s simple to provision new Kubernetes clusters on top of Harvester using Rancher. Harvester has provided a built-in CSI driver and Cloud Provider to the clusters provisioned by Rancher, which makes Harvester the ideal solution for any users who want to run Kubernetes workloads on top of VMs in the data center.

What does Harvester do?

As an HCI solution, Harvester brings compute, storage and network management together. Here are some highlighted features in the Harvester v1.0 release.  


  • Installation 
  • Via ISO 
  • Via PXE 
  • Air Gap environment support 
  • Proxy support 


  • VM lifecycle management 
  • Built-in monitoring dashboard 
  • Cloud Config 
  • SSH key injection 
  • Graphic console to VNC and serial port 
  • VM Template 
  • Live migration 
  • Export images from existing VMs 
  • Terraform Provider 


  • High performance and efficient block storage 
  • Built-in highly-available image repository 
  • VM backup/restore to S3 
  • Hot plug disks 


  • Virtual IP for the cluster 
  • Multi-network 
  • VLAN 
  • Custom SSL certificate 

Integration with Rancher 

    • Virtualization Management via Rancher for multiple Harvester clusters 
    • Multi-tenancy support with RBAC 
    • Kubernetes cluster provisioning 
    • Built-in CSI driver 

What is Harvester made of? 

Operating System

Harvester is delivered as an appliance, with the operating system and everything needed to run included, and is designed to be installed on bare metal servers. The operating system is based on the widely used and trusted foundation of Linux kernel development for which SUSE has been known for more than 29 years.  


On top of the OS, Harvester uses Rancher Kubernetes Engine 2 (RKE2) to provide the Kubernetes experience. Built by the SUSE Rancher engineering team, RKE2 is a Kubernetes distribution created for enterprises with additional security features. It’s the sibling of the widely popular K3s distribution. By using RKE2, Harvester has a solid foundation of the orchestration layer.  


KubeVirt is a CNCF sandbox project that provides virtualization management on top of Kubernetes. KubeVirt was originally created by Red Hat. It’s a virtualization management tool based on KVM, the most popular open source hypervisor. The Harvester team has worked closely with the KubeVirt teams to add features like live migration with hot-plugged disks to KubeVirt to enhance the user experience of Harvester.   


Longhorn is a CNCF incubation project that provides highly available persistent storage support to Kubernetes. Longhorn was originally created by Rancher Labs and is now maintained by SUSE. It’s one of the most popular cloud native storage solutions out there. There are more than 40,000 nodes running Longhorn worldwide. The Harvester team has also worked closely with the Longhorn project on features like backing image and live migration support. 

Other Cloud Native projects  

Harvester has also used Multus to provide multiple network support for the VMs, Kube-Vip for floating IP to the Harvester cluster as well as load balancing service to the guest cluster.   

Quick Start Harvester

Minimal requirement

  • CPU: x86_64 only. Hardware-assisted virtualization is required. 8-core processor minimum; 16-core or above preferred  
  • Memory: 32 GB minimum, 64 GB or above preferred  
  • Disk Capacity: 120 GB minimum, 500 GB or above preferred  
  • Disk Performance: 5,000+ minimal random IOPS per disk (SSD/NVMe). Management nodes (first 3 nodes) must be fast enough for Etcd.  
  • Network Card: 1 Gbps Ethernet minimum, 10Gbps Ethernet recommended  
  • Network Switch: Trunking of ports required for VLAN support  


You can install Harvester via ISO or PXE into your bare metal nodes. Make sure to choose the first node to install as `Create a Harvester cluster`, all the other nodes should be configured as `Join a Harvester cluster`. Read more about ISO Install here or PXE Boot Install for more detail. 


Once you have installed Harvester, you will see the IP address of Dashboard in the bare metal node’s terminal.  

Put the IP into your web browser, then you will get access to the Harvester Dashboard.  

Integration with Rancher 

One of the most exciting features in Harvester is the integration with Rancher. Now you can manage your container and virtualization workload in the same Rancher instance, which gives you a unified experience for all your workloads in the data center. 

Notice that one Rancher cluster can manage multiple Harvester clusters, though one Harvester cluster can only be imported into one Rancher cluster. You can now access the Harvester UI via the Rancher UI. Also, you can now easily provision new Kubernetes clusters using the managed Harvester cluster. You can learn more about why we chose to integrate Rancher and Harvester here. 

For RKE1 and RKE2 clusters provisioned by Rancher, you can get the load balancer and persistent volume support automatically with the clusters provisioned by Harvester (which we will refer to as guest clusters in the future). For more documentation on the integration please read our docs.


Harvester’s product and engineering team are always open to suggestions and feedback. Test out Harvester today and let us know what you think! You can reach us on our Slack channel, or submit a request in GitHub or reach out to us in the SUSE & Rancher Community. You can keep up to date with Harvester via our open source project page where you can access our latest docs. 

Also, join me and the SUSE & Rancher community team on the 19th of January 2022 at 10 am Pacific Time as we host our global community meetup introducing Harvester. You can also find out more about the GA release here. 

Enjoy Harvester! 

Harvester is now production-ready and generally available  

Tuesday, 21 December, 2021

2021 has been a memorable year for the Harvester team. In May, SUSE hosted the first virtual SUSECON, where we announced the beta release of Harvester, alongside a cast of new innovative open source projects from the SUSE Rancher engineering team. In October, for the first time in two years, we were able to meet our industry peers and the community face-to-face at KubeCon North America where we announced Harvester’s plans to integrate with our leading Kubernetes management platform SUSE Rancher.

Today, we’re closing out the year with one more major announcement – that Harvester is now production-ready and generally available for our customers and the open source community! Harvester’s highly anticipated release marks a major milestone for SUSE as it is the first brand new product release since SUSE’s acquisition of Rancher Labs and expands SUSE’s portfolio capabilities into the hyperconverged infrastructure space.

Why did SUSE build an HCI product?

This year, SUSE made a commitment to our customers and the community to help them ‘Choose Open’ and innovate across their business using open source solutions. Harvester plays an integral piece in SUSE’s portfolio as it showcases our commitment in enriching the open source landscape while providing our customers and the community valuable solutions to help them solve their infrastructure challenges.

Harvester is a natural extension to our existing strong background in container management. It takes an open, interoperable approach to hyperconverged infrastructure and addresses common challenges, including managing sprawl, siloing of teams and resource limitations faced by IT operators who need to manage modern environments comprised of both virtualized and containerized workloads.

What’s Harvester?

Harvester is a 100% free-to-use, open source modern hyperconverged infrastructure solution that is built on a foundation of cloud native solutions including Kubernetes, Longhorn and Kubevirt. It has been designed as an enterprise-ready turnkey solution that gives operators a familiar operating experience like other proprietary HCI solutions in the market.

Though built on Kubernetes, it does not require any pre-existing knowledge to operate. Its integration with SUSE Rancher gives users the ability to operate their virtualized and container workloads all within the same platform while also creating an easy, low-risk pathway for organizations looking to adopt cloud native solutions into their infrastructure modernization strategy. Learn more about the technical capabilities of Harvester in this blog by Sheng Yang, Engineering Lead for Harvester.

Image 1. Harvester as part of SUSE Rancher Console

Harvester integrates with SUSE Rancher

With today’s GA, one of the biggest milestones the Harvester engineering team has achieved this year is the integration of Harvester into the SUSE Rancher console.

As organizations look to accelerate their IT modernization journey, complexity rapidly grows as teams adopt multiple different solutions to help them manage their ever-expanding environments.  Organizations now need tools that can help them both confidently scale environments that simultaneously efficiently manages and governs their stack. Harvester and SUSE Rancher together addresses these needs by consolidating the management of operations for virtualized and containerized workloads – all accessible in a single Rancher platform instance.

This means both Harvester and Rancher clusters can be managed side by side within Rancher’s instance, reducing operators’ need to use separate solutions between the two workloads. Users can access the Harvester UI directly from within the Rancher console. In addition, Harvester clusters also have the ability to access the same features available to Rancher clusters, including authentication, role-based access control and cluster provisioning.

Another opportunity with Harvester and Rancher is that organizations who may be early in their modernization journey can use both open source solutions together as a low-risk pathway to adopting cloud native technology across their stack. Both solutions promote innovation by encouraging organizations to build their confidence in integrating modern technology to develop cloud native applications. For extra piece of mind, customers who may need an additional helping hand can have access SUSE’s support subscription available for Harvester.

Harvester’s general availability extends further than its integration with SUSE Rancher and its ability to consolidate VM and container workloads. Learn more from Robert Sirchia, Senior Technical Evangelist at SUSE, as he explores how Harvester’s cloud-native lightweight nature can be applied at the edge and also used as a platform to modernize applications.

Don’t miss the SUSE and Rancher community’s Global Online Meetup introducing Harvester on the 19th of January 2022 and 10am Pacific Time – alternatively find a local Harvester meetup near you. Learn more about Harvester here or get started today.