[TOPIKUNIK] Proxmox, une solution de virtualisation kellébien !

Recherche :

Sujet(s) à lire :
- VirtualBox /VMWare mais surtout Xen ...Mangez en...

Mot : Pseudo : Filtrer Aller à la page :
Page : 1 2 3 4 5 .. 84 85 86 .. 200 201 202 203 204 205 Page Suivante Page Précédente Bas de page
Auteur	Sujet : [TOPIKUNIK] Proxmox, une solution de virtualisation kellébien !

eeeinstein

Électricien au CERN

Reprise du message précédent :
Fstab

Normal pour la RAM et Plex

Message cité 1 fois
Message édité par eeeinstein le 22-04-2019 à 16:38:47

Publicité

sir_siegfrieds

Besoin de Sous Besoin de Vous

eeeinstein a écrit :

Fstab

Normal pour la RAM et Plex

Dans Fstab, j'ai tout mis en auto, no fail, Default etc.
Rien ni fait en reboot, je dois faire mount -a

eeeinstein

Électricien au CERN

Il doit te manquer un paramètre, j'ai pas de soucis chez moi.

Message édité par eeeinstein le 22-04-2019 à 17:14:48

sir_siegfrieds

Besoin de Sous Besoin de Vous

Ben explique moi donc quels parametre ?

Message cité 1 fois

l0g4n

Expert en tout :o

sir_siegfrieds a écrit :

Ben explique moi donc quels parametre ?

Celui qu'on peux deviner comme ça, sans voir ta conf. Au lieu d'être pédant, montre ton fstab et détail un peu ton fonctionnement (NFS dans une autre VM ? Sur un NAS ?).

---------------
Fort et motivé. Sauf parfois.

depart

Je pose ça là même si c'est pas spécifique à proxmox, mais avec la virtualisation et la multiplication des VM, on se retrouve vite avec un paquet de linux indépendants, ce qui multiplie la quantité de "machines" à mettre à jour.
Quelles sont vos stratégies pour suivre un peu les mises à jour, aussi bien en terme d'OS que d'applications (typiquement Apache, PHP, ...) ?

Là j'ai 3 dédiés chez OVH (serveurs web) + 4 "serveurs" chez moi (2 proxmox + 2 Pi) + 4-5 VM (serveur web, OMV, Ubiquiti Unifi, ...) ça commence à être la misère de suivre tout ça, entre les versions de PHP deprecated et plus unifiées d'un serveur à l'autre, les clusters qui feraient mieux d'avoir toujours des versions synchros, les machins qu'on oublie (les pi avec leur pihole et autre domoticz) j'ai l'impression de passer mon temps dans les apt upgrade et compagnie (avec des pétages de trucs régulièrement, genre changement de version de php, des apache pas à jour sauf à forcer des repos "ppa:ondrej" )...

Bref, vous avez une stratégie ? Des outils ?

Message édité par depart le 23-04-2019 à 13:25:43

XaTriX

management de conf: puppet, ansible, etc

---------------
"Xat le punk à chien facho raciste. C'est complexe comme personnage." caudacien 05/10/2020

l0g4n

Expert en tout :o

Satellite ou Katello+TheForeman

---------------
Fort et motivé. Sauf parfois.

XaTriX

tu vas finir commercial ibm à ce rythme

---------------
"Xat le punk à chien facho raciste. C'est complexe comme personnage." caudacien 05/10/2020

l0g4n

Expert en tout :o

Si seulement

---------------
Fort et motivé. Sauf parfois.

Publicité

XaTriX

tu me fais peur

---------------
"Xat le punk à chien facho raciste. C'est complexe comme personnage." caudacien 05/10/2020

sir_siegfrieds

Besoin de Sous Besoin de Vous

C'est une VM tournant sous debian, le fstab ressemble a ça
qnapplex/souvenir /nas/souvenir nfs auto,defaults,nofail 0 0

Qnap correspondant a l'ip de mon Qnap enregistrer sur le fichier host.
Ce qui ne fait pas monter mes disque au démarrage de ma VM.

Les Vms sont sur Proxmox, et démarrage auto en cas de redémarrage de proxmox

depart

J'ai mis à jour proxmox sur mes nodes (5.4 désormais) et visiblement ça a pété la réplication ZFS

