Due diligence questions for a managed private cloud provider

The provider's own suppliers, after Equinix Metal

Send them in writing as private cloud RFP questions, and the answers can go into the contract.

We run a managed private cloud on our own hardware. Trinsic Technologies, INC. has operated since 2005 and has run this cloud since about 2015 (About Petrichor).

A managed private cloud provider has suppliers of its own: whoever owns or leases the hosts, and whoever licenses the hypervisor. Either one can end your environment on its own schedule.

Equinix's shutdown FAQ set Equinix Metal's end of life at 11:59 PM PST on June 30, 2026. At that point all customer infrastructure and data became inaccessible, API keys and SSH keys were deleted, and Metal's networking resources were released, including IP address allocations, VLANs and VRFs. Owners keep billing-only console access until December 31, 2026. A managed provider that built its platform on Metal inherited that date for every one of its customers, and their IP addresses went with it.

Two questions reach past the provider to its suppliers:

• Hosts. Owned outright, financed, leased, or rented as bare metal from another company. If rented, the name of that company and the notice its contract gives.
• Hypervisor. Product and version, who holds the license, whether it comes directly from the vendor or through a partner program, and the renewal date. Customers inherit whatever terms the license holder accepts at renewal, including a platform change if the partner program closes.

A strong answer names each company, the product version, the license holder and the renewal month, and offers the paperwork. "Enterprise infrastructure from leading partners", with no company named, answers neither question.

We built and own the hardware this cloud runs on, and we do not resell AWS, Azure or Google capacity, so no bare-metal landlord sits under the hosts. The trade-off is that parts, warranties and the refresh cycle are ours to carry.

Where the spare drives are when one fails

Every provider replaces failed drives and power supplies. What separates them is how long the replacement part takes to arrive and how exposed the storage pool is while it rebuilds.

Part arrival depends on fine print in the hardware support contract. Take Dell's ProSupport Plus for Infrastructure service description (v16.5, July 2026). It calls four-hour delivery of critical parts an objective, stocks the four-hour parts locations with components Dell selects, and lists GPUs among the parts those locations do not carry. Four-hour on-site service applies inside the Dell Service Area, defined as within 100 drivable miles of a Dell service location. The Mission Critical option's four-hour response and six-hour repair apply only within 50 miles (80 km) of a Dell designated support hub, and the six-hour repair is a commercially reasonable effort.

Rebuild exposure is arithmetic. A 20 TB drive rebuilt at a sustained 150 MB/s takes about 37 hours (20,000,000 MB divided by 150 MB/s is roughly 133,000 seconds), and production I/O competes with the rebuild the whole time. On single-parity RAID, a second drive failure during those hours loses the pool, and an unreadable sector on another drive can fail the rebuild or corrupt the data in that stripe.

• Which support contract and tier covers the hosts, and has the vendor confirmed the facility sits inside the distance its response terms require?
• Spares on site: drives of each model in service, power supplies, memory, and who swaps them.
• The redundancy protecting a storage pool during a rebuild (RAID level, erasure coding or replica count), and how long the last rebuild took at current fill.
• Host ages and warranty end dates. A host past warranty falls outside every contract term above.

Listen for a contract tier, a confirmed distance, a shelf list by part, and a rebuild time measured on the last failure. "Four-hour hardware replacement" with no distance and no part list leaves every condition in the Dell document unanswered.

Log CPU steal for a week during the trial

Overcommit ratios rarely appear on a proposal. A trial machine carrying your own test load, logged for a week, shows whether the host gives your virtual CPUs the time they were sold. On a Linux guest:

vmstat -t 60 10080 > vmstat-week.log   # one sample a minute for 7 days: 7 x 24 x 60 = 10,080
mpstat 60 10080 > mpstat-week.log      # %steal per interval, from the sysstat package
grep '^cpu ' /proc/stat                # 8th number after "cpu" is cumulative steal, in ticks

The st column in vmstat and top is time the hypervisor gave to something else while your VM was ready to run. Find it by name in the header line, because newer procps releases add a gu column after it.

For a single number, read /proc/stat at the start and end of a busy hour and convert the steal delta with getconf CLK_TCK, which is usually 100. The cpu line sums every vCPU, so a 4-vCPU guest that gains 18,000 ticks in an hour lost 180 seconds out of 14,400 vCPU-seconds, or 1.25 percent. An hourly average can hide ten bad minutes, so plot the per-minute log and set the peaks beside your application's latency for the same minutes.

