Proxmox's spiceproxy API returns proxy as a ready-made "http://<addr>:3128"
URL and host as the real (often cluster-internal) SPICE target. buildVVFile
picked params.proxy first and wrote that whole URL into the .vv file's
host= field, and never emitted a proxy= line at all — so virt-viewer tried
to dial "http://<ip>:3128" as a literal hostname instead of tunneling
through the proxy, and every connection failed.
Bump to 1.0.7.
- Auto-connect (single-VM shortcut and autostart match) now renders the
VM list first instead of skipping straight to the connect attempt.
With cluster dedup collapsing 3 duplicate entries down to 1, the VM
vanished from the screen entirely whenever the connection failed.
- proxmox:connect now returns the resolved host:port it handed to
remote-viewer, shown in the success notice, so connection failures
(e.g. Proxmox handing out a cluster-internal node address the client
cannot route to) can be diagnosed without racing delete-this-file.
Only one VM can be marked for autostart at a time — checking a new
one unchecks the previous. Matched by host+vmid since the same vmid
can exist on multiple standalone Proxmox hosts in a cluster setup.
Comma-separated host list logs into every host, merges VM lists tagged
by origin host, and routes SPICE connections to the right one. Also
adds a username format hint (user@realm) on the login form.
VirtViewer's installer folder name includes the version number
(e.g. "VirtViewer v11.0-256"), so the previous hardcoded path never
matched a real install. Now scans Program Files for any VirtViewer*
folder, and adds a Settings dialog (Windows only) to pick the
remote-viewer.exe path manually as a fallback.
- Windows NSIS: lädt VirtViewer MSI herunter und installiert es
während der App-Installation (via PowerShell + msiexec)
- Linux .deb: Depends: virt-viewer — apt zieht es automatisch rein
- Linux AppImage: Startup-Check mit pkexec-Dialog falls virt-viewer fehlt
- BUILD.md aktualisiert: Installer-Verhalten dokumentiert
aria.hacker