2019-04-24 09:33:00 100-0: start replication job
2019-04-24 09:33:00 100-0: guest => CT 100, running => 1
2019-04-24 09:33:00 100-0: volumes => rpool:subvol-100-disk-0
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) Someone could be eavesdropping on you right now (man-in-the-middle attack)!
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) It is also possible that a host key has just been changed.
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) The fingerprint for the RSA key sent by the remote host is
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) SHA256:blablablablablabla.
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) Please contact your system administrator.
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) Add correct host key in /root/.ssh/known_hosts to get rid of this message.
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) Offending RSA key in /etc/ssh/ssh_known_hosts:3
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) remove with:
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) ssh-keygen -f "/etc/ssh/ssh_known_hosts" -R node2
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) RSA host key for node2 has changed and you have requested strict checking.
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: (remote_prepare_local_job) Host key verification failed.
2019-04-24 09:33:00 100-0: (remote_prepare_local_job)
2019-04-24 09:33:00 100-0: end replication job with error: command '/usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=node2' root@192.168.1.12 -- pvesr prepare-local-job 100-0 --scan rpool rpool:subvol-100-disk-0 --last_sync 1555975800' failed: exit code 255

J'ai dégagé la clé de /etc/ssh/ssh_known_hosts ... du coup ça pète toujours la réplication car il n'y a plus d'autorisation
J'ai tenté un "ssh 192.168.1.12" (ip du node2, en root, depuis le node1), ajouté la clé... mais ça le fait pour root, pas pour tous les users... et c'est pas la même tronche de clés entre /root/.ssh/known_hosts et son pendant dans /etc/ssh donc je me vois mal copier l'un verswl'autre
Je suis censé faire quoi ???

Message édité par depart le 24-04-2019 à 09:39:45

l0g4n

Expert en tout :o

Donne un peu de détails sur les known_hosts et aurhorized_keys que tu as .

---------------
Fort et motivé. Sauf parfois.

depart

node 1 (source de la réplication, 192.168.1.7)
/etc/ssh/known_hosts :

node1 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCiTKSLP3SDBt0UeNXICzx51P99rk7Bqc1ICutWYYnH3Q4EBMYqI+ooeCOSVCL3F97UW08e587OuSxaUiwPH+fCIDoFR3GtzXZJezRqH2DW3nMR+pYR8DNrvHhr5Wa8Uj3S0eDJGEIX87BMb52NrFe03weD7AAbF
192.168.1.7 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCiTKSLP3SDBt0UeNXICzx51P99rk7Bqc1ICutWYYnH3Q4EBMYqI+ooeUVCL3F97UW08e5SxaUiwPH+fCIDoFR3GtzXZJezRqH2DW3nMR+pYR8DNrvHhr5Wa8Uj3S0eDJGEIX87BMb52NrFe03weD7AAbF
node2 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDCZJ5s6n3ooipKR9A86Pa9DKKaijpkC0AR0X8zYJbMk9jXkwAxSe9vvBfwI3ggQepvirGtOZj6AbxlD6r7VLOZ11SCCaV6PiayjRwVZkxVGkdjVPBPp7ppCgOVNpfqbAlWd85XOpvrfC7TDcEWRktfdu3vs9i5x
192.168.1.12 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDCZJ5s6n3ooipKR9A86Pa9DKKaijpkC0AR0X8zYJbMk9jXkwAxSe9vff1JIKUxVh0sQepvirGtOZj6AbxlD6r7VLOZ11SCC+AEaHkdjVPBPp7ppCgOVNpfqbAlWd85XOpvrfC7TDcEWRktfdu3vs9i5x

