gpg: Signature made Sun Dec 16 12:23:59 2018 UTC
gpg: using DSA key 2099B64CBF15490B
gpg: Good signature from "Andy Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andrew James Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andy Smith (UKUUG) <andy.smith@ukuug.org>" [unknown]
gpg: aka "Andy Smith (BitFolk Ltd.) <andy@bitfolk.com>" [unknown]
gpg: aka "Andy Smith (Linux User Groups UK) <andy@lug.org.uk>" [unknown]
gpg: aka "Andy Smith (Cernio Technology Cooperative) <andy.smith@cernio.com>" [unknown]
Hi Johnathon,
On Mon, Dec 10, 2018 at 03:30:48PM +0000, Johnathon Tinsley wrote:
> If you have a spare HV, why not try to identify the guest involved by moving
> half the guests off of hen? The HV that crashes has the errant guest, move
> another half from that HV, see which HV crashes. Continue till you've
> identified, or you've a small enough number to be worth contacting users and
> asking what their guests are doing at the panic time?
Okay, so, I do know which guest was executing at the time of the
last crash. There could easily be more than one though, and moving
guests about imposes a reboot on them anyway.
I'm afraid I want to treat customers on hen as guinea pigs at least
one more time for the purposes of collecting information.
It will be interesting to see if the same guest is implicated next
time, in which case certainly I will isolate it then.
Also I've been suggested a setting which may avoid the area of
code where the bug is thought to lie, but it will require a reboot
to apply it. If/when there is another crash, it will come back up
with that setting applied and then we will go from there.
So, there is likely to be 1 more crash at some point, after which I
hope things settle done but if not I will take more extreme steps
such as this.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
