How did you set the manangement interface in /etc/network/interfaces ?
You've set it to manual ?
Getting vPro remote KVM working on Minisforum MS-01
- Thread starter merlina2
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
You've set it to manual ?
Login as root to your Proxmox host and edit /etc/network/interfaces. Then restart the service using `systemctl restart networking`. See here for more details: NetworkConfiguration - Debian Wiki
I think the issue for me might have been caused during initial installation of Proxmox as I purposefully didn't connect the LM port. And/or didn't enable the relevant port in the setup options. Once the port was enabled and I'd gone through the BIOS settings to enabled MEBx, then I had no trouble connecting via MeshCommander.
These notes were very helpful... I spent hours scratching my head why the freaking video on the KVM wouldn't work until this post said that vPro doesn't work headless and it requires a dummy HDMI plug.... ordered one and hope it fixes it.
In the meantime enabled the serial console but it only works after OS boot (couldn't get the grub startup to work I guess)
Signed up to the forum as i've bought 3x MS01's and do need to do something about OOB management. I initially decided against it due to complexity, security and lack of clear simple information on vPro. I have WOL working with Proxmox so i'm already covered in a situation where its powered off and not needing remote hands, but after moving the servers into a data center its taken only 24 hours to have one become unreachable..... 
That's the only scenario I need it for, when something crashes or fails and I need to remotely power off/on the device. To fulfil just that I could use a raspberry pi and GPIO pins connected to the power button pins. However being able to see what's on the screen might show obvious memory/drive faults, overheating, fan failure or some other such issue that might be more useful
So what is the bare minimum to have this functionality? Some people seem to want to use it like Teamviewer to actually do things on the machine as if its a client PC, but I really don't need that. Once it boots to proxmox and is reachable I can do everything else over the network. I just need screen and power control and i'm happy
I have never used vPro before. I understand going into BIOS, turning it on, setting static IP/dns/etc as mentioned in this thread and using a dummy HDMI plug. I presume it'll use the first 2.5G ethernet port which is fine I can make a dedicated subnet for that. What about actually getting to it though? Do I need meshcommander or any other software? Or does vPro have its own web UI and I just go to the statically set IP in a web browser on another PC?
That's the only scenario I need it for, when something crashes or fails and I need to remotely power off/on the device. To fulfil just that I could use a raspberry pi and GPIO pins connected to the power button pins. However being able to see what's on the screen might show obvious memory/drive faults, overheating, fan failure or some other such issue that might be more useful
So what is the bare minimum to have this functionality? Some people seem to want to use it like Teamviewer to actually do things on the machine as if its a client PC, but I really don't need that. Once it boots to proxmox and is reachable I can do everything else over the network. I just need screen and power control and i'm happy
I have never used vPro before. I understand going into BIOS, turning it on, setting static IP/dns/etc as mentioned in this thread and using a dummy HDMI plug. I presume it'll use the first 2.5G ethernet port which is fine I can make a dedicated subnet for that. What about actually getting to it though? Do I need meshcommander or any other software? Or does vPro have its own web UI and I just go to the statically set IP in a web browser on another PC?
Last edited:
I was in the same boat as you I only needed vPro for powering off and on and occasional bios upgrade. I could never get the power on/off to work with vPro or WOL on the MS-01. I am using Unraid and it only seems to freeze or lock up. I went with a very simplistic approach with SwichBot. The device can be controlled remotely to press the power switch. vPro was never reliable for me even seeing the screen getting into the bios etc. PiKVM on the other hand worked flawlessly. If you get the PiKVM v4 Plus you can pair it with a kvm switch to control multiple devices from a single PiKVM v4 plus. PiKVM also supports GPIO. With vPro you need software to control it so you need meshcommander. All the software for vPro is old and not updated. VPro was just never adopted so trying to use it you are forced to use neglected software.
If you get vPRO to work powering on/off please let me know it would make things a lot simpler for me
So what is required for setting vPro up? Just turn it on in BIOS and follow steps already posted, then install meshcommander on a win10 virtual machine and connect to it? Or is there firmware that also needs to be flashed as well
And regarding power on, are you able to connect to the device via vPro but it just can't wake the machine? Or its not reachable at all when its off?
Perhaps it uses WOL internally and if so it may require the MAC address of the ethernet port, SFP won't work
WOL does not work for me using integrated proxmox WOL feature (I presume its not picking the right interface) however it works fine by opening terminal/shell on one of the proxmox nodes, install etherwake (or any other WOL software) with 'apt install etherwake' then enter
etherwake -i enp87s0 [MAC-ADDRESS]
or
etherwake -i enp90s0 [MAC-ADDRESS]
enp87s0 is the name assigned to the ethernet port closest to the 10G SFP cages (i'll refer to it as eth1 and enp90s0 as eth2). I daisy chain the cluster by connecting each node from eth2 to eth1
eth1 and eth2 are inside a bridge with RSTP to create 1 logical interface and not have loops. But i'm pretty sure that once a node turns off it reverts to treating them as individual interfaces. Hence its important to use the correct MAC address for the corresponding interface
So i.e. because node1/eth2 connects to node2/eth1 I would have to open the shell on node1 and type
etherwake -i enp90s0 [MAC-ADDRESS of enp87s0 on node2)
Or from node3 (which connects from node3/eth1 to node2/eth2)
etherwake -i enp87s0 [MAC ADDRESS of enp90s0 on node2)
If you were instead using a switch to connect all the nodes and just using eth1/enp87s0 then this shouldn't matter, just make sure you're using the MAC of eth1 and not the MAC of eth2 or the SFP ports as it won't work
The SFP cages lose power when the machine is off so you would not be able to use those for WOL, only ethernet. I don't believe I had to set anything in the BIOS for ethernet ports to stay on. You should still see lights on the rear of the MS01 at the ethernet ports when they are connected and turned off
And regarding power on, are you able to connect to the device via vPro but it just can't wake the machine? Or its not reachable at all when its off?
Perhaps it uses WOL internally and if so it may require the MAC address of the ethernet port, SFP won't work
WOL does not work for me using integrated proxmox WOL feature (I presume its not picking the right interface) however it works fine by opening terminal/shell on one of the proxmox nodes, install etherwake (or any other WOL software) with 'apt install etherwake' then enter
etherwake -i enp87s0 [MAC-ADDRESS]
or
etherwake -i enp90s0 [MAC-ADDRESS]
enp87s0 is the name assigned to the ethernet port closest to the 10G SFP cages (i'll refer to it as eth1 and enp90s0 as eth2). I daisy chain the cluster by connecting each node from eth2 to eth1
eth1 and eth2 are inside a bridge with RSTP to create 1 logical interface and not have loops. But i'm pretty sure that once a node turns off it reverts to treating them as individual interfaces. Hence its important to use the correct MAC address for the corresponding interface
So i.e. because node1/eth2 connects to node2/eth1 I would have to open the shell on node1 and type
etherwake -i enp90s0 [MAC-ADDRESS of enp87s0 on node2)
Or from node3 (which connects from node3/eth1 to node2/eth2)
etherwake -i enp87s0 [MAC ADDRESS of enp90s0 on node2)
If you were instead using a switch to connect all the nodes and just using eth1/enp87s0 then this shouldn't matter, just make sure you're using the MAC of eth1 and not the MAC of eth2 or the SFP ports as it won't work
The SFP cages lose power when the machine is off so you would not be able to use those for WOL, only ethernet. I don't believe I had to set anything in the BIOS for ethernet ports to stay on. You should still see lights on the rear of the MS01 at the ethernet ports when they are connected and turned off
Above I outlined the setup and yes just use meshcommander to control it. There is software for windows linux etc.
I tried everything to get it to work with powering on and could never get it to work. I tried using the other ethernet ports for WOL and they did not work either.
I was able to power the machine down with vPRO.
Well.... I think I can declare vPro - at least in this device - an utter pile of garbage
Stuck in the DC for hours trying to get it working, it kinda sorta works but its so unreliable its a joke
First device would respond to pings and allow me to log in via mechcommander when its in the powered off state or up until the BIOS. Once the OS loads then it would stop responding and the only way to get it back was to physically yank the power, boot it back up, hit pause or just go into BIOS to stop the OS loading and then after about 60 seconds it would respond. Once the OS loads it would stop again. I spent a good hour trying to get this to work and I can't say for sure what it was but in my case i'm running proxmox with both ethernet ports in an OVS bridge. I had to reconfigure the bridge exactly the same way, initially turning RSTP off (in order to actually create a loop by accident) and then re-enable RSTP. After that it seemed to respond, though it does still take approx a minute after the interface is up, working and passing traffic before the IP set to vPro actually starts to respond. (Note that the interface has been working in proxmox and VM guests this entire time)
It's very flakey with its IP assignment. If I assign the same it the same IP or subnet as the OS then neither the OS nor vPro will respond to pings
I expected vPro to operate as a hardware chip wholely independently of the OS like a true OOB management solution, but that's evidently not the case
Second device was much more compliant, all I had to do was set 'Network Active' and then set a static IP, done. Nothing else needs to be configured in order to get to it. No FQDN or anything else
Third device however does not work at all. At no point have I been able to get it to respond to pings whatsoever. Tried different IP's just in case there was some weird internal reservation, nothing. Has the same configuration as the other 2, same BIOS, same everything
IPv6 also does not work. It must initially be enabled via meshcommander as the BIOS has no mention of IPv6. However despite being able to ping, meshcommander just will not connect to it, so IPv4 only
Power on is strange, if I use mechcommander or the physical power button to turn it off then it will still respond to pings. If I shut the system down via the OS then pings stop responding. So these 2 states are different to each other, yet I can still use etherwake to send a WOL packet and the system will boot up and become responsive again
=====================================================
The TLDR is its a shitty unreliable OOB management system. It should be entirely independent of the OS and act like a separate piece of hardware, it does not. And it doesn't even work uniformly across identical devices (1 doesn't work at all)
PiKVM or similar devices are a substantially better solution
Stuck in the DC for hours trying to get it working, it kinda sorta works but its so unreliable its a joke
First device would respond to pings and allow me to log in via mechcommander when its in the powered off state or up until the BIOS. Once the OS loads then it would stop responding and the only way to get it back was to physically yank the power, boot it back up, hit pause or just go into BIOS to stop the OS loading and then after about 60 seconds it would respond. Once the OS loads it would stop again. I spent a good hour trying to get this to work and I can't say for sure what it was but in my case i'm running proxmox with both ethernet ports in an OVS bridge. I had to reconfigure the bridge exactly the same way, initially turning RSTP off (in order to actually create a loop by accident) and then re-enable RSTP. After that it seemed to respond, though it does still take approx a minute after the interface is up, working and passing traffic before the IP set to vPro actually starts to respond. (Note that the interface has been working in proxmox and VM guests this entire time)
It's very flakey with its IP assignment. If I assign the same it the same IP or subnet as the OS then neither the OS nor vPro will respond to pings
I expected vPro to operate as a hardware chip wholely independently of the OS like a true OOB management solution, but that's evidently not the case
Second device was much more compliant, all I had to do was set 'Network Active' and then set a static IP, done. Nothing else needs to be configured in order to get to it. No FQDN or anything else
Third device however does not work at all. At no point have I been able to get it to respond to pings whatsoever. Tried different IP's just in case there was some weird internal reservation, nothing. Has the same configuration as the other 2, same BIOS, same everything
IPv6 also does not work. It must initially be enabled via meshcommander as the BIOS has no mention of IPv6. However despite being able to ping, meshcommander just will not connect to it, so IPv4 only
Power on is strange, if I use mechcommander or the physical power button to turn it off then it will still respond to pings. If I shut the system down via the OS then pings stop responding. So these 2 states are different to each other, yet I can still use etherwake to send a WOL packet and the system will boot up and become responsive again
=====================================================
The TLDR is its a shitty unreliable OOB management system. It should be entirely independent of the OS and act like a separate piece of hardware, it does not. And it doesn't even work uniformly across identical devices (1 doesn't work at all)
PiKVM or similar devices are a substantially better solution
OK, I am lost already.
I managed to get AMT OOB working. When it works, it get IP from DHCP etc.
But...when I turn host off, it also goes off
And when I turn it on, it does not start to work unless I bring manual interface up in linux (ip link set dev ethXXX up).
Isn't it is something quite opposite to OOB management?
What do I do wrong? Do I need to force linux somehow to ignore interface completely?
Is it normal that it is still available in OS, despite choice of OOB management?
I managed to get AMT OOB working. When it works, it get IP from DHCP etc.
But...when I turn host off, it also goes off
And when I turn it on, it does not start to work unless I bring manual interface up in linux (ip link set dev ethXXX up).
Isn't it is something quite opposite to OOB management?
What do I do wrong? Do I need to force linux somehow to ignore interface completely?
Is it normal that it is still available in OS, despite choice of OOB management?
OK, will partially answer myself
to separate linux (have no idea about windows) and vPro NIC, I configured to load pci-stub module before igc module, and added PCI ID of vPro nic to pci-stub. So, now intel driver does not touch nic, interface is not present in the system etc.
As result, once after boot vPro configured this nic at 100Mb/s, it stays there as commanded by vPro. (before it would go off one intel modules are loaded, and go on again only if I would bring interface up in the os, and then it would go full 2.5Gbps). So, separation is here, but....
it still goes of when I power down system, which makes whole vPro senseless
But, this part might be due to ill BIOS or something.
Although, would love to hear is someone have it working after powering system off.
to separate linux (have no idea about windows) and vPro NIC, I configured to load pci-stub module before igc module, and added PCI ID of vPro nic to pci-stub. So, now intel driver does not touch nic, interface is not present in the system etc.
As result, once after boot vPro configured this nic at 100Mb/s, it stays there as commanded by vPro. (before it would go off one intel modules are loaded, and go on again only if I would bring interface up in the os, and then it would go full 2.5Gbps). So, separation is here, but....
it still goes of when I power down system, which makes whole vPro senseless
But, this part might be due to ill BIOS or something.
Although, would love to hear is someone have it working after powering system off.
I just got my MS-01 and am using UNRAID on it. I can turn it on and off using AMT without any issues, and Wake-on-LAN (WOL) worked fine before I tried to get MeshCommander firmware working. No matter which version of MeshCommander I use, I'm stuck on the loading screen. If I select the TLS option, I get a timeout error. Has anyone managed to get this working on UNRAID? I am using either my Mac or a Windows machine (as a VM on UNRAID) to connect. I don't have a standalone Windows PC to test with. Pinging Intel AMT works from all computers, and the Intel AMT webpage loads successfully. However, MeshCommander cannot find the Intel AMT.
Update: WOL working as expected as well.
Update: WOL working as expected as well.
Last edited:
I've just received a new MS-01, sealed into film wrap etc. When I go into the MEBx entry in the BIOS, it asks me to "Enter Current Password". I've never set a password.
I've read elsewhere that "admin" should be the default, but it isn't, and I've tried a number of the other usual suspects (blank, 'password',...) to no avail.
Any suggestions are very welcome.
I've read elsewhere that "admin" should be the default, but it isn't, and I've tried a number of the other usual suspects (blank, 'password',...) to no avail.
Any suggestions are very welcome.
Update:
I was right about my guess. I’m using Unraid, and when I try to use Meshcommander from a VM on a Windows machine or any other PC/Mac, I just keep getting the loading sign. So, I installed Windows on a USB for the MS-01, and I can access AMT from that local machine using Meshcommander.
I uploaded the AMT firmware, enabled KVM, and had to use a Dummy HDMI plug to avoid getting a black screen. However, the screen occasionally goes blank. Since I don't need this every day, I'm okay with it. To address the issue, I added a Kasa smart outlet to power off and on whenever I encounter problems. I'll try to document the steps in detail soon.
Thanks, everyone. The information shared in this forum was very helpful.
I was right about my guess. I’m using Unraid, and when I try to use Meshcommander from a VM on a Windows machine or any other PC/Mac, I just keep getting the loading sign. So, I installed Windows on a USB for the MS-01, and I can access AMT from that local machine using Meshcommander.
I uploaded the AMT firmware, enabled KVM, and had to use a Dummy HDMI plug to avoid getting a black screen. However, the screen occasionally goes blank. Since I don't need this every day, I'm okay with it. To address the issue, I added a Kasa smart outlet to power off and on whenever I encounter problems. I'll try to document the steps in detail soon.
Thanks, everyone. The information shared in this forum was very helpful.
Could you point me to this firmware and what you had to do to upload it? Does it sit behind the password-locked MEBx menu entry that I can't yet get access to, or might it help with getting access to it?
If you're not using a qwerty keyboard make sure to type 'admin' as if it was on a qwerty kb, as there is not keymapping done in the MS-01 BIOS.
If you disconnect the bios battery it will reset the amt password (and all other amt and bios configuration) to default. The bios battery is a royal pain to disconnect/reconnect, I suggest using a pair of tweasers or needle node pliers with a 90deg bend (and even then it is more than a bit frustrating). AMT passwords must be at least 8 chars with upper case, lower case, number and symbol. I use MeshCommander with mine, I can power on/off the system, reset the system, use the remote desktop (it's actually VNC) and mount ISO files (IDER) for remote install which is painfully slow (hour long prox install) and sometimes stops working part way through resulting needing to reboot and start over.
You can install MeshCommander in a LXC in prox and connect to the host it is running on but ONLY if the traffic goes out a port other than the i226LM port (i.e. out one of the 10G nics and back into the I226LM) due to the way AMT works on the NIC, obviously not very useful for BIOS level access but if you have a cluster of MS-01's setting it up on each means you can control one from another (Installing it on another machine works fine too). I have the I226LM connected and set to manual in prox, configuring an IP on that port in prox makes AMT stop working after prox boots. For reference the I226LM port is the one next to the SFP ports in prox this shows up as enp0s89 (i9-12900H model) or enp0s90 (i5-12600H).
To get IDER (remote iso mount) working in MeshCommander I use graceful mode to mount the iso while sitting in the BIOS screen and hit "Save and Exit" (not save and reset, that doesn't work). It is more than a bit flakey. When installing prox like this on my 01's half of them had to be done twice because it stopped working part way through, the remote desktop session continues to work though so I could see the proxmox installer complain that it could not read one of the install files, resetting the system from meshcommander and going through the whole song and dance again allowed me to complete the install the second time on the two that failed. As I mentioned is it painfully slow to do this (over an hour to install proxmox) so I would strongly recommend using a USB stick to install if you value your time at all.
I've been using AMT(vPRO) for well over 10 years or so on various hardware, while it does suck performance with when compared to most other remote management solutions (ipmi/idrac/ilo/redfish ect...) it does (mostly) work when configured correctly and if you are managing desktops/laptops/workstations it is often the easiest/most readily available option. When used with remote provisioning it can be really powerful.