[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] task queue trashing by crashed domains


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: George Shuklin <george.shuklin@xxxxxxxxx>
  • Date: Mon, 04 Oct 2010 21:12:10 +0400
  • Delivery-date: Mon, 04 Oct 2010 10:13:20 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=CSLNgRh32HE9IqVNBbJyYLKJtlr+om1mzyAfAO2F7XMS5Xsus/E1oWgX5W/H3AHpLq EG5PNHpOyqQPxSoKLdMoRZpuTi/TfPQsRH8YVWIqScB0zp2RL0Ueb0BZiY745zCVE054 F0XzAk86neEH79bTG66qUEawP8Az72JBsaW80=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Good day.

In some cases (mostly domU crashing or hanging up) xapi on slave is
unable to perform some task (f.e. migration). This task appear in
task-list as 'pending' and can not be cancelled by normal way. I found
single way - to restart master xapi (and slave xapi afterwards) - this
clean all pending task queue.

But I think it really brute (and not very good, some other tasks may be
in progress and they will fail unreasonably).

Does XCP support some kind of 'force drop task' operation? During xen
kernel researches I very often reproduce this problem and I believe it
can be created even on normal (xs) kernel by malicious application with
root access. By creating 'unmigrable' state and causing XCP somehow (by
excessive memory allocation f.e.) it can cause compromising whole pool
instead been kept within single domain.

I think this is simply administrative kind of command (forgot task) and
does not required to change system/hypervisor code. 

---
wBR, George.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.