Table of Contents
ProxMox
(wp) Proxmox Virtual Environnement (abrégé Proxmox VE ou PVE) est une plateforme de virtualisation libre (licence AGPLv3) basée sur l'hyperviseur Linux KVM, et offre aussi des conteneurs avec LXC.
Tips
Curseur VNC mal centré
En utilisant NoVNC avec un host graphique, comme Windows 11 par exemple, le curseur ne s'affiche pas au bon endroit, ce qui provoque de mis-clics intempestif et empêche carrément de se servir de la VM, tant le décalage est important.
C'est un bug qui semble se résoudre en vérifiant que le périphérique de saisie “tablet” est activé. En GUI : sélectionner la VM, et dans Options vérifier que “Use tablet for pointer” est activé (“Yes”). Dans mon cas il l'était, mais en désactivant/réactivant ce paramètre, ça a corriger le soucis de curseur !
src : https://forum.proxmox.com/threads/novnc-console-mouse-way-off-from-local-mouse.111559/
Redimensionner la taille du stockage local-lvm
Mon but est de redimensionner le stockage local-lvm, utilisé par Proxmox pour les images disque et les conteneurs ; je veux le réduire et de récupérer le téra libéré pour un usage tier.
Par défaut Proxmox partitionne le disque ainsi:
lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:0 0 1.9T 0 disk ├─nvme0n1p1 259:1 0 1007K 0 part ├─nvme0n1p2 259:2 0 1G 0 part /boot/efi └─nvme0n1p3 259:3 0 1.9T 0 part ├─pve-swap 252:0 0 8G 0 lvm [SWAP] ├─pve-root 252:1 0 96G 0 lvm / ├─pve-data_tmeta 252:2 0 15.9G 0 lvm │ └─pve-data 252:4 0 1.7T 0 lvm └─pve-data_tdata 252:3 0 1.7T 0 lvm └─pve-data 252:4 0 1.7T 0 lvm
Proxmox utilise LVM pour organiser les espaces de stockage de la 3e partition nvme0n1p3 : il créé un PV (physical volume), puis un VG (volume group) qui est par défaut divisé en LV (logical volume) pour la partition de swap (LV “swap”), / (LV “root”), et le local-lvm (LV “data”). PI le stockage local est quant à lui un sous-répertoire de / (/var/lib/vz).
N'ayant pas réussi à réduire directement le volume “data”:
lvresize -L -1500G /dev/pve/data Thin pool volumes pve/data_tdata cannot be reduced in size yet.
… je l'ai supprimé (il faut au préalable le supprimer dans la webUI : Datacenter> Storage> local-lvm → Remove)
lvremove /dev/pve/data Do you really want to remove active logical volume pve/data? [y/n]: y Logical volume "data" successfully removed.
J'en ai profité pour augmenter un peu le “root”, tant qu'à faire:
lvresize -L +100G /dev/pve/root Size of logical volume pve/root changed from 96.00 GiB (24576 extents) to 196.00 GiB (50176 extents). Logical volume pve/root successfully resized. resize2fs /dev/pve/root resize2fs 1.47.0 (5-Feb-2023) Filesystem at /dev/pve/root is mounted on /; on-line resizing required old_desc_blocks = 12, new_desc_blocks = 25 The filesystem on /dev/pve/root is now 51380224 (4k) blocks long.
J'ai programmé un check au prochain reboot, la partition étant montée il n'est pas possible de le faire à chaud:
e2fsck -f /dev/pve/root e2fsck 1.47.0 (5-Feb-2023) /dev/pve/root is mounted. e2fsck: Cannot continue, aborting. touch /forcefsck
Je recréé le volume “data”, je le convertis en thin-pool :
lvcreate -L200G -n data pve lvconvert --type thin-pool pve/data Thin pool volume with chunk size 128.00 KiB can address at most 31.75 TiB of data. WARNING: Converting pve/data to thin pool's data volume with metadata wiping. THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.) Do you really want to convert pve/data? [y/n]: y Converted pve/data to thin pool.
NB : il faut le faire avant d'allouer tout l'espace sinon on obtient l'erreur suivante:
lvconvert --type thin-pool /dev/pve/data Thin pool volume with chunk size 128.00 KiB can address at most 31.75 TiB of data. WARNING: Converting pve/data to thin pool's data volume with metadata wiping. THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.) Do you really want to convert pve/data? [y/n]: y Volume group "pve" has insufficient free space (0 extents): 25 required.
Et j'alloue tout le reste de l'espace à un nouveau LV “datarv”, que je formate en ext4 :
lvcreate -l100%VG -n data2rv pve Reducing 100%VG to remaining free space <1.47 TiB in VG. Logical volume "datarv" created. mkfs.ext4 -m 0 /dev/pve/datarv mke2fs 1.47.0 (5-Feb-2023) Discarding device blocks: done Creating filesystem with 393879552 4k blocks and 98476032 inodes Filesystem UUID: ee159ef2-f2d0-400b-af01-a8f6bf3593a3 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 Allocating group tables: done Writing inode tables: done Creating journal (262144 blocks): done Writing superblocks and filesystem accounting information: done echo "/dev/pve/datarv /mnt/datarv ext4 defaults 0 0" >>/etc/fstab mkdir -p /mnt/datarv mount /mnt/datarv
Ce qui nous donne :
df -Th /mnt/datarv Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/pve-datarv ext4 1.5T 28K 1.5T 1% /mnt/datarv lvscan ACTIVE '/dev/pve/data' [200.00 GiB] inherit ACTIVE '/dev/pve/swap' [8.00 GiB] inherit ACTIVE '/dev/pve/root' [196.00 GiB] inherit ACTIVE '/dev/pve/datarv' [<1.47 TiB] inherit lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:0 0 1.9T 0 disk ├─nvme0n1p1 259:1 0 1007K 0 part ├─nvme0n1p2 259:2 0 1G 0 part /boot/efi └─nvme0n1p3 259:3 0 1.9T 0 part ├─pve-swap 252:0 0 8G 0 lvm [SWAP] ├─pve-root 252:1 0 196G 0 lvm / ├─pve-data_tmeta 252:2 0 100M 0 lvm │ └─pve-data 252:4 0 200G 0 lvm ├─pve-data_tdata 252:3 0 200G 0 lvm │ └─pve-data 252:4 0 200G 0 lvm └─pve-datarv 252:5 0 1.5T 0 lvm
Partager un stockage local entre les LXC
(Inspiré de Using local directory bind mount points) Pour partager la partition précédemment créée entre un ou plusieurs conteneurs non privilégiés (le 100 pour cet exemple) :
Dans la conf de chaque LXC :
echo "mp0: /mnt/datarv,mp=/data # uid map: from uid 0 map 1005 uids (in the ct) to the range starting 100000 (on the host), # so 0..1004 (ct) → 100000..101004 (host) lxc.idmap = u 0 100000 1005 lxc.idmap = g 0 100000 1005 # we map 1 uid starting from uid 1005 onto 1005, so 1005 → 1005 lxc.idmap = u 1005 1005 1 lxc.idmap = g 1005 1005 1 # we map the rest of 65535 from 1006 upto 101006, so 1006..65535 → 101006..165535 lxc.idmap = u 1006 101006 64530 lxc.idmap = g 1006 101006 64530" >>/etc/pve/lxc/100.conf
Sur le système hôte:
echo "root:1005:1" >>/etc/subuid echo "root:1005:1" >>//etc/subgid chown -R 1005:1005 /mnt/datarv
Puis redémarrer le conteneur:
lxc-stop 100 && lxc-start 100
Liens:
Ajouter un SSD M.2 en passthrough sur une VM
(ref: https://pve.proxmox.com/wiki/Passthrough_Physical_Disk_to_Virtual_Machine_(VM) )
En connectant un SSD m.2 sur le châssis ProxMox il est connecté en direct sur une ligne PCI express. On peut l'ajouter en mode Passthrough sur une VM dans Proxmox, pour maximiser les performances ; l'inconvénient est que ce disque sera physiquement attaché à la VM, celle-ci ne sera pas transférable sur un autre Proxmox si on a un cluster.
La procédure se fait en ligne de commande :
Préalable potentiel…
apt install -y lshw
Vérifier qu'il est bien détecté par Proxmox
lshw -class disk -class storage *-nvme description: NVMe device product: WD Blue SN5000 4TB vendor: Sandisk Corp physical id: 0 bus info: pci@0000:01:00.0 logical name: /dev/nvme0 version: 341600WD serial: 0123456789 width: 64 bits clock: 33MHz capabilities: nvme pm msi msix pciexpress nvm_express bus_master cap_list configuration: driver=nvme latency=0 nqn=nqn.2018-01.com.wdc:guid:E8238FA6BF53-0001-001B444A41DF50DA state=live resources: irq:16 memory:5f600000-5f603fff
On doit le retrouver dans /dev/disk/by-id , en recherchant sur sa marque ou son serial:
ls -l /dev/disk/by-id | grep 0123456789 lrwxrwxrwx 1 root root 13 Apr 2 18:10 nvme-WD_Blue_SN5000_4TB_0123456789 -> ../../nvme0n1 lrwxrwxrwx 1 root root 13 Apr 2 18:10 nvme-WD_Blue_SN5000_4TB_0123456789_1 -> ../../nvme0n1
Cette commande barbare résume tous les disques détectés:
lsblk |awk 'NR==1{print $0" DEVICE-ID(S)"}NR>1{dev=$1;printf $0" ";system("find /dev/disk/by-id -lname \"*"dev"\" -printf \" %p\"");print "";}'|grep -v -E 'part|lvm' NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS DEVICE-ID(S) sda 8:0 0 3.6T 0 disk /dev/disk/by-id/wwn-0x5002538f00000000 /dev/disk/by-id/usb-Samsung_PSSD_T5_EVO_0123456789-0:0 /dev/disk/by-id/ata-Samsung_Portable_SSD_T5_EVO_0123456789 nvme0n1 259:0 0 3.6T 0 disk /dev/disk/by-id/nvme-eui.e8238fa6bf530001001b444a41df50da /dev/disk/by-id/nvme-WD_Blue_SN5000_4TB_0123456789 /dev/disk/by-id/nvme-WD_Blue_SN5000_4TB_0123456789_1 nvme1n1 259:1 0 1.9T 0 disk /dev/disk/by-id/nvme-ORICO_0123456789 /dev/disk/by-id/nvme-eui.34354536423432374ce0001830363033 /dev/disk/by-id/nvme-ORICO_0123456789_1
Dans notre cas il s'agit du WD 4 To ; on l'ajoute à la VM 103 en tant que disque scsi1 avec la commande:
qm set 103 -scsi1 /dev/disk/by-id/nvme-WD_Blue_SN5000_4TB_0123456789 update VM 103: -scsi1 /dev/disk/by-id/nvme-WD_Blue_SN5000_4TB_0123456789
Vérification:
grep 0123456789 /etc/pve/qemu-server/103.conf scsi1: /dev/disk/by-id/nvme-WD_Blue_SN5000_4TB_0123456789,size=3907018584K
Si on change d'avis, on peut toujours enlever le disque de la VM :
qm unlink 103 --idlist scsi1