timeout: no zvol device link

V

vikozo

Renowned Member
May 4, 2014
781
31
93
suisse
www.wombat.ch
Hallo

Ich will/muss eine VM starten die sich abgemeldet hat.
Im GUI wenn ich starte bekomme ich die Meldung:

TASK ERROR: timeout: no zvol device link for 'vm-401-disk-0' found after 300 sec found.

Wenn ich Sie migrieren will dann gibt es:

2020-11-17 19:36:58 ERROR: migration aborted (duration 00:04:59): timeout: no zvol device link for 'vm-401-disk-0' found after 300 sec found.
TASK ERROR: migration aborted

was kann man noch tun?

gruss
vinc
 
Hallo,
kannst Du das Volumen mit zfs list sehen? Was zeigt ls -l /dev/zvol/<Pfad zum zvol> an? Gibt es irgendwas auffälliges in /var/log/syslog oder mit dmesg?

EDIT: Befehl korrigiert.
 
Last edited:
Leider ging es in diesem Thread nicht weiter. Wir haben das selbe Problem. Es wurde eine VM auf einem Storage erstellt, nicht richtig war. Nun habe ich das Laufwerk der VM auf das richtige Storage umbewegt und die Konfiguration manuell angepasst. Die VM lässt sich jetzt aber nicht mehr starten und hängt ewig. Ein Backup der VM zeigt die obige Fehlermeldung. Was ist denn nun die Lösung?
 
Hallo,
Mister X said:
Leider ging es in diesem Thread nicht weiter. Wir haben das selbe Problem. Es wurde eine VM auf einem Storage erstellt, nicht richtig war. Nun habe ich das Laufwerk der VM auf das richtige Storage umbewegt und die Konfiguration manuell angepasst. Die VM lässt sich jetzt aber nicht mehr starten und hängt ewig. Ein Backup der VM zeigt die obige Fehlermeldung. Was ist denn nun die Lösung?
Click to expand...
sicher, dass es keine Referenz mehr auf die gelöschte Disk gibt? Bitte die Konfiguration der VM posten cat /etc/pve/qemu-server/<ID>.conf und pveversion -v.
 
Konfiguration:
Code: 
#172.16.10.20
#Hostname%3A vmserver7
#
#172.16.10.2 (dc01).
agent: 1
boot: order=ide2;scsi0
cores: 2
ide2: none,media=cdrom
memory: 2048
name: vmserver7
net0: virtio=AE:81:D5:86:21:1E,bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
scsi0: local-zfs:vm-105-disk-0,size=20G
scsihw: virtio-scsi-pci
smbios1: uuid=1e6fbdfa-6e0e-42ea-8347-ab0e84ad4717
sockets: 1
startup: order=2
vmgenid: 086ca507-df04-4b9e-9c44-d62d76ba19f8

pveversion -v
Code: 
proxmox-ve: 6.3-1 (running kernel: 5.4.78-2-pve)
pve-manager: 6.3-3 (running version: 6.3-3/eee5f901)
pve-kernel-5.4: 6.3-3
pve-kernel-helper: 6.3-3
pve-kernel-5.3: 6.1-6
pve-kernel-5.4.78-2-pve: 5.4.78-2
pve-kernel-5.4.55-1-pve: 5.4.55-1
pve-kernel-5.3.18-3-pve: 5.3.18-3
pve-kernel-5.3.10-1-pve: 5.3.10-1
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.1.0-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: residual config
ifupdown2: 3.0.0-1+pve3
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.20-pve1
libproxmox-acme-perl: 1.0.7
libproxmox-backup-qemu0: 1.0.2-1
libpve-access-control: 6.1-3
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.3-2
libpve-guest-common-perl: 3.1-4
libpve-http-server-perl: 3.1-1
libpve-storage-perl: 6.3-4
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.3-1
lxcfs: 4.0.6-pve1
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.0.8-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.4-3
pve-cluster: 6.2-1
pve-container: 3.3-2
pve-docs: 6.3-1
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.1-3
pve-ha-manager: 3.1-1
pve-i18n: 2.2-2
pve-qemu-kvm: 5.1.0-8
pve-xtermjs: 4.7.0-3
qemu-server: 6.3-3
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 0.8.5-pve1

Und das Backup sagt:
Code: 
105    vmserver7    FAILED    00:04:59    timeout: no zvol device link for 'vm-105-disk-0' found after 300 sec found.
 
