Query host info for motd from VM

[jeffrey_233]

Hi All

We have about 8 proxmox hosts.
I've started loading up this motd on to my vm's https://gist.github.com/rojenzaman/2a62276739574832da5f5ab00855303f
what I'd like to be able to display here is the proxmox server name of the vm i'm connecting to.
example image.
Anyone know who I could do this easily?

 

[LnxBil]

Anyone know who I could do this easily?

This information is not exposed.

I don't know if this is easy or not for you, but you could generate a list of VMs running on your cluster via the API and export this as json to a webserver and query it from your script.

 

[bbgeek17]

I don't know if this is easy or not for you, but you could generate a list of VMs running on your cluster via the API and export this as json to a webserver and query it from your script.

Or create a PVE user with r/o (limited) permissions, generate an authtoken and send request directly to PVE, process the output and show the outcome.

---

Blockbridge: Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[jeffrey_233]

Nothing we can do via the QEMU Guest agent?
Like i reverse look up

 

[bbgeek17]

no, because the hypervisor polls the agent in the VM, the agent does not push random data.
Its also considered "bad" for a tenant in the infrastructure to know anything about underlying "cloud". It should be transparent to the tenant, so the manager of the cloud can change things at will.

---

Blockbridge: Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[jeffrey_233]

Or create a PVE user with r/o (limited) permissions, generate an authtoken and send request directly to PVE, process the output and show the outcome.

---

Blockbridge: Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

Do you know of a link to a guide to do this?

 

[jlauro]

You can adjust much of the /sys/class/dmi/id/* values on the host. Never tried, but they probably wouldn't be updated when you moved the vm to a different host unless you rebooted the vm.

You could push a message to the QEMU Guest agent, and probably put it in a crontab to run every minute or whatever so it is updated a little bit after you move it.

You may have to remove any blacklist from /etc/sysconfig/qemu-ga (el8 clones, locations/etc depends on distro), but can then do something like
for vm in $( qm list | awk '{ if ( $3=="running" ) { print $1 } }' ) ; do
qm guest exec $vm /root/messagefromhost "As of $( date), you are vmid=$vm running on $( hostname )"
done

Then put a simple script in /root/messagefromhost to store the message "$1" passed in the argument that your motd script can read.

Obviously there are potential security implications to this, especially removing the execute blacklist and it does create a background load pushing the updates.

If you have ssh keys on your host to each guest, you could simply have the host scp a file to each of it's guests.

 

[bbgeek17]

Do you know of a link to a guide to do this?

There is no single guide to do exactly what you want. Having a restricted user is an icing on the cake. For the cake recipe (API) you can start here:
https://pve.proxmox.com/wiki/Proxmox_VE_API

---

Blockbridge: Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[esi_y]

This information is not exposed.

I don't know if this is easy or not for you, but you could generate a list of VMs running on your cluster via the API and export this as json to a webserver and query it from your script.

Is it just me but I found even the idea of putting API on the same VLAN as any VM extremely bad architecture. Here the suggestion above would be much more sensible model.

 

[LnxBil]

Is it just me but I found even the idea of putting API on the same VLAN as any VM extremely bad architecture. Here the suggestion above would be much more sensible model.

Sure it's bad, yet it'll solves the problem OP asked. Having the Hypervisor and its guests in any way via network reachable could also be consided a "bad architecture", so none of the presented network-based solutions would work. Having stuff executed inside a guest by a hypervisor is also a no-go in my book.

 

[czechsys]

Try lldpd, but it will show more info than just pve hostname.