Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/05/17 14:42, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable test] 108068: 
> regressions - FAIL"):
>> This is known, and has definitely been discussed before on xen-devel
>> before (although it involved IanC last time he looked at these tests, so
>> a while ago now).
>>
>> In an APCI view of the world, the two pieces of information you can
>> convey is "The user pressed the power button", and "The user pressed the
>> sleep button".
>>
>> Windows typically defaults these to suspend and sleep, not shutdown. 
>> Neither suspend nor sleep are typically available to VMs (unless you
>> alter the apci_* defaults in the xl.cfg file).
>>
>> You must explicitly change the defaults to always treat the power button
>> as poweroff, or install PV drivers which will intercept the PV protocol
>> and DTRT before the toolstack falls back to ACPI event.
> The VM images we are using are the ones from Citrix's XenRT.  They are
> supposed to have the PV drivers, I think.  If this theory were the
> whole of the explanation, the problem would be repeatable and
> universal.

The XenRT images very specifically don't have PV drivers installed,
because large parts of our testing is installation of the drivers.

Also, it is not representative of what end users would do, who would
first install windows natively from an ISO, then find some PV drivers to
install.

I see no evidence in the qemu logs of PV drivers in any boot of that guest.

>
>> Another issue which gets in the way is windows deciding to install
>> updates, which can result in reboots at any point when other options
>> have been selected.  I presume the COLO firewall should prevent all
>> behaviour like that?
> In theory the guest could guess at the location of the squid proxy and
> get out that way.  But I have just checked the squid logs and there is
> nothing from the guest's IP address there.  So I think I can rule that
> out.

Ok.  That is good to hear, as it takes one variable off the table.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel