search for: 08fbb6b6136c758d027e90ff139d5701

...main(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@redhat.com> 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...

...ain>: 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@redhat.com> 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 q...

...t; 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@redhat.com> 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(). &gt...

...37c >> > 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@redhat.com> 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 &gt...

Hi all, In IRC last night Dan helpfully confirmed my analysis of an issue we are seeing attempting to launch high memory KVM guests backed by hugepages... In this case the guests have 240GB of memory allocated from two host NUMA nodes to two guest NUMA nodes. The trouble is that allocating the hugepage backed qemu process seems to take longer than the 30s QEMU_JOB_WAIT_TIME and so libvirt then