Whilst tinkering with lvm (which now works great - thanks!), I made a typo which caused the domain to stop booting. I think it was just that I got the config file wrong in terms of which device mapped to which. Anyway, I had specified ''restart=True'' and so the domain was starting to boot, failing, then restarting again. This was the expected behaviour, but it was a pain to kill. Had I thought of it I would have just killed xend but I was doing an ''xm list'' to find the domain number, then ''xm destroy'', but by then it had moved on. doh! How easy would it be to put in some logic to detect a domain restarting rapidly in quick succession and either stop restarting it, or introduce an increasing delay between restarts? James
> Whilst tinkering with lvm (which now works great - thanks!), I made a typo which caused the domain to stop booting. I think it was just that I got the config file wrong in terms of which device mapped to which. > > Anyway, I had specified ''restart=True'' and so the domain was starting to boot, failing, then restarting again. This was the expected behaviour, but it was a pain to kill. Had I thought of it I would have just killed xend but I was doing an ''xm list'' to find the domain number, then ''xm destroy'', but by then it had moved on. doh! > > How easy would it be to put in some logic to detect a domain restarting rapidly in quick succession and either stop restarting it, or introduce an increasing delay between restarts?Fair point. Mike is jsut about to make some changes to the reboot logic so that the reboot flag is a tristate: ''always''/''never''/''if_domain_exits_with_a_reboot_code''. This won''t necessarily fix the flapping problem, unless the domain exits with a non reboot code, which Linux tends not to. The flapping problem is a right pain. (I do an ''xm list'' then try killing domid+1). The easiest hack might be to add a 30s delay between restarts if the uptime of the domain is less than e.g. 2 minutes. Ian ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 14 Jul 2004, James Harper wrote:> How easy would it be to put in some logic to detect a domain restarting > rapidly in quick succession and either stop restarting it, or introduce > an increasing delay between restarts?how about a control for xen which essentially says ''stop scheduling all VMs and don''t start any new ones until I tell you to start again'' this would nicely cover this and a lot of other cases. Essentially a ''halt'' switch for anyone who remembers front panels. ron ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 14 Jul 2004, ron minnich wrote:> how about a control for xen which essentially says ''stop scheduling all > VMs and don''t start any new ones until I tell you to start again''except Dom0, of course, sorry. ron ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel