KVM Console and Remote Access for VPS

SSH is the primary day-to-day administration channel for a healthy Linux or Windows VPS. The KVM console provided in your Nexelya dashboard is out-of-band access to the virtual machine display—equivalent to plugging a keyboard and monitor into a physical server. Use KVM when SSH is unavailable, during initial OS setup, when fixing GRUB or networking, or when validating boot errors.

Nexelya exposes noVNC against our Proxmox cluster so you do not need VPN access to the hypervisor. Sessions are tied to your authenticated client account and scoped to services you own.

From Dashboard → VPS → your service, click Open console or KVM. A new tab or embedded viewer connects to the VM framebuffer. If the screen is blank, send Ctrl+Alt+Del or use the panel reboot action to cycle the guest. For Linux, you may see a login prompt; for Windows, the lock or setup screen.

Console sessions can disconnect during long idle periods or hypervisor maintenance. Reopen the console if you lose the display; your VM continues running unless you explicitly stopped it.

Black screen after boot often indicates the guest OS is not starting the framebuffer driver yet—common during minimal installs. Wait for install completion or switch to a serial console in your OS if configured. Keyboard layout in noVNC follows your browser locale; special keys are available from the noVNC toolbar.

If the console fails to connect entirely, verify the VM is running, check for ongoing maintenance notices from Nexelya, and try a hard reboot once. Persistent failures warrant a support ticket with service ID and timestamp.

• Disable browser ad blockers that strip WebSocket connections.
• Use a current Chromium, Firefox, or Safari release.
• Avoid multiple simultaneous KVM sessions to the same VM when testing.

Configure sshd for key-only auth, non-default ports only if you understand operational tradeoffs, and AllowUsers or AllowGroups restrictions for multi-admin teams. Use ssh-agent forwarding sparingly; prefer jump hosts for production environments.

Combine security groups at the OS firewall with application bindings on localhost where possible. Nexelya does not replace your need for bastion architecture when compliance requires it—com for clients who need fully managed operations.

For Windows guests, KVM is often the fastest path to enable RDP, join Active Directory, or recover from Sysprep issues. After enabling RDP and configuring Windows Firewall, continue administration over RDP for performance. Keep Windows Update current and restrict RDP exposure via firewall allow lists.

KVM sessions are not recorded by default for privacy; maintain your own session logs for regulated environments. If compliance requires session recording, use a bastion with audit capabilities in front of SSH.

Clipboard sharing in noVNC depends on browser and guest tools; for bulk file transfer prefer scp, rsync, or SFTP once SSH is online.

Concurrent KVM and SSH are safe for troubleshooting; avoid editing the same config files simultaneously from two channels to prevent race conditions.