Search results

Already exists in upstream proxmoxer module: https://github.com/swayf/proxmoxer/pull/83 pip install -U git+https://github.com/ssi444/proxmoxer@master

Good catch, will have a look

As i'm using this module a lot, i was co-authoring it and meanwhile we've found something (which was my first impression anyways ;)): It's just the storage which does not exists. We used qm create with all the options to debug further: qm create 134 --scsi0...

Ansible Lookups (https://docs.ansible.com/ansible/latest/user_guide/playbooks_lookups.html) are fetching data from a file, in this case the template defined in the key template: (e.g. template: 'deploy-args-ubuntu.j2'). Does the file or the proper config key exist? And as i guess this...

in 2015, there was no pve-zsync yet ;) Of course, today you should use it.

Huh, quite a long time ago i was using this. I'm not sure if i used the interfaces directly, not the bridge. So something like -i enoX (a slave of vmbr0) and -o tapXXXi0 (the interface of the VM)

Same here ;)

try zpool upgrade pool1

In my case, it's no lockup, it's just IO which is stalling...in the end, the result is the same, due to heavy IO load i can't reboot or power off the system (hangs forever in systemd shutdown process) and i need to hard reset.

Thanks for the hint, i'll try.

Hm, another crash ... not sure where to look at [Fr Aug 9 13:23:53 2019] INFO: task zvol:619 blocked for more than 120 seconds. [Fr Aug 9 13:23:53 2019] INFO: task txg_quiesce:1478 blocked for more than 120 seconds. [Fr Aug 9 13:23:53 2019] INFO: task kvm:14072 blocked for more than 120...

Hm....interesting. Got an IO lockup today on an Epyc Server while ZFS was taking snapshots too (sanoid). It stayed reachable via SSH and so on, but i needed to reboot to get rid of the high I/O wait. Will keep an eye on it...

I'm not able to reproduce your issue. If you (or others having this problem) like to help, just comment in https://github.com/swayf/proxmoxer/issues/79 For me, basic authentication and interaction with the cluster works. Edit: Nevermind, found and fixed it. Have fun ;)

Jip, you're right, it's not working without another call to start kexec-pve.service ... will look into this.

FTR, this one looks good: https://github.com/chungy/zfs-boottime-encryption Seamless integration into systemd boot process using default mechanisms....

Hm, probably a timing issue....i do have a brand new PVE6 test lab installation right now and will check if i can reproduce this.

This indicates you need to load a kernel into kexec. systemctl start kexec-pve.service If you want to use it anytime, just issue a systemctl enable kexec-pve.service