<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 1, 2018 at 8:43 PM, Alex K <span dir="ltr"><<a href="mailto:rightkicktech@gmail.com" target="_blank">rightkicktech@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi all and Happy New Year!<br><br></div>I have a ovirt 4.1.3.5 cluster (running with 3 nodes and shared gluster storage). <br></div>I have randomly observed that some Windows 10 64bit VMs are reported from engine dashboard with 100%CPU while when connecting within the VM the CPU utilization is normal. <br></div>Sometimes, when reported with 100% CPU I cannot get a console at VM (console gives black screen) then I have to force shutdown the VM and start it up again. The only warning I see is in the qemu logs of the guest reporting that CPUs not present in any NUMA nodes. <br><br></div>Any ideas how to tackle this?<br><br></div>Thanx, <br></div>Alex<br></div>
<br></blockquote><div> </div></div></div><div class="gmail_extra">Hi Alex,</div><div class="gmail_extra">I have seen something similar but on ISCSI domain environment and not GlusterFS one, when I got problems with the storage array (in my case it was a firmware update that lasted too much) and the VMs were paused and after some seconds reactivated again.</div><div class="gmail_extra">For some of them I registered the related qemu-kvm process going to fixed 100% cpu usage and unable to open spice console (black screen). But in my case also the VM itself was stuck: unable to connect to it via network or ping.</div><div class="gmail_extra">I had to force power off the VM and power on it again. Some other VMs resumed from pause state without any apparent problem (apart from clock unsync).</div><div class="gmail_extra">Both the good and bad VMs had ovirt guest agent running: they were CentOS 6.5 VMs</div><div class="gmail_extra">Perhaps your situation is something in the middle.... verify you didn't had any problem with your storage and that your problematic VM had not been paused/resumed due to that<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Gianluca<br></div></div>