Am 12/09/2023 um 11:16 schrieb Fiona Ebner: > 10 minutes is not long enough when disks are large and/or network > storages are used when preallocation is not disabled. The default is > metadata preallocation for qcow2, so there are still reports of the > issue [0][1]. If allocation really does not finish like the comment > describing the timeout feared, just let the user cancel it. > > Also note that when restoring a PBS backup, there is no timeout for > disk allocation, and there don't seem to be any user complaints yet. > > The 5 second timeout for receiving the config from vma is kept, > because certain corruptions in the VMA header can lead to the > operation hanging there. > > There is no need for the $tmp variable before setting back the old > timeout, because that is at least one second, so we'll always be able > to set the $oldtimeout variable to undef in time in practice. > Currently, there shouldn't even be an outer timeout in the first > place, because the only call path leading to here is via the create > API (also used by qmrestore), both of which don't set a timeout. > > [0]: https://forum.proxmox.com/threads/126825/ > [1]: https://forum.proxmox.com/threads/128093/ > > Signed-off-by: Fiona Ebner <f.eb...@proxmox.com> > --- > PVE/QemuServer.pm | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) > >
applied series a bit ago already, thanks! It's actually a v3, as there where two older revisions sent for this in 2020, sorry for the delay I guess. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel