Reprise du message précédent :
Bonjour !
 
Je vais devoir changer le HDD de mon noeud Proxmox.
Comment est-ce que je peux faire pour exporter mes VMs ?
 
Merci !

Ton HDD actuel est toujours exploitable ? Si oui fais un clone avec "dd" et un extend de filesystems ensuite si le nouveau est plus gros.

backup!
c'est ultra simple, j'ai du le faire il y a qq semaines.
tu plug un autre disque, tu le monte sur un répertoire. (via la console)
ensuite datacenter-> storage, tu déclare un nouveau storage en mode directory, en indiquant le répertoire monté,en ajoutant dans la section "content" la ligne "vzdump backup file".
plus qu'a éteindre ta/tes vm, clic droit dessus --> backup
il restera plus qu'a faire l'option inverse  une fois ton nouveau disque configuré.
tu remonte le disque de backup, tu va voir le contenu, plus qu'a selectionner le/les fichiers de backup et tu a un bouton "restore" en haut.
tu peut aussi faire la mème chose avec un répertoire partagé, style nfs.

Sauvegarde ?

 
Oui largement
Merci je vais faire comme ça alors !

Je viens une nouvelle fois abuser de la gentillesses des linuxiens !
Pour résumer, mon hote proxmox monte un share nfs hébergé dans une de ses vm pour faire les backup de vm.
Quand je redémarre le serveur, j'éteins d'abord la vm le résultat c'est que le système ne parvient pas à démonter le share NFS.
Je voudrais savoir comment faire sous proxmox 5.1 pour lancer la commande umount -fl lors de l'arrêt de la machine.
A priori cela résoudrait mon problème !

Ou alors je fais un backup de ma VM sur une cle USB.... vu que j'ai qu'une vm et que ca rentre

Bonjour,
 
J'utilise Proxmox depuis 2 ans maintenant. Super outil. Avec le recul, une seule chose me dérange c'est les lock de VM lors des backup. Ca arrive souvent (1 fois par semaine environ) avec des VM windows ou linux. Aucun souci avec des lxc. Je connais la commande magique pour délocker (qm unlock vmdid) mais ça pour conséquence de rendre la vm inutilisable tant que l'on n'est intervenu.
 
Comment résoudre ce probleme et éviter les lock incessants ?
 
Merci.

bizarre, je l'utilise depuis 3 mois avec backup une fois par semaine (en mode stop), jamais eu de lock.
tu est en mode suspend?

Je suis en backup snapshot tous les jours.

Aucun problèmes chez moi non plus

Si ça lock, c'est que tu as une erreur durant la sauvegarde, commence par regarder les logs de sauvegarde et corrige la source du problème

+1

