How to remove old 6.17.x kernel packages when using 7.0.x kernel :
pveversion
proxmox-boot-tool kernel list
apt purge proxmox-kernel-6.17*
Virtual Machines Hypervisors : VMWare ESXi, Proxmox VE
How to remove old 6.17.x kernel packages when using 7.0.x kernel :
pveversion
proxmox-boot-tool kernel list
apt purge proxmox-kernel-6.17*
#!/bin/sh
WEB_JS=/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
if [ -s "$WEB_JS" ] && ! grep -q NoMoreNagging "$WEB_JS"; then
echo "Patching Proxmox VE Web UI nag..."
sed -i -e "/data\.status/ s/!//" -e "/data\.status/ s/active/NoMoreNagging/" "$WEB_JS"
fi
echo "Restarting Proxmox VE Web UI..."
systemctl restart pveproxy.service
This has been tested in Proxmox VE 9.1 and must be run after each update of the Proxmox User Interface. (source : https://community-scripts.github.io/ProxmoxVE/)
In the file :
/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
search for the line :
.data.status.toLowerCase() !== 'active') {
and replace with :
.data.status.toLowerCase() == 'active') {
Then, restart the Web UI :
systemctl restart pveproxy.service
Install the vmfs pckages :
sudo apt install vmfs6-tools
Mount the partition sdX1 using FUSE :
vmfs6-fuse /dev/sdX1 /mnt/media
There are hidden files in the root of any VMFS volume which start with a dot and end with the extension .sf, and some free space seems to be missing from a newly created VMFS datastore.
These system files are indexes and descriptors of the files on the VMFS filesystem and cannot be deleted.
The VMFS-3 file system organizes all space on disk in collections of resources. There are four resource types managed by the VMFS-3 file system: Blocks, sub-blocks, pointer blocks, and file descriptors.
Resources are grouped together into collections called CLUSTERs and clusters can be further grouped together into CLUSTER GROUPS.
Each resource type is managed by one of several system files which are created during the file system bootstrap process:
The VMFS-5 file system uses one additional system file:
In the Proxmox VE host, display the local disks in the Disks section and note the device you’ll be passing to your VM (e.g. /dev/sdX).
Then, run the host console in the web UI or connect via ssh.
Take note of the VM ID that the physical hard disk will be connecting to.
list the local disks available (since we’ll be passing a physical disk, ignore partitions) :
ls -n /dev/disk/by-id/
sample output :
lrwxrwxrwx 1 0 0 9 Feb 11 10:05 ata-CT1050MX30SSD1_1723175912B9 -> ../../sdb
…
lrwxrwxrwx 1 0 0 9 Feb 11 10:05 ata-CT525MX300SSD1_171816E67E70 -> ../../sdc
…
lrwxrwxrwx 1 0 0 9 Feb 11 10:05 ata-CT500MX500SSD1_21102D720097 -> ../../sda
Make sure the VM is stopped before changing its configuration.
Using the VM ID noted earlier, pass the disk to your VM either as a virtio or sata (recommended) device :
qm set VMID -sata1 /dev/disk/by-id/YYY
usage:
qm set %VMID% -%VIRTUALDEVICE% %DISKID
%VIRTUALDEVICE% can ben set as sataN where N is a digit between 0 and 5.
Then, check in the VM’s Hardware tab that the disk is listed.
Verify inside the guest OS that the physical disk is connected, then it can then be used normally as a physical disk (mount partitions, etc…)
The CPU type must be ‘host’; otherwise the VM will kernel panic while booting the installer ISO.
That’s because EL9 now requires CPUs to be compatible with the x86-64 v2 instruction set, which the default Qemu x64 exposed vCPU doesn’t support.
To allow root access on the ESXi host, change PermitRootLogin no to PermitRootLogin yes in the /etc/ssh/sshd_config file. To disable password login, ensure that the ChallengeResponseAuthentication and PasswordAuthentication are set to no.
If changes were made to the SSHd config file, reload the service :
For ESXi :/etc/init.d/SSH restart
For ESX : service sshd reload
After activating the SSH service on the ESXi host (in the web UI : Host tab > Actions menu > Services > Enable Secure Shell (SSH)), backup the original certificates :
cd /etc/vmware/ssl mv rui.key rui.key.ori mv rui.crt rui.crt.ori
For ESXi 5.x, 6.0, 6.5 and 6.7, the authorized_keys is located at :
/etc/ssh/keys-<username>/authorized_keys
Copy the generated public/private key and test the connection to the ESXi host.
(source : https://kb.vmware.com/s/article/1002866)
Create a TLS certificate (e.g. via acme.sh) and copy to the ESXi host the newly generated certificate :
scp tls_esxihost.cer root@esxihost.lan:/etc/vmware/ssl/rui.crt scp tls_esxihost.key root@esxihost.lan:/etc/vmware/ssl/rui.key
Then, reload services to serve the new certificate :
services.sh restart
(source : https://www.linuxtricks.fr/wiki/wiki.php?title=vmware-esxi-ajouter-son-propre-certificat)