I have the MS-A2, and I would like to setup a virtualization server using ProxMox. I have some questions.

I have a small business, and I need several server instances to handle internal and external tasks. I may be small biz, but to me it's critical that I don't loose data. Is it possible to install 2 NVME drives in a mirrored pair for redundancy? Ive been told to use HW raid because using SW raid means the software stack running the raid has more potential failure points compared to a dedicated HW raid configuration. Also, im wondering how to setup a network config which has private/internal VM's which can communicate outward, and also a set of VM's which can reach outward but are not allowed to reach inward to my internal/private network. I really don't know how to set that up. I have a ubiquity router, and all attempts to setup subnets don't provide that network isolation. It seems all nodes can communcate regardless of which network they are on, so im not geting that isolation of the internal network away from the nodes which are on a public network.

Just not sure what im doing wrong. So, looking for advice.

A few different tech sites have picked up the story and there are some interesting early details starting to surface. I pulled together the concrete info below so we can discuss it. The image below is from here:

CPU: Intel Core Ultra 7 356H (Panther Lake)

The MS-03 is expected to be powered by Intel’s upcoming Panther Lake mobile platform, specifically the Core Ultra 7 356H.

Specs floating around right now include the following for the CPU:

• 16 cores total

  • 4 Performance cores

  • 8 Efficiency cores

  • 4 Low power Efficiency cores

• Boost clocks up to about 4.7 GHz

• 18 MB cache

• Xe3 integrated graphics

• Integrated NPU for AI acceleration

Panther Lake is Intel’s next architecture after Lunar Lake and Meteor Lake, so this will likely bring improvements in both performance and efficiency.

AI compute looks like a big focus

One interesting part of the specs is how much AI acceleration is being advertised with this one. There are several reported numbers related to AI performance, including the following:

• ~40 TOPS from the GPU

• ~50 TOPS from the NPU

• ~90 TOPS total AI compute

That suggests Minisforum may be positioning this system partly as an AI workstation mini PC, not just a general desktop, which is not surprising as most of the manufacturers are jumping on this bandwagon of marketing.

Power target around 70 W

Some reports say the system may run the CPU at around a 70 W power envelope, but it will be interesting to see if when released if it is around this power level as this will be somewhat high for mini PC and home lab I think but still doable. But also, if that ends up being true, it could mean much stronger sustained performance compared to many compact systems that throttle heavily.

Chassis size

The MS-03 appears to remain very compact and look basically like the MS-01 (see the picture above), with the dimensions of 195 × 195 × 42.5 mm. So still firmly in the small workstation mini PC category.

Possible MS-01 successor

Several sites suggest this is essentially the next generation of the MS-01 platform, even though they have already released the MS-02. I think we would all agree the MS-02 was really its own type of mini PC and looks more like a mini workstation footprint, instead of what the MS-01 started. That raises some obvious questions for those of us running MS-01 systems today.

Things we still don’t know are the following. Will it keep 10GbE networking or maybe have 25 GbE like the MS-02? Will there still be multiple NVMe slots? Will OCuLink be there for external GPU support? Will there be any PCIe expansion options? What will be the memory type and capacity? Is there a release timeline or pricing?

Why this could be interesting for home labs

If Minisforum keeps the same philosophy as the MS-01, this could end up being another strong home lab node with many of the same features that we really liked about the MS-01 such as the high core count CPU, small footprint, high-speed networking, AI acceleration, integrated graphics. So if they do, I think this could definitely be interesting for running Proxmox clusters, AI inference workloads, edge compute clusters or bare metal Kubernetes or Docker nodes. 

Curious what everyone thinks

A few questions for those in the forum. Do you think 10GbE returns on this system? Would you upgrade from an MS-01 for Panther Lake? Would you use this more for virtualization or AI workloads?

Personally I am really curious if Minisforum doubles down on the mini workstation / home lab hybrid concept again. If they keep the networking and storage flexibility of the MS-01 but add Panther Lake performance, this could end up being another really popular platform.

Would love to hear what everyone thinks.

Networks used for segmented traffic

MTU 1500 (Client-facing/Management):

• vmbr0 (10.3.33.0/24) - Management/API/SSH
• bond0.335 (10.3.35.0/24) - Proxmox Cluster (Corosync ring1)
• All VM VLANs (2, 10, 149, 222)

MTU 9000 (Backend Infrastructure):

• bond0.334 (10.3.34.0/24) - Ceph OSD cluster traffic
• bond0.336 (10.3.36.0/24) - VM live migration
• bond0 and physical interfaces (must stay 9000)

Moving Ceph OSD traffic

Storage traffic benefits from being on its own dedicated network and VLAN. This way you can cleanly set jumbo frames and dedicate links to this network if you want as well. For me I am using bonded LACP 10 gig connections for all my traffic. So, I am using VLANs to segment and carve the traffic up.

Step 1: Verify Connectivity

# On each host, verify new network is configured and reachable
ping -c 2 10.3.34.210  # From any host to pvehost01
ping -c 2 10.3.34.211  # pvehost02
ping -c 2 10.3.34.212  # pvehost03
ping -c 2 10.3.34.213  # pvehost04
ping -c 2 10.3.34.214  # pvehost05

Step 2: Update Ceph Configuration

# On any one node (config replicates automatically):
nano /etc/pve/ceph.conf

# Change ONLY the cluster_network line:
cluster_network = 10.3.34.0/24

# Leave public_network and all monitor addresses on old network
public_network = 10.3.33.0/24

Step 3: Set noout Flag

ceph osd set noout

Step 4: Rolling OSD Restart

After setting the noout flag, we roll through all the hosts and restart the OSD service. It is important after each host to check the status of Ceph with the ceph -s command and wait for any backfilling that might happen to complete.

# On each node, one at a time:
systemctl restart ceph-osd.target
sleep 10
ceph -s  # Verify cluster health before next node

# Wait for any backfilling to complete between nodes
# Continue to next node when ceph -s shows all PGs active+clean

Step 5: Verify Migration

# Check OSDs are using new network:
ceph osd dump | head -30

# Should see cluster addresses like:
#  
#      ^public           ^cluster (new!)

Step 6: Unset noout

ceph osd unset noout

Result: Ceph cluster replication traffic now on dedicated 10.3.34.0/24 network with MTU 9000

Move your Proxmox Cluster Ring (Corosync)

Instead of totally moving my cluster network, what I am doing below is "adding" another network to the Corosync networks. This way I have two networks that can be used for cluster traffic. If something happens to one VLAN, the other network/VLAN should be unaffected.

Step 1: Edit Corosync Configuration

# On any one node (config replicates automatically):
nano /etc/pve/corosync.conf

# Add ring1_addr to each node in nodelist:
node {
  name: pvehost01
  nodeid: 1
  quorum_votes: 1
  ring0_addr: 10.3.33.210
  ring1_addr: 10.3.35.210  # ADD THIS
}
# Repeat for all nodes with their respective .211, .212, .213, .214 addresses

# Add second interface to totem section:
totem {
  ...
  config_version: 20  # INCREMENT THIS
  interface {
    linknumber: 0
  }
  interface {          # ADD THIS
    linknumber: 1
  }
  ...
}

Below you can see the additional network added for the corosync configuration.

Step 2: Restart Corosync

You may not technically HAVE to restart the corosync service across all your hosts as they may automatically pick up the changes, but it is a "cover the bases" type operation. 

# Modern Proxmox with knet may apply automatically
# Check if both rings are active:
corosync-cfgtool -s

# If not showing both rings, restart on each node:
systemctl restart corosync
pvecm status  # Verify cluster stays quorate

Step 3: Verify Dual-Ring Operation

# On each node:
corosync-cfgtool -s

# Should show:
# LINK ID 0 udp - addr = 10.3.33.X (all nodes connected)
# LINK ID 1 udp - addr = 10.3.35.X (all nodes connected)

Result: Proxmox cluster has redundant communication paths with ring1 on dedicated 10.3.35.0/24 network

Move the VM Migration Network

Finally, we will move the VM migration network so that it uses its own dedicated network for migration traffic.

Step 1: Configure Migration Network

# Via GUI:
# Datacenter → Options → Migration Settings → Edit
# Type: secure
# Network: 10.3.36.0/24

# Or via CLI:
nano /etc/pve/datacenter.cfg
# Add:
migration: secure,network=10.3.36.0/24

The new network has been selected and confirmed.

Result: VM live migrations now use dedicated 10.3.36.0/24 network with MTU 9000

ceph status

or 

ceph -s

Step 1: Identify the Problem OSD

# Check overall cluster health
ceph status
# Get detailed health information (shows which OSD has issues)
ceph health detail
```
**Example output:**
```
 BLUESTORE_SLOW_OP_ALERT: 1 OSD(s) experiencing slow operations in BlueStore
osd.6 observed slow operation indications in BlueStore
Note the OSD number (in this case: osd.6)

Step 2: Locate the OSD's Host

# Find which physical host contains the OSD
ceph osd find <osd-number>
# Example:
ceph osd find 6
Example output:
json
{
"osd": 6,
"addrs": {
"addrvec": 
},
"osd_fsid": "900daf28-d681-4637-90db-9764bcfd2f11",
"host": "pvehost04",
"crush_location": {
"host": "pvehost04",
"root": "default"
}
}
Note the hostname (in this case: pvehost04)

Step 3: Connect to the Host

# SSH to the host containing the problematic OSD
ssh root@pvehost04

Step 4: Identify the Physical Disk

# Find the OSD's logical volume
ceph-volume lvm list | grep -A 10 "osd.<number>"
# Example:
ceph-volume lvm list | grep -A 10 "osd.6"
```
**Example output:**
```
====== osd.6 =======
 /dev/ceph-46ed1f42-7685-4bfd-b64f-ad525bddc935/osd-block-900daf28...
block device /dev/ceph-46ed1f42-7685-4bfd-b64f-ad525bddc935/osd-block-900daf28...
block uuid f94nrL-KRDg-D648-Ia7B-F3Yx-hjwQ-HppqAT
Note the VG name (in this case: ceph-46ed1f42-7685-4bfd-b64f-ad525bddc935)

Find the underlying physical disk:

# Show the complete disk hierarchy
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE
# Or find the physical volume for the VG
pvs | grep <vg-name>
# Example:
pvs | grep ceph-46ed1f42-7685-4bfd-b64f-ad525bddc935
```
**Example output:**
```
/dev/nvme1n1 ceph-46ed1f42-7685-4bfd-b64f-ad525bddc935 lvm2 a-- <953.87g
Note the physical device (in this case: /dev/nvme1n1)

Step 5: Check Disk Health

For NVMe Drives:

# Install nvme-cli if not present
apt install nvme-cli -y
# Check SMART health summary
nvme smart-log /dev/nvme1n1
# Or using smartctl
smartctl -a /dev/nvme1n1
# Check for errors
nvme error-log /dev/nvme1n1

For SATA/SAS Drives:

# Install smartmontools if not present
apt install smartmontools -y
# Quick health check
smartctl -H /dev/sdX
# Full SMART information
smartctl -a /dev/sdX
# Check for specific error indicators
smartctl -a /dev/sdX | grep -E "Reallocated|Pending|Current_Pending|Offline_Uncorrectable|UDMA_CRC_Error"

Step 6: Interpret Health Results

Critical Values to Check:

For NVMe:

• critical_warning: Should be 0 (anything else is bad)
• temperature: Should be < 70°C (< 158°F)
• available_spare: Should be > 10%
• percentage_used: Wear indicator (100% = end of life)
• media_errors: Should be 0
• error log entries: Review for I/O errors

For SATA/SAS:

• SMART overall-health: Should be PASSED
• Reallocated_Sector_Ct: Should be 0 (or very low)
• Current_Pending_Sector: Should be 0
• Offline_Uncorrectable: Should be 0
• UDMA_CRC_Error_Count: High values indicate cable/connection issues
• Temperature: Should be < 55°C

Step 7: Check OSD Performance Metrics

# From any Ceph node, check OSD performance
ceph osd perf
# Check OSD utilization
ceph osd df
# Check for current slow operations (run on the OSD's host)
ceph daemon osd.<number> dump_ops_in_flight
# Check historic slow operations (run on the OSD's host)
ceph daemon osd.<number> dump_historic_slow_ops

Step 8: Monitor I/O Performance (Optional)

# Install sysstat if not present
apt install sysstat -y
# Monitor real-time I/O stats (watch for high await times or %util)
iostat -x <device> 2 5
# Example for NVMe:
iostat -x nvme1n1 2 5
# Example for SATA:
iostat -x sda 2 5
Key metrics to watch:
%util: > 90% consistently = saturated disk
await: > 10ms = slow responses
r_await / w_await: Read/write latency separately

Step 9: Check System Logs

# Check for disk-related errors in dmesg
dmesg -T | grep -i "<device>" | tail -50
# Example:
dmesg -T | grep -i nvme1n1 | tail -50
# Check systemd journal for Ceph or disk issues
journalctl -u ceph-osd@<number> --since "1 hour ago"
# Example:
journalctl -u ceph-osd@6 --since "1 hour ago"

Step 10: Common Issues and Resolutions

Issue: Slow Operations During Rebalancing

ceph health mute BLUESTORE_SLOW_OP_ALERT --sticky