/root/.ssh/authorized_keys :

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAIAlqCidifubjl1Q4abW7C6oBvgZcjetfcv1M7dyGuQ8GBNwY3+5pOQVL6FzaWNF6M6fL1dvrlPfAOfFszpPS4o1vld4eoRW9r401GF5ftOtrTcNNvNUQHmmMvWMiqowngNX21FTTUa79nqC510RYn+pT root@node1
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCdotRx61ZeMiPYvIdNGJRbfBJG3KUXvmPh5xEvAg5sAWtZZzxei86zFP6cndW3gAhgaYsFK8UMU3Ra+ZQlaU9DwJGbMUfeytXZDuwBmTk25d9bYQbpImAEFFI8s7SV+qIydAWE7oyDWJjFNvgv2FRaiMdN root@node2
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0nudCA8nrIJkQOxuiPscyuO4iUXB3MX9a8UL7lXgiMoaPGR2r2KBzTjOEAueX+ZSWPj67XfSKQkW2ex4PxNekCYfAdQPYG9k3D0gKbaF5yKdozxiB1LFmSUBZYGL4sGjEmv3TcG1IkqPf9rISzj4m2nyj root@node2
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+z2EzKHRD0v0dsUzAI3NMAfLjIQAZg7dq7Z+LSs1h7IvE4nN+18f5zj47j1tHLNhD2qx8LZJ7ZLNsdEK6SsyzJXAV9qIWJiy37uNBD74nucKK4r2MxaZhWZLvBzwmjAh9CjeNMT69IMjHuiDXUbLWhyxf root@node2

node2 (destination, 192.168.1.12) :
/etc/ssh/known_hosts :

node1 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCiTKSLP3SDBt0UeNXICzx51P99rk7Bqc1ICutWYYnH3Q4EBMYqI+ooeU3bAzuirKx8XqduQVcMdN64zSPuvED140J7DGtzXZJezRqH2DW3nMR+pYR8DNrvHhr5Wa8Uj3S0eDJGEIX87BMb52NrFe03weD7AAbF
node2 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDCZJ5s6n3ooipKR9A86Pa9DKKaijpkC0AR0X8zYJbMk9jXkwAxSe9vvBfwI3ggYhKTFAe3gvLFzkesaF6AyPkagTUTaV6PiayjRwVZkxVGkdjVPBPp7ppCgOVNpfqbAlWd85XOpvrfC7TDcEWRktfdu3vs9i5x
192.168.1.12 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDCZJ5s6n3ooipKR9A86Pa9DKKaijpkC0AR0X8zYJbMk9jXkwAxSe9vvBfwI3ggYhLdnQvLFzkesaF6AyPkaYXXAu4VjRwVZkxVGkdjVPBPp7ppCgOVNpfqbAlWd85XOpvrfC7TDcEWRktfdu3vs9i5x

