how to detect on wich node is running a vm

Nov 7, 2019
1
0
21
61
hello,

is it possible to know the node on wich a vm is running on a cluster ?
so if it is the master node all is good, but if the vm is running on a
slave node, the vm is able to know that the master node if offline
and the process run a replication image of the disk that does not
contain up to date datas.

i use a cluster with 2 nodes and a linux device with corosync-qnetd
for the quorum, the replication take place early in the morning
before work , the VM is running a custom Debian V9
the two node are running pve 6.0-4

thank you for you interest

regards.
 
Hi,

so if it is the master node all is good, but if the vm is running on a
slave node, the vm is able to know that the master node if offline
and the process run a replication image of the disk that does not
contain up to date datas.

In Proxmox VE there's no master/slave, the clustering in PVE is a multi-master design, all nodes are equal.
But, you need to enable HAto get automatic recovery if a node fails.

is it possible to know the node on wich a vm is running on a cluster ?

There's the GET /cluster/resource API call which includes all cluster resources, nodes, VMs, CTs, storages.
There's the information included on what node it runs, to get a feeling you could try:
Code:
pvesh get /cluster/resources --type vm --output-format yaml
You'll see data of VMs and CTs with id and node and some other entries.
 
  • Like
Reactions: hellfire
Here a command that get's you the node name directly:

Code:
pvesh get /cluster/resources --type vm --output-format json \
   | jq -r ' .[] | select(.name == "your_vm_name") | .node'
 
Here a command that get's you the node name directly:

Code:
pvesh get /cluster/resources --type vm --output-format json \
   | jq -r ' .[] | select(.name == "your_vm_name") | .node'

Hi,

Very big thx for this command line =)
 
Or if you don't want to rely on external packages that don't ship with Proxmox (jq) just to do something that really should be part of the core API... ;)

Code:
pvesh get /cluster/resources -type vm --noborder | awk '{if($13 == "your_vm_name") print $14}'

The pvesh command itself seems oddly thought out. It prints a column called type that are invalid values as it's type input. :rolleyes:
 
Last edited:
just to do something that really should be part of the core API...
You're using the "core" API to get this info...
pvesh get /cluster/resources -type vm --noborder | awk '{if($13 == "your_vm_name") print $14}'
This is rather brittle and, e.g., doesn't work if there's a HA state, then it'd be the $14 column.

If you really are not allowed, or do not want, to install such a basic tool like jq you can always use existing interpreters like python (outputting all nodes, if there are multiple guests named the same way):

Code:
pvesh get /cluster/resources -type vm --noborder --output-format json-pretty | python3 -c "import json,sys;j=json.load(sys.stdin);print(next((d['node'] for d in j if d['name']=='YOUR_VM_NAME'), 'Guest not found'))"

Or Perl, just outputting the first it finds:
Code:
pvesh get /cluster/resources -type vm --noborder --output-format json | perl -MJSON -ne 'my $j=decode_json($_); for my $res ($j->@*) { if ($res->{type} =~ /qemu|lxc/ && $res->{name} eq "YOUR_VM_NAME") { print $res->{node}."\n"; last; }}'

Or Perl but getting all nodes for guests with the same name:
Code:
pvesh get /cluster/resources -type vm --noborder --output-format json | perl -MJSON -ne 'my $j=decode_json($_); print "$_->{node}\n" for grep { $_->{type} =~ /qemu|lxc/ && $_->{name} eq "YOUR_VM_NAME" } $j->@*;'


Both Python and Perl are widely available and installed by default on Proxmox VE, as both have native JSON modules it's way better to use such a structured format than some brittle AWK parsing.

One can also create a small shell script that makes this easier to use:
Bash:
#!/bin/sh

name="$1"
if [ -z "$name" ]; then
    printf "usage: $0 <guest-name>\n"
    exit 1
fi

pvesh get /cluster/resources -type vm --noborder --output-format json \
    | NAME="$name" perl -MJSON -ne 'my $j=decode_json($_); print "$_->{node}\n" for grep { $_->{type} =~ /qemu|lxc/ && $_->{name} eq $ENV{"NAME"}} $j->@*;'

E.g., save this as /usr/local/bin/find-guest-node on Proxmox VE nodes, make it executable (chmod +x /usr/local/bin/find-guest-node) and then you can use find-guest-node "vm name" to get the node(s).

The pvesh command itself seems oddly thought out. It prints a column called type that are invalid values as it's type input. :rolleyes:
The only thing slightly odd is that the input type's "vm" should be named "guest", as it includes all our virtual guest types.
That the return type uses the value of the specific type has also its reasons though, we had other implementations for some types like CT was openvz a long time ago. And while we always support both VMs and CTs, the underlying technology might change, thus the "different" types so that frontends could decide how to operate on a guest, as depending on the actual type different features and such are available. So input asks for guests, which makes sense as VMIDs are a single namespace between all guests, and output gives you the specific type; we see no issue there (besides, as already mentioned, that the input "vm" should be "guest", but just breaking API for that seem a lot of churn for a lot of projects that depend on us..)
 
Last edited:
You're using the "core" API to get this info...
I'm just saying that if VM ID is unique to a cluster, I'm not the first person to wish there was a convenience call (I call it this because I guess it's not needed by PVE to function) to get the node ID based on the VM ID (or indeed get a VM's info without caring what node it's on), without all of this ^^. I'm sure there is a good architectural/topology reason why this is not possible though.

besides, as already mentioned, that the input "vm" should be "guest", but just breaking API for that seem a lot of churn for a lot of projects that depend on us.
Fair enough, this does make sense.

Thank you for the perl scripts, this is appreciated! I'm against having to install additional things because it's beneficial to keep Proxmox as close to the out of the box install as possible. Cheers!
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!