Last edited:
Was sagen denn pvesm list local-zfs und zfs list?
 
Code: 
pvesm list local-zfs
Volid                   Format  Type              Size VMID
local-zfs:vm-100-disk-0 raw     images    107374182400 100
local-zfs:vm-101-disk-0 raw     images    107374182400 101
local-zfs:vm-101-disk-1 raw     images    751619276800 101
local-zfs:vm-106-disk-0 raw     images    107374182400 106
local-zfs:vm-107-disk-0 raw     images    107374182400 107
local-zfs:vm-200-disk-0 raw     images    107374182400 200
local-zfs:vm-202-disk-0 raw     images    161061273600 202
local-zfs:vm-203-disk-0 raw     images    107374182400 203
local-zfs:vm-206-disk-0 raw     images     65498251264 206
local-zfs:vm-214-disk-0 raw     images      2147483648 214
local-zfs:vm-214-disk-1 raw     images     21474836480 214
local-zfs:vm-215-disk-0 raw     images    161061273600 215

Code: 
zfs list
NAME                      USED  AVAIL     REFER  MOUNTPOINT
local-zfs                4.24T  2.52T      192K  /local-zfs
local-zfs/vm-100-disk-0   287G  2.72T     84.1G  -
local-zfs/vm-101-disk-0   237G  2.72T     33.9G  -
local-zfs/vm-101-disk-1  2.09T  3.91T      719G  -
local-zfs/vm-106-disk-0   203G  2.67T     51.4G  -
local-zfs/vm-107-disk-0   203G  2.70T     20.2G  -
local-zfs/vm-200-disk-0   203G  2.61T      113G  -
local-zfs/vm-202-disk-0   379G  2.82T     74.5G  -
local-zfs/vm-203-disk-0   203G  2.64T     74.5G  -
local-zfs/vm-206-disk-0   124G  2.62T     24.1G  -
local-zfs/vm-214-disk-0  4.57G  2.52T      518M  -
local-zfs/vm-214-disk-1  46.8G  2.56T     6.21G  -
local-zfs/vm-215-disk-0   305G  2.76T     61.5G  -

Erstaunlicher Weise fehlt die Platte wirklich! Im einem "updatedb" und "locate" ist sie aber auch nicht auffindbar, wobei das vermutlich damit zusammenhängt, dass ich damit das ZFS-Storage nicht auslesen kann, oder?!

Nachtrag:
Wenn ich mir das mit einem "lsblk" ansehe, finde ich dort auch die Platte der VM, sprich die "pve-vm--105--disk--0".
Code: 
# lsblk
...
nvme0n1                      259:0    0 238.5G  0 disk
├─nvme0n1p1                  259:1    0  1007K  0 part
├─nvme0n1p2                  259:2    0   512M  0 part /boot/efi
└─nvme0n1p3                  259:3    0   238G  0 part
  ├─pve-swap                 253:0    0     8G  0 lvm  [SWAP]
  ├─pve-root                 253:1    0  59.3G  0 lvm  /
  ├─pve-data_tmeta           253:2    0   1.6G  0 lvm
  │ └─pve-data-tpool         253:4    0 151.6G  0 lvm
  │   ├─pve-data             253:5    0 151.6G  0 lvm
  │   ├─pve-vm--105--disk--0 253:6    0    20G  0 lvm
  │   └─pve-vm--108--disk--0 253:7    0   150G  0 lvm
  └─pve-data_tdata           253:3    0 151.6G  0 lvm
    └─pve-data-tpool         253:4    0 151.6G  0 lvm
      ├─pve-data             253:5    0 151.6G  0 lvm
      ├─pve-vm--105--disk--0 253:6    0    20G  0 lvm
      └─pve-vm--108--disk--0 253:7    0   150G  0 lvm
 
Last edited:
Wurde bei der Installation des Knotens ZFS oder LVM konfiguriert? Oder wurde nachträglich beides konfiguriert?

Die Disk scheint jedenfalls auf der LVM thin Storage zu liegen (standardmäßig als local-lvm in PVE). Mit einem qm rescan --vmid 105 sollte diese in der VM-Konfiguration wieder auftauchen. Alternativ kann die Storage ID in der VM Konfiguration manuell korrigiert werden.
 
Ja, es ist beides konfiguriert. Und ja, die Platte wird nach dem rescan wieder erkannt. Allerdings ist die VM nicht startbar.

