On 15 February 2017 at 00:57, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > What is the actual error you're getting during startup. # virsh -d0 start instance-0000037c start: domain(optdata): instance-0000037c start: found option <domain>: instance-0000037c start: <domain> trying as domain NAME error: Failed to start domain instance-0000037c error: monitor socket did not show up: No such file or directory Full libvirtd debug log at https://gist.github.com/bmb/08fbb6b6136c758d027e90ff139d5701 On 15 February 2017 at 00:47, Michal Privoznik <mprivozn@xxxxxxxxxx> wrote: > I don't think I understand this. Who is running the other job? I mean, > I'd expect qemu fail to create the socket and thus hitting 30s timeout > in qemuMonitorOpenUnix(). Yes you're right, I just blindly started looking for 30s constants in the code and that one seemed the most obvious but I had not tried to trace it all the way back to the domain start job or checked the debug logs yet, sorry. So looking a bit more carefully I see the real issue is in src/qemu/qemu_monitor.c: 321 static int 322 qemuMonitorOpenUnix(const char *monitor, pid_t cpid) 323 { 324 struct sockaddr_un addr; 325 int monfd; 326 int timeout = 30; /* In seconds */ Is this safe to increase? Is there any reason to keep it at 30s given (from what I'm seeing on a fast 2-socket Haswell system) that hugepage backed guests larger than ~160GB memory will not be able to start in that time? -- Cheers, ~Blairo _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
