Get VMID from inside LXC Guest

[apmuthu]

Getting the VMID inside a Debian Guest:

In a Debian OpenVZ container we could use:

VMID=`awk '{print $1}' /proc/vz/veinfo`

What is the equivalent for a Debian LXC container?

 

[apmuthu]

Currently the only means (optimise if possible) is:

VMID=`cat /var/log/dmesg | \
grep "i0: port 1(" | \
grep "entered forwarding state" | \
awk '{printf $2}' | \
cut -b 5- | \
grep -o "[0-9]\+" | \
head -n1`

 

[apmuthu]

The above means to get the VMID will always return 101 or the first container number and hence is wrong.
The following is a kludge but if the Container number and the disk raw image is the same, then it should be fine:

VMID=`cat /etc/mtab | \
grep '/dev/mapper/' | \
head -n1 | \
cut -d'-' -f4`

 

[LnxBil]

The above means to get the VMID will always return 101 or the first container number and hence is wrong.
The following is a kludge but if the Container number and the disk raw image is the same, then it should be fine:

VMID=`cat /etc/mtab | \
grep '/dev/mapper/' | \
head -n1 | \
cut -d'-' -f4`

Needs optimizing on other storages, but in the end a good idea.

 

[apmuthu]

This version of VMID does not work in PVE 7.2-11.
This is because /etc/mtab now uses /proc/mounts which is symlinked to /proc/self/mounts that does not have the necessary /dev/mapper line anymore.

Even the functionality of grep has been truncated to be useless when used like grep -Ril "lxc" /

Why did Proxmox team choose to prevent the guest from knowing the VMID from within?
How is it now universally determined in a template built using DAB?

Looks like with every passing version of PVE, LXC control and functionality is being eroded.

 

[apmuthu]

The following will work from the host to get the container ID from hostname (eg., sqlamp):

# pct list | grep sqlamp
101        running                 sqlamp

# pct list | grep sqlamp | cut -d" " -f 1
101

The challenge now is to execute it from within the guest LXC container without resorting to bind mounts and shares.
Where in the host does the LXC get it's bootstrap files / symlinks?

 

[LnxBil]

The following will work from the host to get the container ID from hostname (eg., sqlamp):

a much faster way is to directly grep /etc/pve on the host. pct is very slow and would do the same, but slower.

 

[apmuthu]

Yes, on the host provides:

# cat /etc/pve/.vmlist | grep '"type": "lxc"'
"101": { "node": "pr72", "type": "lxc", "version": 6 }}

but does not provide the VMName to search for.

The conf files are listed with:

# ls -al /etc/pve/nodes/pr72/lxc
total 1
drwxr-xr-x 2 root www-data   0 Sep 18 22:45 .
drwxr-xr-x 2 root www-data   0 Sep 18 22:45 ..
-rw-r----- 1 root www-data 247 Oct 16 14:50 101.conf

Also with the node name (pr72) abstracted:

# ls /etc/pve/lxc
101.conf

And now finally for a LXC container named sqlamp, the LXC container ID would be obtained with:

# cat `grep -Ril "hostname: sqlamp"  /etc/pve/lxc/*.conf` | \
grep rootfs | \
cut -d":" -f3 | \
cut -d"/" -f1

would yield: 101

Furthermore, how do we do this from within the guest LXC?

 

[fiona]

Hi,
why do you need the ID inside the container? One could argue that since the container is containerized, it has no real business knowing its ID or any other "outside" information

 

[apmuthu]

This feature has been available since PVE 3.4. It is stopped fully in PVE 7.x.

This has been used to populate an inventory list for the end user to contact the PVE admin. When migrated to other VMIDs or nodes, it can be updated in the text file at the enduser's container.

This can be populated by some bash construct after container generation and during first start.

 

[fiona]

This feature has been available since PVE 3.4. It is stopped fully in PVE 7.x.

This has been used to populate an inventory list for the end user to contact the PVE admin. When migrated to other VMIDs or nodes, it can be updated in the text file at the enduser's container.

This can be populated by some bash construct after container generation and during first start.

What about using a hookscript (best to see the example script mentioned there) and in the post-start phase, write the ID and node name to some file within the container?