Agreed 30s isn’t enough, but for long running processes LXD has async operations (which use websockets to monitor the progress of the operation), so the initial header response should still be <30s.
I’ve tested importing large instances that take over 30s (and indeed our own automated tests do this for VMs as well) and we don’t see the issue. I’ve also tested launching instances from images that take over 30s to download (by slowing down the network), and don’t see the issue there either.
So something else is at play here, but so far nobody on related issue golang client net/http: timeout awaiting response headers · Issue #10377 · lxc/lxd · GitHub has been able to provide the associated server logs at the same time as the client request is timing out. So I am not sure what is going on.
I am also planning to increase the timeout massively until we can figure it out Client: Increase header timeout from 30s to 1 hour by tomponline · Pull Request #10407 · lxc/lxd · GitHub, although as soon as that is merged we will likely lose visibility on the users who are experiencing these issues.