Dass die Platte ursprünglich auf dem local-lvm liegt, war falsch konfiguriert. Das fiel mir aber erst später auf, sodass ich die Platte per move auf das local-zfs umbewegen wollte. Danach konnte ich die VM aber nicht mehr starten, was auch jetzt noch so ist.

Das Problem scheint anderenorts zu liegen. Möchte ich jetzt über den Button "Move disk" die Platte verschieben und im Feld "Target Storage" das local-zfs auswählen, bleibt die Anzeige hängen.

Ich denke, ich werde mal das Node neu starten.
 

Attachments

  • a.png
    a.png
    18.2 KB · Views: 12
Nach dem Rescan muss die Disk noch "angesteckt" werden. Am besten vorher die nicht existierende Disk aushängen und dann die Unused Disk bearbeiten und anhängen. Dann noch bei den VM Optionen die Boot-Reihenfolge richtig stellen.
 
Ich habe das nochmal ausprobiert, leider aber mit keinem anderen Ergebnis.

Wie oben schon erwähnt, wird mir auf diesem Node das Storage nicht mehr angzeigt. Alle anderen VMs laufen zwar noch, aber ich wenn ich das Node anklicke und rechts auf "Disks" gehe, zeigt er mir ebenso kein Storage mehr an. Kann ich diesen Fehler beheben, ohne das Node neu starten zu müssen und ohne, dass mir davon die darauf noch laufenden VMs betroffen sind? Irgendein Dienst, der neu gestartet werden muss oder ähnliches?
 

Attachments

  • b.png
    b.png
    31.3 KB · Views: 9
Was ist die Ausgabe von
Code: 
systemctl status pvestatd.service pvedaemon.service pveproxy.service
pvecm status
?

Gibt es Warnungen/Fehler im /var/log/syslog?
 
