Search results

Today's update: # apt-get update Hit:1 http://security.debian.org bullseye-security InRelease Hit:2 http://ftp.debian.org/debian bullseye InRelease Hit:3 http://ftp.debian.org/debian bullseye-updates InRelease Hit:4 http://download.proxmox.com/debian/pve bullseye InRelease Reading package...

pct push <VMID> pct pull <VMID> The above can be used on the host only when the LXC container is started and running with say pct start 101. When an LXC has been created, pct set hostscript ... can be used to execute a script on the LXC guest when it is started or when it is explicitly stopped...

You will be surprised how many users still run PVE 1.9 and PVE 3.4 with OpenVZ. Many just do not want to change. Why fix it if it ain't broken and no great requirement in OS / Hardware change is there? Difficult for an old dog to learn new tricks especially if they do not want anything more...

I tried with and without the double quotes and it did not work.

When a container is created, we need to populate the VMID and the NODE name into the LXC guest. Tried the following in vain: system("pct exec $vmid -- echo $vmid $node > /root/VMID-NODE"); inside the post-start section of the hookscript. There was a "-c" parameter referred to in this post for...

This is meant for recovery and resotarion before moving onto PVE 7.x. Otherwise everyone will be stuck in PVE 3.2 and OpenVZ only and old hardware that is supported by the old kernel on older PVEs. The basic ability of using SFTP needs a working ssh key.

Thankyou. So there is no way get the hookscript to be set from the guest LXC and it has to be set from the host cli using pct set VMID --hookscript ... only and that too after the first boot is over. Hence for DAB to be aware of the VMID can we not have a script that will allow the first run...

Attempted building a Debian 6 (Squeeze) template and could not SFTP into it as the old keys were not loading. Solved it on the LXC console with: ssh-keygen -q -t rsa -f /etc/ssh/ssh_host_rsa_key -N "" <<< $'\ny' >/dev/null 2>&1 ssh-keygen -q -t dsa -f /etc/ssh/ssh_host_dsa_key -N "" <<< $'\ny'...

Having allowed snippets folder in the storage section of the Web GUI in the node and having named the script as lxc_hookscript.pl and made it 755 permissions, other than cli mode with pci set... where in the container (from template) do we put in the this script name? Otherwise, are all scripts...

Is there any means to execute scripts on the host and have the results placed in the guest LXC during first boot of the container? # dmesg | grep apparmor [ 4091.454217] audit: type=1400 audit(1665995133.442:20): apparmor="STATUS" operation="profile_load" profile="/usr/bin/lxc-start"...

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...

Any update on this in PVE 7.x?

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 ...

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...

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" /...

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`

Upgrading to PVE-7.x is not an option for the said installation as it has excessive customisation/extension. A dummy install is maintained to test updates to provide support. Production servers should not be indiscriminately upgraded - if it ain't broke, don't fix it. Migrating containers and...

Refer https://pve.proxmox.com/wiki/Cluster_Manager where mixing versions of the nodes are generally not supported with some exceptions. Other resources: https://www.unixmen.com/setting-cluster-proxmox/

For those who still use PVE 6.x, just checked today and found the following updates from the upstream Debian repos: bind9-host dnsutils libbind9-161 libdns-export1104 libdns1104 libirs161 libisc-export1100 libisc1100 libisccc161 libisccfg163 liblwres161 11 upgraded, 0 newly installed, 0 to...

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`