When we started brain storming a project for hack week, one of the floated ideas was to remake the 1983 film WarGames, and for lack of available space, a local lot with storage units was proposed. Over the course of the following years, while we planned, we realized that this whole idea would not be the most feasible, but it still felt like we were onto something.
Eventually, we settled with keeping the name and changing the scope.
Instead, we are proposing to create a virtual environment on which war games will be played, with a focus on storage -- in particular, with a focus on Ceph and its ecosystem.
What are war games?
Wikipedia has a few entries talking about the concept of war games, pertaining to military exercices and simulations. We are not going to go into much detail about what the whole concept is about for two reasons: 1) getting definitions 100% right is a deep rabbit hole that would consume our whole week, and 2) because "war game" is chosen mostly because it's a cool name.
In essence though, the concept relies on simulating adverse conditions, to develop, trial and refine possible solutions, without actual exposing the participants to real-life scenarios where failure would (potentially) be catastrophic.
In the context of software-defined storage, Ceph in particular, we are looking to leverage this concept to allow participants to develop their capabilities in recovering from cluster failures, as well understanding how failures are caused and how to prevent them.
General Overview
The ten thousand feet view involves two teams: Red, and Blue.
The Red team's takes the adversarial position, meant to cause as much trouble for the Blue Team as possible, while observing whatever constraints are established for the duration of the exercise. The Blue team's objective will be to keep a healthy, functioning cluster, thwarting Red's attempts at mayhem.
Each exercise will be bound by a set of constraints, defined before the exercise begins, and to be observed by both teams. For instance, if a constraint is "no data shall be deleted", then the Red team shall not delete the data on the disks. Remember, this is meant for people to learn, may it be by causing the problems or by fixing them.
The exercises will take place on virtual machines: a healthy cluster will be set up, with all the services that are meant to be running for a given exercise; there will be a login node, that shall be accessible by both teams. Teams will log into this node, and will issue their actions into the cluster from it.
Each team will have a predefined, non-overlapping time window to perform their actions on the cluster. Once the window closes, teams will no longer be able to login, connections will be booted off the node.
All actions, commands, shall be logged to a remote node, alongside with cluster health and other relevant information, for further analysis, postmortem, etc.
Hack Week's Objective
Getting this working. Some of it? All of it? Finding out how much we will be diverging from the initial objective by week's end. :)
Looking for hackers with the skills:
This project is part of:
Hack Week 17
Activity
Comments
Be the first to comment!
Similar Projects
Extracting, converting and importing VMs from Nutanix into SUSE Virtualization by emendonca
Description
The idea is to delve into understanding Nutanix AHV internals on how it stores and runs VMs, and how to extract them in an automated way for importing into a KVM-compatible hypervisor, like SUSE Virtualization/Harvester. The final product will be not only be documentation, but a working prototype that can be used to automate the process.
Goals
1) document how to create a simple lab with NutaniX AHV community edition 2) determine the basic elements we need to interact with 3) determine what are the best paths to grab the images through, balancing speed and complexity 4) document possible issues and create a roadmap for tackling them 4) should we adapt an existing solution or implement a new one? 5) implement the solution!
Resources
Similar project I created: https://github.com/doccaz/vm-import-ui Nutanix AHV forums Nutanix technical bulletins
Q2Boot - A handy QEMU VM launcher by amanzini
Description
Q2Boot (Qemu Quick Boot) is a command-line tool that wraps QEMU to provide a streamlined experience for launching virtual machines. It automatically configures common settings like KVM acceleration, virtio drivers, and networking while allowing customization through both configuration files and command-line options.
The project originally was a personal utility in D, now recently rewritten in idiomatic Go. It lives at repository https://github.com/ilmanzo/q2boot
Goals
Improve the project, testing with different scenarios , address issues and propose new features. It will benefit of some basic integration testing by providing small sample disk images.
Updates
- Dec 1, 2025 : refactor command line options, added structured logging. Released v0.0.2
- Dec 2, 2025 : added external monitor via telnet option
- Dec 4, 2025 : released v0.0.3 with architecture auto-detection
- Dec 5, 2025 : filing new issues and general polishment. Designing E2E testing
Resources
SUSE Virtualization (Harvester): VM Import UI flow by wombelix
Description
SUSE Virtualization (Harvester) has a vm-import-controller that allows migrating VMs from VMware and OpenStack, but users need to write manifest files and apply them with kubectl to use it. This project is about adding the missing UI pieces to the harvester-ui-extension, making VM Imports accessible without requiring Kubernetes and YAML knowledge.
VMware and OpenStack admins aren't automatically familiar with Kubernetes and YAML. Implementing the UI part for the VM Import feature makes it easier to use and more accessible. The Harvester Enhancement Proposal (HEP) VM Migration controller included a UI flow implementation in its scope. Issue #2274 received multiple comments that an UI integration would be a nice addition, and issue #4663 was created to request the implementation but eventually stalled.
Right now users need to manually create either VmwareSource or OpenstackSource resources, then write VirtualMachineImport manifests with network mappings and all the other configuration options. Users should be able to do that and track import status through the UI without writing YAML.
Work during the Hack Week will be done in this fork in a branch called suse-hack-week-25, making progress publicly visible and open for contributions. When everything works out and the branch is in good shape, it will be submitted as a pull request to harvester-ui-extension to get it included in the next Harvester release.
Testing will focus on VMware since that's what is available in the lab environment (SUSE Virtualization 1.6 single-node cluster, ESXi 8.0 standalone host). Given that this is about UI and surfacing what the vm-import-controller handles, the implementation should work for OpenStack imports as well.
This project is also a personal challenge to learn vue.js and get familiar with Rancher Extensions development, since harvester-ui-extension is built on that framework.
Goals
- Learn Vue.js and Rancher Extensions fundamentals required to finish the project
- Read and learn from other Rancher UI Extensions code, especially understanding the
harvester-ui-extensioncode base - Understand what the
vm-import-controllerand its CRDs require, identify ready to use components in the Rancher UI Extension API that can be leveraged - Implement UI logic for creating and managing
VmwareSource/OpenstackSourceandVirtualMachineImportresources with all relevant configuration options and credentials - Implemnt UI elements to display
VirtualMachineImportstatus and errors
Resources
HEP and related discussion
- https://github.com/harvester/harvester/blob/master/enhancements/20220726-vm-migration.md
- https://github.com/harvester/harvester/issues/2274
- https://github.com/harvester/harvester/issues/4663
SUSE Virtualization VM Import Documentation
Rancher Extensions Documentation
Rancher UI Plugin Examples
Vue Router Essentials
Vue Router API
Vuex Documentation
Reassess HiFive Premier P550 board (for RISC-V virtualization) by a_faerber
Description
With growing interest in the RISC-V instruction set architecture, we need to re-evaluate ways of building packages for it:
Currently openSUSE OBS is using x86_64 build workers, using QEMU userspace-level (syscall) emulation inside KVM VMs. Occasionally this setup causes build failures, due to timing differences or incomplete emulation. Andreas Schwab and others have collected workarounds in projects like openSUSE:Factory:RISCV to deal with some of those issues.
Ideally we would be using native riscv64 KVM VMs instead. This requires CPUs with the H extension. Two generally available development boards feature the ESWIN 7700X System-on-Chip with SiFive P550 CPUs, HiFive Premier P550 and Milk-V Megrez. We've had access to the HiFive Premier P550 for some time now, but the early version (based on Yocto) had issues with the bootloader, and reportedly later boards were booting to a dracut emergency shell for lack of block device drivers.
Goals
- Update the boot firmware
- Test whether and how far openSUSE Tumbleweed boots
Results
- Boot firmware image 2025.11.00 successfully flashed onto board
- Enables UEFI boot in U-Boot by default
- U-Boot's embedded Flat Device Tree is lacking a timebase-frequency, required for recent (6.16.3) mainline kernels (panic leading to reset, visible via earlycon=sbi)
- Tested eswin/eic7700-hifive-premier-p550.dtb from Ubuntu 2025.11.00 image
- Allows to boot past the above panic, but times out in JeOS image while waiting for block device, dropping to dracut emergency shell
- No devices shown in lsblk -- 6.16 appears to be lacking device drivers still
Resources
Contribute to terraform-provider-libvirt by pinvernizzi
Description
The SUSE Manager (SUMA) teams' main tool for infrastructure automation, Sumaform, largely relies on terraform-provider-libvirt. That provider is also widely used by other teams, both inside and outside SUSE.
It would be good to help the maintainers of this project and give back to the community around it, after all the amazing work that has been already done.
If you're interested in any of infrastructure automation, Terraform, virtualization, tooling development, Go (...) it is also a good chance to learn a bit about them all by putting your hands on an interesting, real-use-case and complex project.
Goals
- Get more familiar with Terraform provider development and libvirt bindings in Go
- Solve some issues and/or implement some features
- Get in touch with the community around the project
Resources
- CONTRIBUTING readme
- Go libvirt library in use by the project
- Terraform plugin development
- "Good first issue" list