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

[Xen-users] some more tweaking in xendomains script

  • To: Xen Users <xen-users@xxxxxxxxxxxxxxxxxxx>
  • From: Florian Heigl <florian.heigl@xxxxxxxxx>
  • Date: Thu, 16 Jun 2011 15:43:21 +0200
  • Delivery-date: Thu, 16 Jun 2011 06:44:48 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZNNtX6CU7cKzoUIb8zzLvBoaUT+jsOtXAfbWM+prv/XszahEtoBG8LQf5rj79THBr3 ejrDcxipa98qzVKlqs38Amr5iOI7pc14BkW5uKxraBwZ70inXJHDcGyaBv9EFNv1hxez c7MPPjD3v6O135ArC8xLjGqfVVC06nV5zQfjQ=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>


I wonder if one of you has changed /etc/init.d/xendomains to run in a
different order?
My idea is to have it
* initiate a xm shutdown,
* wait for the --halt --wait until the XENDOMAINS_STOP_MAXWAIT is reached
* then (and not as the first step!)
* fire the specific sysrq's and sleep for the XENDOMAINS_CREATE_USLEEP
before finally
* doing an xm destroy

oh, and while at it, it might be also *about time* to add xm trigger
<domid> power in between those steps?
This is needed for any HVM domU that doesn't have anything listening on Xenbus.

Another bad thing is that the maxwait timer affects any "command" no
matter if that acts on all VMs or on a single one, whereas this has a
huge impact in practice.

imho this could improve a lot and will help all users - so to avoid
reinventing wheels, *PLEASE* let me know if you did any
modifications/improvments there so we can merge them and commit back
one thing.

Thanks & greetings,

the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

Xen-users mailing list



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