> > Thomas: I looked at your host dmesg and your provided vm.conf. It > > looks like 11 vm's with the default 512M memory and one (minecraft) > > with 8G. Your host seems to have only 16GB of memory, some of which > > is probably unavailable as it's used by the integrated gpu. I'm > > wondering if you are effectively oversusbcribing your memory here. > > > > I know we currently don't support swapping guest memory out, but not > > sure what happens if we don't have the physical memory to fault a > > page in and wire it. > > > > Something else gets swapped out.
Wire == Can't swap out? top shows 15G real memory available. That should be enough (8G + 11 * 0.5G = 13.5G), or is this inherently risky with 6.8? I can try -current as suggested in the other mail. Is this a likely cause or should I run with VMM_DEBUG for further investigation? Is "somewhat slower" from VMM_DEBUG still usable? I don't need full performance, but ~month downtime until the problem shows again would be too much. > > Even without a custom kernel with VMM_DEBUG, if it's a uvm_fault > > issue you should see a message in the kernel buffer. Something like: > > > > vmx_fault_page: uvm_fault returns N, GPA=0x...., rip=0x.... > > > > mlarkin: thoughts on my hypothesis? Am I wildly off course? > > > > -dv > > > > Yeah I was trying to catch the big dump when a VM resets. That would > tell us if the vm caused the reset or if vmd(8) crashed for some > reason. But if vmd crashed it wouldn't restart automatically or does it? All VMs down from vmd crashing would have been noticed. That kernel message would have shown in the dmesg too, wouldn't it? Kind regards, Thomas
