> These being failures of Dom0 trying to bind inter-domain event
> channels between itself and Dom2, these would quite likely be
> accompanied by some log entries from the xen tools or the Dom0
> kernel. In any case - the failure message here indicates that the
> event channel either wasn't in "unbound" state, or wasn't
> intended to be bound to by Dom0. For what it's worth, both seem
> pretty unlikely...
>
> Furthermore, you certainly realize that with the update to Xen 4.3,
> which isn't part of 12.3, you also got switched from xend/xm to the
> libxl based tools, which may be part of your problem. Thus it would
> also be important to know what's so specific about this one failing
> VM (there ought to be something, or else it wouldn't be always the
> same VM that fails to come up).
That's enough explanation for me to read further on, thanks.
The most verbose log anomalies that I've noticed so far I've included
above. Nothing else I've noticed in dmesg, xl dmesg, journalctl, serial
console output, /var/log/*, etc.
I _do_ also find in /var/log/xen/*,
cat qemu-dm-test1.log
qemu: terminating on signal 1 from pid 1176
and,
cat xl-test2.log
Waiting for domain pvr (domid 2) to die [pid 2976]
Not much detail there. Either I'm not looking in the right places, my
logging level isn't sufficient, or there isn't anything else. I'll keep
digging on logs.
Something's clearly changed recently. Although I've made pkg-upgrades @
Dom0, I haven't made any knowing changes to the failing Guest. The two
Guest domains are supposed to be roughly similar; different RAM
allocations, basically. They _used_ to both launch @boot without error;
they still do, manually. But, a test of 10 reboots resulted in 10
identical @boot failures -- all & only this same Guest. Supports your
suggestion that there's something specific to this Guest.
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
