Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I tested every IP KVM in my Homelab

jeffgeerling.com

Post reply on HN
Print view View original

91–99 of 99 posts

Re: I tested every IP KVM in my Homelab

#91

Post by wtallis »

burnt-resistor wrote: post #88
wtallis wrote: post #16

Earlier quoted context omitted.

Don't your servers already have BMCs supporting IPMI to provide full remote management? Often features like full KVM will require extra licensing, but remote power on is one of the most basic features and I've never encountered a BMC that didn't provide at least that much remote control.

It likely depends on the mfgr. Supermicro calls it SFT-OOB-LIC. HP has standard and advanced iLO. Haven't tried the IPMI interface on Supermicro without a license, but basic power operation might work.

I've used several Supermicro boards across several generations, and never needed the extra license key for remote power on capability. Every server BMC I've ever used from any vendor had that capability standard without requiring the premium option. The features gated behind an extra license are typically things like remote KVM or remote changing of BIOS options.

Re: I tested every IP KVM in my Homelab

#92

Post by atomicnumber3 »

noncoml wrote: post #56
atomicnumber3 wrote: post #52

Earlier quoted context omitted.

It's one of those things where $400 is WAY too much for a homelabber, but most companies (even small ones) can barely count that low when speccing out hardware, ESPECIALLY these days. $400 is like one hard drive in a machine that will potentially have 8-24 of them. ......Unsettlingly that's also like 16GB of dram in a machine that might be measuring memory in TBs

don't these boxes already have a BMC? KVM is kind of poor man's BMC.

TBC I don't necessarily mean they're using them on those servers. Just saying the prices are peanuts to them. I find KVMs are usually used for non-rackmount / weird hardware that nonetheless ends up in a server room.

Re: I tested every IP KVM in my Homelab

#93

Post by trumpdong »

gregsadetsky wrote: post #57
JdeBP wrote: post #51

Earlier quoted context omitted.

I'm not from GL. I write my own USB HID handlers and I'm being nosy about bad protocol that exists in the wild. Was the 0 byte in some input report? In a descriptor? Somewhere else?

TLDR - GLKVM's kernel emits a trailing 0-byte DATA packet (ZLP) (which PiKVM does not) 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.

Isn't that expected in USB so the receiving side knows it's at the end of the data transfer?

Re: I tested every IP KVM in my Homelab

#94

Post by yencabulator »

rendaw wrote: post #71

I was looking into this and there were reports of e.g. connection delays making it impossible to access bios on a booting machine. This is a huge issue - rebooting and power management are big ip kvm use cases, and it isn't even touched on in the review. 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…

FWIW in the world of UEFI most firmware provides a way to boot into the firmware setup without needing to win that race. systemd-boot calls it "Reboot Into Firmware Interface", and you can do systemctl reboot --firmware-setup from a running linux.

Re: I tested every IP KVM in my Homelab

#95

Post by yencabulator »

geerlingguy wrote: post #40
bobson381 wrote: post #30

Earlier quoted context omitted.

Could you get a kvm connected to a networked PDU with per-outlet control? Then a power cycle on the plug for the mac would accomplish the same thing. Or just use the network port on the PDU directly w/o kvm.

The annoying thing with Macs is they don't have the ability to 'Power on after clean shutdown and power cycle'. They can power on after a power fail, but that's not the same thing. 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 :(

Worst case scenario, physically press the button: https://www.switch-bot.com/products/switchbot-bot

Re: I tested every IP KVM in my Homelab

#96

Post by yencabulator »

ryanmcbride wrote: post #22

It will never make sense to me why KVMs are such a hard problem to solve. It seems like something we should have a good answer for by now but we still really just don't without dropping hundreds of dollars, and even then it still feels like a crap shoot.

In an alternate timeline, we would have gotten IP-only servers:

https://www.usenix.org/legacy/events/usenix06/tech/ben-yehud...

Re: I tested every IP KVM in my Homelab

#97

Post by geerlingguy »

geerlingguy wrote: post #40
bobson381 wrote: post #30

Earlier quoted context omitted.

Could you get a kvm connected to a networked PDU with per-outlet control? Then a power cycle on the plug for the mac would accomplish the same thing. Or just use the network port on the PDU directly w/o kvm.

The annoying thing with Macs is they don't have the ability to 'Power on after clean shutdown and power cycle'. They can power on after a power fail, but that's not the same thing. 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 :(

I just found out newer desktop Macs now have a setting as of 26.5 that allows power on after power restore even without an unsafe shutdown. I'll have to test this.

Re: I tested every IP KVM in my Homelab

#98

Post by McGlockenshire »

kotaKat wrote: post #79
McGlockenshire wrote: post #59

Earlier quoted context omitted.

I'm not surprised that nobody noticed it at all. That's because it's not a KVM that you can purchase and test, the subject to the article. 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 i…

> Ain't no consumer buying fuckin vPro machines. 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.

Man, I wish that tool was available fifteen years ago. All of our machines in our half-Linux half-Windows manufacturing operation were Q chips with vPro motherboards, that we (I) chose on purpose, but we didn't have the IT bandwidth to ever sit down and learn how to use them properly.
Post reply on HN