Displaying 4 results from an estimated 4 matches for "fe89b687a0".
2017 Feb 15
2
Re: high memory guest issues - virsh start and QEMU_JOB_WAIT_TIME
...able to start in
> > that time?
> >
>
> I recall some similar discussion took place in the past. But I just
> cannot find it now. I think the problem was that kernel is zeroing the
> pages on huge page allocation. Anyway, this timeout used to be 3 seconds
> and inly in fe89b687a0 it has been changed to 30 seconds.
>
> We can increase the limit, but that would solve just this case until
> somebody tries to assign even more RAM to their domain. What if we would
> instead make this configurable? Have yet another variable living inside
> qemu.conf that by defaul...
2017 Feb 15
2
Re: high memory guest issues - virsh start and QEMU_JOB_WAIT_TIME
On 15 February 2017 at 00:57, Daniel P. Berrange <berrange@redhat.com> 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
2017 Feb 15
0
Re: high memory guest issues - virsh start and QEMU_JOB_WAIT_TIME
...rger than ~160GB memory will not be able to start in
> that time?
>
I recall some similar discussion took place in the past. But I just
cannot find it now. I think the problem was that kernel is zeroing the
pages on huge page allocation. Anyway, this timeout used to be 3 seconds
and inly in fe89b687a0 it has been changed to 30 seconds.
We can increase the limit, but that would solve just this case until
somebody tries to assign even more RAM to their domain. What if we would
instead make this configurable? Have yet another variable living inside
qemu.conf that by default has value of 30 and spe...
2017 Feb 15
0
Re: high memory guest issues - virsh start and QEMU_JOB_WAIT_TIME
...> that time?
>> >
>>
>> I recall some similar discussion took place in the past. But I just
>> cannot find it now. I think the problem was that kernel is zeroing the
>> pages on huge page allocation. Anyway, this timeout used to be 3 seconds
>> and inly in fe89b687a0 it has been changed to 30 seconds.
>>
>> We can increase the limit, but that would solve just this case until
>> somebody tries to assign even more RAM to their domain. What if we would
>> instead make this configurable? Have yet another variable living inside
>> qemu....