Marrant comme sur le node2 il n'y a pas duplication de la ligne avec l'ip du node1 (192.168.1.7), mais j'ai tenté de l'ajouter, ça ne change rien (et le problème n'a pas l'air - de toute façon - d'être dans ce sens)

/root/.ssh/authorized_keys :

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAIAlqCidifubjl1Q4abW7C6oBvgZcjetfcv1M7dyGuQ8GBNwY3+5pOQVL6FzaWNF6M6fL1dvrlPfAOfFszpPS4o1vld4eoRW9r401GF5ftOtrTcNNvNUQHmmMvWMiqowngNX21FTTUa79nqC510RYn+pT root@node1
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCdotRx61ZeMiPYvIdNGJRbfBJG3KUXvmPh5xEJAyplwIlvOqOpeagXXFjyaz7DrGtBSR65lPpN3U2dqv3QlaU9DwJGbMUfeytXZDuwBmTk25d9bYQbpImAEFFI8s7SV+qIydAWE7oyDWJjFNvgv2FRaiMdN root@node2
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0nudCA8nrIJkQOxuiPscyuO4iUXB3MX9a8UtzDzvKA100ECd01llsePZ+wwD2AUR9U1VsIiaizly3stxgyxNekCYfAdQPYG9k3D0gKbaF5yKdozxiB1LFmSUBZYGL4sGjEmv3TcG1IkqPf9rISzj4m2nyj root@node2
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC+z2EzKHRD0v0dsUzAI3NMAfLjIQAZg7dq7Z+1tHLNhD2qx8LZB3+LFKQW8PUE5OVKyLTbSwS9v8ywAwHN8SsyzJXAV9qIWJiy37uNBD74nucKK4r2MxaZhWZLvBzwmjAh9CjeNMT69IMjHuiDXUbLWhyxf root@node2

/root/.ssh/id_rsa.pub :

ssh-rsa AAAB3NzaC1yc2EAAAADAQABAAABAQC+z2EzKHRD0v0dsUzAI3NMAfLjIQAZg7dq7Z+1tHLNhD2qx8LZB3+LFKQW8PUE5OVKyLTbSwS9v8ywAwHN8SsyzJXAV9qIWJiy37uNBD74nucKK4r2MxaZhWZLvBzwmjAh9CjeNMT69IMjHuiDXUbLWhyxf root@node2

Nota : j'ai altéré/raccourci les clés mais conservé les débuts et fins réelles.

wow... il y a aussi des clés dans /etc/pve/priv... je regarde... mais ça a l'air identique.

Pour info aucun souci pour lancer manuellement une connexion ssh d'un node vers l'autre (en root, sans saisir de mot de passe).

Message édité par depart le 24-04-2019 à 11:56:25

depart

grr. Solution :

pvecm updatecerts

et ça remarche !

Message cité 1 fois
Message édité par depart le 24-04-2019 à 12:30:38

webmail-75000

bien vu !

---------------

XaTriX

depart a écrit :

grr. Solution :

pvecm updatecerts

et ça remarche !

évidemment [:dawao]

---------------
"Xat le punk à chien facho raciste. C'est complexe comme personnage." caudacien 05/10/2020

sir_siegfrieds

Besoin de Sous Besoin de Vous

Logan cela s'adressait a moi ?

depart

Un peu de bizareries... j'ai remis le nez dans mes problèmes de performances de partage samba (VM OpenMediaVault, volume ZFS chiffré LUKS sur un disque de 8To, passé "ouvert" à la VM)

J'ai des grosses irrégularités dans les débits, surtout en écriture.
Globalement ça démarre plein pot et ensuite fait des gros yoyos, avec parfois des pauses, parfois pas, des débits qui tombent à quelques Mo/sec puis remontent...

J'ai testé :
- Remplacer samba par un montage NFS, jamais réussi à gérer l'accès depuis mon pc sous Windows, ça sent la galère de droits à plein nez
- tester le transfert depuis une VM Windows sur la même machine : même genre de comportement avec débits erratiques (laisse penser que le pb n'est pas réseau
- ajouter une carte réseau, la passer à OMV en PCI passthrough et l'utiliser pour les transferts : même comportement

- jouer sur les modes de cache (writeback ou aucun), pas de changement notable
- tester via SCP direct entre l'hôte et la VM OMV, c'est nettement plus stable (sans avoir des débits de folie non plus)

pve c'est l'hôte (avec /root sur un ssd), et 192.168.1.13 c'est la VM OMV (et son disque de 8To) :

root@pve:~# scp -P2212 192.168.1.13:/srv/dev-disk-by-id-scsi-0QEMU_QEMU_HARDDISK_drive-scsi1/P/jenaimarredeflouter.mp4 /root
jenaimarredeflouter.mp4 100% 3725MB 42.8MB/s 01:27
root@pve:~# scp -P2212 /root/jenaimarredeflouter.mp4 192.168.1.13:/srv/dev-disk-by-id-scsi-0QEMU_QEMU_HARDDISK_drive-scsi1/P/jenaimarredeflouter2.mp4
jenaimarredeflouter.mp4 100% 3725MB 87.8MB/s 00:42

Donc 42.8 Mo/sec en moyenne en lecture depuis la VM et 87.8 Mo/sec en écriture, avec un débit au départ très élevé (genre 200 Mo/sec, puis qui descend doucement).
WTF ?

Message édité par depart le 24-04-2019 à 22:52:06

l0g4n

Expert en tout :o

Et sans passer par le réseau, tu as des soucis de débit aussi ? T'a nic virtuelle est bien en virtio ?
La charge CPU dit quoi pendant le transfert ? Sur chaque core avec htop par exemple.

Message cité 1 fois
Message édité par l0g4n le 24-04-2019 à 23:07:15

---------------
Fort et motivé. Sauf parfois.

depart

l0g4n a écrit :

Et sans passer par le réseau, tu as des soucis de débit aussi ? T'a nic virtuelle est bien en virtio ?
La charge CPU dit quoi pendant le transfert ? Sur chaque core avec htop par exemple.

Sans passer par le réseau tu suggères quoi comme test pour avoir une info de débit ?

Pour la charge CPU pendant un transfert, elle est assez importante, sur les 4 coeurs (j'en ai filé 2 à la VM OpenMediaVault sur les 4 dont je dispose), et elle évolue relativement en corrélation avec le débit, c'est-à-dire que quand je vois dans ma fenêtre de transfert windows que le débit s'écroule, l'occupation cpu s'écroule aussi.

Dans l'autre sens (en lecture depuis le NAS) le transfert se fait à 112Mo/sec sans broncher tout du long, occupation CPU tranquille :

Sinon je viens de refaire le test scp d'hier... lol

root@pve:~# scp -P2212 192.168.1.13:/srv/dev-disk-by-id-scsi-0QEMU_QEMU_HARDDISK_drive-scsi1/P/jenaimarredeflouter.mp4 /root
jenaimarredeflouter.mp4 100% 3725MB 265.4MB/s 00:14
root@pve:~# scp -P2212 /root/jenaimarredeflouter.mp4 192.168.1.13:/srv/dev-disk-by-id-scsi-0QEMU_QEMU_HARDDISK_drive-scsi1/P/jenaimarredeflouter2.mp4
jenaimarredeflouter.mp4 100% 3725MB 64.2MB/s 00:58

En le relançant une 2è et 3è fois (j'avais oublié de regarder ce qui se passe dans htop) :
débit en lecture :
1e fois : 265 Mo/sec
2e fois : 101 Mo/sec
3e fois : 177 Mo/sec
lol
en écriture :
1e fois : 64 Mo/sec
2e fois : 61 Mo/sec
3e fois : 74.4 Mo/sec
Ce qui est bizarre, c'est que le débit au départ est entre 200 et 300 Mo/sec, l'occupation CPU s'envole sur les 4 coeurs et finit par être à 100% partout, à partir de là le débit descend, et l'occupation cpu... ça dépend, soit ça reste au taquet, soit elle redescend et varie au prorata du débit... bizarre, très bizarre !

Message édité par depart le 25-04-2019 à 08:08:48

kaari

Fuck Yeah !

C'est quoi ton cpu ?
Quelle encryption luks ?

Message édité par kaari le 25-04-2019 à 08:03:22

---------------
Mon topic ventes ;)

l0g4n

Expert en tout :o

Euh, cp ?!

Message cité 1 fois

---------------
Fort et motivé. Sauf parfois.

depart

cpu i3-8100 (4 coeurs 3.6 Ghz)
16 go de ram

chiffrement créé ainsi :
cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 /dev/disk/by-id/ata-ST8000DM004-2CX188_WCTABCDEF
pool zfs créée ainsi :
zpool create -o ashift=12 -O normalization=formD -O atime=off -m none -R /mnt -O compression=lz4 tank /dev/mapper/8to2_chiff

l0g4n a écrit :

Euh, cp ?!

Va falloir que je sorte le chrono et la calculette alors, ou alors j'ai loupé une option pour afficher les stats

Message édité par depart le 25-04-2019 à 08:12:09

l0g4n

Expert en tout :o

date;cp toto toto2;date

Message cité 1 fois

---------------
Fort et motivé. Sauf parfois.

kaari

Fuck Yeah !

Peux-tu sortir un "cat /proc/cpuinfo" sur ton host et sur ton guest stp ?

---------------
Mon topic ventes ;)

Deadlock

Feck off, cup !

l0g4n a écrit :

date;cp toto toto2;date

time cp toto toto2 ...

Message cité 1 fois

---------------
Institutions européennes: Ensemble d'outils dont le but est de transformer une grande quantité d'argent en merde. Cette merde est utilisée pour créer de nouveaux fonctionnaires. L'argent restant payant des externes pour faire leur travail.

depart

Je commence par le plus facile :
hôte :

root@pve:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz
stepping : 11
microcode : 0x8e
cpu MHz : 1077.023
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 7200.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz
stepping : 11
microcode : 0x8e
cpu MHz : 1143.557
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 7200.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz
stepping : 11
microcode : 0x8e
cpu MHz : 1140.860
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 4
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 7200.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz
stepping : 11
microcode : 0x8e
cpu MHz : 2918.572
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 7200.00
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

VM OMV :

root@nas:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz
stepping : 11
microcode : 0x1
cpu MHz : 3600.000
cache size : 16384 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 7200.00
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz
stepping : 11
microcode : 0x1
cpu MHz : 3600.000
cache size : 16384 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves arat
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 7200.00
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

Pour info en type de CPU dans les paramètres de la VM j'avais mis "host" (justement pour profiter de l'accélération AES-NI, même si finalement la VM ne gère pas la crypto).
En tout cas merci de votre aide, c'est sympa !

Tiens je rajoute :
sur la VM :

root@nas:~# sort -u /proc/crypto | grep module
module : aesni_intel
module : aes_x86_64
module : crc32c_generic
module : crc32c_intel
module : crc32_pclmul
module : crct10dif_pclmul
module : cryptd
module : ghash_clmulni_intel
module : kernel

sur l'hôte :

root@pve:~# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 1422762 iterations per second for 256-bit key
PBKDF2-sha256 1669707 iterations per second for 256-bit key
PBKDF2-sha512 1325633 iterations per second for 256-bit key
PBKDF2-ripemd160 1028015 iterations per second for 256-bit key
PBKDF2-whirlpool 779031 iterations per second for 256-bit key
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 1090.1 MiB/s 3311.6 MiB/s
serpent-cbc 128b 90.4 MiB/s 669.5 MiB/s
twofish-cbc 128b 201.0 MiB/s 372.1 MiB/s
aes-cbc 256b 827.1 MiB/s 2652.6 MiB/s
serpent-cbc 256b 91.5 MiB/s 671.4 MiB/s
twofish-cbc 256b 203.2 MiB/s 372.2 MiB/s
aes-xts 256b 2045.6 MiB/s 2057.6 MiB/s
serpent-xts 256b 655.1 MiB/s 667.7 MiB/s
twofish-xts 256b 366.6 MiB/s 366.2 MiB/s
aes-xts 512b 1895.2 MiB/s 1895.0 MiB/s
serpent-xts 512b 655.3 MiB/s 667.3 MiB/s
twofish-xts 512b 365.4 MiB/s 366.3 MiB/s

sur la VM (mais ça n'est pas pertinent car ça n'est pas la VM qui gère LUKS) :

root@nas:~# cryptsetup benchmark
# Tests approximatifs en utilisant uniquement la mémoire (pas de stockage E/S).
PBKDF2-sha1 1452321 iterations per second for 256-bit key
PBKDF2-sha256 1699474 iterations per second for 256-bit key
PBKDF2-sha512 1264868 iterations per second for 256-bit key
PBKDF2-ripemd160 1042322 iterations per second for 256-bit key
PBKDF2-whirlpool 777875 iterations per second for 256-bit key
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 1085,4 MiB/s 3339,6 MiB/s
serpent-cbc 128b 87,2 MiB/s 685,3 MiB/s
twofish-cbc 128b 199,7 MiB/s 370,8 MiB/s
aes-cbc 256b 823,5 MiB/s 2666,9 MiB/s
serpent-cbc 256b 92,1 MiB/s 694,7 MiB/s
twofish-cbc 256b 203,3 MiB/s 371,1 MiB/s
aes-xts 256b 2071,7 MiB/s 2049,8 MiB/s
serpent-xts 256b 662,0 MiB/s 654,8 MiB/s
twofish-xts 256b 364,7 MiB/s 366,3 MiB/s
aes-xts 512b 1941,0 MiB/s 1925,3 MiB/s
serpent-xts 512b 669,0 MiB/s 654,9 MiB/s
twofish-xts 512b 363,9 MiB/s 366,2 MiB/s

Message édité par depart le 25-04-2019 à 09:10:52

l0g4n

Expert en tout :o

Deadlock a écrit :

time cp toto toto2 ...

Très juste, mais moins drôle.

---------------
Fort et motivé. Sauf parfois.

Deadlock

Feck off, cup !

C'est pas drôle non plus le calcul mental en bases 24/60/60

Message édité par Deadlock le 25-04-2019 à 09:21:17

depart

J'ai donc monté le volume ZFS de la VM directement sur l'hôte :

mount /dev/tank/vm-107-disk-0 /mnt/temp

- du volume ZFS sur le disque chiffré vers le ssd :

time cp /mnt/temp/P/jenaimarredeflouter.mp4 /root
real 0m37.576s

(pour un fichier de 3906059446 octets soit 3725 Mo)
donc en "lecture" : 99 Mo/sec
le cpu s'ennuie (2-5%).

- du ssd vers le volume ZFS du disque dur :

time cp /root/jenaimarredeflouter.mp4 /mnt/temp/P/jenaimarredeflouter2.mp4
real 0m59.127s

donc en "écriture" : 63 Mo/sec
le cpu s'ennuie tout autant (2-5%).
J'ai refait le test plusieurs autres fois : pire et meilleurs temps : 1min13 et 0min50 ! soit respectivement 51Mo/sec et 74.5 Mo/sec)

Par contre ça ne permet pas trop de savoir si c'est stable ou pas (genre 130 Mo/sec par moments et des pauses à 1 Mo/sec)

Message édité par depart le 25-04-2019 à 10:22:07

depart

J'ai "timé" aussi le transfert via scp (en démontant le volume de l'hôte et en relançant la VM)

