Here are some more screenshots from debian:

Hello,

I know some people here will absolutely hate the idea of reviving that old-school thick client (yes I am talking about XenAdmin), but there are also some of us that just love it and can't get to like those web-based UIs

Despite running Xen Orchestra for many things almost everywhere (it's really handy) I just still prefer doing many things in the original thick client - especially setup of new pools and cluster, low level stuff like HA configuration, and so on (also - deploying that first VM with xen orchestra - hah).

I already have experience with rewriting C# apps to Qt (I have many years of experience with both programming languages) and I had this idea in my head for a long time, but never felt like I could take such challenge on all by myself - since original XenAdmin is about 1715 files (files, not lines) of code, but then AI happened and it just seems it's really great at translating one language to another.

But fret not, this is not some vibe coded AI slop, I was just using AI (for months) to help convert large pieces of code and then gave a manual review to everything and corrected most of stuff and I plan to do that until everything works completely.

The project lives here for now: https://github.com/benapetr/XenAdminQt

It's using exactly same license as original XenAdmin. I also took liberty of reusing the icons as I am terrible with graphics. If you have any problems with that (especially the rocket logo) let me know, I will have AI generate some slop logo instead, but I really would like to expand the xcp-ng open source world with this

Here is a screenshot from Debian:

(Now that I am looking at it, there are some visual artefacts in that bottom toolbar - but that's just because of that active dark mode, in light mode it looks fine :P)

The client already works great on both macOS and linux (I use both platforms extensively - I don't do much Windows TBH) - if you don't have Windows and want to give it a try, you can compile it easily, assuming you have Qt installed you can just open the .pro file, compile it and run it. No tricks needed, it's very easy and straightforward - I purposefully decided to not add any 3rd party dependencies beside Qt itself to keep it very easy to port anywhere.

In fact thanks to WASM this thing can probably even run in a browser, but networking stack would need some overhaul for that to work.

Just keep in mind this is alpha - run at your own risk, I am myself only using it in my lab clusters, but it didn't break anything so far

Hello,

I am using CEPH for a very long time, I started back in the times of old Citrix Xen Server (I think version 6 maybe?)

I was using RBD for a long time in a hacky way via LVM with a shared attribute, which had major issues in latest xcp-ng, then I migrated to CephFS (which is relatively stable, but has its own issues related to the nature of CephFS - reduced performance, dependency on the MDS etc.).

I finally decided to move outside of my comfort zone and try and write my own SM driver for actual RBD and after some testing move it to my production cluster. I know there is already another github project wrote by another guy, that is unmaintained for many years and has various versions. I didn't want to bother trying to understand how that one is implemented - I already know how to use RBD with CEPH, I just needed to put it into a SM driver. So I made my own.

I will see how it goes, there are drawbacks already to that "native" RBD over CephFS - while IO performance is superior, the "meta" performance (creating disks, snapshots, deleting disks, rescanning SR) is actually slower because it relies on native CEPH APIs and doesn't just use very fast low-level "file access" of CephFS. But I still think it could be a valuable addition to people who need raw IO performance.

My driver is fully open source and available here - I currently target XCP-ng 8.2 and SMAPIv2, because that's what I use on my production cluster which I am primarily making this for. But eventually I will try to test this with XCP-ng 8.3 and when SMAPIv3 is finally ready, I might port it there as well.

Here is the code: https://github.com/benapetr/CephRBDSR/blob/master/CephRBDSR.py

There is also an installation script that makes the installation of the SM driver pretty simple, may need a tweak as I am not sure if manually adding SM modules to /etc/xapi.conf is really a good idea

Please note it's a work in progress, it's unfinished, and some features probably don't work yet.

What is already tested and works:

• SR creation, unplug, plug, rescan, stat
• Basic RBD / VDI manipulation - creating VDI, deleting VDI, openning VDI / mapping VDI, copying VDI

It's really just managing RBD block devices for you and uses aio to map VDIs to them

What is not tested yet

• Snapshots
• Cluster behaviour

I only recommend for use on dev xcp-ng environments at this moment. I think within a month I might have a fully tested version 1.0

Feedback and suggestions welcome!

I just released 0.0.2 https://github.com/benapetr/XenAdminQt/releases/tag/v0.0.2-alpha

The first version was really just a proof-of-concept demonstration, this second version is already pretty usable. It can handle all basic stuff, including provisioning of new VMs, VM control (start / stop / suspend / pause), force actions, parallel connections to multiple clusters etc. etc.

Status of what is tested and works and what does:

# Needs work
* Menu items
* Tree view - should show Virtual Disks, Networks in objects view
* Pool HA tab missing
* Actions and commands, see actions todo
* Performance tab
* Search tab has unfinished options panel
* VM import / export
* Folder and tag views
* Network tab (host) - needs finish and test, especially wizards and properties
* New pool wizard
* New storage wizard
* New VM wizard
* VM deleting
* HA tab
* NIC tab - bonding
* Clone VM
* Create template from VM
* Create VM from template

# Needs polish
* General tab - shows data, but access to data is weird (should use native XenObjects and their properties instead of scrapping QVarianMaps), overall layout is also not good
* Memory tabs - they already work, but could look better
* Console - it works most of the time, but there are random scaling issues during boot, RDP not supported
* UI - menus and toolbar buttons sometime don't refresh on events (unpause -> still shows force shutdown)

# Needs testing
* VM disk resize
* VM disk move
* VM live migration
* VM cross pool migration
* Properties of Hosts, VMs and Pools
* VM deleting
* Options
* Maintenance mode

# Finished and tested
* Add server
* Connection to pool - redirect from slave to master
* Connection persistence
* Basic VM controls (start / reboot / shutdown)
* Pause / Unpause
* Suspend / Resume
* Snapshots
* VM disk management (create / delete / attach / detach)
* SR attach / detach / repair stack
* CD management
* Grouping and search filtering (clicking hosts / VMs in tree view top level)
* Tree view (infrastructure / objects)
* Events history
* Network tab (VM)
* Host command -> Restart toolstack

I made a first "demonstrator" preview release for macOS, will upload .deb and .rpm packages as well: https://github.com/benapetr/XenAdminQt/releases/tag/v0.0.1-alpha

Well, so I found it, the culprit is not even the SM framework itself, but rather the XAPI implementation, the problem is here:

https://github.com/xapi-project/xen-api/blob/master/ocaml/xapi/xapi_vm_snapshot.ml#L250

This logic is hard-coded into XAPI - when you revert to snapshot it:

• First deletes the VDI image(s) of the VM (that is "root" for entire snapshot hierarchy - this is actually illegal in CEPH to delete such image)
• Then it creates new VDIs from the snapshot
• Then it modifies the VM and rewrites all VDI references to newly created clones from the snapshot

This is fundamentally incompatible with the native CEPH snapshot logic because in CEPH:

• You can create any amount of snapshots you want for an RBD image - but that makes it illegal to delete the RBD image as long as there is any snapshot. CEPH is using layered CoW for this, however snapshots are always read-only (which is actually fine in Xen world as it seems).
  • Creation of snapshot is very fast
  • Deletion of snapshot is also very fast
  • Rollback of snapshot is somehow also very fast (IDK how CEPH does this though)
• You can create a clone (new RBD image) from a snapshot - that creates a parent reference to the snapshot - eg. snapshot can't be deleted until you make the new RBD independent of it via flatten operation (IO heavy and very slow).

In simple words when:

• You create image A
• You create snapshot S (A -> S)

You can very easily (cheap IO) drop S or revert A to S. However if you do what Xen does:

• You create image A
• You create snapshot S (A -> S)
• You want to revert S - Xen clones S to B (A -> S -> B) and replaces VDI ref in VM from A to B

Now it's really hard for CEPH to clean both A and S as long as B depends on both of them in the CoW hierarchy. Making B independent is IO heavy.

What I can do as a nasty workaround is that I can hide VDI for A and when the user decides they want to delete S I would just hide S as well and schedule flatten of B as some background GC cleanup job (need to investigate what are my options here), which after finish would wipe S and subsequently A (if it was a last remaining snapshot for it).

That would work, but still would be awfully inefficient software emulation of CoW, completely ignoring that we can get a real CoW from CEPH that is actually efficient and IO cheap (because it happens on storage-array level).

Now I perfectly understand why nobody ever managed to deliver native RBD support to Xen - it's just that XAPI design makes it near-impossible. No wonder we ended up with weird (also inefficient) hacks like LVM pool on top of a single RBD, or CephFS.

I also added windows build so that people can help with testing also on windows. It's a static build, no need for installer, just single zipped .exe file. No dependencies.

I just released 0.0.2 https://github.com/benapetr/XenAdminQt/releases/tag/v0.0.2-alpha

The first version was really just a proof-of-concept demonstration, this second version is already pretty usable. It can handle all basic stuff, including provisioning of new VMs, VM control (start / stop / suspend / pause), force actions, parallel connections to multiple clusters etc. etc.

Status of what is tested and works and what does:

# Needs work
* Menu items
* Tree view - should show Virtual Disks, Networks in objects view
* Pool HA tab missing
* Actions and commands, see actions todo
* Performance tab
* Search tab has unfinished options panel
* VM import / export
* Folder and tag views
* Network tab (host) - needs finish and test, especially wizards and properties
* New pool wizard
* New storage wizard
* New VM wizard
* VM deleting
* HA tab
* NIC tab - bonding
* Clone VM
* Create template from VM
* Create VM from template

# Needs polish
* General tab - shows data, but access to data is weird (should use native XenObjects and their properties instead of scrapping QVarianMaps), overall layout is also not good
* Memory tabs - they already work, but could look better
* Console - it works most of the time, but there are random scaling issues during boot, RDP not supported
* UI - menus and toolbar buttons sometime don't refresh on events (unpause -> still shows force shutdown)

# Needs testing
* VM disk resize
* VM disk move
* VM live migration
* VM cross pool migration
* Properties of Hosts, VMs and Pools
* VM deleting
* Options
* Maintenance mode

# Finished and tested
* Add server
* Connection to pool - redirect from slave to master
* Connection persistence
* Basic VM controls (start / reboot / shutdown)
* Pause / Unpause
* Suspend / Resume
* Snapshots
* VM disk management (create / delete / attach / detach)
* SR attach / detach / repair stack
* CD management
* Grouping and search filtering (clicking hosts / VMs in tree view top level)
* Tree view (infrastructure / objects)
* Events history
* Network tab (VM)
* Host command -> Restart toolstack

I made a first "demonstrator" preview release for macOS, will upload .deb and .rpm packages as well: https://github.com/benapetr/XenAdminQt/releases/tag/v0.0.1-alpha

@Greg_E most likely yes, RAM wouldn't be problem, since it's a C++ app it only needs little of it. On macOS when connected to large cluster with many VMs and consoles it shows 110MB usage.

It just needs X11 or wayland compatible environment to start

@bvitnik yes I also spent years trying to get the original C# client to work, even using mono etc. I know C#, but it's just hard-wired into windows too much, it literally hooks into some Win32 .dlls and then some other (for RDP service etc.)

This is a native client in C++ it has 0 deps on Windows. The RDP integration is one of those things that are missing now, but there is already a stub code using xrdp library, it just needs finishing and is really a low prio, I never really used that RDP integration anyway, native VNC based console is good enough.

Here are some more screenshots from debian:

Hello,

I know some people here will absolutely hate the idea of reviving that old-school thick client (yes I am talking about XenAdmin), but there are also some of us that just love it and can't get to like those web-based UIs

Despite running Xen Orchestra for many things almost everywhere (it's really handy) I just still prefer doing many things in the original thick client - especially setup of new pools and cluster, low level stuff like HA configuration, and so on (also - deploying that first VM with xen orchestra - hah).

I already have experience with rewriting C# apps to Qt (I have many years of experience with both programming languages) and I had this idea in my head for a long time, but never felt like I could take such challenge on all by myself - since original XenAdmin is about 1715 files (files, not lines) of code, but then AI happened and it just seems it's really great at translating one language to another.

But fret not, this is not some vibe coded AI slop, I was just using AI (for months) to help convert large pieces of code and then gave a manual review to everything and corrected most of stuff and I plan to do that until everything works completely.

The project lives here for now: https://github.com/benapetr/XenAdminQt

It's using exactly same license as original XenAdmin. I also took liberty of reusing the icons as I am terrible with graphics. If you have any problems with that (especially the rocket logo) let me know, I will have AI generate some slop logo instead, but I really would like to expand the xcp-ng open source world with this

Here is a screenshot from Debian:

(Now that I am looking at it, there are some visual artefacts in that bottom toolbar - but that's just because of that active dark mode, in light mode it looks fine :P)

The client already works great on both macOS and linux (I use both platforms extensively - I don't do much Windows TBH) - if you don't have Windows and want to give it a try, you can compile it easily, assuming you have Qt installed you can just open the .pro file, compile it and run it. No tricks needed, it's very easy and straightforward - I purposefully decided to not add any 3rd party dependencies beside Qt itself to keep it very easy to port anywhere.

In fact thanks to WASM this thing can probably even run in a browser, but networking stack would need some overhaul for that to work.

Just keep in mind this is alpha - run at your own risk, I am myself only using it in my lab clusters, but it didn't break anything so far

Hello,

Do we have any resources on how to build a fully working XCP-ng (dom0, installer, .iso etc.) from source code?

There are few "helper" repos with scripts like the dev container for SRPM building, but I couldn't find any script set to actually build the installer for dom0 OS (which is IMHO some fork of CentOS 7).

I wanted to experiment trying to get a working dom0 based on something much newer with latest kernel, like Rocky Linux 10, but I don't want to reinvent everything, I suppose there are some build scripts right? Or how do you produce the .iso file?

@psafont thanks for the reply, but isn't that 16 year old logic part of XAPI? I mean - this same hacky logic is present in SMAPIv3 isn't it?

I was going through SMAPIv3 docs and from SM driver perspective (feature-wise) it doesn't seem much different, it looks to me more like many cosmetic changes that make packaging and modularization easier (definitely a good thing), but don't really change any fundamental SM logic - the RPCs are all same as in SMAPIv1, even porting my own driver is probably going to be pretty trivial, it's just about splitting it into multiple files and add some wrappers around it, but it still won't solve my problem - the rollback RPC is just not there, so I would need to instead support this "rollback by making another snapshot of a snapshot" logic enforced by XAPI

Meanwhile until I finish the RBD-native driver which is probably going to take much longer than I anticipated and is probably never going to have "ideal snapshot rollback mechanism", I also decided to create another driver called LVMoRBD which is essentially same as LVMoHBA - it builds LVM-SR on top of RBD block device and is meant to work without need for some complex hacks - https://github.com/benapetr/CephRBDSR/commit/fbde8b49b180d4de60ffea477dffe712f07a4d07

it's really rather a trivial wrapper, it's main benefits as described in the commit message are the ability to auto-mount the RBD image on reboot and to use its own LVM config that enables RBD devices (so no need to modify the default shipped with xcp-ng) and some other things that make creation of LVMSR on top of RBD far easier and natural.

Again - it's not production ready yet, I will be doing many tests on it and probably still need to fix some SCSI related false-positive errors that sometimes appear in SM log. I estimate it will be ready much sooner than RBD-native driver.

LVM on top of RBD is not ideal as there is some tiny overhead, but still probably better than CephFS when it comes to RAW performance (RBD really is something like LUN from HBA)

And yes I do plan to create SMAPIv3 equivalents later when I learn how for now I am still targetting XCP-ng 8.2 as that's what I use in production, and I haven't seen many SMAPIv3 drivers there.

0 benapetr committed to benapetr/CephRBDSR

new driver LVMoRBD

This is a simple wrapper for LVM on RBD which is something I have
experience with from the past - it's actually possible to do this using
native LVMSR driver with few hacks - such as modifying the
master/lvm.conf to work with RBD devices

This SR driver is meant to streamline the access without any need for
custom hacks.

Its main benefits over using LVMSR:

* It automatically maps and unmaps rbd devices for you on reboot
* It uses some wrappers to suppress SCSI meta-calls that cause
  unnecessary false-positive warnings in SM log (rbd devices don't have
  SCSI ID)
* It automatically creates RBD device for you with compatibility
  settings known to work fine with XCP-ng dom0 kernel
* It uses its custom LVM config file, so you don't need to expose RBD
  LVM structure to hypervisor, or override the default config file