Other hypervisors keep the numbers on the host side, where the provider pulls them. On VMware, CPU Ready in the vSphere performance chart is milliseconds of ready time summed across the VM's vCPUs over the chart interval: 20 seconds in the real-time view and five minutes in the last-day view. A 4-vCPU VM showing 1,600 ms in real time is at 1,600 x 100 / 20,000 = 8 percent summed, or 2 percent per vCPU. The same 8 percent reads 24,000 ms in the last-day view, so ask which view a screenshot came from. Ready time alone does not prove a performance problem; line it up against the application's latency.

On Hyper-V, \Hyper-V Hypervisor Virtual Processor(*)\CPU Wait Time Per Dispatch reports the average wait before a virtual processor gets a logical processor. Windows Server 2025 added CPU Contention Time Per Dispatch, which isolates the wait caused by other virtual processors. Multiply it by Logical Processor Dispatches/sec to get contention delay per second, because the per-dispatch figure read alone misleads. Ask for all three, exported for your virtual processors during the trial.

Then ask for the vCPU-to-physical-core ratio and the memory overcommit ratio on the hosts your machines land on, and whether the vCPU ratio counts cores or hardware threads: 4:1 against threads is 8:1 against cores on a host running two threads per core. Ask as well what the provider does when steal rises on your machines. The answer worth having states both ratios, names the unit, and offers to export host metrics for your machines. A provider that states neither ratio and keeps host metrics to itself leaves the week of logging as your only evidence.

A week on one trial host says little about the host production will land on. Near-zero steal on an idle machine proves nothing either, which is why the logged week runs your application's normal test load. Private and public cloud covers tenancy layer by layer, including burst credits to rule out before blaming a neighbor.

For a qualified prospect, one of our engineers can stand up a version of the workload on our cloud so your team can watch it run, arranged through a conversation.

Maintenance windows and admin access logs

A change or a login sits at the start of many incidents in a managed environment, and both leave records you can request before signing.

• How many people can log in to the hypervisor and to your guests, by role, how each login is recorded, and whether you can get the record for your machines.
• Who picks the guest patch window, how much notice you get, whether a snapshot runs first, and who runs your smoke test afterward.
• When the provider patches its hosts, whether your machines live-migrate to another host or reboot, and how much spare capacity the cluster keeps so a host can be emptied.

The last question connects back to overcommit. A live-migrated guest needs room on another host, so a cluster running near full cannot evacuate a host for patching, and the provider either delays the patch or reboots guests in place. With one host's worth of spare capacity (N+1), a cluster can empty any single host.

The evidence comes in three documents: the last three maintenance notices sent to a customer, redacted; the access list for your environment by role; and one sample log entry for an administrative login. Those records show whether the provider guards against two failures: a host patch that reboots every guest because live migration was unavailable, and a guest patch applied while nobody ran the application owner's check. Managed hosting: who does what? walks a Windows patch through a responsibility matrix.

For one customer, we patch and maintain a hosted third-party application and coordinate access when the software's vendor needs in. We automate with Salt, Ansible and Terraform, the same tools as everyone else, and an engineer watches the automation because it fails silently.

When an incident starts after hours

The after-hours path decides how long an incident lasts, and a proposal rarely describes it past a support label.

Ask how many engineers share the rotation. With two, each carries the pager every other week. Ask what counts as a severity one and who decides, and who calls you, and when, if the provider finds the problem first. During the trial, tell the provider a test call will come one night that week, then call the after-hours number and note who answers and what they can see of your environment.

Customers have names and phone numbers for people at Petrichor.

Backup copies outside the primary storage pool

Take a hypothetical attacker holding a provider's hypervisor admin credential. They delete the guests, then the snapshot backups stored on the same array, and recovery depends on a copy that credential cannot reach. A snapshot on the primary array undoes a bad patch and goes down with the array.

Ask where copies sit (the same array, separate storage, or another site), how often they run and how long they are kept, whether the credential that manages your machines can delete them, and whether any copy is immutable for its retention period. The restore questions follow: when one was last tested, and whether you can watch a restore of your trial database to a named point in time.

Restore time can be estimated the same way. A 2 TB database restored at 200 MB/s takes close to three hours (2,000,000 MB divided by 200 MB/s is 10,000 seconds) before transaction log replay starts, so a four-hour recovery target on that database has about an hour of slack.

The evidence is a backup job report for one machine showing target and timestamps, the retention settings, and the most recent restore test record with step timings. Plan your next restore covers reading those timings against a recovery target.

Tickets for database work, backups and restores go to Petrichor engineers (What our engineers handle).

Four core licenses for a SQL Server VM with two vCPUs

