Acceptance Testing a Refurbished ThinkStation P720 - Homelab
The machine that will run this lab is a refurbished Lenovo ThinkStation P720. Two Xeon Gold 6246 give 24 cores and 48 threads at a 3.3 GHz base clock, which is unusually high for a Xeon and is why I wanted this part: interactive Windows guests feel the base clock more than the core count. There is 128 GB of registered ECC memory, a 1 TB NVMe for the operating system, a 2 TB Crucial P510 for virtual machines, a 4 TB Seagate SkyHawk for ISOs and backups, an RTX 2080 Ti I did not ask for and kept anyway, and a 900 W supply on an Intel C621 board.
Before switching anything on I took the side panel off. Coolers, air ducts and the small fans over the memory were all in place, and the heatsink fins were clean, which on a machine of this age is not a given. All seven chassis fans reported a speed in software, from about 650 rpm at idle to 3,240 rpm under load.
The refurbisher's Windows was still on the NVMe, due to be wiped, so I used it only as a measuring instrument, with no accounts and no credentials. The readings below come from HWiNFO 8.52.
The storage plan hung on the exact model of the 1 TB drive: it puts the hypervisor and the SIEM there, assuming an OEM pull is TLC with a DRAM cache. It is a Samsung PM9A1, widely reported as the OEM twin of the 980 PRO, so the plan stands. The better evidence is one field in HWiNFO, Host Memory Buffer: unsupported on the PM9A1, enabled at 64 MB on the P510. A drive borrows system RAM for its mapping table only when it has no DRAM of its own, so that field tells you which drive has a cache without trusting a datasheet.
SMART filled in the rest. The PM9A1 has 9,055 power-on hours across only 128 power cycles, a workstation left running rather than switched off every evening, and 4 percent of its endurance used, which agrees with 18.96 TB of host writes against the 980 PRO's 600 TBW rating. Zero media errors, full spare capacity. The odd figure is 56 unsafe shutdowns among those 128 cycles: history rather than a fault, but history on the disk that will hold the hypervisor root. The P510 had one power-on hour and the SkyHawk zero.
The memory is eight dual-rank PC4-2666 RDIMMs, half Samsung and half SK Hynix, at their rated speed with ECC active, in slots 3 to 6 of each processor. This board has one DIMM per channel and six slots per processor, so the upgrade is two more per socket, and four identical modules cannot be badly placed even by accident.
The firmware pass took twenty minutes and was mostly confirmation. Six of the seven settings I needed were already right: VT-d on, AHCI on both SATA controllers, CSM off with UEFI-only boot, Wake on LAN on, Enhanced Power Saving Mode off (Lenovo's name for the ErP standby cut that usually kills Wake-on-LAN), and After Power Loss on Power On. I reversed that last one a day later, so that the tower now stays off after a power cut. The seventh, VT-x, has no entry at all, and checking it from Windows has a trap in it: Win32_Processor reports the virtualization properties as False, because they go false whenever a hypervisor is already running, and Windows 11 starts one by itself for Memory Integrity. HypervisorPresent returns True, and a hypervisor cannot run without VT-x.
The find of the session was Intel AMT. I had said it would not be there, since vPro is a client chipset feature and this is a dual socket Xeon. That was wrong. Windows enumerates an AMT serial-over-LAN port, and the firmware's AMT Configuration menu shows Manageability Control enabled, ME firmware 11.22.60.1561, state Operational. Out-of-band power and console access would beat Wake-on-LAN, but this is an ME 11 management stack that can listen on the home network below the operating system, on a machine built to host vulnerable targets, and Setup does not show whether the previous owner provisioned it. The first step either way is the Unconfigure checkbox in that menu.
One real fault turned up. With a network cable attached the machine took three minutes or more to boot: POST went to PXE, the router answered the DHCP request, no boot server replied, and the firmware kept retrying before falling through to the disk, although the boot sequence screens put the NVMe drives first. Those screens cannot fix it. The x key that excludes an entry on a ThinkPad does nothing here, and walking the Network group down with minus never drops it into the Excluded section. The setting is under Devices, Network Setup, where PXE IPv4 and PXE IPv6 can each be set to Disabled.
Prime95 Small FFTs, which on Cascade Lake means AVX-512, ran on all 48 threads for six and a half hours: 2,738 self-tests completed, no errors. Each package drew about 150 W, with peaks of 176 and 174 W, and reached 84 and 86 C with no thermal throttling in 467 logged samples. Clocks settled around 2.5 GHz, below the 3.3 GHz base. That is the AVX-512 offset, not throttling: the only limit either processor reached was the 165 W power limit, ten degrees clear of anything thermal. The WHEA counter stayed at zero, which on a refurbished dual socket machine is the number I care about most.
CrystalDiskMark 9 gave both NVMe drives peaks of about 3,300 MB/s reading and 3,400 MB/s writing. That is PCIe 3.0 x4, saturated, so the Gen4 Samsung and the Gen5 Crucial measure the same on this board and always will. A default run also writes far more than its 1 GiB test size suggests, about 120 GB to each drive, with no collapse in write rate, so the sustained write test I had planned happened by accident. Neither drive passed 38 C.
That left the memory, which needed Secure Boot out of the way, and the idle draw, which needed a meter I did not have.
The memory, a day later
I turned Secure Boot off the next day and left it off. Memtest86+ carries no signature it would accept, and on this host Secure Boot buys little: the firmware now has an administrator password, and everything hostile in the lab will run inside virtual machines.
Memtest86+ 8.10 booted from a Ventoy stick, found 127 GB and both sockets, and ran on all 48 threads in parallel. It showed no ECC status, and a single-bit error that ECC corrects reaches it already fixed, so a clean run here only rules out errors that ECC could not correct.
The first pass took about 1 hour 17 minutes, quick for 127 GB, and the source explains why: on the first pass Memtest86+ divides every test's iteration count by three. The second, full pass ended while I was out of the room. Working back from the progress readings, it took about 3 hours 25 minutes, give or take ten. The pass percentage is a poor clock: at 56 percent it pointed to an ending half an hour later than the real one.
I stopped the run at 4 hours 54 minutes, a few percent into the third pass. Zero errors, and 78 C at the hottest. With the clean Prime95 run behind it, that closes the acceptance tests. Next is Debian.