VM startet nicht automatisch

wieso hast du wenig einfluss auf die import services? du kannst die ja enablen (oder unmasken falls notwendig) Oo
 
Wegen diesem Verhalten:

Code: 
systemctl status zfs-import
○ zfs-import.service
     Loaded: masked (Reason: Unit zfs-import.service is masked.)
     Active: inactive (dead)

Code: 
systemctl unmask zfs-import

Code: 
systemctl status zfs-import
○ zfs-import.service
     Loaded: masked (Reason: Unit zfs-import.service is masked.)
     Active: inactive (dead)

Bfo
 
zfs-import ist eine template unit, du musst zfs-import@POOL oder zfs-import-scan oder zfs-import-cache enablen, je nachdem welche der variant du willst.
 
Ahhh... danke. Ich bin geborener SysVinit User ... tue mich immer noch schwer mit systemd.
Mein "store" war disabled, ich habe ihn jetzt eingeschaltet... mal sehen, wie es wirkt ...
DANKE!!!

Bfo
 
  • Like
Reactions: fabian
fireon said:
Wenns nur um das geht... so ein Timeout kannst du auch im Webinterface bei den VM's unter Optionen setzten.
Click to expand...

z.b. so:

In case your VMs/containers rely on slow-to-start external resources, for example an NFS server, you can also set a per-node delay between the time Proxmox VE boots and the time the first VM/container that is configured to autostart boots (see Automatic Start and Shutdown of Virtual Machines).
You can achieve this by setting the following (where 60 represents the delay in seconds):

Code: 
pvenode config set --startall-onboot-delay 60

Screenshot_20230805_153521.png


Oder auch je nach Anwendungsgebiet bei VM's:

Startup delay: Defines the interval between this VM start and subsequent VMs starts. For example, set it to 10 if you want to wait 10 seconds before starting other VMs.

Screenshot_20230805_153737.png
 
Hallo,

falls jemand mit dem gleichen Fehlerbild hier landet: Die von Fabian beschriebene Race-Condition ist genau das Problem. pvestatd und der Autostart der Gäste aktivieren den Storage direkt nach dem Boot fast gleichzeitig. Während der erste 'zpool import' läuft, scheitert der zweite mit "no such pool available", und beide führen 'zfs mount -a' parallel aus, was "mountpoint or dataset is busy" ergibt. Da 'zfs mount -a' schon fehlschlägt, wenn irgendein Dataset im Pool nicht gemountet werden kann, reicht bei einem Pool mit vielen Datasets (wie hier mit dem Backup-Baum) eine Kollision, damit der VM-Start scheitert.

Ich habe das als Bug #8230 gemeldet und einen Patch an pve-devel geschickt (Import und Mount pro Pool mit einem Lock serialisieren, 'zfs mount -a' nur dann als Fehler werten, wenn das Dataset des Storage nicht gemountet ist). Ausführliche Beschreibung, ein Testpaket für libpve-storage-perl 9.1.13 und Workarounds hier:
C

Thread 'Onboot guests on ZFS pool fail at boot with "no such pool available" or "dataset is busy" – race in activate_storage (bug #8230, patch + test package)'

Hi,

in case someone else hits this: after a reboot, guests with onboot=1 on a zfspool storage sometimes do not start, although the pool is imported and fine a minute later. Typical task log:

Code: 
Starting VM 124 failed: could not activate storage 'vmdata1zfs', zfs error: cannot import 'data1': no such pool available

or

Code: 
could not activate storage 'vm', zfs error: cannot mount 'store/...': mountpoint or dataset is busy

Cause

ZFSPoolPlugin::activate_storage() imports the pool on demand (with cachefile=none, so the pool is not in zpool.cache and ZFS does not import it at...

Bug: https://bugzilla.proxmox.com/show_bug.cgi?id=8230
 
  • Like
Reactions: Bu66as
You must log in or register to reply here.
Top Bottom
Back