Invoices surprise buyers through three things: the meter, license minimums, and charges that outlive a deleted machine. The license line is the easiest of the three to price in advance. Microsoft's SQL Server licensing guidance requires a core license for every virtual core in a VM, with a minimum of four licenses per virtual operating system environment, and licensing by VM requires Software Assurance or a subscription.

Take a hypothetical property management software company, Coldbrook Leasing, with dev, QA and staging databases on SQL Server Standard, licensed per core.

Coldbrook's six vCPUs pay for twelve core licenses, the same count twelve vCPUs would. If the 2-vCPU machines run short of CPU, doubling them costs nothing in SQL Server licensing. Consolidating onto one VM cuts the count to four and puts QA load on the same CPU and memory as dev.

Check the edition before trusting any of those counts. SQL Server's Developer editions carry no license charge and are licensed for development, testing and demonstration only, and SQL Server 2025 includes a Standard Developer edition so a test database can match Standard's feature limits. With dev and QA on Developer edition, Coldbrook licenses only staging's four cores. A quote that bills Standard core licenses on dev and QA machines deserves a question, and so do the provider's terms for running Developer edition on its hosts.

The meter needs its own questions:

• The billing unit: allocated or used capacity, and hourly, daily or monthly
• Whether destroying a machine stops its charge the same day
• Lines billed outside compute: licenses, backup storage, bandwidth, public IPs, support hours, monitoring
• A spending ceiling, and who can set one

Charges that outlive a machine tend to hang off something attached to it, such as an IP address, a backup volume or an interconnect. Metal customers were told that Fabric interconnections left in place could keep incurring charges after shutdown.

In a private cloud provider comparison, price the same three machines, license lines included, on every quote, and mark which of the 25 tasks in the Operating work sheet each quote includes in its price. The meter stated in one sentence, with a sample invoice attached, is what to look for. A single monthly figure with no lines and no stated meter is the weak answer.

A Petrichor invoice shows what a single server costs, and our quotes start from how much capacity the workload needs. The service agreement states the rates and any overage terms.

Boot one exported disk image on another hypervisor

An exit clause gets tested the first time an exported disk boots on another platform, and the trial is the cheapest time to run that test. Ask the provider to export one trial machine's disk, flattened rather than left as a descriptor with a snapshot chain, in a format your target reads: VMDK, VHDX, qcow2, raw, or an OVF package. QEMU reads VMDK and VHDX alongside qcow2 and raw, so any KVM host can take the file. On a Proxmox VE test box:

qemu-img info exit-test.vmdk                   # format, virtual size, and any backing file left from snapshots
qm create 9001 --name exit-test --memory 4096 --net0 virtio,bridge=vmbr0
qm disk import 9001 exit-test.vmdk local-lvm   # attaches as unused0 and prints the volume name
qm set 9001 --sata0 local-lvm:vm-9001-disk-0 --boot order=sata0
qm start 9001

For an OVF package, qm importovf builds the VM from the manifest instead. Two boot failures come up often. Guests installed under UEFI need --bios ovmf and an --efidisk0 on the new VM, or the firmware finds nothing to boot. A Windows guest with no VirtIO SCSI driver stops at startup; attaching the disk as SATA, as above, gets it up, and after you install the VirtIO drivers inside it, the boot disk can move to VirtIO SCSI.

A disk export carries no configuration, so request it separately: firewall rules, load balancer settings, backup history, monitoring checks and DNS records. Databases should come out in native format, a SQL Server .bak or a pg_dump -Fc file, with per-table row counts to compare after the restore.

The remaining exit questions cover the notice period, how long access continues after notice, who does the export work and at what charge, and written confirmation of deletion. IP addresses and licenses catch teams late. A block of addresses the provider owns stays with the provider (Equinix released them at shutdown), and only a block registered to you can be announced from a new network. Windows and SQL Server licenses billed through the provider remain the provider's as well, so a Windows guest arrives needing a license of your own.

Look for a written exit schedule naming formats, timeline and charges, one that can attach to the contract. "Your data is always yours" names no format and no date.

Reasons to keep a workload on a hyperscaler

Some requirements end a managed private cloud evaluation before any of these questions matter. Traffic that needs several regions, or a recovery plan that has to survive losing a whole facility, rules out a single-facility provider, and everything we host runs in one data center. Products built on managed services that exist in only one cloud belong in that cloud. When a platform team already runs its account well and wants root on every host, it gains little from handing the work over. Private and public cloud lists the other cases.

In the mixed case, development and QA move while production stays where it is, and that is where we prefer to start.

Book a call with a consultant and bring this list.