On 07/10/2014 03:52 PM, Angel Docampo wrote:
I also already used the ovirt windows guest tools iso. I did installed a brand new windows 7 and installed the ovirt windows guest tools via iso, but when we started our kvm virtual machine adding this parameter:

-chardev socket,id=ovirtagent,path=/tmp/104.com.redhat.vdsm,server,nowait -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -device virtserialport,chardev=ovirtagent,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port1

This is how ours would look like:

-chardev socket,id=charchannel0,path=/tmp/104.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,*nr=1,*chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm
-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6

Notice how the 'nr=1' seems to be missing from yours, not sure though that this is the reason but might be.

was when the CPU fired to 100% (1CPU) or 50% (2CPUs) Perhaps we put something wrong on that...

If you set those parameters, you vCPU is not fired to 50% or 100%?


El jue 10 jul 2014 15:46:17 CEST, Vinzenz Feenstra escribió:
On 07/10/2014 03:24 PM, Angel Docampo wrote:
Of course, Vinzenz

The VM is a Windows 7 (I've tried both 32 and 64 bits, same result).
The C:\Windows\SysWOW64\rhev-agent log says:

Dummy-1::INFO::2014-07-10
14:35:57,417::OVirtGuestService::80::root::Starting OVirt Guest Agent
service

After look at the code, perhaps the problem may come on the run()
function in OvirtAgentLogic.py
def run(self):
       logging.debug("AgentLogicBase:: run() entered")
       thread.start_new_thread(self.doListen, ())
       thread.start_new_thread(self.doWork, ())
       # Yuck! It's seem that Python block all signals when executing
       # a "real" code. So there is no way just to sit and wait (with
       # no timeout).
       # Try breaking out from this code snippet:
       # $ python -c "import threading; threading.Event().wait()"
       while not self.wait_stop.isSet():
           self.wait_stop.wait(1)

Where this "while" is evaluating itself each second... besides the
wait function of the python module

By commenting  thread.start_new_thread(self.doWork, ()) the CPU has a
normal level when the service starts, but when we make a petition
through the host socket, the VM CPU goes to 100%.

Hope this helps, if you need any action from me, please tell me.
Hmm this is really strange, I am running the guest agent pretty
regularly on Windows 7 and I never noticed anything like this.

Could you please try to use the ovirt windows guest tools iso to
install the guest agent?
I am somehow surprised about the issue you're seeing.


Regards,

El jue 10 jul 2014 08:56:55 CEST, Vinzenz Feenstra escribió:
On 07/08/2014 09:15 AM, Angel Docampo wrote:
I just realized that my 64bit machine has 1 CPU and my 32bit machine
has two. If I set two processors to the 64bit machine,
oVirtGuestAgent.exe process eats a 50% CPU, not 100%, exactly like
the 32bit machine...
So I think there is a problem in the implementation of the agent. As
I'm not a developer myself, I cannot help to improve the agent.
Can I reduce the amount of CPU consumed by the process doing
something, like change the CPU virtualization (at the moment, is host
emulation), or something else?

The most interesting information for me really would be what version
of Windows you're using exactly.
I have never seen the guest agent running on that high CPU so I would
need some more information.

It'd be great if you could enable debug logging and restart the
service (or VM) and get me the logs after it is spiking the CPU so
much.

Thanks.



El 07/07/14 15:50, Angel Docampo escribió:
Hello everybody,

This is my very first email here. I've just compiled both 32 and 64
bits oVirtGuestAgent in order to make SSO from my application to a
Windows VM.

32 bits works flawlessly, I can login, logout and lock screen at the
moment, but the 64 bits version cannot login (but can lock screen
and logout) and the worse of all, puts the VM CPU at 99%, making it
useless.

Anyone has experieced this? Or give me some guidance to investigate?

Thank you!
--



*Angel Docampo
*
*Datalab Tecnologia, s.a.*
Castillejos, 352 - 08025 Barcelona
Tel. 93 476 69 14 - Ext: 706
Mob. 670.299.381


Nota Legal <http://www.dltec.net/aviso-legal>


_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

--



*Angel Docampo
*
*Datalab Tecnologia, s.a.*
Castillejos, 352 - 08025 Barcelona
Tel. 93 476 69 14 - Ext: 706
Mob. 670.299.381



_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community
collaboration.
See how it works at redhat.com

--



*Angel Docampo
*
*Datalab Tecnologia, s.a.*
Castillejos, 352 - 08025 Barcelona
Tel. 93 476 69 14 - Ext: 706
Mob. 670.299.381





--



*Angel Docampo
*
*Datalab Tecnologia, s.a.*
Castillejos, 352 - 08025 Barcelona
Tel. 93 476 69 14 - Ext: 706
Mob. 670.299.381




--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to