Chengcheng vDisk can now give remote users two kinds of desktop: VDI virtual desktops on the server, and the desktop of a real PC in a lab or office. Users sign in to one portal, open with one vDX client, and the same console assigns, books, and audits them; both Windows and Linux can be published.
Frame rates and traffic are measured in Chengcheng's test environment; actual results vary with network and hardware.
Leave light work to virtual desktops on the server, and connect straight to the real PC for GPU-heavy work; both kinds can go in the same desktop pool or be assigned to the same person at once
| Comparison | Virtual desktops (VDI) | Physical desktops (remote access to physical PCs) |
|---|---|---|
| Where the desktop runs | Virtual machines on the server | That PC in the lab or office |
| Who compresses the picture | Hardware compression on the server GPU (Intel / AMD) | Encoded by that PC's own GPU, with the server only relaying |
| Good for | Office work, teaching software, and temporary use for people without a fixed PC | Design, drawing, 3D, and video editing: work that leans on the GPU |
| How it's assigned | Fixed assignment, or a floating pool that assigns at sign-in and restores after use | Fixed ownership, or booked for borrowing by time slot |
| What opens it | The vDX client, or open directly in a browser | vDX client |
With ordinary remote desktop and VDI, the picture is computed and compressed on the server, and it gets tight as people multiply and the work gets heavier. vDisk's physical desktop publishing works the other way round: the picture is encoded by that PC's own GPU, and the server only authenticates and relays as is, with no decoding or re-encoding. Whatever that PC can run, you can use from outside.
There is no frame-rate cap: it follows the refresh rate of that PC's monitor, and 1080p was measured at about 60 fps in the test environment, on an ordinary office PC with Intel integrated graphics.
The software runs on that PC and uses its own GPU, picture encoding doesn't weigh on the server, and many people connected at once don't compete for server compute.
The mouse pointer is drawn on your own computer and doesn't wait with the picture, so dragging, selecting, and clicking menus feel more responsive.
The connected PC calls out to the server and opens no listening port; each connection uses a one-time passphrase and checks the source address. The publishing feature is built into the vDisk client, with no extra software to install.
For office work, teaching software, and temporary use, one virtual desktop is enough; it is reclaimed and restored automatically after use, so the next person gets a clean desktop
The server GPU (Intel / AMD) compresses the picture in hardware, with traffic measured at about 1/40 of lossless transfer in the test environment; once the picture stops, a lossless frame follows after about 1 second and text becomes clear automatically.
After a lab moves to Linux, the machines can still be booked and used remotely after class and over breaks, and Linux PCs can install the client to connect to remote desktops
Physical terminals can publish Windows and Linux distributions such as Ubuntu, in bulk by group, or one at a time, or hidden.
Beyond x86, ARM64 platforms have been through adaptation testing and other platforms are adapted per model; ARM64 and LoongArch terminals run Linux systems.
Images for different processor architectures are made separately and managed on one platform; the same system image can go straight to physical terminals or generate virtual desktops on the server.
The vDX client has a Linux version, with deb and rpm packages for five architectures including x86, ARM64, and LoongArch, so Linux PCs can also connect to remote desktops, with picture, sound, and text clipboard.
The management server itself can also be installed on Linux. For how to package images for Linux terminals and how drivers are handled, seeLinux VOI cloud desktop.
Lab PCs sit idle outside scheduled class time, which is a particular waste in specialist labs for design and 3D, where the GPU is the costliest part and students can't use it back in their dorms. vDisk makes both lab PCs and virtual desktops bookable: they switch on when booked, are reclaimed on time, and every use is logged with its duration.
In the portal's "My bookings", pick a machine and a slot; administrators can book on others' behalf, see the schedule, and turn on approval if needed.
When a borrowing slot ends, the PC is reclaimed automatically and any connected remote session is cut, so no one holds it indefinitely.
A virtual desktop is swapped for a free one in the same pool; physical PCs and virtual machines can sit in the same pool and be scheduled together.
A PC has to be on to be reached: use the console's scheduled tasks to wake lab PCs by time slot so students can connect on time.
On a campus network where dorms and labs share the same network, students connecting to lab PCs in the evening need no public address; from off campus they can connect to the school VPN first. To open a whole lab's or research room's idle compute to the whole school by time slot, seeCompute Sharing Platform.
Whether remote use feels smooth and whether problems can be traced are the first two things school IT and enterprise IT ask
Schools, companies, and channel partners can all style the sign-in portal as their own
Theme, main color, sign-in page style, title, logo, background image, and footer can all be changed, and the download entry can be on or off.
Bind a properly registered domain to serve directly on ports 80 / 443, with a self-signed or uploaded official certificate and a built-in DNS check.
Installs from Windows 7 up, installs itself on first run, and launches with one click from the web page.
deb and rpm packages are available for five architectures including x86, ARM64, and LoongArch, installable on Linux PCs, and currently marked as a preview in the portal.
Open labs, coursework for specialist subjects, remote work, and contract or temporary staff all run on one platform
Students in design, architecture, film, and 3D courses book the lab PC with the GPU from their dorms to do their coursework; labs stay in use after class and over breaks, and the return on assets is visible.
Screens and files only pass through the company's own server. Once office PCs are managed by vDisk, employees connect back to their own from home; copy and file transfer can be switched off by direction.
People without a fixed PC get a virtual desktop, and when they leave you simply reclaim it, with no chasing PCs and no installing anything on other people's computers.
A few high-end workstations are booked by time slot and used in turns; trainees book by lesson hour and access is reclaimed on time.
What can't be done yet is spelled out first, to save detours when choosing
Cloud desktop covers how lab PCs get systems installed, restored, and updated, with the desktop running locally on the PC so it works offline. Remote desktop publishing builds on that and hands the desktop to people who aren't on site: VDI virtual desktops on the server, or the physical PC in the lab or office. Both live on the same platform and in the same console.
No. The connected PC calls out to the server and opens no listening port, and each connection uses a one-time passphrase and checks the source address. What must be reachable is the server: on a campus or enterprise network it works directly, and from the internet the server needs a public address or port mapping.
Yes, by connecting to a physical desktop: the software runs on that PC, its own GPU encodes the picture, and 1080p was measured at about 60 fps in the test environment. Virtual desktops suit office and teaching software better; with Intel integrated graphics split, DirectX 12 and WebGL inside the desktop are hardware-accelerated. Remote sessions currently carry only keyboard and mouse, with no pen pressure support.
Yes. Students pick a PC and a slot themselves under "My bookings" in the portal; administrators can book on their behalf, see the schedule, and turn on approval. When the slot ends, the PC is reclaimed automatically and any connected remote session is cut. The PC has to be on to be reached, and scheduled tasks in the console can power it on by time slot.
Copy-paste and file transfer switch on or off separately for in and out, with optional size limits, set globally, per desktop pool, or per machine, and it applies to physical desktops too; the picture can carry a watermark; every connection logs the time, desktop, source address, duration, and reason it ended, and live sessions can be cut on the spot.
Yes. Physical terminals can publish Ubuntu and other Linux distributions, x86 and ARM64 platforms have been through adaptation testing, and ARM64 and LoongArch terminals run Linux systems; the same image can go to physical terminals or generate virtual desktops on the server. The vDX client has Linux versions for x86, ARM64, LoongArch, and other architectures, so Linux PCs can connect too. On Windows terminals the picture is encoded by the local GPU, while on Linux terminals it goes through the system's own screen service at a lower frame rate.
One Linux server can both manage and run virtual desktops; the six-step "Get started" wizard and "Initialize this machine" install the virtualization components in one click. Publishing physical desktops requires those PCs to be managed by vDisk already.
Related pages:Remote desktop publishing feature list,Comparing desktop virtualization approaches,Comprehensive Solution,Cloud DesktopData Security
Request a trial or book a remote demo, and we'll propose a deployment plan for the size of your lab and your network