Code: 
systemctl status pvestatd.service pvedaemon.service pveproxy.service
● pvestatd.service - PVE Status Daemon
   Loaded: loaded (/lib/systemd/system/pvestatd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2021-03-06 13:51:23 CET; 1 months 0 days ago
  Process: 3442 ExecStart=/usr/bin/pvestatd start (code=exited, status=0/SUCCESS)
  Process: 202305 ExecReload=/usr/bin/pvestatd restart (code=exited, status=0/SUCCESS)
Main PID: 3462 (pvestatd)
    Tasks: 2 (limit: 39321)
   Memory: 723.3M
   CGroup: /system.slice/pvestatd.service
           ├─  3462 pvestatd
           └─110097 /sbin/lvs --separator : --noheadings --units b --unbuffered --nosuffix --config report/time_format="%s" --options vg_name,lv_name,lv_size,lv_attr,pool_lv,data_percent,metadata_percent,snap_p

Apr 06 09:56:51 pve02 pvestatd[3462]: status update time (73.038 seconds)
Apr 06 09:57:55 pve02 pvestatd[3462]: status update time (64.463 seconds)
Apr 06 09:59:03 pve02 pvestatd[3462]: status update time (68.125 seconds)
Apr 06 10:00:12 pve02 pvestatd[3462]: status update time (68.682 seconds)
Apr 06 10:01:17 pve02 pvestatd[3462]: status update time (64.721 seconds)
Apr 06 10:02:25 pve02 pvestatd[3462]: status update time (68.150 seconds)
Apr 06 10:03:30 pve02 pvestatd[3462]: status update time (65.020 seconds)
Apr 06 10:04:34 pve02 pvestatd[3462]: status update time (64.463 seconds)
Apr 06 10:05:39 pve02 pvestatd[3462]: status update time (64.497 seconds)
Apr 06 10:06:47 pve02 pvestatd[3462]: status update time (68.116 seconds)

● pvedaemon.service - PVE API Daemon
   Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2021-03-06 13:51:24 CET; 1 months 0 days ago
  Process: 3460 ExecStart=/usr/bin/pvedaemon start (code=exited, status=0/SUCCESS)
Main PID: 3487 (pvedaemon)
    Tasks: 4 (limit: 39321)
   Memory: 199.7M
   CGroup: /system.slice/pvedaemon.service
           ├─  3487 pvedaemon
           ├─ 60946 pvedaemon worker
           ├─ 87355 pvedaemon worker
           └─117399 pvedaemon worker

Apr 06 08:20:55 pve02 pvedaemon[3487]: starting 1 worker(s)
Apr 06 08:20:55 pve02 pvedaemon[3487]: worker 200864 started
Apr 06 08:55:52 pve02 pvedaemon[137775]: worker exit
Apr 06 08:55:52 pve02 pvedaemon[3487]: worker 137775 finished
Apr 06 08:55:52 pve02 pvedaemon[3487]: starting 1 worker(s)
Apr 06 08:55:52 pve02 pvedaemon[3487]: worker 60946 started
Apr 06 09:10:40 pve02 pvedaemon[200864]: worker exit
Apr 06 09:10:40 pve02 pvedaemon[3487]: worker 200864 finished
Apr 06 09:10:40 pve02 pvedaemon[3487]: starting 1 worker(s)
Apr 06 09:10:40 pve02 pvedaemon[3487]: worker 117399 started

● pveproxy.service - PVE API Proxy Server
   Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2021-03-06 13:51:25 CET; 1 months 0 days ago
  Process: 3492 ExecStartPre=/usr/bin/pvecm updatecerts --silent (code=exited, status=1/FAILURE)
  Process: 3494 ExecStart=/usr/bin/pveproxy start (code=exited, status=0/SUCCESS)
  Process: 6256 ExecReload=/usr/bin/pveproxy restart (code=exited, status=0/SUCCESS)
Main PID: 3636 (pveproxy)
    Tasks: 4 (limit: 39321)
   Memory: 190.2M
   CGroup: /system.slice/pveproxy.service
           ├─ 3636 pveproxy
           ├─ 6545 pveproxy worker
           ├─16143 pveproxy worker
           └─38019 pveproxy worker

Apr 06 08:39:57 pve02 pveproxy[3636]: starting 1 worker(s)
Apr 06 08:39:57 pve02 pveproxy[3636]: worker 6545 started
Apr 06 08:42:49 pve02 pveproxy[6339]: worker exit
Apr 06 08:42:49 pve02 pveproxy[3636]: worker 6339 finished
Apr 06 08:42:49 pve02 pveproxy[3636]: starting 1 worker(s)
Apr 06 08:42:49 pve02 pveproxy[3636]: worker 16143 started
Apr 06 08:48:57 pve02 pveproxy[6337]: worker exit
Apr 06 08:48:57 pve02 pveproxy[3636]: worker 6337 finished
Apr 06 08:48:57 pve02 pveproxy[3636]: starting 1 worker(s)
Apr 06 08:48:57 pve02 pveproxy[3636]: worker 38019 started

Die einzige Meldung im syslog, die als Fehler angezeigt wird:
Code: 
Apr  6 10:00:30 pve02 pvesr[42043]: 214-0: got unexpected replication job error - command 'zfs snapshot local-zfs/vm-214-disk-0@__replicate_214-0_1617696020__' failed: got timeout
 
Ist mit dem Netzwerk und Netzwerk/Cluster-Konfiguration alles in Ordnung? Ist der Corosync-Traffic sauber von anderem Traffic separiert?
 
Das läuft und ich sehe auch keine Fehler. Das Netzewerk ist von dem PVE-Netz sauber getrennt.

Code: 
systemctl status corosync.service
● corosync.service - Corosync Cluster Engine
   Loaded: loaded (/lib/systemd/system/corosync.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2021-03-06 13:51:23 CET; 1 months 0 days ago
     Docs: man:corosync
           man:corosync.conf
           man:corosync_overview
Main PID: 3444 (corosync)
    Tasks: 9 (limit: 39321)
   Memory: 146.6M
   CGroup: /system.slice/corosync.service
           └─3444 /usr/sbin/corosync -f

Mar 06 13:51:30 pve02 corosync[3444]:   [KNET  ] host: host: 2 (passive) best link: 0 (pri: 1)
Mar 06 13:51:31 pve02 corosync[3444]:   [QUORUM] Sync members[3]: 1 2 3
Mar 06 13:51:31 pve02 corosync[3444]:   [QUORUM] Sync joined[1]: 2
Mar 06 13:51:31 pve02 corosync[3444]:   [TOTEM ] A new membership (1.c0) was formed. Members joined: 2
Mar 06 13:51:31 pve02 corosync[3444]:   [QUORUM] Members[3]: 1 2 3
Mar 06 13:51:31 pve02 corosync[3444]:   [MAIN  ] Completed service synchronization, ready to provide service.
Mar 06 13:51:42 pve02 corosync[3444]:   [KNET  ] pmtud: PMTUD link change for host: 2 link: 0 from 469 to 1397
Mar 06 13:51:42 pve02 corosync[3444]:   [KNET  ] pmtud: PMTUD link change for host: 1 link: 0 from 469 to 1397
Mar 06 13:51:42 pve02 corosync[3444]:   [KNET  ] pmtud: Global data MTU changed to: 1397
Mar 22 21:00:30 pve02 corosync[3444]:   [TOTEM ] Retransmit List: 48f7c3
 
Last edited:
Mister X said:
Apr 06 09:56:51 pve02 pvestatd[3462]: status update time (73.038 seconds)
Apr 06 09:57:55 pve02 pvestatd[3462]: status update time (64.463 seconds)
Apr 06 09:59:03 pve02 pvestatd[3462]: status update time (68.125 seconds)
Apr 06 10:00:12 pve02 pvestatd[3462]: status update time (68.682 seconds)
Apr 06 10:01:17 pve02 pvestatd[3462]: status update time (64.721 seconds)
Apr 06 10:02:25 pve02 pvestatd[3462]: status update time (68.150 seconds)
Apr 06 10:03:30 pve02 pvestatd[3462]: status update time (65.020 seconds)
Apr 06 10:04:34 pve02 pvestatd[3462]: status update time (64.463 seconds)
Apr 06 10:05:39 pve02 pvestatd[3462]: status update time (64.497 seconds)
Apr 06 10:06:47 pve02 pvestatd[3462]: status update time (68.116 seconds)
Click to expand...
Der Status-Daemon braucht sehr lange, um die Informationen zu bekommen. Vielleicht macht das Probleme. Was für Storages sind alles konfiguriert (/etc/pve/storage.cfg)? Was passiert, wenn Du pvesm status ausführst?
 
Code: 
cat /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content backup,iso,vztmpl

lvmthin: local-lvm
        thinpool data
        vgname pve
        content rootdir,images

nfs: pve-storage
        export /volume1/pve_storage
        path /mnt/pve/pve-storage
        server 172.15.10.10
        content rootdir,backup,vztmpl,images
        options vers=4.1
        prune-backups keep-last=2

zfspool: local-zfs
        pool local-zfs
        content rootdir,images
        mountpoint /local-zfs
        sparse 0

nfs: pve-iso
        export /volume2/pve_iso
        path /mnt/pve/pve-iso
        server 172.15.10.10
        content rootdir,iso,vztmpl
        options vers=4.1

pbs: pbs-b01
        datastore backup01
        server 172.16.10.110
        content backup
        fingerprint 4b:0d:77:fb:d9:c4:c3:65:7d:c4:ed:9c:d1:fa:84:ed:37:13:4c:74:00:69:db:f6:dc:b8:46:c7:12:39:5a:c7
        prune-backups keep-all=1
        username root@pam

cifs: transfer
        path /mnt/pve/transfer
        server 172.16.13.10
        share transfer
        content images
        domain jaeger-automotive.de
        prune-backups keep-all=1
        username administrator

Wenn ich pvesm status auf den anderen Nodes ausführe, dauert das ca. 2 Sekunden. Auf diesem Node dauert es in der Tat bis zu 100 Sekunden. Aber warum??? Wie ist das zu beheben? Wie schon angedroht, würde ich nötigenfalls einmal das Node neu starten.
 
Du könntest versuchen mit pvesm status --storage <storage ID> die Storages der Reihe nach durch zu probieren, um die problematische zu finden.
 
Es ist egal, welches Storage ich wähle. Es dauert immer so lange.

Ich habe mir mal mit top angesehen, ob es Prozesse gibt, die das System auslasten. Hierbei ist mir ein kvm-Prozess aufgefallen:
Code: 
 17583 root      20   0   17.4g  13.4g  15600 S 104.6   7.1  33116:16 /usr/bin/kvm -id 200 -name servername2 -no-shutdown -chardev socket,id=qmp,path=/var/run/qemu-server/200.qmp,server,nowait -mon chard+

Ich habe dann mal die VM 200 runtergefahren, woraufhin die Last auch weg war. Leider wurde mir aber das Storage in der WebGUI noch immer nicht angezeigt. Die VM habe ich wieder gestartet. Sie erzeugt aktuell auch nicht mehr diese höhere Last. - Was mein Problem leider noch immer nicht löst!
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom