For a Debian 13 box at 10.6.6.100, the setup is pretty small.

On the Debian 13 qdevice host:

sudo apt update
sudo apt install corosync-qnetd

Debian 13/Trixie ships corosync-qnetd directly, so there’s no extra repo needed. (Debian Packages)

Then make sure the service is running:

systemctl status corosync-qnetd

If it isn’t active:

sudo systemctl enable --now corosync-qnetd

Now on both Proxmox nodes, install the client-side qdevice package:

apt update
apt install corosync-qdevice

Proxmox’s documented flow is exactly corosync-qnetd on the external witness and corosync-qdevice on every PVE node. (Proxmox VE)

Make sure both miku and nezuko are online before the next step.

From either Proxmox node, run:

pvecm qdevice setup 10.6.6.100

That command does the cluster-side configuration and certificate/key exchange for you. Proxmox notes that the setup process needs SSH access to the qnetd host; either root key-based SSH must work or you can temporarily allow root password login for the setup. (Proxmox VE)

So if the Debian VM currently has root SSH disabled, one straightforward temporary approach is:

sudo passwd root

Then in /etc/ssh/sshd_config temporarily permit root login:

PermitRootLogin yes

and restart SSH:

sudo systemctl restart ssh

Run again from miku or nezuko:

pvecm qdevice setup 10.6.6.100

Once it finishes successfully, you can turn root SSH back off:

PermitRootLogin prohibit-password

or whatever your normal SSH policy is, then:

sudo systemctl restart ssh

Proxmox specifically says the cluster SSH key is automatically copied during this process. (Proxmox VE)

Finally, on either Proxmox node:

pvecm status

You want to see roughly:

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate Qdevice

and membership resembling:

Nodeid      Votes    Qdevice Name
0x00000001      1            miku
0x00000002      1            nezuko
0x00000000      1       A,V,NMW qdevice

That means:

miku        1 vote
nezuko      1 vote
10.6.6.100  1 qdevice vote

quorum = 2

So if nezuko is down:

miku + qdevice = 2 votes
                   ^
                 quorum

and vice versa. Proxmox's own example shows the same expected-votes=3 / quorum=2 arrangement. (Proxmox VE)

One networking thing I'd check

The qnetd daemon normally listens on TCP 5403, so if 10.6.6.100 is behind a firewall, allow your Proxmox nodes to reach it there. SSH also needs to be reachable during initial setup.

For example, if you're using ufw on the Debian VM:

sudo ufw allow from <MIKU_IP> to any port 5403 proto tcp
sudo ufw allow from <NEZUKO_IP> to any port 5403 proto tcp

and SSH as appropriate for your environment.

After that, you're done. The Debian VM doesn't need Corosync itself, doesn't join the Proxmox cluster as a node, doesn't get a Proxmox UI, and doesn't store any VM state. It's basically just sitting at 10.6.6.100 answering, “yes, I can see this side of the argument.”