flight 11601 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11601/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-i386-i386-win 14 guest-start.2 fail like 11600
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass
test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-i386-i386-xl-win 13 guest-stop fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
version targeted for testing:
xen 4271634e4c86
baseline version:
xen 4271634e4c86
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-i386-i386-xl pass
test-amd64-i386-rhel6hvm-amd fail
test-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-amd64-xl-sedf-pin pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
test-i386-i386-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Published tested tree is already up to date.
On Thu, 2012-01-26 at 06:16 +0000, xen.org wrote: [...]> Tests which did not succeed, but are not blocking: > test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass > test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never passBoth of these are failing with: 2012-01-26 05:08:15 Z toolstack xl Use of uninitialized value in concatenation (.) or string at ./ts-guest-start line 13. 2012-01-26 05:08:15 Z executing ssh ... root@10.80.249.57 xl create Config file not specified and none in save file 2012-01-26 05:08:15 Z command nonzero waitstatus 1536: ssh -o StrictHostKeyChecking=no \ -o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 \ -o PasswordAuthentication=no -o ChallengeResponseAuthentication=no \ -o UserKnownHostsFile=tmp/t.known_hosts_11601.test-amd64-i386-rhel6hvm-amd root@10.80.249.57 xl create Which is presumably a harness failure. I''m not sure I 100% follow things but it seems that "toolstack()->{CfgPathVar}" is going to be "xlpath" rather than "cfgpath" but that Osstest.pm:selectguest is only setting up cfgpath. Ian.
On Thu, 2012-01-26 at 06:16 +0000, xen.org wrote: [...]> Tests which did not succeed, but are not blocking: > test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass > test-amd64-amd64-xl-win 13 guest-stop fail never pass > test-i386-i386-xl-win 13 guest-stop fail never pass > test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass > test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass > test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass > test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass > test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never passThese are all: 2012-01-26 03:35:19 Z executing ssh ... root@10.80.249.148 xl shutdown -w win.guest.osstest PV control interface not available: external graceful shutdown not possible. Use "xl button-press <dom> power" or "xl destroy <dom>". shutdown failed (rc=-10) If you are not amenable to having the harness fallback to xl button-press/trigger power automatically how about something like the following patch with the proviso that it is up to the harness to ensure that a guest is configured appropriately such that ACPI power and reset events map to shutdown and reboot respectively? (patch applies on top of my updated"libxl: remove libxl_button_press in favour of libxl_send_trigger" patch from earlier in the week) Ian. 8<------------------------------------------------------------------------------- # HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1327569659 0 # Node ID c1aeef6cd4c832ddb97a7160be7ab6cb1037d3b8 # Parent a7776e38447d4e633a45b926295f7923c046fbc9 xl: allow enable automatic fallback to ACPI events if PV control not available. Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown or reset event to be sent to the guest in the event that the guest does not support the PV control interface. This is not the default because the response to these triggers is an guest-internal configuration. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r a7776e38447d -r c1aeef6cd4c8 docs/man/xl.pod.1 --- a/docs/man/xl.pod.1 Wed Jan 25 16:55:08 2012 +0000 +++ b/docs/man/xl.pod.1 Thu Jan 26 09:20:59 2012 +0000 @@ -365,13 +365,28 @@ domain actually reboots. For HVM domains this requires PV drivers to be installed in your guest OS. If PV drivers are not present but you have configured the guest OS -to behave appropriately you may be able to use the I<button-press> -subcommand to trigger a power button press. +to behave appropriately you may be able to use the I<-F> option +trigger a reset button press. The behavior of what happens to a domain when it reboots is set by the B<on_reboot> parameter of the domain configuration file when the domain was created. +B<OPTIONS> + +=over 4 + +=item B<-F> + +If the guest does not support PV reboot control then fallback to +sending an ACPI power event (equivalent to the I<reset> option to +I<trigger>. + +You should ensure that the guest is configured to behave as expected +in response to this event. + +=back + =item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile> Build a domain from an B<xl save> state file. See B<save> for more info. @@ -422,8 +437,8 @@ services must be shutdown in the domain. For HVM domains this requires PV drivers to be installed in your guest OS. If PV drivers are not present but you have configured the guest OS -to behave appropriately you may be able to use the I<button-press> -subcommand to trigger a power button press. +to behave appropriately you may be able to use the I<-F> option +trigger a power button press. The command returns immediately after signally the domain unless that B<-w> flag is used. @@ -440,6 +455,15 @@ B<OPTIONS> Wait for the domain to complete shutdown before returning. +=item B<-F> + +If the guest does not support PV shutdown control then fallback to +sending an ACPI power event (equivalent to the I<power> option to +I<trigger>. + +You should ensure that the guest is configured to behave as expected +in response to this event. + =back =item B<sysrq> I<domain-id> I<letter> diff -r a7776e38447d -r c1aeef6cd4c8 tools/libxl/xl_cmdimpl.c --- a/tools/libxl/xl_cmdimpl.c Wed Jan 25 16:55:08 2012 +0000 +++ b/tools/libxl/xl_cmdimpl.c Thu Jan 26 09:20:59 2012 +0000 @@ -2259,19 +2259,24 @@ static void destroy_domain(const char *p if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); } } -static void shutdown_domain(const char *p, int wait) +static void shutdown_domain(const char *p, int wait, int fallback_trigger) { int rc; find_domain(p); rc=libxl_domain_shutdown(ctx, domid); - if (rc) { - if (rc == ERROR_NOPARAVIRT) { + if (rc == ERROR_NOPARAVIRT) { + if (fallback_trigger) { + fprintf(stderr, "PV control interface not available:" + " sending ACPI power button event.\n"); + rc = libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_POWER, 0); + } else { fprintf(stderr, "PV control interface not available:" " external graceful shutdown not possible.\n"); - fprintf(stderr, "Use \"xl button-press <dom> power\" or" - " \"xl destroy <dom>\".\n"); + fprintf(stderr, "Use \"-F\" to fallback to ACPI power event.\n"); } + } + if (rc) { fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1); } @@ -2310,19 +2315,25 @@ static void shutdown_domain(const char * } } -static void reboot_domain(const char *p) +static void reboot_domain(const char *p, int fallback_trigger) { int rc; find_domain(p); rc=libxl_domain_reboot(ctx, domid); - if (rc) { - if (rc == ERROR_NOPARAVIRT) { + if (rc == ERROR_NOPARAVIRT) { + if (fallback_trigger) { + fprintf(stderr, "PV control interface not available:" + " sending ACPI reset button event.\n"); + rc = libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_RESET, 0); + } else { fprintf(stderr, "PV control interface not available:" " external graceful reboot not possible.\n"); - fprintf(stderr, "Use \"xl button-press <dom> power\" or" - " \"xl destroy <dom>\".\n"); + fprintf(stderr, "Use \"-F\" to fallback to ACPI reset event.\n"); } - fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); } + } + if (rc) { + fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); + } } static void list_domains_details(const libxl_dominfo *info, int nb_domain) @@ -3106,29 +3117,41 @@ int main_shutdown(int argc, char **argv) { int opt; int wait = 0; - - while ((opt = def_getopt(argc, argv, "w", "shutdown", 1)) != -1) { + int fallback_trigger = 0; + + while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) { switch (opt) { case 0: case 2: return opt; case ''w'': wait = 1; break; + case ''F'': + fallback_trigger = 1; + break; } } - shutdown_domain(argv[optind], wait); + shutdown_domain(argv[optind], wait, fallback_trigger); return 0; } int main_reboot(int argc, char **argv) { int opt; - - if ((opt = def_getopt(argc, argv, "", "reboot", 1)) != -1) - return opt; - - reboot_domain(argv[optind]); + int fallback_trigger = 0; + + while ((opt = def_getopt(argc, argv, "F", "reboot", 1)) != -1) { + switch (opt) { + case 0: case 2: + return opt; + case ''F'': + fallback_trigger = 1; + break; + } + } + + reboot_domain(argv[optind], fallback_trigger); return 0; }
Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable
FAIL"):> Both of these are failing with:
> 2012-01-26 05:08:15 Z toolstack xl
> Use of uninitialized value in concatenation (.) or string at
./ts-guest-start line 13.
> 2012-01-26 05:08:15 Z executing ssh ... root@10.80.249.57 xl create
> Config file not specified and none in save file
> 2012-01-26 05:08:15 Z command nonzero waitstatus 1536: ssh -o
StrictHostKeyChecking=no \
> -o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100
\
> -o PasswordAuthentication=no -o ChallengeResponseAuthentication=no
\
> -o
UserKnownHostsFile=tmp/t.known_hosts_11601.test-amd64-i386-rhel6hvm-amd
root@10.80.249.57 xl create
>
> Which is presumably a harness failure.
Yes.
> I''m not sure I 100% follow things but it seems that
> "toolstack()->{CfgPathVar}" is going to be "xlpath"
rather than
> "cfgpath" but that Osstest.pm:selectguest is only setting up
cfgpath.
This is an obsolete feature from when libxl didn''t support the same
config files as xend. I have switched this to using the .cfg file
rather than expecting a different file.
This may break 4.0 I guess, but if so I''ll deal with that then.
4.0''s
xl is pretty ropey anyway.
Ian.
Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable
FAIL"):> If you are not amenable to having the harness fallback to xl
> button-press/trigger power automatically how about something like the
> following patch with the proviso that it is up to the harness to ensure
> that a guest is configured appropriately such that ACPI power and reset
> events map to shutdown and reboot respectively?
>
> (patch applies on top of my updated"libxl: remove libxl_button_press
in
> favour of libxl_send_trigger" patch from earlier in the week)
...> xl: allow enable automatic fallback to ACPI events if PV control not
available.
>
> Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown
or
> reset event to be sent to the guest in the event that the guest does not
> support the PV control interface.
>
> This is not the default because the response to these triggers is an
> guest-internal configuration.
I''m happy with this, but then I would have been happy with this being
the default.
Certainly I think this is a good start, so:
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian.
On Tue, 31 Jan 2012, Ian Jackson wrote:> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable FAIL"): > > If you are not amenable to having the harness fallback to xl > > button-press/trigger power automatically how about something like the > > following patch with the proviso that it is up to the harness to ensure > > that a guest is configured appropriately such that ACPI power and reset > > events map to shutdown and reboot respectively? > > > > (patch applies on top of my updated"libxl: remove libxl_button_press in > > favour of libxl_send_trigger" patch from earlier in the week) > ... > > xl: allow enable automatic fallback to ACPI events if PV control not available. > > > > Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown or > > reset event to be sent to the guest in the event that the guest does not > > support the PV control interface. > > > > This is not the default because the response to these triggers is an > > guest-internal configuration. > > I''m happy with this, but then I would have been happy with this being > the default. > > Certainly I think this is a good start, so: >I think it is a good compromise.