I hope you have the agent + driver on the guest.

(In reply to comment #9)
> I hope you have the agent + driver on the guest.    

Yes. both installed and running.
install from rhevm-guest-tools-2.1-39917.iso

1. "-uuid `uuidgen`" means you are giving the VM a different UUID every run. That's strange.
2. "-usbdevice tablet" is not needed if you have the drivers and agents of Spice.

(In reply to comment #17)
> 1. "-uuid `uuidgen`" means you are giving the VM a different UUID every run.
> That's strange.
 Is the uuid saved and reused after I quit and restart vm ?  (since no migration involved ).difficult for me to remember every uuid i have used when start vm from command line directly ... 
  

> 2. "-usbdevice tablet" is not needed if you have the drivers and agents of
> Spice.    

  If this affect current test. I will restart it. otherwise, I will keep the vm running for 12hour.

I don't really understand why you tried to reproduce this bug without "Sysmark" utility.
I managed to reproduce this issue with 20 1GB VM's which are running "Sysmark" utility simultaneously .
I reopen this bug.
Please contact me if you need help with reproducing this issue.

(In reply to comment #24)
> I don't really understand why you tried to reproduce this bug without "Sysmark"
> utility.
> I managed to reproduce this issue with 20 1GB VM's which are running "Sysmark"
> utility simultaneously .
> I reopen this bug.
> Please contact me if you need help with reproducing this issue.    

Oded - which KVM version have you used? Also, it's a good idea to try with newer hypercall drivers (which fix the issue on their side) - they should be available only on the next build (or you can take from nightly - talk to Barak first - I WHQL'ed them already).

## Host CPU information:

$h.GetCpuStatistics()

Cores  : 4
Model  : Intel(R) Xeon(R) CPU           E5310  @ 1.60GHz
Speed  : 1596

## KVM version:

kvm-83-147.el5

I talk to Barak about the new hypercall drivers.

I managed to reproduce this issue with the new hypercall driver,
I'm not sure if it's the same bug because the VM is stuck but it does not consumes 100 percent CPU.

gnatapov is investigating the stuck process.

(In reply to comment #27)
> gnatapov is investigating the stuck process.    

Reassigning to Gleb, then.

Please check if the driver calls the reset device when it unloads (hope that it try to unload)

I think that there are two different issues here (both occurs during "Sysmark" benchmark execution):

In both cases the VM is stuck but in one case it consumes 100 percent CPU ( probably the hypercall issue) and in the second it does not consumes 100 percent CPU.

The second case is quite common and i'm able to reproduce it ( also with the new hypercall drivers )

I have few questions:

1. Do you want me to open separate busy for the second case?
2. Can you assign someone to check this issue immediately , Gleb is quite busy with other things and we have a RHEVM release in few weeks.

I'll try to add memory dump for my stuck Guests.

When the hypercall issue occurs , the VM is consuming 100 percent CPU.
The phenomenon i see is a little bit different: VM stuck after boot but it does not consumes 100 percent CPU. I'm moving this bug back to ON_QA and open a new one.

I run the test with 15 1GB guests ( on 5.5 host - see comment 7 )
Didn't manage to reproduce the 100 percent CPU issue.
You can move this bug status to VERIFIED

5.5 and 5.4-z shared the same patch. so setting to verified.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0088.html