New Home Hypervisor - XCP-ng/ Xen Orchestra

 

With Broadcom's recent licensing changes for VMware, I decided to change the hypervisor for my home lab. After evaluating several freely available options likely to work in an enterprise environment, I chose the XCP-ng/Xen Orchestra solution.
When reviewing XCP-ng as a solution, it appears to be the closest to running VMware while maintaining an open-source foundation. The stack consists of two main components: XCP-ng and Xen Orchestra. XCP-ng is the equivalent of ESXi and is directly installed on the hardware. With the recent release of 8.3, XOA-Lite is now part of the stack, allowing for a GUI experience on the host without requiring an external controller. Xen Orchestra is a vCenter-like control plane that centralizes control. Unlike vCenter, it is installed on another machine, and hosts can be controlled by multiple XO instances. For day-to-day operations, it runs on an Ubuntu server VM, though I have an instance installed through my main laptop's WSL instance. Overall, the appliance is much lighter than a traditional vCenter. For home lab or non-production use, you can compile it yourself from GitHub. In a production environment, Vates provides support through a licensed appliance.
An important goal of this migration was to move existing VMs from the VMware stack to the new stack, using XO’s convenient tool. Here are the high-level steps I took during the migration.
 

Migration Process

  1.  Power down all unused services in my existing home lab.
  2. Remove Host 3 from my VMware Cluster.
  3.  Install XCP-ng on Host 3
  4. Create a new VM to host XO using XO-Lite
  5. Compile an open-source XO instance from GitHub
  6. Use the VM import tool to convert machines to VMware
  7. Fully decommission the vCenter environment
  8. Install XCP-ng on the other two hosts
  9. Add everything to a single pool in XO and verify functionality

 End Results

Overall, I was very pleased with the migration process and was able to complete it on a Saturday, restoring things to work as expected. All the functionality I expected, including live migration of VMs between hosts, works as expected, along with additional features such as integrated backups. The one area that seems like an immediate miss is the lack of thin provisioning on iSCSI disks, which will lead me to convert my storage NAS to NFS at a later date to utilize thin provisioning. I have more upcoming content on using XCP-ng planned for the future, so stay tuned and check out some of the resources I used below.
 

 Links/ Resources

 

 


Comments

Post a Comment

Popular posts from this blog

Home Lab Hardware 2.0 – New Hosts

Image
     While working on some projects in my home lab recently, I’ve begun encountering resource shortages. Many of these shortages stem from my original intention to utilize repurposed desktop hardware. Although my lab no longer uses VMware, I still utilize it for work and read content, such as William Lam’s blog . While browsing his VCF9 content, I began to notice some relatively inexpensive machines that would meet my needs by providing more CPU and RAM for my workloads. The Minisforum MS-A2 immediately came to consideration due to its 16-core/32-thread AMD processor and the ability to support up to 96GB of RAM. However, shipping is relatively delayed, and I don’t need the smallest form factor available. Further research led me to the Minisforum 795S7 , which has similar specifications but in a larger case.     The 795S7 fits exactly what I was looking for in a lab machine. The processor and RAM mentioned above enable me to reduce the required number of hosts f...
Read more

PowerShell Logging Part 2 — Rotating Your Logs

Image
  A few weeks ago, I wrote a post about using PowerShell for logging script outputs and mentioned there’d be a part two. So here we go, finally. PowerShell logging is great for keeping track of data, but log files can quickly get too big. This makes it hard to find what you need or manage storage. With a simple script, you can split logs into separate files when needed. $logPath = "c:\Scripts\NICPingCheck.log" #Check if old log files exist and delete them if (Test-Path "$logPath.old") { Remove-Item "$logPath.old" -Force Write-Host "Old log file removed." } else { Write-Host "No old log file found to remove." } #Rename the current log file to .old if (Test-Path $logPath) { Rename-Item -Path $logPath -NewName "$logPath.old" -Force Write-Host "Current log file renamed to .old." } The script starts by deleting any files ending in .old. Next, it renames the current log file to add .old, so you al...
Read more

PowerShell Logging — Recording the Output of Your Scripts

Image
PowerShell is one of the most powerful tools in an administrator's toolbox, and I use it daily. The more I do with PowerShell, the more I need to record my script and save my script output as reference or proof of the changes made. For example, when did that condition-based automation fire, and what did it do, or what data did you update from that data extract from HR against AD? PowerShell provides several options, and here are my favorites. Write-Host The simplest option is the "Write-Host" command, which returns the output to the command window. This is great for returning simple values; you can watch as the script runs. By including the variable after the write host command, you can print its value at that point in the code for reference- $timestamp = (Get-Date).ToString("yyyy-MM-dd HH:mm:ss") $message = "Logging Blog" Write-Host "$timestamp - $message" Typically, this wouldn't record the output anywhere other than i...
Read more