How/why? The AI needs to navigate the BIOS among other tasks - so we need a KVM to send arrow down and enter, roughly speaking.
We were a GL.iNet KVM shop until we ran into a nasty issue with a specific ThinkPad - the GL.iNet would send an incorrect USB 0 byte which most laptops ignored, except this ThinkPad which was freaked out by it / beeped / wouldn't accept any key command.
I couldn't let this problem go, so I got a low level USB debugger [0] (which I extremely recommend) and wire-debugged the USB signal, A/B comparing the GL.iNet and the PiKVM. The PiKVM was doing things properly (usb-wise), so we swapped all (~10) of our KVMs for it.
I also remember that the GL.iNet was stranger/more difficult to customize (it's just running pikvm the software but doesn't let you customize it as much). The GL offers a nicer UI, but it doesn't matter that much (we drive it via API) and we're happy to support the actual PiKVM authors/company. It's a fantastic product. Not cheap, but truly truly great.
P.S. If someone from GL wants to reach out, I can offer you a lot of low-level debugging info -- fixing this issue would be great.
They also have a nice (if messy) solution for multiple device management with an external box (TechnoTim had some good coverage on his channel/website[1]).
Most other Pi-based KVMs use PiKVM's software anyway, and I'm not sure if any directly support PiKVM upstream (they should, IMO).
The other class is the JetKVM and its derivatives (many forked JetKVM's snappier Go software), and that's another reason I've stuck with JetKVM itself. It seems to have a nice community around it for mounts in almost any situation, and hacks to get weird things working correctly with it. They're also going to have a PoE + full-size HDMI version soon, I think, with microSD for expanded ISO storage.
Supposedly, this is due to the `req->zero = ((count % maxpacket) == 0)` line in the kernel's f_hid.c - which, for 8-byte HID keyboard reports, makes it append a trailer packet. Strict BIOS HID stacks treat this 0-byte packet as malformed and beep.
......Unsettlingly that's also like 16GB of dram in a machine that might be measuring memory in TBs
If you want to plug into a system that isn't server class, then they should be producing a video card that hooks into the USB bus, the always on rail of the power supply, the power switch pin of the power supply, and has an RJ45 jack. The contents of the card should be an off the shelf BMC chip.
But realistically if you want this kind of functionality, just buy server class systems that come with it.
Nearly thirty years ago when I used to work on Silicon Graphics kit everything from powering on and off a server to installing the OS from scratch over the network could be done out of band via serial - and automatically, using expect(1)
That’s progress, I guess.
https://www.digi.com/products/networking/infrastructure-mana...
The downside is you now had to ask of any Cat5 cable "is this serial or is this ethernet?"
But, the devices here are geared towards people using consumer products as servers (which I do at home, not critizing), and serial console during early boot is not an option on those, and most boards don't even have a serial port anymore.
I will say, if you're presenting a usb keyboard, you might also be able to present usb storage which could be nice for booting off of.
https://www.usenix.org/legacy/events/usenix06/tech/ben-yehud...
Some of those servers can have multiple power supplies for failover too. They also can have cards in them to power them on/off remotely as well as long as they have power.
Instead, you're just talking about IMPIjr. These specific features are not in consumer grade CPUs, but in CPUs marked for workstations. Ain't no consumer buying fuckin vPro machines. These are enterprise IT management features, not user features. They're also subject to frequent insane rants by people obsessed with them as possible privacy issues.
Yeah, fine, but a lot of people have been snapping up the tiny/micro class PCs instead of overpriced Pis and a lot of them have vPro.
I shove https://github.com/Ylianst/MeshCommander into the AMT on any vPro boxes I manage so I can have an easy-to-use frontend right on the AMT.
Dude, I wish. I run a large homelab filled with consumer and small business grade intel hardware, and would love to have vpro on all my mid-high end consumer intel platforms. I have the experience and network environment to lock it all down securely, and it's very reliable high performance low level access from before boot.
It's true that some number of relatively expensive consumer-grade CPUs support vPro, but the catch is it also requires the motherboard's chipset to support it, and it has to be both implemented and enabled in the BIOS.
You rarely if ever see consumer hardware with a chipset that supports it. On all the systems I have that fully support vpro from soup to nuts, you have to intentionally turn it on because it's quite dangerous in the wrong circumstances.
Do you know which one of these works well with that?
I want to be able to have power toggle on my Mac remotely, but without soldering in a jumper on the power button, AFAIK there's no way to do it :(
Admittedly, I haven't looked at any open-sourced firmwares either which could have improved things.
I have found the Sispeed USB KVM very useful, the convenience is well worth the $50 it cost me. The UX isn't great but you don't really need it to be. It works (most of the time) via WebUSB for the keyboard mouse.
I will say iDRAC has been a lot more reliable for me, but the chance I'll ever buy a Dell server for home use is basically 0.
I'm trying to make sense of this test. It seems like basically a listicle with "this is great" and a copy/paste of the datasheet specs. Most of the observations are things you'd spot instantly looking at it on amazon. The most critical comment is "it didn't work with ubuntu" (why, how, what went wrong). I was expecting a list of facets that were tested, with insight you can only get from having the hardware in front of you...
But otherwise, I've tested BIOS access on every one of these and it works on the PCs I've tested. Mounting ISO's can be tricky sometimes but mostly "just works" now.
Also did you test this stuff from within the lab, or remotely from somewhere else? I think e.g. JetKVM BIOS issues may be when accessed via Tailscale while on the road, or at a hotel, etc.
KVM switches are relatively cheap[^1] so I'm surprised there isn't an integrated solution.
[^1]: e.g. https://www.amazon.com/Computers-Switches-Supports-switching...
[1] https://technotim.com/posts/pikvm-at-scale/
What I found seems to indicate that Jet fixed those two issues in a hardware revision but it’s really difficult to distinguish the new on from the old as they’ve seemingly kept the same name and not added a v2 or something like that to the naming. One of their vendors has a Poe va non poe sku, the other has a an emmc vs tf card sku. All seemingly without a name distinguishing them.
There’s also just chaos on Amazon as they are being sold in at least 4 separate listings with no name distinguishing which model is which, non of them mention poe and all claim full size hdmi.
In any case I thought you should know that your write up is out of date here but you probably need to do some digging to figure it out.
Most employ heavy compression by default, and it looks a little more pronounced with motion. A few have 'high quality' mode, but especially on the Pi-based KVMs this eats up more CPU, so I don't use that.
It's on the whole best for use cases where you just need to log into remote servers and check on things, or reinstall/re-image something. I don't think I'd like using any of these for a constant remote session for daily work. I do use Screen Sharing on macOS for that sometimes, and it works great in its low-latency mode. None of the KVMs I've tested are quite to that level.
Jeff Geerling rocks
So, sure, nerd out and add more hardware to your rack, but I need a physical keyboard and mouse attached to a machine in my rack like once per year.
I bought a SiPeed NanoKVM. It caught fire 15 minutes after being plugged in. Despite providing pictures of the charred PCB, they insisted I ship it back, costing me €20, and then tried 3 times during the transit to get AliExpress to void my return as fraudulent. I eventually provided proof of signed delivery to their people on the last possible day of my final appeal, and AliExpress ruled in my favor, refunding my purchase price but not the return shipping cost. Better some money back than none at all!
Maybe just buy the JetKVM. It looks nice!
https://www.tomshardware.com/tech-industry/cyber-security/re...
https://arstechnica.com/security/2026/03/researchers-disclos...
[1] https://www.raritan.com/products/kvm-serial/kvm-over-ip-swit...
Even though I have it on Ethernet on a gigabit network at home, with WiFi 7 mesh that gets 950mb up/down to the internet, I’ve never been able to use jetkvm whether through their cloud portal or through direct ip connection without it feeling very sluggish. It’s plugged into an aging NUC that I know is still performant, and I previously had no machine setup with settings configured to a smooth basically realtime feel even over Tailscale remotely, so I don’t know if I just am using the wrong settings or something or what. Might just have to have codex computer use fiddle with it to see if it can figure it out.
The article covers a range of "new" KVMs but doesn't even mention the staples used for decades like Avocent, Aten and APC. When I ran or built a lab, we'd always have the key systems on KVM but always three or four "swing" adapters on long runs of cat6 to reach anywhere in the whole room. Lifesaver.
Some(?) of the KVMs not only simulate a USB keyboard and mouse, but also a USB storage device.
This means you can remotely provide a boot image and the KVM will make a USB drive appear that the remote system can boot (and install from).
Only thing I wish I could find a remote solution for is scanning a QR code with their phone. Does anyone have any ideas for this?
https://www.hp.com/us-en/shop/pdp/hp-anyware-remote-system-c...
I was pretty disappointed to discover DGX spark has no BMC. I was able to hook it up to pikvm by connecting leads to the power switch wires. It honestly works really well and I can provision it with MAAS
Shout-out to pikvm for their redfish support with the pikvm switch
Great writeup there are quite a few here that are new to me