Voila ce que me donne  les logs du backup mais à moins que je sois à coté de mes pompes (ce n'est pas exclu) ça ne me donne pas l'origine du problème :  
 
ERROR : unexpected status
INFO: starting new backup job: vzdump --storage backup --compress gzip --mailto xxxx@xxxxx.fr --quiet 1 --all 1 --mailnotification failure --mode snapshot
INFO: Starting Backup of VM 102 (qemu)
INFO: status = running
INFO: update VM 102: -lock backup
INFO: VM Name: sagecoala
INFO: include disk 'virtio0' 'local-zfs:vm-102-disk-1' 100G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating archive '/rpool/backup/dump/vzdump-qemu-102-2017_11_04-08_00_02.vma.gz'
INFO: started backup task '784e16ee-8eb7-418a-bd11-f7eeb0edf98c'
INFO: status: 0% (107479040/107374182400), sparse 0% (15081472), duration 3, 35/30 MB/s
INFO: status: 1% (1096679424/107374182400), sparse 0% (73871360), duration 46, 23/21 MB/s
INFO: status: 2% (2151415808/107374182400), sparse 0% (114479104), duration 95, 21/20 MB/s
INFO: status: 3% (3224174592/107374182400), sparse 0% (150573056), duration 151, 19/18 MB/s
INFO: status: 4% (4295229440/107374182400), sparse 0% (169799680), duration 199, 22/21 MB/s
INFO: status: 5% (5386141696/107374182400), sparse 0% (200286208), duration 259, 18/17 MB/s
INFO: status: 6% (6442844160/107374182400), sparse 0% (205770752), duration 307, 22/21 MB/s
INFO: status: 7% (7522353152/107374182400), sparse 0% (219734016), duration 356, 22/21 MB/s
INFO: status: 8% (8601862144/107374182400), sparse 0% (248082432), duration 414, 18/18 MB/s
INFO: status: 9% (9677570048/107374182400), sparse 0% (280268800), duration 455, 26/25 MB/s
INFO: status: 10% (10749476864/107374182400), sparse 0% (370061312), duration 503, 22/20 MB/s
INFO: status: 11% (11817582592/107374182400), sparse 0% (540852224), duration 547, 24/20 MB/s
INFO: status: 12% (12891127808/107374182400), sparse 0% (691322880), duration 594, 22/19 MB/s
INFO: status: 13% (13987414016/107374182400), sparse 0% (975564800), duration 639, 24/18 MB/s
INFO: status: 14% (15044706304/107374182400), sparse 1% (1232211968), duration 679, 26/20 MB/s
INFO: status: 15% (16135618560/107374182400), sparse 1% (1314230272), duration 718, 27/25 MB/s
INFO: status: 16% (17218928640/107374182400), sparse 1% (1336397824), duration 779, 17/17 MB/s
INFO: status: 17% (18282708992/107374182400), sparse 1% (1380962304), duration 829, 21/20 MB/s
INFO: status: 18% (19351011328/107374182400), sparse 1% (1393278976), duration 920, 11/11 MB/s
INFO: status: 19% (20404240384/107374182400), sparse 1% (1451364352), duration 968, 21/20 MB/s
INFO: status: 20% (21480210432/107374182400), sparse 1% (1478610944), duration 1019, 21/20 MB/s
INFO: status: 21% (22567059456/107374182400), sparse 1% (1485434880), duration 1082, 17/17 MB/s
INFO: status: 22% (23646568448/107374182400), sparse 1% (1509847040), duration 1145, 17/16 MB/s
INFO: status: 23% (24726077440/107374182400), sparse 1% (1513549824), duration 1195, 21/21 MB/s
 

t'as pas la fin du log? car bon c'est la que l'erreur est indiquée

Ou la fin du log précédent, celui qui a provoqué le "unexpected status"
1200 secondes et t'es qu'a 23% ? 20Mo/s ? C'est vraiment pas ouf comme perfs

J'ai déjà eu des problèmes de backup qui n'allaient pas au bout ou prenaient plus de 5 heures, je me suis rendu compte par la suite qu'un peu de ménage sur le volume de backup avait permis de revenir a la normale. C'est peut être une piste a explorer.

Non je revérifie c'est tout ce qu'il y a.
J'ai fait deux copies écran pour que vous puissiez mieux voir. Déposé sur ma dropbox.
 
https://www.dropbox.com/s/18msf9upi8ata3l/img1.png?dl=0
https://www.dropbox.com/s/5m89t8p5l812dic/img2.jpg?dl=0
 

Tu préfère pas aller chercher les fichiers de logs, sur le système ?
Parceque, là, il manque clairement un bout
De tête, ils sont pas loin de là où sont stockés les fichiers de backups

Mince j'ai suivi le conseil précédent. J'ai fait le ménage dans le répertoire backup et supprimer tous les logs. Je vais devoir attendre un prochain incident pour vous partager un log

Le contenu de ce message a été effacé par son auteur

Faire du ménage en supprimant des fichiers de log de quelques ko sur un système moderne, c'est avoir un problème avec les unités de grandeur

Ou une installation sur SD de 4Go et rsyslogd en debug... Plus de log que d'OS du coup.

 
avec vzdump j'ai des perfs de merde même sur un raid 6 de 6*600Go 10k... pas trouvé d'où ca vient et pas cpu limited sur du bi E5645

Même remarque, check le remplissage de ton volume de backup, juste pour voir.

lv tout neuf dédié à ca de 3x la taille du backup

drapo

 
Le problème s'est reproduit le 07 nov lors que la sauvegarde de 20h00. J'ai regardé dans le répertoire du backup, le log concerné. Il n'y figure pas sans doute que comme le backup a été interrompu, le fichier log n'a pas été créé. Le dernier log est vzdump-qemu-102-2017_11_06-20_00_03.log. Il représente le dernier backup a s'être correctement terminé.
 
Que me conseillez-vous de faire pour résoudre ce problème ?
 
Merci

je vient de faire un test sur mon infra virtuelle, effectivement pas de log si le backup est interrompu.
par contre pas non plus de log si c'est un problème lié au nombre de backup autorisés sur le stockage, tu a vérifié que tu n'a pas atteint la limite que tu a défini?
tu ne voit rien dans le syslog de ton serveur proxmox?
car en cas de limite de nombre de stockage, pas de log, mais l'erreur apparait dans le syslog
 
si tu n'a aucune trace d'une erreur nulle part, tu devrait peut-être déjà faire un memtest et un fsck histoire d’éliminer un éventuel pb matériel.
pas de message d'erreur au lancement de proxmox? (journalctl -b -p err)
tu a quoi coté stockage comme filesystem?

et tant qu'on y est, le résultat de :
pveversion -v
cat /etc/pve/qemu-server/XXX.conf (sur une vm qui freeze)
cat /etc/pve/storage.cfg

et un screenshot de la partie "hardware" et "options" d'une vm freezant

Hu. Me parait bizarre.
Perso je ferais le tour de tout les logs système/pve, y'a forcément le problème quelque part

ok j'ai du boulot. Je prépare ça demain pour vous.

sinon tu prends la même commande et tu la passe en ssh direct et tu aura le log en direct

Oui enfin, vu la durée d'un backup, il a intérêt à la séparer du shell et à se coller les logs dans un fichier

tu fais tourner ca dans un tmux

sauf que d’après ce qu'il dit, ça ne se produit pas chaque fois, alors qu'il backup chaque jour.
y'a rien de pire a debugger que les trucs aléatoires

pveversion -v
proxmox-ve: 4.4-96 (running kernel: 4.4.83-1-pve)
pve-manager: 4.4-18 (running version: 4.4-18/ef2610e8)
pve-kernel-4.4.6-1-pve: 4.4.6-48
pve-kernel-4.4.13-1-pve: 4.4.13-56
pve-kernel-4.4.35-1-pve: 4.4.35-77
pve-kernel-4.4.13-2-pve: 4.4.13-58
pve-kernel-4.4.35-2-pve: 4.4.35-79
pve-kernel-4.4.21-1-pve: 4.4.21-71
pve-kernel-4.4.59-1-pve: 4.4.59-87
pve-kernel-4.4.44-1-pve: 4.4.44-84
pve-kernel-4.4.16-1-pve: 4.4.16-64
pve-kernel-4.4.67-1-pve: 4.4.67-92
pve-kernel-4.4.19-1-pve: 4.4.19-66
pve-kernel-4.4.83-1-pve: 4.4.83-96
lvm2: 2.02.116-pve3
corosync-pve: 2.4.2-2~pve4+1
libqb0: 1.0.1-1
pve-cluster: 4.0-53
qemu-server: 4.0-113
pve-firmware: 1.1-11
libpve-common-perl: 4.0-96
libpve-access-control: 4.0-23
libpve-storage-perl: 4.0-76
pve-libspice-server1: 0.12.8-2
vncterm: 1.3-2
pve-docs: 4.4-4
pve-qemu-kvm: 2.9.0-5~pve4
pve-container: 1.0-101
pve-firewall: 2.0-33
pve-ha-manager: 1.0-41
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u3
lxc-pve: 2.0.7-4
lxcfs: 2.0.6-pve1
criu: 1.6.0-1
novnc-pve: 0.5-9
smartmontools: 6.5+svn4324-1~pve80
zfsutils: 0.6.5.9-pve15~bpo80

root@prox2:~# cat /etc/pve/qemu-server/102.conf
agent: 1
balloon: 8
bootdisk: virtio0
cores: 4
memory: 8192
name: sagecoala
net0: virtio=6E:BF:6E:5D:64:E6,bridge=vmbr0
numa: 0
ostype: win8
protection: 1
smbios1: uuid=0b1c6b6d-203c-420d-ac75-8cb16404d8f4
sockets: 1
virtio0: local-zfs:vm-102-disk-1,cache=writeback,size=100G

root@prox2:~# cat /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content vztmpl,backup,iso
 
zfspool: local-zfs
        pool rpool/data
        content rootdir,images
        sparse 1
 
dir: backup
        path /rpool/backup
        maxfiles 30
        shared 1
        content backup

Le contenu de ce message a été effacé par son auteur

Le contenu de ce message a été effacé par son auteur