VDI and Desktop Virtualisation Cluster Services
Centralised desktops judged on one number: how long a login takes during the morning rush, when everyone arrives at once.
What this usually looks like
Users keep data on laptops, and centralising it means either a per-seat licence that doubles the project cost or an engineering effort nobody has scoped.
- A previous VDI pilot was abandoned after users described it as "unusable in the morning".
- Desktop images are built by hand and drift within weeks of deployment.
- User data is spread across laptops, personal drives and a shared folder nobody owns.
- Nobody has measured the storage IOPS a login storm actually requires.
Three ways to buy this
Audit if you want to know how bad it is. Build if you have the team and want the capability. Managed if you don't want to own the pager. Most engagements start with the audit and decide afterwards.
Audit
A fixed-price health check — the cheapest way in
- User population and concurrency modelling, by working pattern not by headcount
- Storage IOPS requirement for a simulated login storm, measured
- Application compatibility review for the candidate desktop image
- Endpoint strategy: what happens to the devices users already have
Build
One-off delivery: design, code, hardening, handover
- Virtualisation platform sized for concurrent sessions with headroom for a node loss
- Golden image pipeline with versioned images and a tested rollback
- Session brokering made highly available behind a floating address
- Profile and data redirection onto clustered storage — no unique data on endpoints
- Login-storm test at realistic concurrency, with results published to stakeholders
Managed
Build plus 7×24 on-call, SLA and quarterly drills
- Image lifecycle management with a monthly patch image and staged rollout
- Session performance monitoring with login-time trending
- Capacity review per site against concurrency growth
- Storage and profile layer maintenance, including cleanup of orphaned profiles
- Quarterly node-failure test during business hours
What we actually deploy
Specific tooling, not categories. If a version matters to your decision, ask — we will tell you which one we would pick and why, including when the answer is the older one.
Platform
- Proxmox VE
- Harvester / KubeVirt
- XCP-ng (existing estates)
- vSphere (migration source)
Brokering & session
- Kasm Workspaces
- Apache Guacamole
- X2Go
- RDS session host farm
- UAG / gateway HA
Images
- Packer golden image pipeline
- versioned templates
- sysprep / cloud-init equivalents
- fast clone / linked clones
Profiles & data
- profile redirection
- folder redirection
- clustered SMB / CephFS
- FSLogix-equivalent containers on Linux
Storage for sessions
- Ceph RBD (session volumes)
- NVMe tier for linked clones
- QoS so one user cannot starve the rest
Supporting services
- FreeIPA / AD identity
- printing strategy
- peripheral and USB redirection policy
What we will be measured on
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- p95 login time under the agreed threshold at full simulated concurrency — measured, not modelled.
- Losing one node does not reduce session count below the contracted concurrency.
- Image rollback is tested and works, so a bad image is a ten-minute problem.
- No user data resides on endpoint devices, verified by sampling.
- A login-storm test at 100% of design concurrency is run before go-live and reported.
What we would build, and where the weak point is
The broker is the hidden single point of failure in every VDI design — one login round trip, one dependency. Pair it, put it behind a floating address, and test what happens when it dies with live sessions, because that is the failure users will remember.
marks a single point of failure we would raise with you rather than hide. Every architecture has one; the question is whether you know where it is.
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Requires partner
Device procurement and hardware lifecycle for endpoints
We define the requirements and test the devices. We do not resell thin clients or laptops.
- Requires partner
Licensing strategy for commercial VDI platforms
We will build a cost model comparing options including open source. The licence contract is between you and the vendor.
- Requires partner
Application packaging and re-platforming for virtual desktops
We will package straightforward applications. Anything needing application virtualisation or rewrites is a specialist engagement.
- Requires partner
GPU-accelerated workstation virtualisation for CAD and video
We deploy it on the platforms we know and will be explicit about which workloads we have actually delivered.
What it looked like last time
A professional services firm needing centralised data without a per-seat virtual desktop licence: 300 named users on a four-node Proxmox and Kasm deployment, profile and data redirection onto clustered storage, and a login-storm test that put 180 concurrent sessions through in a defined window at a measured p95 under twenty seconds.
Anonymised under NDA. No client names, no logos, no invented metrics. Full case library on the work page.
Talk to the virtualisation engineer about your vdi & desktop virtualisation
Send us the architecture, or just describe what broke most recently. You'll get an engineer's answer, not a discovery questionnaire.
Talk to a virtualisation engineer: botonwa@gmail.com · +86 130 5181 3099