As said in my review of the KVM-A8, I picked this up at the same time, though I had to wait longer to put it into service. At the time I bought the KVM-A8, I already had a Pi 4B in hand, but needed to wait when it came to getting a CM4.
So now that I was able to put it into service, time to talk about it…
What do you get?
You have the option to buy the X680 on its own or in several kits depending on how many systems you need to control via ATX. In my instance, I needed support for 3 systems: Nasira, Cordelia, and my mail server. That was “Kit C” (on Geekworm’s site, “X680-X630-A5-3” on AliExpress), which comes with three X630-A5 boards and requisite cable harnesses, along with three 1m Cat5e cables.
If you buy the X680 on its own, you get 4 USB 2.0 cables plus the power brick, which will still allow you to control up to 4 systems, but you won’t be able to remotely control the power and reset function.
It does NOT come with any HDMI cables.
Note: buying the kit with the X630-A5s is less expensive than buying the X630-A5s later. So depending on where you’ll be deploying this, it may be worthwhile grabbing the full kit with four (4) X630-A5s now so you won’t have to buy them later if you anticipate needing to control four systems eventually.
You have three boot options: NVMe SSD, microSD, or onboard eMMC. I think most everyone who uses this will be using either microSD or eMMC, though, so it’s rather… strange they included an NVMe slot. Sure, NVMe is more versatile compared to microSD, and probably more so compared to the onboard eMMC. But getting it set up is a little bit of a chore.
And it’s not like you need the write endurance of an NVMe since the Pi-KVM OS operates with the file system on read-only.
I paired mine with the CM400200, which is the 2GB “Lite” version of the Raspberry Pi CM4, meaning no onboard eMMC and no WiFi.
Again, the X680 gives you the option to boot from NVMe or microSD along with the onboard eMMC (if your CM4 has that). I went with the same microSD card I used with the KVM-A8: Samsung PRO Endurance 32GB. It was just… far easier doing that. If your CM4 has eMMC, it must be 16GB to use it as the boot device.
Like the KVM-A8, this does also have an onboard real-time clock which needs a CR-1220 or CR-1216 battery. It’s the same socket used in the KVM-A8, which I already said will accept a CR-1216 without issue.
The main unit is also 30cm x 9cm (12″ x 3.5″) and about 2.75cm tall (a hair over 1″). This isn’t large enough to fill a 1U space and does not come with rack ears – nor does it have any screw holes for attaching them. So you will need a shelf if you’re putting this in a 19″ rack.
Unfortunately this does NOT support Power over Ethernet. But even if it did, I’m not sure I would want to use it via PoE anyway. The KVM-A8 being powered via PoE is perfectly sensible since it’s inside my OPNsense router. This is a purely external appliance.
Like with the KVM-A8, I set this up before connecting anything. This also gave me a chance to replace the SSL certificate and make sure it had all needed updates.
Given the commands to set this up, I actually wish Pi-KVM included a Bash script that could be run instead. Perhaps I’ll look into writing that later. It would just make it a lot easier on everyone for the setup instructions to include “run
setup_pivkm.sh and follow the prompts” for the most common setup and customization steps.
X630-A5 and low-profile servers
Why is there no low-profile bracket available for the X630-A5?
That’s a bit of a pain since my mail server is in a 2U chassis. So to get this to “work”, I just removed the card from the full-height bracket and… attached it to the side of the chassis using VHB with the Ethernet cable just… dangling through the back.
In all seriousness, how could they NOT anticipate needing a low-profile bracket? PiKVM has a low-profile bracket for their ATX control board – though it’s odd they sell that separately. So Geekworm should get on that.
And I wonder if the Pi-KVM ATX control board works with the Geekworm appliance, if the pinouts match.
Getting this to work was… interesting. The mail server worked fine pretty much out of the gate. It did have this interesting error, though:
Nasira and Cordelia? Not so much.
Powering off the KVM and powering it back on with everything connected brought Nasira around. So there must’ve been some kind of hiccup with whatever video driver TrueNAS is using. (Which I’d expect it to be a generic graphics driver, not anything specific to any chipset.)
Cordelia was a bit more involved. And it’s safe to say the NVIDIA driver was the issue.
I have a Docker container for Frigate, and a GTX 1060 for video transcoding. And that video transcoding requires the NVIDIA proprietary driver. But I had installed the driver via packages from Ubuntu’s repository. This had… kinda worked with the Frigate container. And removing the NVIDIA proprietary driver packages brought Cordelia around to cooperating with the KVM – though also presenting the same EDID error as the mail server.
Now to figure out how to get the NVIDIA proprietary driver working here. Provided that’s possible. Obviously I can’t speak to the AMD drivers since the systems I’m controlling don’t have AMD cards, and I don’t have any spare AMD cards to test.
So first point of order: if the servers you will be controlling have an NVIDIA card running Linux, don’t use the proprietary drivers. And if you must, you’ll likely be better served using one of the other single-machine Pi-KVM options available. I can’t speak to Windows servers for this, so your mileage may vary.
(Note: I’ll update this article if I manage to get the proprietary NVIDIA driver working, but for the time being I’m leaving things as-is.)
Though if you need to control a mix of Windows, Linux, and Mac servers, you may be better served doing this:
And I considered doing this as well when I ran into the above-mentioned frustrations.
But the cost of the standalone Pi-KVM v3 HAT and the ezCoo KVM he used surpasses the cost of the the Geekworm X680 kit. Though if you use Geekworm’s KVM-A3 (buy from Amazon, AliExpress, or Geekworm), you’re about breaking even. But having an all-in-one solution I feel is better.
And once I got past the hiccups… it works.
Now does it work better than what it’s replacing? Yes and no.
There’s much higher fidelity in the video feed going to the browser with the Pi-KVM for… obvious reasons. Keyboard and mouse input latency is much better than the Avocent MPU. The Avocent MPU also had this weird… offset issue with the mouse cursor that is definitely non-existent with the Pi-KVM. Never did get that fully troubleshooted.
But I’m not going to be controlling these servers through the KVM the vast majority of the time. I use the TrueNAS web interface for Nasira and SSH for the mail server and Cordelia the vast majority of the time.
While a KVM-over-IP solution can be used for remote server management, it isn’t the most efficient means. Windows servers can be remote-administered using Remote Desktop (RDS), VNC, or one of the several remote admin products available. Most Linux servers are remotely administered via SSH.
So why have a KVM-over-IP solution? So you can see that a server comes back up when you reboot it – e.g. after doing package updates – and troubleshoot it remotely if it doesn’t. The ability to control the power and reset remotely on all connected servers is a nice bonus with the Geekworm X680.
Driver issues aside, my only real gripe with this is cable bulk. Since you have three cables per system you’re administering: USB, ATX (Cat5E), and HDMI. Cable sleeving can help tame the madness. I just wish it was as easy making custom-length USB and HDMI cables as it is Cat5E.
Which is the advantage of the Avocent MergePoint Utility KVM-over-IP solutions. The individual control modules contain both USB and video, and talk to the main appliance over Cat5E. One module – one cable – per system you’re administering.
While there are other KVM solutions with combined cables, the Cat5E means you can build your cables to whatever length you need. The modules that went to the mail server and Cordelia ran off short patch cables typically used to connect a patch panel to a front-facing switch. Plus they have modules for serial consoles for switches and uninterruptible power supplies.
Adding something like that to a Pi-KVM would take a LOT of effort. (Provided Vertiv doesn’t own any patents on that.) But that’s largely not worth it since the Pi-KVM is built to control just one system, the Pi-KVM OS written for controlling just one input. A substitute for IPMI, not a replacement for existing KVM-over-IP solutions designed from the outset for handling multiple servers.
That Geekworm was able to make the X680 is remarkable taking this into account. And it works… reasonably well.
Would using the ezCoo KVM with the PiKVM v3 HAT, or similar, or the v4 Plus work better? Likely. But simply due to the external KVM being what’s switching between systems.
Having an integrated solution, I feel, is easier to deploy and manage. And with the Geekworm X680, you also have remote power and reset control. The ezCoo KVM doesn’t have that function. So if you require that, you’ll have to figure something out for it. And the Avocent MPU also doesn’t have that.
So, in the end, I would still recommend this. If your use case is like mine, and you’re controlling a bunch of Linux servers without the need to work with a graphical desktop, this should work fine for you.