Issue: High Media Errors or Reallocated Sectors

# Mark OSD out (triggers data migration)
ceph osd out <osd-number>
# Monitor rebalancing
watch ceph -s
# Once complete, remove OSD
ceph osd down <osd-number>
ceph osd rm <osd-number>
ceph auth del osd.<osd-number>
ceph osd crush rm osd.<osd-number>

Issue: High Temperature

Issue: Disk Full

ceph osd df tree
ceph osd reweight <osd-number> <weight>

Quick Reference Checklist

# 1. Identify problem OSD
ceph health detail
# 2. Find host
ceph osd find <osd-number>
# 3. SSH to host
ssh <hostname>
# 4. Find physical disk
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE
# 5. Check health (NVMe)
nvme smart-log /dev/<device>
# 5. Check health (SATA)
smartctl -a /dev/<device>
# 6. Check OSD performance
ceph osd perf
ceph daemon osd.<number> dump_historic_slow_ops
# 7. Monitor I/O
iostat -x <device> 2 5
# 8. Check logs
journalctl -u ceph-osd@<number> --since "1 hour ago"

Let's look at how to install PegaProx in your home lab. Take a look at my full write up on PegaProx here: Managing Multiple Proxmox Clusters Gets Messy When You Want Smarter Placement.

Interestingly, PegaProx provides both VM and LXC container templates you can download from their mirrors that already have PegaProx installed. You can install it in a Docker container as well, but this is noted to be a dev-only type solution. When you provision these, they have a quick wizardized provisioning process to configure PegaProx in your environment.

Download the images from the Pegaprox site here: PegaProx.

I picked the LXC container image. You download the image, and then copy this to your Proxmox host or just curl the image URL from your Proxmox host directly if you have it connected to the Internet.

Once you pull down the backup image they provide, you can import it into Proxmox using the commands below for each respective image type. Be sure to change out the ID for the VM or LXC container and also what storage you want to target.

# For VM
qmrestore /var/lib/vz/dump/vzdump-qemu-XXX-YYYY_MM_DD-HH_MM_SS.vma.zst 100 --storage local-lvm

# For Container
pct restore 100 /var/lib/vz/dump/vzdump-lxc-XXX-YYYY_MM_DD-HH_MM_SS.tar.zst --storage local-lvm

# Replace:
#   100 = Your desired VM/CT ID
#   local-lvm = Your target storage name
#   File path = Path to your downloaded backup

Below you can see me running the command for the downloaded image and getting this restored to my Proxmox server host.

I like how easy they have made this to get up and running. When you first login with the default username and password which are the below:

Container:

Virtual machine:

Then it will launch the configuration wizard you see below. You will set up your network connection and choose which port you want to run it on. It defaults to port 5000, 5001, 5002.

Setting a new password, etc.

At this point once the configuration wizard is ran, you can connect to the IP address and port configuration and login with the default password:

• user: pegaprox
• pass: admin

After you get logged in for the first time, this is what the all clusters overview screen by default looks like.

pvecm status

This will show you the current status of your Proxmox cluster. Then to remove the selected node, you run the following command:

pvecm delnode <nodename>

However, you may have times when you run this command, it says it worked, but you still see the node listed in the Proxmox web UI. When this happens check the directory located here to see if there is a directory still showing for the deleted node:

ls /etc/pve/nodes

If you see the deleted Proxmox cluster node listed here, then you can delete the folder representing the node:

rm -rf /etc/pve/nodes/<nodename>

Check the web UI to make sure the node is gone.

First confirm your storage ID:

grep -Rho --include="*.conf" -E '^(scsi|virtio|sata|ide)+:\s*+:' /etc/pve/nodes/*/qemu-server/*.conf \
| sed -E 's/^(scsi|virtio|sata|ide)+:\s*(+):.*/\2/' \
| sort -u

In this output, my storage id was "rbd-vm:

STORAGE_ID="rbd-vm"

# Get list of HA-managed VMIDs
HA_VMS=$(ha-manager config | awk '/^vm:/{print $1}' | sed 's/vm://')