time scp -P2212 /root/jenaimarredeflouter.mp4 192.168.1.13:/srv/dev-disk-by-id-scsi-0QEMU_QEMU_HARDDISK_drive-scsi1/P/jenaimarredeflouter2.mp4

Même genre de variatation : 1er test : 47 secondes, 2è test : 1 minute 13, 3è 1min 15
et ça n'a pas l'air "fluide", cad que le "compteur" de débit de scp fige régulièrement, ça n'est pas une progression régulière en pourcents. Au début ça se met à jour genre 1x par seconde puis au bout de qq secondes ça fige (par exemple à 42% et 250 Mo/sec) puis ça avance de manière un peu bizarre, genre 42%->45->63->81->82->91->95->100% avec des bonnes pauses à chaque fois.

Au passage dans l'interface de proxmox, j'ai le délai E/S qui monte très fortement lors des transferts, entre 30 et 50% en général.

Message édité par depart le 25-04-2019 à 10:44:04

sir_siegfrieds

Besoin de Sous Besoin de Vous

Toujours pas de réponse concernant ce probleme de mount de mes dossiers dispo sur le NAS directement sur ma VM Plex ?

J'ai donné des éléments de réponses, mais je sais pas quoi vous donner de plus comme infos ?

Merci d'avance

depart

