Comment 20 for bug 1323658

Hi Phil,

This is one of the theories I am trying to confirm.
Unfortunately the failing test suite did not report console log output, which is a shame.
Some user-driven reproductions of the bug revealed an empty console log - which might be consistent with your hypothesis.
However, using logstash I observed the VM taking an IP after reboot always, meaning that the file system was not corrupted. (This can be observed from syslog.txt.gz in test logs).

One might then point the finger on the l3 agent, however:
- l3 agent logs have no event at all between VM shutoff and subsequent destroy after failure
- the same failure was observed also on VMware minesweeper for NSX, which does not use the l3 agent

I think we should reason on what triggered the bug on the gate.
That was a simple patch for verifying a guest was active and reachable before doing further tests on it.
That patch, at the end of the day did two things:
- ensure the VM went into active state, and the floating ip was wired
- add a bit of delay before performing the actual test

The difference is that before the shutoff action was performed most of the time even before the vm reached active status.
I'm not sure if this might explain anything.