for cfg in /etc/pve/nodes/*/qemu-server/*.conf; do
  id=$(basename "$cfg" .conf)

  # Skip if already HA-managed
  if echo "$HA_VMS" | grep -qx "$id"; then
    continue
  fi

  # Skip templates
  if grep -q '^template: 1' "$cfg"; then
    continue
  fi

  # Skip vbr-worker VMs
  name=$(awk '/^name:/{print $2}' "$cfg")
  if []; then
    continue
  fi

  # Only include Ceph RBD-backed VMs
  if grep -q "${STORAGE_ID}:" "$cfg"; then
    ha-manager add "vm:$id" --state started
    echo "Added vm:$id ($name) to HA"
  fi
done

Just like Proxmox VE Server, you need to add the no subscription repository to your PDM server as you can see I have done below.

Then refresh the updates that are available. Once you have done that, you can apply the updates. It will launch the pop-up dialog like it does with Proxmox VE Server and you will type a Y to confirm.

That is all there is to it. Once the updates apply, you can refresh the interface and it should reflect a new version listed for Proxmox Datacenter Manager.

Deploying the OVA appliance in vSphere

This is just classic OVA deployment in vSphere but below are the screenshots of the process for my home lab.

Selecting the name and folder location.

Select a compute resource where you want the OVA to be deployed.

Review the initial details that it shows in the OVA wizard.

Select the target storage for the OVA appliance deployment.

Select the virtual network where you want to attach it.

Ready to complete the OVA deployment wizard.

Starting the appliance and initial configuration wizard

Once the appliance is deployed, power it up. You will see the appliance boot as below.

It will then kick off an initial configuration wizard for Veeam. First, accept the EULA.

Next, set the hostname for the appliance.

Next, configure your network settings.

On the next step, you will be able to configure your NTP setup.

Next, set your veeamadmin password.

Be sure to set something that is super complex, it will only allow 3 characters of the same type in a row.

Setup MFA for your user account.

Configure a security officer account. This is optional and you can check the box to skip this part if you want.

Summary screen of the initial configuration settings.

It will apply the configuration settings and restart all the services.

The appliance will reboot and you will see something similar to the below on the console. This allows you to see how you connect to the appliance.

When logging in, the first thing it will do is update the host components and apply updates.

Hopefully, this walkthrough of how to install the Veeam hardened linux appliance using the OVA appliance in a VMware vSphere environment works. The process is straightforward and intuitive in classic Veeam fashion. Enjoy!

Let's Encrypt is starting to move toward SSL/TLS certificates for IP addresses, not just DNS names. That’s something we haven’t really had from public CAs before, and it solves a pretty common problem.

What does this mean in plain terms?

Right now, if you hit something like: https://192.168.1.50

You either:

• Get a browser warning

• Use a self-signed cert

• Or create a fake/internal DNS name just to make HTTPS happy

With this change, you’ll be able to get a trusted HTTPS certificate for an IP address directly and you won't need a domain name.

Why this actually matters

This comes up way more often than people might think, especially in labs or development environments. Think about things like the following URLs where we usually get a certificate warning:

• Proxmox, ESXi, or appliance web UIs

• NAS management pages

• Firewalls and switches

• Internal dashboards

• Test services you don’t want to bother putting behind DNS

A lot of us just live with browser warnings for these, but this will give us a better way moving forward.

A couple important gotchas

This isn’t magic and there are limits.

• These certs are IP-only. Currently, if I am reading this right, you can’t mix DNS names and IPs in the same cert, so this will cause some complexity and either/or scenarios

• Validation is done via HTTP-01 or TLS-ALPN-01

• Let’s Encrypt needs to be able to reach that IP during issuance

So this isn’t for completely isolated internal-only IPs unless you already have a way to expose them temporarily to get a cert issued.

This doesn’t replace normal DNS certs

If you already have proper DNS and domain-based certs, nothing really changes there. DNS certs are still the cleanest solution long-term. This new solution as part of upcoming changes will just give admins another option to help reduce some challenges they may face. It will also help with bad habits like ignoring cert warnings and it will make IP access only much cleaner and trustworthy.

Why this may be a big deal for home labs

Most of us start out accessing things IP-only. DNS comes later in the lab (a soon later). And then it means you need a public DNS name that you can use for proper SSL certificate issuance. So many likely don't start with this out of the gate. So these upcoming changes will help to run secure HTTPS earlier, avoid self-signed certificates that can be a nightmare to manage and make management feel more production-grade.

Rollout timing

This is still rolling out, so don’t expect everything to work right away. ACME clients and reverse proxies will need updates. If you’re using Certbot, Traefik, Caddy, Nginx, etc., support will depend on client updates.

Read their blog here: Upcoming Changes to Let’s Encrypt Certificates - API Announcements - Let's Encrypt Community Support

Curious how others here might use this. Proxmox UI? Network gear? Temporary lab services? I think we also need more information on the requirements and limitations of needing to have Let's Encrypt be able to access the IP for issuance.