Je poursuis mes investigations, je m'arrache vraiment les cheveux, je n'arrive pas à trouver la source du goulet d’étranglement.
Quand je pense que j'avais plus de 100Mo/sec constant en écriture avec mon disque NTFS chiffré Bitlocker sur un atom J1900 (en partage SMB) et que là j'arrive à rien d'approchant sur du matos 4 fois plus performant, ça commence un peu à me faire regretter windows

Des suggestions pour identifier d'où pourrait venir le ralentissement ?

Message édité par depart le 26-04-2019 à 14:59:01

depart

sur la VM OMV :

root@nas:/srv/dev-disk-by-id-scsi-0QEMU_QEMU_HARDDISK_drive-scsi1/P# dd if=/dev/zero of=tempfile bs=1M count=30720
30720+0 enregistrements lus
30720+0 enregistrements écrits
32212254720 bytes (32 GB, 30 GiB) copied, 204,099 s, 158 MB/s
root@nas:/srv/dev-disk-by-id-scsi-0QEMU_QEMU_HARDDISK_drive-scsi1/P# dd if=/dev/zero of=tempfile bs=1M count=10000
10000+0 enregistrements lus
10000+0 enregistrements écrits
10485760000 bytes (10 GB, 9,8 GiB) copied, 37,8126 s, 277 MB/s

Message édité par depart le 26-04-2019 à 20:36:32

ptibeur

Today you, tomorrow me

Tu n'as qu'une seule VM active à la fois ?
Il suffit qu'il y ait une autre activité disque quelconque (logs, sanity check, whatever ) pour que ça parasite les perfs de ton transfert séquentiel.

Message cité 1 fois

---------------
It ain't what you got, it's what you do with what you have... do you understand? And, it ain't what you do, it's how you do it.

depart

ptibeur a écrit :

Tu n'as qu'une seule VM active à la fois ?
Il suffit qu'il y ait une autre activité disque quelconque (logs, sanity check, whatever ) pour que ça parasite les perfs de ton transfert séquentiel.

L'hôte proxmox à 1 vm omv et 2 conteneurs (un pour le contrôleur ubiquiti (juste un point d'accès) et un serveur Web qui reçoit quelques requêtes par seconde.
Mais :
- la vm omv est la seule à toucher au disque dur étudié
- en coupant tout sauf la vm omv ça ne change rien.

Message édité par depart le 07-05-2019 à 13:46:22

depart

Petite mise à jour débit... Franchement j'ai tellement de gros lags sur les transferts de fichiers via samba vers ma VM OMV que j'ai fini par faire ce que vous évoquiez... j'ai installé samba sur l'hôte pve et :

CPU et délai E/S restent au minimum (alors que quand je passe par la VM ça explose avec au passage des énormes lags sur les autres VM, genre lors d'un gros transfert j'avais quand même des ralentissements dans un terminal ssh d'une autre VM en faisant des bêtes ls, vi... !).

Bon par contre je me retrouve donc à stocker du contenu directement sur mon volume ZFS monté (/dev/tank/dossieràlacon), ce qui sort du principe prévu par proxmox pour la gestion des réplications... (qui demande un ID de VM)

1/ Ca serait quoi le plus efficace pour faire une réplication ZFS quotidienne (programmée) du contenu de /dev/tank sur les différents nodes du cluster ?

(pour info la création de la pool zfs) :

cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 /dev/disk/by-id/ata-ST8000DM004-2CX188_WCT123456
cryptsetup luksOpen /dev/disk/by-id/ata-ST8000DM004-2CX188_WCT123456 8to2_chiff
zpool create -o ashift=12 -O normalization=formD -O atime=off -m none -R /mnt -O compression=lz4 tank /dev/mapper/8to2_chiff

2/ Au passage j'ai déjà un très gros volume (99% de l'espace du disque à la louche) passé à ma VM OMV, comment faire pour transférer le contenu de ce volume (assez plein : 949 Go de libre sur 7,16 To) vers l'espace vide vu que le volume passé à la VM a une taille fixe (je pensais justement que l'allocation ZFS était dynamique) ?
Je vous fais un schéma :

Actuellement dès que j'essaie de mettre quelque chose de + de 10 Go dans /dev/tank j'ai une erreur d'espace disque insuffisant.

3/ Si au final je fais ça, comment par exemple donner un accès DLNA aux mp3 stockés sur cet espace ? Si je garde ma VM OMV par exemple, elle prend comme source du service DLNA un dossier local, pas un partage samba. J'ai essayé de monter (dans le fstab de la VM) le partage samba, ça fonctionne (genre j'ai bien accès aux fichiers dans /mnt/pvexyz) , mais OMV ne permet pas d'utiliser cet espace. --- >EDIT : il y a un plugin "Montage distant" qui a l'air de faire l'affaire... quand j'aurai capté le système de droits un peu étranges (les contenus montés apparaissent avec root/root comme propriétaire alors qu'ils sont user1/user1 sur le dossier source sur l'hôte proxmox)

Message édité par depart le 07-05-2019 à 15:27:49

lestat67sel

:-)

Perso je stock directement sur le ZFS de l'hôte, et tous mes services sont dans des CT. Pour passer le stockage local à un container, suffit de faire un bind de dossier.

C'est simple et ça marche avec de bonne perfs sans empiler whatmille couche logiciels

Mais par contre j'ai pas la problématique de la réplication vu que j'ai qu'un seul hôte.

Message cité 1 fois

depart

lestat67sel a écrit :

t'aurais la ligne exacte de ce que tu as mis dans ton fichier de conf d'un de tes lxc stp ?
Je commence à avoir un peu de mal avec "l'inception des droits" là : entre les fichiers/dossiers créés via samba, ceux directement sur l'hôte et ceux sur le conteneur, un même fichier apparaît avec des propriétaires différents selon l'endroit où je fais un ls !!!

Message édité par depart le 07-05-2019 à 16:37:19

Publicité

Page : 1 2 3 4 5 .. 84 85 86 .. 200 201 202 203 204 205

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Linux et OS Alternatifs

Logiciels

[TOPIKUNIK] Proxmox, une solution de virtualisation kellébien !

Sujets relatifs
Choix Hyperviseur pour Xeon [Box de test]	Routage vm Proxmox
Questionnement sur un hyperviseur	[Topikunik] Personnalisation des interfaces graphiques
Plus de sujets relatifs à : [TOPIKUNIK] Proxmox, une solution de virtualisation kellébien !

Page générée en 0.074 secondes