Re: [Xen-devel] [xen-unstable test] 65141: regressions - FAIL
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Saturday, December 5, 2015 4:10 PM
> To: Hu, Robert ; Ian Jackson
> ; Nakajima, Jun ;
> Tian, Kevin
> Cc: xen-de...@lists.xensource.com; osstest service owner
> ; Jan Beulich ;
> Andrew Cooper
> Subject: Re: [xen-unstable test] 65141: regressions - FAIL
>
> On Wed, 2015-12-02 at 13:51 +, Ian Campbell wrote:
>
> > http://osstest.test-lab.xenproject.org/~osstest/pub/logs/65301/
> >
> > I think that ought to give a baseline for the bisector to work with. I'll
> > prod it to do so.
>
> Results are below. TL;DR: d02e84b9d9d "vVMX: use latched VMCS machine
> address" is somehow at fault.
>
> It appears to be somewhat machine specific, the one this has been
> failing on is godello* which says "CPU0: Intel(R) Xeon(R) CPU E3-1220
> v3 @ 3.10GHz stepping 03" in its serial log.
>
> Andy suggested this might be related to cpu_has_vmx_vmcs_shadowing
> so Haswell and newer vs IvyBridge and older.
>
> Ian.
>
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-qemuu-nested-intel
> testid debian-hvm-install/l1/l2
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
>
> *** Found and reproduced problem changeset ***
>
> Bug is in tree: xen git://xenbits.xen.org/xen.git
> Bug introduced: d02e84b9d9d16b6b56186f0dfdcb3c90b83c82a3
> Bug not present: 3b47431691409004c7218f6a6ba5c9c0bcf483ea
> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/65388/
>
>
> commit d02e84b9d9d16b6b56186f0dfdcb3c90b83c82a3
> Author: Jan Beulich
> Date: Tue Nov 24 12:07:27 2015 +0100
>
> vVMX: use latched VMCS machine address
>
> Instead of calling domain_page_map_to_mfn() over and over, latch
> the
> guest VMCS machine address unconditionally (i.e. independent of
> whether
> VMCS shadowing is supported by the hardware).
>
> Since this requires altering the parameters of __[gs]et_vmcs{,_real}()
> (and hence all their callers) anyway, take the opportunity to also drop
> the bogus double underscores from their names (and from
> __[gs]et_vmcs_virtual() as well).
>
> Signed-off-by: Jan Beulich
> Acked-by: Kevin Tian
>
>
> For bisection revision-tuple graph see:
>
> http://logs.test-lab.xenproject.org/osstest/results-adhoc/bisect/xen-unstabl
> e/test-amd64-amd64-qemuu-nested-intel.debian-hvm-install--l1--l2.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
>
>
> Running cs-bisection-step
> --graph-out=/home/logs/results-adhoc/bisect/xen-unstable/test-amd64-am
> d64-qemuu-nested-intel.debian-hvm-install--l1--l2
> --summary-out=tmp/65388.bisection-summary
> --blessings=real,real-bisect,adhoc-bisect --basis-template=65301
> --basis-flight=65301 xen-unstable test-amd64-amd64-qemuu-nested-intel
> debian-hvm-install/l1/l2
> Searching for failure / basis pass:
> 65314 fail [host=godello1] / template as basis? using template as basis.
> Failure / basis pass flights: 65314 / 65301
> (tree with no url: ovmf)
> (tree with no url: seabios)
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
> Latest 769b79eb206ad5b0249a08665fefb913c3d1998e
> c530a75c1e6a472b0eb9558310b518f0dfcd8860
> bc00cad75d8bcc3ba696992bec219c21db8406aa
> 3fb401edbd8e9741c611bfddf6a2032ca91f55ed
> 2c4f313a7e62c7e559a469d4af4c3d03c49afa43
> Basis pass 1230ae0e99e05ced8a945a1a2c5762ce5c6c97c9
> c530a75c1e6a472b0eb9558310b518f0dfcd8860
> bc00cad75d8bcc3ba696992bec219c21db8406aa
> 816609b2841297925a223ec377c336360e044ee5
> d07f63fa6e70350b23e7acbde06129247c4e655d
> Generating revisions with ./adhoc-revtuple-generator
> git://xenbits.xen.org/linux-pvops.git#1230ae0e99e05ced8a945a1a2c5762ce
> 5c6c97c9-769b79eb206ad5b0249a08665fefb913c3d1998e
> git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb955
> 8310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
> git://xenbits.xen.org/qemu-xen-traditional.git#bc00cad75d8bcc3ba696992b
> ec219c21db8406aa-bc00cad75d8bcc3ba696992bec219c21db8406aa
> git://xenbits.xen.org/qemu-xen.git#816609b2841297925a2
Re: [Xen-devel] [xen-unstable test] 65141: regressions - FAIL
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, November 27, 2015 11:54 PM
> To: Hu, Robert
> Cc: xen-de...@lists.xensource.com; osstest service owner
>
> Subject: Re: [xen-unstable test] 65141: regressions - FAIL
>
> osstest service owner writes ("[xen-unstable test] 65141: regressions -
> FAIL"):
> > flight 65141 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/65141/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail
> REGR. vs. 65114
>
> Hi, Robert. I hope you don't mind me asking you about these Nested
> HVM tests in osstest production; if there's someone else we should
> contact please let us know.
[Hu, Robert]
I'm trying to look for...
But can I get the bad commit first?
>
> Anyway: it seems this test failed just now.
>
> osstest thinks it is a regression, but I think it is more likely that
> this test either exhibits a heisenbug, or that there is some problem
> which is specific to the particular host.
>
> We'd appreciate it if you and your colleagues could take a look at
> this and analyse the failure.
>
> In the meantime the osstest bisector will try to start work on it and
> I will report what it discovers.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST] make-flight: Run separate nested jobs on AMD and Intel
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, November 23, 2015 6:49 PM
> To: ian.jack...@eu.citrix.com; xen-devel@lists.xen.org
> Cc: Ian Campbell ; Hu, Robert
>
> Subject: [PATCH OSSTEST] make-flight: Run separate nested jobs on AMD and
> Intel
>
> nested HVM relies heavily on the underlying HVM implementation, which
> is different for Intel and AMD and therefore worth testing separately.
>
> Currently test-amd64-amd64-qemuu-nested is not tied to any specific
> vendor, split it into -amd and -intel jobs and set the host flags
> appropriately.
>
> Signed-off-by: Ian Campbell
> Cc: "Hu, Robert"
> ---
> make-flight | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/make-flight b/make-flight
> index 6f462ad..6b2b3ea 100755
> --- a/make-flight
> +++ b/make-flight
> @@ -269,7 +269,9 @@ do_hvm_debian_nested_tests () {
> xen-4.3-testing) return;;
>esac
>
> - job_create_test test-$xenarch$kern-$dom0arch$qemuu_suffix-nested \
> + for cpuvendor in amd intel; do
> +
> +job_create_test
> test-$xenarch$kern-$dom0arch$qemuu_suffix-nested-$cpuvendor \
> test-nested xl $xenarch $dom0arch $qemuu_runvar
> \
> l1_image=$(usual_debianhvm_image amd64)
> \
> l1_vifmodel='e1000'
> \
> @@ -277,7 +279,9 @@ do_hvm_debian_nested_tests () {
> l1_enable_nestedhvm='true'
> \
> l2_image=$(usual_debianhvm_image amd64)
> \
> bios=$bios
> \
> -all_hostflags=$most_hostflags,hvm
> +all_hostflags=$most_hostflags,hvm-$cpuvendor
> +
> + done
> }
>
> branch_debianhvm_arch () {
[Hu, Robert]
Aced-by: Robert Hu
And thanks!
> --
> 2.6.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Nested HVM in xen-unstable tests
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, November 20, 2015 10:46 PM
> To: Hu, Robert
> Cc: osstest service owner ; Jin, Gordon
> ; xen-de...@lists.xensource.com
> Subject: Nested HVM in xen-unstable tests
>
> osstest service owner writes ("[xen-unstable test] 64750: regressions -
> FAIL"):
> > flight 64750 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/64750/
> ...
> > test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail
> baseline untested
>
> It appears that this new test case is failing in xen-unstable. The
> logs are here:
>
>
> http://logs.test-lab.xenproject.org/osstest/logs/64750/test-amd64-amd64-
> qemuu-nested/info.html
[Hu, Robert]
Thanks Ian letting us know about this.
Where can I find the related xen/qemu/dom0 kernel information?
>
> If you would like to avoid this feature regressing, you probably want
> to figure out what is wrong and send patches to fix it. In the
> meantime, the test will continue to fail in osstest but this will
> not block pushes and will not impede anyone else's work.
>
[Hu, Robert]
I thought the test failure would block related patches getting accepted.
>
> The primary failure symptom detected by osstest is visible here:
>
> http://logs.test-lab.xenproject.org/osstest/logs/64750/test-amd64-amd64-
> qemuu-nested/16.ts-debian-hvm-install.log
>
> Near the end:
>
> ssh: connect to host 172.16.146.31 port 22: No route to host
>
> Searching for 172.16.146.31 from the top of that log shows this:
>
> 2015-11-19 16:24:15 Z guest l1.guest.osstest: 5a:36:0e:ee:00:15
> 172.16.146.31
>
> So, at some point during the L2 install, the L1 has fallen off the
> network. "No route to host" almost certainly means it has stopped
> responding to ARP requests.
>
> The L1's `serial console' log (actually, the log captured by the L0 on
> the L1' emulated serial port) is here:
>
>
> http://logs.test-lab.xenproject.org/osstest/logs/64750/test-amd64-amd64-
> qemuu-nested/rimava0---var-log-xen-osstest-serial-l1.guest.osstest.log
>
> That shows
>
> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to
> DOM0)
>
> which is a result of ts-logs-capture sending it the debug keys (which
> you can see here
>
>
> http://logs.test-lab.xenproject.org/osstest/logs/64750/test-amd64-amd64-
> qemuu-nested/17.ts-logs-capture.log
>
> 2015-11-19 16:27:33 Z spawning 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_64750.test-amd64-amd64-qemuu
> -nested root@172.16.144.42
> 'cat >/root/64750.test-amd64-amd64-qemuu-nested.l1.guest.osstest.serial.i
> n'
> 2015-11-19 16:27:33 Z xenuse sending request for input to Xen
>
> So the L1 hasn't completely crashed.
[Hu, Robert]
Yes. Let me try to reproduce this after you tell me the Xen/qemu/dom0
version/commit id.
>
> During the log capture, ossstest correctly diagnoses that the L1 is
> unreachable. osstest would then normally `power cycle' the `host',
> but in the version of osstest used for this test, that functionality
> is broken. This was fixed in my recent set of patches which have
> passed the osstest push gate, and we will soon start to see test
> reports which are using the fixed version.
[Hu, Robert]
OK. Thanks.
>
> You can see a similar failure with better logs here:
>
>
> http://osstest.xs.citrite.net/~osstest/testlogs/logs/38313/test-amd64-amd6
> 4-qemuu-nested/info.html
>
>
> Let me know if I can do more to help point you to the right bits of
> the logs, etc. Good luck.
>
> Regards,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 1/2] Nested hosts: Provide hostnamepath and hostnamepath_list
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, November 17, 2015 5:51 PM
> To: Hu, Robert ; Ian Jackson
> ; xen-de...@lists.xenproject.org
> Subject: Re: [OSSTEST PATCH 1/2] Nested hosts: Provide hostnamepath and
> hostnamepath_list
>
> On Tue, 2015-11-17 at 02:14 +, Hu, Robert wrote:
> > > -Original Message-
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > Sent: Monday, November 16, 2015 11:21 PM
> > > To: xen-de...@lists.xenproject.org
> > > Cc: Ian Campbell ; Ian Jackson
> > > ; Ian Jackson ;
> > > Hu,
> > > Robert
> > > Subject: [OSSTEST PATCH 1/2] Nested hosts: Provide hostnamepath and
> > > hostnamepath_list
> > >
> > > This can (and often should) be used to replace $ho->{Name}.
> > >
> > > For an L0 host it returns "$ho->{Name}", ie HOST.
> > >
> > > For a plain guest or L1 guest it returns
> > > "$ho->{Host}{Name}_$ho->{Name}", ie HOST_GUEST or HOST_L1.
> > >
> > > For an L2 guest it recurses further, giving HOST_L1_L2.
> > >
> > > Signed-off-by: Ian Jackson
> > > CC: Robert Ho
> > > ---
> > > Osstest/TestSupport.pm | 15 +++
> > > 1 file changed, 15 insertions(+)
> > >
> > > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > > index 6be50e3..47b3e6f 100644
> > > --- a/Osstest/TestSupport.pm
> > > +++ b/Osstest/TestSupport.pm
> > > @@ -70,6 +70,7 @@ BEGIN {
> > >
> > > selecthost get_hostflags
> get_host_property
> > > get_target_property
> > > get_host_native_linux_console
> > > + hostnamepath hostnamepath_list
> > > power_state power_cycle
> power_cycle_sleep
> > > serial_fetch_logs
> > > propname_massage
> propname_check
> > > @@ -1063,6 +1064,20 @@ sub get_host_method_object ($$$) {
> > > return $mo;
> > > }
> > >
> > > +sub hostnamepath_list ($);
> > > +sub hostnamepath_list ($) {
> > > +# returns list of guest/host names, innermost first
> > > +my ($ho) = @_;
> > > +return () unless $ho && $ho->{Name};
> > [Hu, Robert]
> >
> > Is the situation $ho or $ho->{Name} undefined normal? Shall we
> > add warning here?
>
> It can happen through the recursion in the line below. i.e. this is a bit
> like the NULL terminator at the end of a linked list.
[Hu, Robert]
Oh, I see. Yes, that's right.
>
> >
> > > +return ($ho->{Name}, hostnamepath_list($ho->{Host}));
> > > +}
> > > +
> > > +sub hostnamepath ($) {
> > > +my ($ho) = @_;
> > > +my @l = hostnamepath_list($ho);
> > > +join '_', reverse @l;
> > > +}
> > > +
> > > #-- stashed files --
> > >
> > > sub open_unique_stashfile ($) {
> > > --
> > > 1.7.10.4
> >
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 1/2] Nested hosts: Provide hostnamepath and hostnamepath_list
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Monday, November 16, 2015 11:21 PM
> To: xen-de...@lists.xenproject.org
> Cc: Ian Campbell ; Ian Jackson
> ; Ian Jackson ; Hu,
> Robert
> Subject: [OSSTEST PATCH 1/2] Nested hosts: Provide hostnamepath and
> hostnamepath_list
>
> This can (and often should) be used to replace $ho->{Name}.
>
> For an L0 host it returns "$ho->{Name}", ie HOST.
>
> For a plain guest or L1 guest it returns
> "$ho->{Host}{Name}_$ho->{Name}", ie HOST_GUEST or HOST_L1.
>
> For an L2 guest it recurses further, giving HOST_L1_L2.
>
> Signed-off-by: Ian Jackson
> CC: Robert Ho
> ---
> Osstest/TestSupport.pm | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index 6be50e3..47b3e6f 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -70,6 +70,7 @@ BEGIN {
>
>selecthost get_hostflags get_host_property
>get_target_property
> get_host_native_linux_console
> + hostnamepath hostnamepath_list
>power_state power_cycle power_cycle_sleep
>serial_fetch_logs
>propname_massage propname_check
> @@ -1063,6 +1064,20 @@ sub get_host_method_object ($$$) {
> return $mo;
> }
>
> +sub hostnamepath_list ($);
> +sub hostnamepath_list ($) {
> +# returns list of guest/host names, innermost first
> +my ($ho) = @_;
> +return () unless $ho && $ho->{Name};
[Hu, Robert]
Is the situation $ho or $ho->{Name} undefined normal? Shall we
add warning here?
> +return ($ho->{Name}, hostnamepath_list($ho->{Host}));
> +}
> +
> +sub hostnamepath ($) {
> +my ($ho) = @_;
> +my @l = hostnamepath_list($ho);
> +join '_', reverse @l;
> +}
> +
> #-- stashed files --
>
> sub open_unique_stashfile ($) {
> --
> 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing)
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, November 16, 2015 6:30 PM
> To: Hu, Robert ; Ian Jackson
>
> Cc: Jin, Gordon ; xen-de...@lists.xenproject.org
> Subject: Re: Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2
> 10-26/26] Nested HVM testing)
>
> On Mon, 2015-11-16 at 01:49 +, Hu, Robert wrote:
> > >
> > Great, thank you both.
> > So it will go into your pretest soon, after Ian C. acks, right?
>
> Ian seems to have pushed it over the weekend, the result ("tolerable FAIL -
> PUSHED") is at
> http://lists.xenproject.org/archives/html/osstest-output/2015-11/msg01982
> .html
>
> I suppose you will be most interested in:
> http://logs.test-lab.xenproject.org/osstest/logs/64314/test-amd64-amd64-
> qemuu-nested/info.html
>
> So it should be live in any relevant flights started from now on.
>
> Congrats!
[Hu, Robert]
Thanks and appreciate your review and guidance!
>
> Ian, I notice in the logs that some of the webspace files (specifically
> those relating to the l2, I think[0]) do not have the l0 hostname in the
> filename, mightn't they therefore clash?
>
> Ian.
>
> [0] e.g. "webspace-l1.guest.osstest_l2.guest.osstest_known_hosts"
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing)
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, November 13, 2015 6:29 PM
> To: Hu, Robert
> Cc: Ian Campbell ; Jin, Gordon
> ; xen-de...@lists.xenproject.org
> Subject: RE: Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2
> 10-26/26] Nested HVM testing)
>
> Hu, Robert writes ("RE: Osstest nested patch v15 (was RE: [OSSTEST PATCH
> v14 PART 2 10-26/26] Nested HVM testing)"):
> > Yes. In last test step, ts-logs-capture host, I can see
> >
> > 2015-11-12 03:22:06 Z fetching
> /var/log/xen/osstest-serial-l1.guest.osstest.log to
> osstest-host2---var-log-xen-osstest-serial-l1.guest.osstest.log
> > 2015-11-12 03:22:06 Z executing scp ...
> root@192.168.199.70:/var/log/xen/osstest-serial-l1.guest.osstest.log
> logs/standalone/test-amd64-amd64-qemuu-nested/osstest-host2---var-log-
> xen-osstest-serial-l1.guest.osstest.log
>
> Good.
>
> > See attached. Seems no debug keys in it.
>
> Actually:
>
> (XEN) '0' pressed -> dumping Dom0's registers
>
> ...
> (XEN) 'H' pressed -> dumping heap info (now-0x119:584209D7)
>
> ...
>
> So it is working.
>
> Thanks. I will send out a final version for the record (and for Ian C
> to hopefully ack).
>
[Hu, Robert]
Great, thank you both.
So it will go into your pretest soon, after Ian C. acks, right?
> Regards,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing)
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, November 13, 2015 12:10 AM
> To: Hu, Robert
> Cc: Ian Campbell ; Jin, Gordon
> ; xen-de...@lists.xenproject.org
> Subject: RE: Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2
> 10-26/26] Nested HVM testing)
>
> Hu, Robert writes ("RE: Osstest nested patch v15 (was RE: [OSSTEST PATCH
> v14 PART 2 10-26/26] Nested HVM testing)"):
> > Here is detail logs
>
> Thanks. Most of this is fine.
>
> > 2015-11-12 03:21:43 Z serial: collecting logs for l1.guest.osstest
> > Use of uninitialized value in concatenation (.) or string at
> Osstest/Serial/guest.pm line 91.
> > Use of uninitialized value in concatenation (.) or string at
> Osstest/Serial/guest.pm line 91.
>
> This is me being idiotic. I have a patch below which I'm pretty sure
> will fix it. Anyway, I don't think I need it retested for this reason
> because this is just a wrong log message, which we can fix in-tree if
> necessary.
>
> What I want to know is whether the l1 serial console logfile was
> collected, and contains the debug output.
>
> I think you should find this in the output of the ts-logs-capture for
> the host (L0). Something like
>
> 2015-11-12 03:21:48 Z fetching
> /var/log/xen/osstest-serial-l1.guest.osstest.log to
> MYHOSTNAME---var-log-xen-osstest-serial-l1.guest.osstest.log
[Hu, Robert]
Yes. In last test step, ts-logs-capture host, I can see
2015-11-12 03:22:06 Z fetching /var/log/xen/osstest-serial-l1.guest.osstest.log
to osstest-host2---var-log-xen-osstest-serial-l1.guest.osstest.log
2015-11-12 03:22:06 Z executing scp ...
root@192.168.199.70:/var/log/xen/osstest-serial-l1.guest.osstest.log
logs/standalone/test-amd64-amd64-qemuu-nested/osstest-host2---var-log-xen-osstest-serial-l1.guest.osstest.log
>
> If you look in the logs directory, do you have a file matching
> *-serial-l1.* ? If so, can you send it to me ? I think (hope)! it
> will have the debug keys.
[Hu, Robert]
See attached. Seems no debug keys in it.
>
> Thanks,
> Ian.
>
> diff --git a/Osstest/Serial/guest.pm b/Osstest/Serial/guest.pm
> index 286773d..2511556 100644
> --- a/Osstest/Serial/guest.pm
> +++ b/Osstest/Serial/guest.pm
> @@ -86,7 +86,7 @@ sub keys_shutdown {
> }
>
> sub fetch_logs {
> -my ($mo);
> +my ($mo) = @_;
>
> logm("$mo->{Target}{Name} (nested host) serial console logs".
>" will be found in guest logs from $mo->{Parent}{Name} (parent)");
osstest-host2---var-log-xen-osstest-serial-l1.guest.osstest.log
Description: osstest-host2---var-log-xen-osstest-serial-l1.guest.osstest.log
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing)
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, November 11, 2015 10:06 PM
> To: Hu, Robert ; Ian Campbell
> ; Jin, Gordon ;
> xen-de...@lists.xenproject.org
> Subject: RE: Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2
> 10-26/26] Nested HVM testing)
>
> Ian Jackson writes ("RE: Osstest nested patch v15 (was RE: [OSSTEST PATCH
> v14 PART 2 10-26/26] Nested HVM testing)"):
> ...
> > This shows that my guest.pm is completely broken. sshuho needs
> > exporting from TestSupport. After that is fixed there are probably
> > other bugs.
>
> I think I have fixed this. I've updated my git branch with some
> fast-forwarding (mostly `squash!') patches.
>
> The result is now available at:
> git://xenbits.xen.org/people/iwj/osstest.git
> http://xenbits.xen.org/git-http/people/iwj/osstest.git
> in wip.nested-hvm.v16.
[Hu, Robert]
Tested wip.nested-hvm.v17-pre.
Here is detail logs
2015-11-12 03:20:39 Z standalone.test-amd64-amd64-qemuu-nested == 19
testid capture-logs/l1(19) ==
2015-11-12 03:20:39 Z awaiting standalone.test-amd64-amd64-qemuu-nested
ts-logs-capture l1
+ OSSTEST_JOB=test-amd64-amd64-qemuu-nested
+ export OSSTEST_JOB
+ ./ts-logs-capture l1
...
2015-11-12 03:20:39 Z guest: using l1 on osstest-host2
2015-11-12 03:20:39 Z serial method guest l1.guest.osstest:
2015-11-12 03:20:39 Z guest l1.guest.osstest: 5e:36:0e:f5:00:01 192.168.199.50
2015-11-12 03:20:39 Z L1 host l1: guest l1 (in osstest-host2) 5e:36:0e:f5:00:01
192.168.199.50
2015-11-12 03:20:39 Z guest: using l1 on l1.guest.osstest
2015-11-12 03:20:39 Z executing ssh ... root@192.168.199.50 xl list
l1.guest.osstest
l1.guest.osstest is an invalid domain identifier (rc=-6)
2015-11-12 03:20:39 Z command nonzero waitstatus 512: timeout 90 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_standalone.test-amd64-amd64-qemuu-nested
root@192.168.199.50 xl list l1.guest.osstest
2015-11-12 03:20:39 Z cannot find domid: status 512 at Osstest/TestSupport.pm
line 410.
2015-11-12 03:20:39 Z guest: using l2 on l1.guest.osstest
2015-11-12 03:20:39 Z executing ssh ... root@192.168.199.50 xl list
l2.guest.osstest
l2.guest.osstest is an invalid domain identifier (rc=-6)
2015-11-12 03:20:39 Z command nonzero waitstatus 512: timeout 90 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_standalone.test-amd64-amd64-qemuu-nested
root@192.168.199.50 xl list l2.guest.osstest
2015-11-12 03:20:39 Z cannot find domid: status 512 at Osstest/TestSupport.pm
line 410.
2015-11-12 03:20:39 Z serial: requesting debug information from l1.guest.osstest
2015-11-12 03:20:39 Z spawning 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_standalone.test-amd64-amd64-qemuu-nested
root@192.168.199.70 'cat
>/root/standalone.test-amd64-amd64-qemuu-nested.l1.guest.osstest.serial.in'
2015-11-12 03:20:39 Z xenuse sending request for input to Xen
2015-11-12 03:20:40 Z xenuse sending Xen debug info request, debug key 0
2015-11-12 03:20:42 Z xenuse sending Xen debug info request, debug key H
2015-11-12 03:20:44 Z xenuse sending Xen debug info request, debug key M
2015-11-12 03:20:46 Z xenuse sending Xen debug info request, debug key Q
2015-11-12 03:20:48 Z xenuse sending Xen debug info request, debug key a
2015-11-12 03:20:50 Z xenuse sending Xen debug info request, debug key c
2015-11-12 03:20:52 Z xenuse sending Xen debug info request, debug key d
2015-11-12 03:20:54 Z xenuse sending Xen debug info request, debug key e
2015-11-12 03:20:56 Z xenuse sending Xen debug info request, debug key g
2015-11-12 03:20:58 Z xenuse sending Xen debug info request, debug key i
2015-11-12 03:21:00 Z xenuse sending Xen debug info request, debug key m
2015-11-12 03:21:02 Z xenuse sending Xen debug info request, debug key n
2015-11-12 03:21:04 Z xenuse sending Xen debug info request, debug key r
2015-11-12 03:21:06 Z xenuse sending Xen debug info request, debug key s
2015-11-12 03:21:08 Z xenuse sending Xen debug info request, debug key t
2015-11-12 03:21:10 Z xenuse sending Xen debug info request, debug key u
2015-11-12 03:21:12 Z xenuse sending Xen debug info request, debug key v
2015-11-12 03:21:14 Z xenuse sending Xen debug info request, debug key z
2015-11-12 03:21:26 Z xenuse sending guest debug info request, debug key q
2015-11-12 03:21:38 Z xenuse sending RET to dom0
2015-11-12 03:21:43 Z serial: collecting logs for l1.gues
Re: [Xen-devel] Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing)
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, November 11, 2015 5:35 PM
> To: Hu, Robert
> Cc: Ian Campbell ; Jin, Gordon
> ; xen-de...@lists.xenproject.org
> Subject: RE: Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2
> 10-26/26] Nested HVM testing)
>
> Hu, Robert writes ("RE: Osstest nested patch v15 (was RE: [OSSTEST PATCH
> v14 PART 2 10-26/26] Nested HVM testing)"):
> > [Ian Jackson:]
> > > Can you please test this final patch in your environment ? Send me
> > > fixes in whatever form you like.
> >
> > Hi Ian, I've tested your v16 patches (from wip.nested-hvm.v16). Pass.
>
> Thanks. I think this is too good to be true.
[Hu, Robert]
I thought this as well. But I looked into logs, see attached. Each step passes.
Also attach osstest-serial-l1.guest.osstest.log.
>
> Can you check to see whether the ts-logs-capture on the L1 actually
> managed to send any debug keys ?
>
> Look in the L1's serial console log which should be in
> /var/log/xen/osstest-serial*, and in the ts-logs-capture output.
[Hu, Robert]
em... From 19 testid capture-logs/l1(19) log, I see failures. Going to look
into.
2015-11-11 03:47:06 Z executing ssh ... root@192.168.199.53 xl list
l1.guest.osstest
l1.guest.osstest is an invalid domain identifier (rc=-6)
2015-11-11 03:47:06 Z command nonzero waitstatus 512: timeout 90 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_standalone.test-amd64-amd64-qemuu-nested
root@192.168.199.53 xl list l1.guest.osstest
2015-11-11 03:47:06 Z cannot find domid: status 512 at Osstest/TestSupport.pm
line 410.
2015-11-11 03:47:06 Z guest: using l2 on l1.guest.osstest
2015-11-11 03:47:06 Z executing ssh ... root@192.168.199.53 xl list
l2.guest.osstest
l2.guest.osstest is an invalid domain identifier (rc=-6)
2015-11-11 03:47:07 Z command nonzero waitstatus 512: timeout 90 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_standalone.test-amd64-amd64-qemuu-nested
root@192.168.199.53 xl list l2.guest.osstest
2015-11-11 03:47:07 Z cannot find domid: status 512 at Osstest/TestSupport.pm
line 410.
2015-11-11 03:47:07 Z serial: requesting debug information from l1.guest.osstest
failed to send debug key(s): Undefined subroutine
&Osstest::Serial::guest::sshuho called at Osstest/Serial/guest.pm line 53.
2015-11-11 03:47:07 Z serial: collecting logs for l1.guest.osstest
Use of uninitialized value in concatenation (.) or string at
Osstest/Serial/guest.pm line 88.
Use of uninitialized value in concatenation (.) or string at
Osstest/Serial/guest.pm line 88.
2015-11-11 03:47:07 Z (nested host) serial console logs will be found in guest
logs from (parent)
2015-11-11 03:47:07 Z executing ssh ... root@192.168.199.53
chmod a+r /var/log/kern.log* >/dev/null 2>&1 ||:
echo /var/log/kern.log*
>
> Thanks,
> Ian.
latest_log
Description: latest_log
osstest-serial-l1.guest.osstest.log
Description: osstest-serial-l1.guest.osstest.log
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing)
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, November 11, 2015 3:46 AM
> To: Hu, Robert
> Cc: Ian Campbell ; Jin, Gordon
> ; xen-de...@lists.xenproject.org
> Subject: Osstest nested patch v15 (was RE: [OSSTEST PATCH v14 PART 2
> 10-26/26] Nested HVM testing)
>
> Hu, Robert writes ("Osstest nested patch v15 (was RE: [OSSTEST PATCH v14
> PART 2 10-26/26] Nested HVM testing)"):
> > I here hand over to you the v15 patch bundle as attached. Hope it can pass
> your pretest soon.
>
> Thanks. (CCing the list.)
>
> All of your fixes were good. Thank you. I have incorporated them.
>
> > * The last patch of 'guest' Serial method, was made by myself, you
> > may want to rewrite it or modify it. I don't have the
> > confidence. But it doesn't blocks others, with or without it, the
> > patch set can work fine.
>
> I rewrote this. I found I wanted to do some refactoring first to make
> this easier.
>
> I am going to send out a v16 of the whole series in just a moment.
>
> Can you please test this final patch in your environment ? Send me
> fixes in whatever form you like.
[Hu, Robert]
Hi Ian, I've tested your v16 patches (from wip.nested-hvm.v16). Pass.
>
> I think we do need this debug keys feature to work before we push this
> to osstest pretest, because otherwise we risk having un-debuggable
> blocking failures in our CI.
>
> Regards,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
> -Original Message-
> From: Hu, Robert
> Sent: Monday, November 2, 2015 11:44 AM
> To: 'Ian Jackson' ;
> xen-de...@lists.xenproject.org
> Cc: Ian Campbell
> Subject: RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
>
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Saturday, September 26, 2015 3:15 AM
> > To: xen-de...@lists.xenproject.org
> > Cc: Hu, Robert ; Ian Campbell
> > ; Ian Jackson
> > Subject: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
> >
> > This is the second part of v14 Robert Ho's osstest patch series to
> > support nested HVM tests.
> >
> > It is also available here:
> > git://xenbits.xen.org/people/iwj/xen.git
> > http://xenbits.xen.org/git-http/people/iwj/xen.git
> > in wip.nested-hvm.v14.part1..wip.nested-hvm.v14
> >
> > Compared to Robert's v13, which was passed to me by private email,
> > * I have rebased onto current osstest pretest;
> > * I have changed how selecthost() is told it's dealing with
> >a nested host (in practice, L1 guest);
> > * There are a large number of minor cleanups;
> > * There are some new preparatory cleanup and admin patches;
> > * I have rewritten almost all of the commit messages.
> >
> > However, I have done only VERY LIMITED testing. Much of the code here
> > is UNTESTED since my changes. My testing was confined to:
> > * Verifying that my changes to cs-adjust-flight worked
> > * Checking that ad-hoc runs of ts-host-reboot and ts-host-powercycle
> >seemed to work when a guest was specified on the command line.
> >
> > Robert, you kindly volunteered to test a revised version of this
> > series. I would appreciate if you would check that all of this still
> > works as you expect. I expect there will be some bugs, perhaps even
> > very silly bugs, introduced by me.
> >
> > I noticed that this series lacks guest serial debug keys and log
> > collection for the L1 guest, because there is no
> > Osstest/Serial/guest.pm. I would appreciate it if you would provide
> > one. I don't think it needs to actually collect any logs, because the
> > L1 serial output log will be collected as part of the L0 log
> > collection. But it ought to support sending debug keys to the L1
> > guest. When you have provided it you can (in the same patch) fix the
> > corresponding `todo' in selecthost, changing `noop' to `guest'.
> [Hu, Robert]
>
> Hi Ian,
> Are you sure would like me to add this part? I took glance at the module
> code (noop, xenuse, etc.), didn't quite understand.
> I can imitate them for the Serial::guest.pm, but afraid will not that good.
>
[Hu, Robert]
Don't quite understand this "\x18\x18\x18" part. What's it for? What's
the meaning of $conswitch? I think it is not needed by guest case.
sub serial_fetch_logs ($) {
my ($ho) = @_;
logm("serial: requesting debug information from $ho->{Name}");
foreach my $mo (@{ $ho->{SerialMethobjs} }) {
$mo->request_debug("\x18\x18\x18",
"0HMQacdegimnrstuvz",
"q") or next;
...
> >
> >
> > Workflow:
> >
> > Robert: I'm handing this (what I have called `part 2') over to you
> > now.
> >
> > When you make changes, feel free to either rebase, or to make fixup
> > commits (perhaps in `git-rebase -i --autosquash' format) on top. If
> > you do the latter then you'll probably want to pass that to me as a
> > git branch (via git push to xenbits or emailing me a git bundle),
> > since `squash!' and `fixup!' commits don't look good in email :-).
> >
> > If you rebase, please put changes
> >v15:
> > in the commit messages, as I have done myself in v14. Leave my v14
> > notes in place.
> [Hu, Robert]
>
> Now I've completed this part of work. Am I going to hand over the v15
> bundle
> to you, with the above unresolved?
> Current changes based on your patch:
> * Some fixed (already get your confirmation) squashed into original patches,
> with
> v15 annotation.
> * 2 fixes (not get your confirmation) are separated as !fixup patch for your
> clear
> review; actually only 1 explicit fixup patch, the other was by mistake
> squashed in
> but I made the annotation clearly.
> * 2 more patches added, you've already been aware of:
> Osstest/Testsupport.pm: change target's default kernkind to 'pvops'
> Osstest/Testsupport.
Re: [Xen-devel] [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: Saturday, September 26, 2015 3:15 AM > To: xen-de...@lists.xenproject.org > Cc: Hu, Robert ; Ian Campbell > ; Ian Jackson > Subject: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing > > This is the second part of v14 Robert Ho's osstest patch series to > support nested HVM tests. > > It is also available here: > git://xenbits.xen.org/people/iwj/xen.git > http://xenbits.xen.org/git-http/people/iwj/xen.git > in wip.nested-hvm.v14.part1..wip.nested-hvm.v14 > > Compared to Robert's v13, which was passed to me by private email, > * I have rebased onto current osstest pretest; > * I have changed how selecthost() is told it's dealing with >a nested host (in practice, L1 guest); > * There are a large number of minor cleanups; > * There are some new preparatory cleanup and admin patches; > * I have rewritten almost all of the commit messages. > > However, I have done only VERY LIMITED testing. Much of the code here > is UNTESTED since my changes. My testing was confined to: > * Verifying that my changes to cs-adjust-flight worked > * Checking that ad-hoc runs of ts-host-reboot and ts-host-powercycle >seemed to work when a guest was specified on the command line. > > Robert, you kindly volunteered to test a revised version of this > series. I would appreciate if you would check that all of this still > works as you expect. I expect there will be some bugs, perhaps even > very silly bugs, introduced by me. > > I noticed that this series lacks guest serial debug keys and log > collection for the L1 guest, because there is no > Osstest/Serial/guest.pm. I would appreciate it if you would provide > one. I don't think it needs to actually collect any logs, because the > L1 serial output log will be collected as part of the L0 log > collection. But it ought to support sending debug keys to the L1 > guest. When you have provided it you can (in the same patch) fix the > corresponding `todo' in selecthost, changing `noop' to `guest'. [Hu, Robert] Hi Ian, Are you sure would like me to add this part? I took glance at the module code (noop, xenuse, etc.), didn't quite understand. I can imitate them for the Serial::guest.pm, but afraid will not that good. > > > Workflow: > > Robert: I'm handing this (what I have called `part 2') over to you > now. > > When you make changes, feel free to either rebase, or to make fixup > commits (perhaps in `git-rebase -i --autosquash' format) on top. If > you do the latter then you'll probably want to pass that to me as a > git branch (via git push to xenbits or emailing me a git bundle), > since `squash!' and `fixup!' commits don't look good in email :-). > > If you rebase, please put changes >v15: > in the commit messages, as I have done myself in v14. Leave my v14 > notes in place. [Hu, Robert] Now I've completed this part of work. Am I going to hand over the v15 bundle to you, with the above unresolved? Current changes based on your patch: * Some fixed (already get your confirmation) squashed into original patches, with v15 annotation. * 2 fixes (not get your confirmation) are separated as !fixup patch for your clear review; actually only 1 explicit fixup patch, the other was by mistake squashed in but I made the annotation clearly. * 2 more patches added, you've already been aware of: Osstest/Testsupport.pm: change target's default kernkind to 'pvops' Osstest/Testsupport.pm: use get_target_property() for some host setup > > Of course if you have any comments or queries about how I have done > things, they would be very welcome. > > Please do not rebase any of the commits in wip.nested-hvm.v14.part1. > If you discover bugs in `part 1' please let us know as I have fed that > into the osstest self-test mill with the expectation that it will go > into production. > > I do not expect you to test the changes to cs-adjust-flight. I have > done that. Indeed they are not really related to the Nested HVM work > and Ian C and I may pick them up in another series. > > > Ian Campbell: You probably want to defer re-reviewing this until > Robert reports back. > > Signed-off-by: Ian Jackson > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 25/26] ts-xen-install: Properly handle hosts without a static IP address
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Monday, September 28, 2015 6:33 PM > To: Ian Jackson ; > xen-de...@lists.xenproject.org > Cc: Hu, Robert > Subject: Re: [OSSTEST PATCH 25/26] ts-xen-install: Properly handle hosts > without a static IP address > > On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote: > > From: Robert Ho > > > > Check IpStatic, and if it is not set, provide a dhcp stanza in > > /etc/network/interfaces, rather than an `inet static' one. > > > > This is necessary for L1 nested hosts, because they don't have a > > static IP address. > > > > In principle this makes matters more correct for physical hosts > > without static IP addresses, but these are currently not supported > > by selecthost(). > > > > Signed-off-by: Robert Ho > > Signed-off-by: Ian Jackson > > Acked-by: Ian Campbell [Hu, Robert] Tested-by: Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 20/26] sg-run-job: Break out per-host-prep and per-host-finish
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, September 28, 2015 6:19 PM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Hu, Robert
> Subject: Re: [OSSTEST PATCH 20/26] sg-run-job: Break out per-host-prep and
> per-host-finish
>
> On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> > No functional change.
> >
> > We now call the per-host-ts finish steps unconditionally, rather than
> > only if !$need_build_host, per-host-ts is (complicated) no-op if
> > $need_build_host, since in that case $need_xen_hosts is {}.
> >
> > Signed-off-by: Ian Jackson
> > Signed-off-by: Robert Ho
> > Tested by: Robert Ho
>
> Acked-by: Ian Campbell
[Hu, Robert]
Tested-by: Robert Ho
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 17/26] await_tcp(): Run check_ip on each loop iteration
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Monday, September 28, 2015 6:16 PM > To: Ian Jackson ; > xen-de...@lists.xenproject.org > Cc: Hu, Robert > Subject: Re: [OSSTEST PATCH 17/26] await_tcp(): Run check_ip on each loop > iteration > > On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote: > > From: Robert Ho > > > > await_tcp is often invoked after a reboot. > > > > In this situation the target's IP address may change. If this happens > > while await_tcp is running, we would continue to poll the old IP address. > > Fix this by running target_check_ip on each iteration. > > > > Signed-off-by: Robert Ho > > Signed-off-by: Ian Jackson > > Acked-by: Ian Campbell [Hu, Robert] Tested-by: Robert Hu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 16/26] target_check_ip: Rename and improve from guest_check_ip
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Monday, September 28, 2015 6:15 PM > To: Ian Jackson ; > xen-de...@lists.xenproject.org > Cc: Hu, Robert > Subject: Re: [OSSTEST PATCH 16/26] target_check_ip: Rename and improve > from guest_check_ip > > On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote: > > Make this function suitable for running on targets with static IP > > addresses. (Ie, on physical hosts.) Accordingly, rename it and > > adjust all call sites. > > > > Signed-off-by: Ian Jackson > > Acked-by: Ian Campbell [Hu, Robert] Tested-by: Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 15/26] DhcpWatch::leases: Fix a reporting message
> -Original Message-
> From: Hu, Robert
> Sent: Monday, October 12, 2015 11:08 AM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Ian Campbell
> Subject: RE: [OSSTEST PATCH 15/26] DhcpWatch::leases: Fix a reporting
> message
>
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Saturday, September 26, 2015 3:15 AM
> > To: xen-de...@lists.xenproject.org
> > Cc: Hu, Robert ; Ian Campbell
> > ; Ian Jackson ; Ian
> > Jackson
> > Subject: [OSSTEST PATCH 15/26] DhcpWatch::leases: Fix a reporting
> message
> >
> > This talks about `guest_check_ip', but this code is now factored out
> > into a method. Use the correct method name in reporting.
> >
> > Signed-off-by: Ian Jackson
> > ---
> > v14: New patch
> > ---
> > Osstest/DhcpWatch/leases.pm |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Osstest/DhcpWatch/leases.pm
> b/Osstest/DhcpWatch/leases.pm
> > index 9a74c40..b74ebf0 100644
> > --- a/Osstest/DhcpWatch/leases.pm
> > +++ b/Osstest/DhcpWatch/leases.pm
> > @@ -171,7 +171,7 @@ sub check_ip ($$) {
> > }
> > $gho->{Ip}= $best->{' addr'};
> >
> > -report_once($gho, 'guest_check_ip',
> > +report_once($gho, 'leases::check_ip',
> > "guest $gho->{Name}: $gho->{Ether} $gho->{Ip}");
> > return undef;
> > }
> Ack.
[Hu, Robert]
Tested-by: Robert Ho
> > --
> > 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 14/26] Nested hosts: Provide PDU power method
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, September 28, 2015 6:11 PM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Hu, Robert
> Subject: Re: [OSSTEST PATCH 14/26] Nested hosts: Provide PDU power
> method
>
> On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> > From: Robert Ho
> >
> > This `guest' power method uses VM create/destroy. It is automatically
> > used for nested hosts. It would not make much sense to configure it
> > manually.
> >
> > For nested host/guest, its power on/off method shall be
> > its host invoke $(toolstack)->create/destroy method.
> >
> > XXX Missing Signed-off-by from Robert Hu
> > Signed-off-by: Ian Jackson
>
> Acked-by: Ian Campbell
[Hu, Robert]
Tested-by: Robert Hu
>
> > ---
> > v14: Mostly rewritten by iwj
> > ---
> > Osstest/PDU/guest.pm | 59
> >
> > Osstest/TestSupport.pm |2 +-
> > 2 files changed, 60 insertions(+), 1 deletion(-)
> > create mode 100755 Osstest/PDU/guest.pm
> >
> > diff --git a/Osstest/PDU/guest.pm b/Osstest/PDU/guest.pm
> > new file mode 100755
> > index 000..b6bf9a1
> > --- /dev/null
> > +++ b/Osstest/PDU/guest.pm
> > @@ -0,0 +1,59 @@
> > +# This is part of "osstest", an automated testing framework for Xen.
> > +# Copyright (C) 2015 Intel.
> > +#
> > +# This program is free software: you can redistribute it and/or modify
> > +# it under the terms of the GNU Affero General Public License as
> > published by
> > +# the Free Software Foundation, either version 3 of the License, or
> > +# (at your option) any later version.
> > +#
> > +# This program is distributed in the hope that it will be useful,
> > +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > +# GNU Affero General Public License for more details.
> > +#
> > +# You should have received a copy of the GNU Affero General Public
> > License
> > +# along with this program. If not, see <http://www.gnu.org/licenses/>.
> > +
> > +
> > +package Osstest::PDU::guest;
> > +
> > +use strict;
> > +use warnings;
> > +use Switch;
> > +
> > +use Osstest;
> > +use Osstest::TestSupport;
> > +use IO::File;
> > +
> > +BEGIN {
> > +use Exporter ();
> > +our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
> > +$VERSION = 1.00;
> > +@ISA = qw(Exporter);
> > +@EXPORT = qw();
> > +%EXPORT_TAGS = ( );
> > +
> > +@EXPORT_OK = qw();
> > +}
> > +
> > +sub new {
> > +my ($class, $ho) = @_;
> > +return bless { Target => $ho }, $class;
> > +}
> > +
> > +sub pdu_power_state {
> > +my ($mo, $on) = @_;
> > +
> > +my $child = $mo->{Target};
> > +my $parent = $child->{Host};
> > +die "$child->{Name} ?" unless $parent;
> > +
> > +logm("power $child->{Name} nested on $parent->{Name}
> ".($on+0));
> > +if ($on) {
> > + toolstack($parent)->create($child);
> > +} else {
> > + toolstack($parent)->destroy($child);
> > +}
> > +}
> > +
> > +1;
> > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > index 9b10602..3025c9f 100644
> > --- a/Osstest/TestSupport.pm
> > +++ b/Osstest/TestSupport.pm
> > @@ -855,7 +855,7 @@ sub selecthost ($) {
> > $child->{Info} = [ "in", $parent->{Name}, @{ $parent->{Info} }
> > ];
> > $child->{NestingLevel} = $parent->{NestingLevel}+1;
> >
> > - # $child->{Power} = 'guest'; todo
> > + $child->{Power} = 'guest';
> > power_cycle_host_setup($child);
> >
> > $child->{Properties}{Serial} = 'noop'; # todo
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 12/26] selecthost: Minor cleanups
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Monday, September 28, 2015 6:02 PM > To: Ian Jackson ; > xen-de...@lists.xenproject.org > Cc: Hu, Robert > Subject: Re: [OSSTEST PATCH 12/26] selecthost: Minor cleanups > > On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote: > > Document the syntax for $ident. > > > > Log the ident as well as the selected hostname. > > > > Signed-off-by: Ian Jackson > > Acked-by: Ian Campbell [Hu, Robert] Tested-by: Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 21/26] sg-run-job: Provide infrastructure for layers of nesting
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson ; Ian
> Jackson
> Subject: [OSSTEST PATCH 21/26] sg-run-job: Provide infrastructure for layers
> of nesting
>
> Provides nested-layer-descend, which can be called in an individual
> test job at the appropriate point (after the L1 has been set up).
>
> The inner host is a guest of the outer host; powering it off means
> destroying it. Putting the poweroff at this point in the loop, rather
> than in per-host-finish, avoids powering off physical servers. The
> use of `.' rather than `!.' for iffail means we do not power off
> after failures (as we might want to preserve the state for debugging
> etc).
>
> Signed-off-by: Ian Jackson
> Tested-by: Robert Ho
> Signed-off-by: Robert Ho
> ---
> v14: Squash syntax fix from Robert Ho into this patch
> ---
> sg-run-job | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/sg-run-job b/sg-run-job
> index 884a21d..8174ef7 100755
> --- a/sg-run-job
> +++ b/sg-run-job
> @@ -39,6 +39,7 @@ proc per-host-finish {} {
>
> proc run-job {job} {
> global jobinfo builds flight ok need_xen_hosts anyfailed
> +global nested_layers_hosts
>
> set ok 1
> set anyfailed 0
> @@ -52,6 +53,7 @@ proc run-job {job} {
> set need_xen_hosts $nh
> set need_build_host 0
> }
> +set nested_layers_hosts {}
>
> catching-otherwise blockedcheck-not-blocked
> if {!$ok} return
> @@ -70,7 +72,15 @@ proc run-job {job} {
>
> if {$ok} { catching-otherwise fail
> run-job/$jobinfo(recipe) }
>
> -per-host-finish
> +while 1 {
> + per-host-finish
> +
> + if {![llength $nested_layers_hosts]} break
> +
> + per-host-ts . = final-poweroff {ts-host-powercycle --power=0}
[Hu, Robert]
I guess here is a unnecessary '='. Just guess, I don't manage to comprehend
the Tcl part.
> +
> +set need_xen_hosts [lunappend nested_layers_hosts]
> +}
>
> if {$need_build_host && $anyfailed} {
> run-ts !broken capture-logs ts-logs-capture + host
> @@ -247,6 +257,15 @@ proc per-host-ts {iffail ident script args} {
> }
> }
>
> +proc nested-layer-descend {nested_hosts} {
> +# We save need_xen_hosts on a stack in nested_layers_hosts
> +# It gets popped again during the cleanup part of run-job
> +global nested_layers_hosts need_xen_hosts
> +lappend nested_layers_hosts $need_xen_hosts
> +set need_xen_hosts $nested_hosts
> +per-host-prep
> +}
> +
> #-- test recipes --
>
> proc need-hosts/test-debian-nomigr {} { return host }
> --
> 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 23/26] Nested HVM: Provide test-nested recipe
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson
> Subject: [OSSTEST PATCH 23/26] Nested HVM: Provide test-nested recipe
>
> From: Robert Ho
>
> Signed-off-by: Robert Ho
> Signed-off-by: Ian Jackson
> ---
> v14: ts-nested-setup command line syntax updated.
> ---
> sg-run-job | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/sg-run-job b/sg-run-job
> index 8174ef7..6b59ab3 100755
> --- a/sg-run-job
> +++ b/sg-run-job
> @@ -348,6 +348,16 @@ proc run-job/test-pair-oneway {} {
> run-ts . = ts-guest-stop dst_host
> + debian
> }
>
> +proc need-hosts/test-nested {} {return host}
> +proc run-job/test-nested {} {
> +run-ts . = ts-debian-hvm-install + host l1
> +run-ts . = ts-nested-setup + --define l1=host:l1
> +nested-layer-descend l1
> +run-ts . = ts-debian-hvm-install l1 l2
> +run-ts . = ts-guest-stop l1 l2
> +run-ts . = ts-guest-destroy + host l1
> +}
> +
[Hu, Robert]
Not sure if rooted to this patch or patch 21 or 22, current test steps will
be
[root@robert-ivt osstest]# ./standalone run-job --dry-run -h dummy
test-amd64-amd64-qemuu-nested |grep testid
Could not open a connection to your authentication agent.
WARNING: Unable to access ssh-agent. Some tests may fail
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 1
testid build-check(1) ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 2
testid hosts-allocate ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 3
testid host-install(3) ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 4
testid host-ping-check-native ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 5
testid xen-install ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 6
testid xen-boot ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 7
testid host-ping-check-xen ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 8
testid leak-check/basis(8) ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 9
testid debian-hvm-install ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 10
testid nested-setup ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 11
testid host-ping-check-native/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 12
testid xen-install/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 13
testid xen-boot/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 14
testid host-ping-check-xen/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 15
testid leak-check/basis/l1(15) ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 16
testid debian-hvm-install/l1/l2 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 17
testid guest-stop/l1/l2 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 18
testid guest-destroy ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 19
testid leak-check/check/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 20
testid capture-logs/l1(20) ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 21
testid final-poweroff/l1 ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 22
testid leak-check/check ==
2015-10-29 02:16:25 Z standalone.test-amd64-amd64-qemuu-nested == 23
testid capture-logs(23) ==
standalone.test-amd64-amd64-qemuu-nested status = pass
Note step 18 destroies l1, while step 19 and step 20 will try to leak check and
capture log in l1.
I'm not quite understand these tcl part, any fix suggestions?
> proc test-guest-migr {g} {
> set to_reap [spawn-ts . = ts-migrate-support-check + host $g 1]
> set can_migrate [reap-ts $to_reap]
> --
> 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest nested patch PART2 -- L1 host has no 'Suite' property
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, October 28, 2015 7:58 PM
> To: Hu, Robert
> Cc: 'Ian Campbell' ; xen-devel@lists.xen.org
> Subject: Re: OSSTest nested patch PART2 -- L1 host has no 'Suite' property
>
> Hu, Robert writes ("OSSTest nested patch PART2 -- L1 host has no 'Suite'
> property"):
> > Now the patch has been refined to get whole
> 'test-amd64-amd64-qemuu-nested' pass.
>
> How exciting :-).
>
> > But still one trivial issue I observed in the test log: L1 host has no
> > 'Suite'
> property.
> > Any suggestions to improve this?
>
> Two questions:
>
> 1. I think this (missing suite) probably ought to be fatal. Which is
> the first ts-* script which complains about it ?
[Hu, Robert]
ts-xen-install l1
>
> 2. In general the suite runvars are set by make-flight. So I think
> your patch to make-flight needs adjusting. TBH I think the suite
> should be set in do_hvm_debian_test_one for all Debian HVM tests,
> even though maybe nothing uses it now.
[Hu, Robert]
In selecthost(),
if (defined $job) {
$ho->{Suite} = get_runvar_default("${ident}_suite",$job,
$c{DebianSuite});
}
by default shall be the config file containing value, which I absolutely have
set.
The odd thing shall be $job is not defined. Any case possible?
Maybe this only happens in my debugging steps, in whole job running, it
probably would disappear.
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest nested patch PART2 -- L2 installation failure [and 1 more messages]
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, October 28, 2015 7:53 PM
> To: Hu, Robert
> Cc: 'Ian Campbell' ; xen-devel@lists.xen.org
> Subject: RE: OSSTest nested patch PART2 -- L2 installation failure [and 1 more
> messages]
>
> Hu, Robert writes ("RE: OSSTest nested patch PART2 -- L2 installation
> failure"):
> > Now another issue: after attach lvm to L1, cannot see it inside.
> > vgdisplay shows nothing.
> >
> > My manual test like this:
> > xl block-attach 13 /dev/osstest-host2/test_l2,raw,sdc,rw
> >
> > xl block-list can see it, while inside L1 cannot.
>
> Hu, Robert writes ("RE: OSSTest nested patch PART2 -- L2 installation
> failure"):
> > Tried:
> > After attach, in L1 cannot see the additional disk, if L1 is nested
> > Xen. After reboot, can see it. If L1 is booted as normal guest, it
> > can see the additional disk at once, after attachment.
>
> So your two tests are:
>
> case A case B
>
>1. boot L1 nestedhvm=1
> nestedhvm=0
> without additional disk
>
>2. xl block-attach in L0
>
>3. xl block-list in L0 shows it
>
>4. ??? in L1 to look for disk not visiblevisible
>
>5. reboot L1 with same nestedhvm
> setting
>
>6. ??? in L1 to look for disk visiblevisible
>
> Is that right ?
[Hu, Robert]
No. Both 2 cases with nestedhvm=1, just different boot entries I select:
one is boot directly from Dom0 kernel, the other from Xen.
>
> I think this may be because the L1 booted with nestedhvm=1 gets its
> disks solely via the emulated IDE controller supplied by qemu in L0.
> And that IDE controller does not support hotplug.
>
> (I don't quite understand why merely setting nestedhvm=1 stops the L1
> from finding its Xen platform PCI device and initialising itself as a
> Xen guest in a way that would prevent it also being a host. I'm not
> sure this is relevant, though.)
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] OSSTest nested patch PART2 -- L1 host has no 'Suite' property
Hi Ians, Now the patch has been refined to get whole 'test-amd64-amd64-qemuu-nested' pass. But still one trivial issue I observed in the test log: L1 host has no 'Suite' property. Any suggestions to improve this? Best Regards, Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest nested patch PART2 -- L2 installation failure
> -Original Message-
> From: Hu, Robert
> Sent: Wednesday, October 28, 2015 10:57 AM
> To: 'Ian Jackson'
> Cc: 'Ian Campbell' ; xen-devel@lists.xen.org
> Subject: RE: OSSTest nested patch PART2 -- L2 installation failure
>
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Tuesday, October 27, 2015 8:10 PM
> > To: Hu, Robert
> > Cc: 'Ian Campbell' ; xen-devel@lists.xen.org
> > Subject: Re: OSSTest nested patch PART2 -- L2 installation failure
> >
> > Hu, Robert writes ("OSSTest nested patch PART2 -- L2 installation failure"):
> > > Now I get to L2 installation.
> > >
> > ...
> > > L1 as host seems not having ether-prefix base defined.
> > ...
> > > L1 as host seems not have dhcp watch method defined
> >
> > I suggest replacing the calls to get_host_property with
> > get_target_property. That looks outwards through the levels of
> > nesting (via the $ho->{Host} field) looking for the property in
> > question. This is what I intended the target property machinery for.
> [Hu, Robert]
>
> Yeah, I had recalled this later yesterday, and tested.
>
> Now another issue: after attach lvm to L1, cannot see it inside.
> vgdisplay shows nothing.
>
> My manual test like this:
> xl block-attach 13 /dev/osstest-host2/test_l2,raw,sdc,rw
>
> xl block-list can see it, while inside L1 cannot.
> Any hints?
[Hu, Robert]
Tried:
After attach, in L1 cannot see the additional disk, if L1 is nested Xen. After
reboot, can see it.
If L1 is booted as normal guest, it can see the additional disk at once, after
attachment.
Lucky that our test step is attach then reboot, so we will not encounter this
in our test, unless
in debugging where we single step execution.
> >
> > Thanks,
> > Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest nested patch PART2 -- L2 installation failure
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Tuesday, October 27, 2015 8:10 PM
> To: Hu, Robert
> Cc: 'Ian Campbell' ; xen-devel@lists.xen.org
> Subject: Re: OSSTest nested patch PART2 -- L2 installation failure
>
> Hu, Robert writes ("OSSTest nested patch PART2 -- L2 installation failure"):
> > Now I get to L2 installation.
> >
> ...
> > L1 as host seems not having ether-prefix base defined.
> ...
> > L1 as host seems not have dhcp watch method defined
>
> I suggest replacing the calls to get_host_property with
> get_target_property. That looks outwards through the levels of
> nesting (via the $ho->{Host} field) looking for the property in
> question. This is what I intended the target property machinery for.
[Hu, Robert]
Yeah, I had recalled this later yesterday, and tested.
Now another issue: after attach lvm to L1, cannot see it inside.
vgdisplay shows nothing.
My manual test like this:
xl block-attach 13 /dev/osstest-host2/test_l2,raw,sdc,rw
xl block-list can see it, while inside L1 cannot.
Any hints?
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] OSSTest nested patch PART2 -- L2 installation failure
Hi Ians,
Now I get to L2 installation.
Failures:
1. Use of uninitialized value $prefix in pattern match (m//) at
Osstest/TestSupport.pm line 1596
sub ether_prefix($) {
my ($ho) = @_;
my $prefix = get_host_property($ho, 'gen-ether-prefix-base');
$prefix =~ m/^(\w+:\w+):(\w+):(\w+)$/ or die "$prefix ?";
my $lhs = $1;
my $pv = (hex($2)<<8) | (hex($3));
$pv ^= $mjobdb->gen_ether_offset($ho,$flight);
$prefix = sprintf "%s:%02x:%02x", $lhs, ($pv>>8)&0xff, $pv&0xff;
return $prefix;
}
L1 as host seems not having ether-prefix base defined.
Proposed fix:
my $prefix = get_host_property($ho, 'gen-ether-prefix-base') // '$some default
value'?
2. Use of uninitialized value $meth in split at Osstest/TestSupport.pm line 1068
sub get_host_method_object ($$$) {
my ($ho, $kind, $meth) = @_;
my (@meth) = split /\s+/, $meth;
my $mo;
eval ("use Osstest::${kind}::$meth[0];".
"\$mo = Osstest::${kind}::$meth[0]->new(\$ho, \@meth);")
or die "get_host_method_object $kind $meth $@";
return $mo;
}
L1 as host seems not have dhcp watch method defined
Proposed fix:
add default value
Your opinions?
Best Regards,
Robert Ho
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Tuesday, October 27, 2015 12:29 AM
> To: Hu, Robert
> Cc: 'Ian Campbell' ;
> 'xen-de...@lists.xenproject.org'
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
>
> Hu, Robert writes ("RE: [OSSTEST PATCH 26/26] ts-xen-install: networking:
> Rename `nodhcp' to `ensurebridge'"):
> > > From: Hu, Robert
> ...
> > > Root cause found: Dom0 kernel boot cmd line: console=xvc0 matters,
> shall
> > > be
> > > hvc0 in nested environment.
> > [Hu, Robert]
>
> Thanks for the update. I'm glad to hear you seem to be making
> good progress.
>
> I think from reading this thread that this is not in fact a bug in
> anything except your osstest series, because the dom0 that is dying is
> the L1 ? I think it's just dying because it can't find its console.
> Is that right ?
[Hu, Robert]
It must miss something in re-constructing patch from v12, which works
well.
Yes, dying Dom0 is L1. It is dying because it try to use xvc0 as console
while its kernkind is pvops.
>
>
> > A patch for this: in ts-xen-install, after exact kernel and xen,
> > check if 'kernkind' for this host exist, if not, set it with
> > existing runvar.
>
> I think that it would be better to change the default for kernkind.
>
> At the moment kernkind runvars are looked at only in
> target_kernkind_check, which has three possible paths:
>
> (a) eq 'pvops'
> (b) m/2618/
> (c) the rest (including undef, although undef prints a warning)
>
> I propose to change the semantics of a missing kernkind runvar from
> (c) to (a).
>
>
> This is safe only if no existing flights would be affected. (That is,
> the meaning of no existing sets of runvars would be changed.)
>
> To check whether this would make any difference I did some database
> searches. Since any time target_kernkind_check is called it sets a
> corresponding `console' runvar, I can search for `console' without a
> corresponding `kernkind'. I ran this query:
>
> select * from (select *, (select name from runvars r2 where
> r2.flight=r1.flight and r2.job=r1.job and r2.name=
> replace(r1.name,'console','kernkind')) kk from runvars r1 where
> r1.name like '%console') iq where kk is null order by flight desc;
>
> and it found nothing since flight 7682. So I think we can change the
> default.
>
>
> I therefore suggest something like this:
>
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index f9eba6b..48b8ffd 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -2006,7 +2006,7 @@ sub target_var ($$) {
> sub target_kernkind_check ($) {
> my ($gho) = @_;
> my $pfx= target_var_prefix($gho);
> -my $kernkind= $r{$pfx."kernkind"};
> +my $kernkind= $r{$pfx."kernkind"} // 'pvops';
> my $isguest= exists $gho->{Guest};
> if ($kernkind eq 'pvops') {
> store_runvar($pfx."rootdev", 'xvda') if $isguest;
>
>
> If you agree and this works for you please put that into your series
> with a proper commit message. Please quote my words about existing
> flights (including the database query etc.) in the commit message.
[Hu, Robert]
Sure.
Tested-by: Robert Hu
>
> Signed-off-by: Ian Jackson
>
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'
> -Original Message- > From: Hu, Robert > Sent: Monday, October 26, 2015 3:05 PM > To: 'Ian Campbell' ; 'Ian Jackson' > ; 'xen-de...@lists.xenproject.org' > > Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename > `nodhcp' to `ensurebridge' > > > -Original Message- > > From: Hu, Robert > > Sent: Sunday, October 25, 2015 10:46 AM > > To: Ian Campbell ; 'Ian Jackson' > > ; 'xen-de...@lists.xenproject.org' > > > > Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename > > `nodhcp' to `ensurebridge' > > > > > -Original Message- > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > Sent: Friday, October 23, 2015 9:38 PM > > > To: Hu, Robert ; 'Ian Jackson' > > > ; 'xen-de...@lists.xenproject.org' > > > > > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename > > > `nodhcp' to `ensurebridge' > > > > > > On Fri, 2015-10-23 at 13:25 +, Hu, Robert wrote: > > > > > -Original Message- > > > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > > > Sent: Friday, October 23, 2015 4:15 PM > > > > > To: Hu, Robert ; 'Ian Jackson' > > > > > ; 'xen-de...@lists.xenproject.org' > > > > > > > > > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: > Rename > > > > > `nodhcp' to `ensurebridge' > > > > > > > > > > On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote: > > > > > > > > > > > [Hu, Robert] > > > > > > Seems the failure log shall be this, any idea? I've spent days on > > > > > > debugging this:( > > > > > > (XEN) traps.c:3290: GPF (): 82d080195082 -> > > 82d080243d9d > > > > > > (XEN) PCI add device :00:00.0 > > > > > > (XEN) PCI add device :00:01.0 > > > > > > (XEN) PCI add device :00:01.1 > > > > > > (XEN) PCI add device :00:01.2 > > > > > > (XEN) PCI add device :00:01.3 > > > > > > (XEN) PCI add device :00:02.0 > > > > > > (XEN) PCI add device :00:03.0 > > > > > > (XEN) d0: Forcing read-only access to MFN fed00 > > > > > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. > > > > > > Issued domain 3 reboot > > > > > > qemu: terminating on signal 1 from pid 4322 > > > > > > > > > > Please can you report this as a regular bug in a fresh thread, that > > > > > way > > > > > the relevant Xen maintainers are likely to see and react to it, rather > > > > > than just us osstest folks. > > > > [Hu, Robert] > > > > > > > > It shall be in that way after I confirm it is a bug. > > > > Currently I'm just still not certain it is a nested bug or because of > > > > the > > > > latest > > > > osstest code change. > > > > I was just asking for if you can recall some hint on what changes (of > > > > osstest) > > > > might causing this. > > > > I'm to restore to my v12 code, with current Xen and qemu selection to > try > > > > again. I think by this way, I can confirm it is an actual nested bug or > > > > not. > > > > Then I would report this in a fresh thread. > > > > > [Hu, Robert] > > > > With v12 code, on same L1 Dom0 kernel, L1 Xen and Qemu selection, > nested > > test > > passes. > > I've saved l1 guest configuration, l1 network configuration, and l1 Dom0 > > kernel > > config for further comparison. Anything else possibly related you can think > > of? > > > > > A dom0 crash of this sort is pretty certainly a bug somewhere in Xen, > > > whether it is exposed by a new osstest case or not. The people who are > > best > > > placed to figure out where the bug is are certainly not reading this > > > osstest thread. > > > > > > So please just report it as a bug as it stands, with the relevant > > > information. > > [Hu, Robert] > > > > Nested Xen is in tech preview phase, not that production level matured. > > It is so nit-picking that any configuration change not meeting its appetite > w
Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'
> -Original Message- > From: Hu, Robert > Sent: Sunday, October 25, 2015 10:46 AM > To: Ian Campbell ; 'Ian Jackson' > ; 'xen-de...@lists.xenproject.org' > > Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename > `nodhcp' to `ensurebridge' > > > -Original Message- > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > Sent: Friday, October 23, 2015 9:38 PM > > To: Hu, Robert ; 'Ian Jackson' > > ; 'xen-de...@lists.xenproject.org' > > > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename > > `nodhcp' to `ensurebridge' > > > > On Fri, 2015-10-23 at 13:25 +, Hu, Robert wrote: > > > > -Original Message- > > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > > Sent: Friday, October 23, 2015 4:15 PM > > > > To: Hu, Robert ; 'Ian Jackson' > > > > ; 'xen-de...@lists.xenproject.org' > > > > > > > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename > > > > `nodhcp' to `ensurebridge' > > > > > > > > On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote: > > > > > > > > > [Hu, Robert] > > > > > Seems the failure log shall be this, any idea? I've spent days on > > > > > debugging this:( > > > > > (XEN) traps.c:3290: GPF (): 82d080195082 -> > 82d080243d9d > > > > > (XEN) PCI add device :00:00.0 > > > > > (XEN) PCI add device :00:01.0 > > > > > (XEN) PCI add device :00:01.1 > > > > > (XEN) PCI add device :00:01.2 > > > > > (XEN) PCI add device :00:01.3 > > > > > (XEN) PCI add device :00:02.0 > > > > > (XEN) PCI add device :00:03.0 > > > > > (XEN) d0: Forcing read-only access to MFN fed00 > > > > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. > > > > > Issued domain 3 reboot > > > > > qemu: terminating on signal 1 from pid 4322 > > > > > > > > Please can you report this as a regular bug in a fresh thread, that way > > > > the relevant Xen maintainers are likely to see and react to it, rather > > > > than just us osstest folks. > > > [Hu, Robert] > > > > > > It shall be in that way after I confirm it is a bug. > > > Currently I'm just still not certain it is a nested bug or because of the > > > latest > > > osstest code change. > > > I was just asking for if you can recall some hint on what changes (of > > > osstest) > > > might causing this. > > > I'm to restore to my v12 code, with current Xen and qemu selection to try > > > again. I think by this way, I can confirm it is an actual nested bug or > > > not. > > > Then I would report this in a fresh thread. > > > [Hu, Robert] > > With v12 code, on same L1 Dom0 kernel, L1 Xen and Qemu selection, nested > test > passes. > I've saved l1 guest configuration, l1 network configuration, and l1 Dom0 > kernel > config for further comparison. Anything else possibly related you can think > of? > > > A dom0 crash of this sort is pretty certainly a bug somewhere in Xen, > > whether it is exposed by a new osstest case or not. The people who are > best > > placed to figure out where the bug is are certainly not reading this > > osstest thread. > > > > So please just report it as a bug as it stands, with the relevant > > information. > [Hu, Robert] > > Nested Xen is in tech preview phase, not that production level matured. > It is so nit-picking that any configuration change not meeting its appetite > will > induce its naughtiness, i.e. crash, I think. :) [Hu, Robert] Root cause found: Dom0 kernel boot cmd line: console=xvc0 matters, shall be hvc0 in nested environment. > > > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Friday, October 23, 2015 9:38 PM > To: Hu, Robert ; 'Ian Jackson' > ; 'xen-de...@lists.xenproject.org' > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename > `nodhcp' to `ensurebridge' > > On Fri, 2015-10-23 at 13:25 +, Hu, Robert wrote: > > > -Original Message- > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > Sent: Friday, October 23, 2015 4:15 PM > > > To: Hu, Robert ; 'Ian Jackson' > > > ; 'xen-de...@lists.xenproject.org' > > > > > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename > > > `nodhcp' to `ensurebridge' > > > > > > On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote: > > > > > > > [Hu, Robert] > > > > Seems the failure log shall be this, any idea? I've spent days on > > > > debugging this:( > > > > (XEN) traps.c:3290: GPF (): 82d080195082 -> 82d080243d9d > > > > (XEN) PCI add device :00:00.0 > > > > (XEN) PCI add device :00:01.0 > > > > (XEN) PCI add device :00:01.1 > > > > (XEN) PCI add device :00:01.2 > > > > (XEN) PCI add device :00:01.3 > > > > (XEN) PCI add device :00:02.0 > > > > (XEN) PCI add device :00:03.0 > > > > (XEN) d0: Forcing read-only access to MFN fed00 > > > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. > > > > Issued domain 3 reboot > > > > qemu: terminating on signal 1 from pid 4322 > > > > > > Please can you report this as a regular bug in a fresh thread, that way > > > the relevant Xen maintainers are likely to see and react to it, rather > > > than just us osstest folks. > > [Hu, Robert] > > > > It shall be in that way after I confirm it is a bug. > > Currently I'm just still not certain it is a nested bug or because of the > > latest > > osstest code change. > > I was just asking for if you can recall some hint on what changes (of > > osstest) > > might causing this. > > I'm to restore to my v12 code, with current Xen and qemu selection to try > > again. I think by this way, I can confirm it is an actual nested bug or > > not. > > Then I would report this in a fresh thread. > [Hu, Robert] With v12 code, on same L1 Dom0 kernel, L1 Xen and Qemu selection, nested test passes. I've saved l1 guest configuration, l1 network configuration, and l1 Dom0 kernel config for further comparison. Anything else possibly related you can think of? > A dom0 crash of this sort is pretty certainly a bug somewhere in Xen, > whether it is exposed by a new osstest case or not. The people who are best > placed to figure out where the bug is are certainly not reading this > osstest thread. > > So please just report it as a bug as it stands, with the relevant > information. [Hu, Robert] Nested Xen is in tech preview phase, not that production level matured. It is so nit-picking that any configuration change not meeting its appetite will induce its naughtiness, i.e. crash, I think. :) > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Friday, October 23, 2015 4:15 PM > To: Hu, Robert ; 'Ian Jackson' > ; 'xen-de...@lists.xenproject.org' > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename > `nodhcp' to `ensurebridge' > > On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote: > > > [Hu, Robert] > > Seems the failure log shall be this, any idea? I've spent days on > > debugging this:( > > (XEN) traps.c:3290: GPF (): 82d080195082 -> 82d080243d9d > > (XEN) PCI add device :00:00.0 > > (XEN) PCI add device :00:01.0 > > (XEN) PCI add device :00:01.1 > > (XEN) PCI add device :00:01.2 > > (XEN) PCI add device :00:01.3 > > (XEN) PCI add device :00:02.0 > > (XEN) PCI add device :00:03.0 > > (XEN) d0: Forcing read-only access to MFN fed00 > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. > > Issued domain 3 reboot > > qemu: terminating on signal 1 from pid 4322 > > Please can you report this as a regular bug in a fresh thread, that way > the relevant Xen maintainers are likely to see and react to it, rather > than just us osstest folks. [Hu, Robert] It shall be in that way after I confirm it is a bug. Currently I'm just still not certain it is a nested bug or because of the latest osstest code change. I was just asking for if you can recall some hint on what changes (of osstest) might causing this. I'm to restore to my v12 code, with current Xen and qemu selection to try again. I think by this way, I can confirm it is an actual nested bug or not. Then I would report this in a fresh thread. > > Please include whatever information you can, e.g. the guest config file > used, details about the type of guest, which level of nesting this is > happening at, the contents of any logs under /var/log/xen in L0 and L1 > host etc. [Hu, Robert] Yes, sure. I will include these in bug reporting. > > If this crash is in an L1 host then you might also want to CC the > nested hvm maintainers at Intel. [Hu, Robert] Yes, thanks for remind. > > See http://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project > for general advice on reporting a bug and other things to consider > including. > > Thanks, > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'
> -Original Message-
> From: Hu, Robert
> Sent: Thursday, October 22, 2015 10:33 AM
> To: 'Ian Jackson' ;
> 'xen-de...@lists.xenproject.org'
> Cc: 'Ian Campbell'
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
>
> > -Original Message-
> > From: Hu, Robert
> > Sent: Thursday, October 15, 2015 5:58 PM
> > To: Ian Jackson ;
> > xen-de...@lists.xenproject.org
> > Cc: Ian Campbell
> > Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp' to `ensurebridge'
> >
> > > -Original Message-
> > > From: Hu, Robert
> > > Sent: Thursday, October 15, 2015 5:39 PM
> > > To: 'Ian Jackson' ;
> > > xen-de...@lists.xenproject.org
> > > Cc: Ian Campbell
> > > Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > > `nodhcp' to `ensurebridge'
> > >
> > > > -Original Message-
> > > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > > Sent: Saturday, September 26, 2015 3:15 AM
> > > > To: xen-de...@lists.xenproject.org
> > > > Cc: Hu, Robert ; Ian Campbell
> > > > ; Ian Jackson ;
> > Ian
> > > > Jackson
> > > > Subject: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > > `nodhcp'
> > > > to `ensurebridge'
> > > >
> > > > This function does not (now) always undo the DHCP configuration.
> > > > Sometimes it leaves it. Its main function is to ensure that we have
> > > > a bridge for use by guests.
> > > >
> > > > So rename the function.
> > > >
> > > > Signed-off-by: Ian Jackson
> > > > ---
> > > > v14: This patch was previously 4/4 of a miniature series containing
> > > > a different way of dealing with the Nested HVM L1 DHCP
> > problem.
> > > > ---
> > > > ts-xen-install |4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/ts-xen-install b/ts-xen-install
> > > > index d9aa694..3d0f394 100755
> > > > --- a/ts-xen-install
> > > > +++ b/ts-xen-install
> > > > @@ -247,7 +247,7 @@ sub hosts () {
> > > > });
> > > > }
> > > >
> > > > -sub nodhcp () {
> > > > +sub ensurebridge () {
> > > > target_editfile_root($ho, "/etc/network/interfaces",
> > > > "etc-network-interfaces", sub {
> > > > my $physif= get_host_property($ho,'interface
> force',undef);
> > > > @@ -370,6 +370,6 @@ if ($checkmode) {
> > > > adjustconfig();
> > > > setupboot();
> > > > setupinitd();
> > > > -nodhcp();
> > > > +ensurebridge();
> > > > hosts();
> > > > }
> > > [Hu, Robert]
> > > Not sure if it is caused by this patch, but after Xen installed in L1,
> > > after L1
> > > reboot,
> > > it boots fail.
> > >
> > > Here is log dumped in L0:
> > > (d53) drive 0x000f6330: PCHS=16383/16/63 translation=lba
> > > LCHS=1024/255/63 s=2048
> > > (d53) drive 0x000f6360: PCHS=0/0/0 translation=lba LCHS=1024/255/63
> > > s=4096
> > > (d53) Space available for UMB: ca800-ee800, f5d80-f62d0
> > > (d53) Returned 258048 bytes of ZoneHigh
> > > (d53) e820 map has 6 items:
> > > (d53) 0: - 0009fc00 = 1 RAM
> > > (d53) 1: 0009fc00 - 000a = 2 RESERVED
> > > (d53) 2: 000f0000 - 0010 = 2 RESERVED
> > > (d53) 3: 0010 - bf7ff000 = 1 RAM
> > > (d53) 4: bf7ff000 - bf80 = 2 RESERVED
> > > (d53) 5: 0000fc00 - 0001 = 2 RESERVED
> > > (d53) enter handle_19:
> > > (d53) NULL
> > > (d53) Booting from DVD/CD...
> > > (d53) Boot failed: Could not read from CDROM (code 0004)
> > > (d53) enter handle_18:
> > > (d53) NULL
> > > (d53) Booting from Hard Disk...
> > > (d53) Booting from :7c00
> > > (XEN) irq.c:275: Dom53 PCI link 0 changed 5 -> 0
> > > (XEN) irq.c:275: Dom53 PCI link 1 changed 10 -> 0
> > > (XEN) irq.c:275: Dom53 PCI link 2 changed
Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'
> -Original Message-
> From: Hu, Robert
> Sent: Thursday, October 15, 2015 5:58 PM
> To: Ian Jackson ;
> xen-de...@lists.xenproject.org
> Cc: Ian Campbell
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
>
> > -Original Message-
> > From: Hu, Robert
> > Sent: Thursday, October 15, 2015 5:39 PM
> > To: 'Ian Jackson' ;
> > xen-de...@lists.xenproject.org
> > Cc: Ian Campbell
> > Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp' to `ensurebridge'
> >
> > > -Original Message-
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > Sent: Saturday, September 26, 2015 3:15 AM
> > > To: xen-de...@lists.xenproject.org
> > > Cc: Hu, Robert ; Ian Campbell
> > > ; Ian Jackson ;
> Ian
> > > Jackson
> > > Subject: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp'
> > > to `ensurebridge'
> > >
> > > This function does not (now) always undo the DHCP configuration.
> > > Sometimes it leaves it. Its main function is to ensure that we have
> > > a bridge for use by guests.
> > >
> > > So rename the function.
> > >
> > > Signed-off-by: Ian Jackson
> > > ---
> > > v14: This patch was previously 4/4 of a miniature series containing
> > > a different way of dealing with the Nested HVM L1 DHCP
> problem.
> > > ---
> > > ts-xen-install |4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/ts-xen-install b/ts-xen-install
> > > index d9aa694..3d0f394 100755
> > > --- a/ts-xen-install
> > > +++ b/ts-xen-install
> > > @@ -247,7 +247,7 @@ sub hosts () {
> > > });
> > > }
> > >
> > > -sub nodhcp () {
> > > +sub ensurebridge () {
> > > target_editfile_root($ho, "/etc/network/interfaces",
> > > "etc-network-interfaces", sub {
> > > my $physif= get_host_property($ho,'interface force',undef);
> > > @@ -370,6 +370,6 @@ if ($checkmode) {
> > > adjustconfig();
> > > setupboot();
> > > setupinitd();
> > > -nodhcp();
> > > +ensurebridge();
> > > hosts();
> > > }
> > [Hu, Robert]
> > Not sure if it is caused by this patch, but after Xen installed in L1,
> > after L1
> > reboot,
> > it boots fail.
> >
> > Here is log dumped in L0:
> > (d53) drive 0x000f6330: PCHS=16383/16/63 translation=lba
> > LCHS=1024/255/63 s=2048
> > (d53) drive 0x000f6360: PCHS=0/0/0 translation=lba LCHS=1024/255/63
> > s=4096
> > (d53) Space available for UMB: ca800-ee800, f5d80-f62d0
> > (d53) Returned 258048 bytes of ZoneHigh
> > (d53) e820 map has 6 items:
> > (d53) 0: - 0009fc00 = 1 RAM
> > (d53) 1: 0009fc00 - 000a = 2 RESERVED
> > (d53) 2: 000f - 0010 = 2 RESERVED
> > (d53) 3: 0010 - bf7ff000 = 1 RAM
> > (d53) 4: bf7ff000 - bf80 = 2 RESERVED
> > (d53) 5: fc00 - 0001 = 2 RESERVED
> > (d53) enter handle_19:
> > (d53) NULL
> > (d53) Booting from DVD/CD...
> > (d53) Boot failed: Could not read from CDROM (code 0004)
> > (d53) enter handle_18:
> > (d53) NULL
> > (d53) Booting from Hard Disk...
> > (d53) Booting from :7c00
> > (XEN) irq.c:275: Dom53 PCI link 0 changed 5 -> 0
> > (XEN) irq.c:275: Dom53 PCI link 1 changed 10 -> 0
> > (XEN) irq.c:275: Dom53 PCI link 2 changed 11 -> 0
> > (XEN) irq.c:275: Dom53 PCI link 3 changed 5 -> 0
> > (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> > (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> >
>
> I'm using latest xen.git master. Will try again with Xen 4.6 release which we
> have
> tested.
[Hu, Robert]
After fixed several environment setting issues, I just run OSSTest on Xen 4.6.0
release code. This issue still exist there, so this is probably the new patch
which
introduced this.
>
> >
> > > --
> > > 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] OSSTest: Xen 4.6.0 tag
Hi Ians, I found xen.git has RELEASE-4.6.0 tag, while corresponding 4.6.0 tags of qemu-xen and qemu-upstream are not in their trees, but in their *-4.6-testing trees. Any reason for such arrangement? Best Regards, Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'
> -Original Message-
> From: Hu, Robert
> Sent: Thursday, October 15, 2015 5:39 PM
> To: 'Ian Jackson' ;
> xen-de...@lists.xenproject.org
> Cc: Ian Campbell
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
>
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Saturday, September 26, 2015 3:15 AM
> > To: xen-de...@lists.xenproject.org
> > Cc: Hu, Robert ; Ian Campbell
> > ; Ian Jackson ; Ian
> > Jackson
> > Subject: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp'
> > to `ensurebridge'
> >
> > This function does not (now) always undo the DHCP configuration.
> > Sometimes it leaves it. Its main function is to ensure that we have
> > a bridge for use by guests.
> >
> > So rename the function.
> >
> > Signed-off-by: Ian Jackson
> > ---
> > v14: This patch was previously 4/4 of a miniature series containing
> > a different way of dealing with the Nested HVM L1 DHCP problem.
> > ---
> > ts-xen-install |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/ts-xen-install b/ts-xen-install
> > index d9aa694..3d0f394 100755
> > --- a/ts-xen-install
> > +++ b/ts-xen-install
> > @@ -247,7 +247,7 @@ sub hosts () {
> > });
> > }
> >
> > -sub nodhcp () {
> > +sub ensurebridge () {
> > target_editfile_root($ho, "/etc/network/interfaces",
> > "etc-network-interfaces", sub {
> > my $physif= get_host_property($ho,'interface force',undef);
> > @@ -370,6 +370,6 @@ if ($checkmode) {
> > adjustconfig();
> > setupboot();
> > setupinitd();
> > -nodhcp();
> > +ensurebridge();
> > hosts();
> > }
> [Hu, Robert]
> Not sure if it is caused by this patch, but after Xen installed in L1, after
> L1
> reboot,
> it boots fail.
>
> Here is log dumped in L0:
> (d53) drive 0x000f6330: PCHS=16383/16/63 translation=lba
> LCHS=1024/255/63 s=2048
> (d53) drive 0x000f6360: PCHS=0/0/0 translation=lba LCHS=1024/255/63
> s=4096
> (d53) Space available for UMB: ca800-ee800, f5d80-f62d0
> (d53) Returned 258048 bytes of ZoneHigh
> (d53) e820 map has 6 items:
> (d53) 0: - 0009fc00 = 1 RAM
> (d53) 1: 0009fc00 - 000a = 2 RESERVED
> (d53) 2: 000f - 0010 = 2 RESERVED
> (d53) 3: 0010 - bf7ff000 = 1 RAM
> (d53) 4: bf7ff000 - bf80 = 2 RESERVED
> (d53) 5: fc00 - 0001 = 2 RESERVED
> (d53) enter handle_19:
> (d53) NULL
> (d53) Booting from DVD/CD...
> (d53) Boot failed: Could not read from CDROM (code 0004)
> (d53) enter handle_18:
> (d53) NULL
> (d53) Booting from Hard Disk...
> (d53) Booting from :7c00
> (XEN) irq.c:275: Dom53 PCI link 0 changed 5 -> 0
> (XEN) irq.c:275: Dom53 PCI link 1 changed 10 -> 0
> (XEN) irq.c:275: Dom53 PCI link 2 changed 11 -> 0
> (XEN) irq.c:275: Dom53 PCI link 3 changed 5 -> 0
> (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
>
I'm using latest xen.git master. Will try again with Xen 4.6 release which we
have
tested.
>
> > --
> > 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson ; Ian
> Jackson
> Subject: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp'
> to `ensurebridge'
>
> This function does not (now) always undo the DHCP configuration.
> Sometimes it leaves it. Its main function is to ensure that we have
> a bridge for use by guests.
>
> So rename the function.
>
> Signed-off-by: Ian Jackson
> ---
> v14: This patch was previously 4/4 of a miniature series containing
> a different way of dealing with the Nested HVM L1 DHCP problem.
> ---
> ts-xen-install |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ts-xen-install b/ts-xen-install
> index d9aa694..3d0f394 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -247,7 +247,7 @@ sub hosts () {
> });
> }
>
> -sub nodhcp () {
> +sub ensurebridge () {
> target_editfile_root($ho, "/etc/network/interfaces",
> "etc-network-interfaces", sub {
> my $physif= get_host_property($ho,'interface force',undef);
> @@ -370,6 +370,6 @@ if ($checkmode) {
> adjustconfig();
> setupboot();
> setupinitd();
> -nodhcp();
> +ensurebridge();
> hosts();
> }
[Hu, Robert]
Not sure if it is caused by this patch, but after Xen installed in L1, after L1
reboot,
it boots fail.
Here is log dumped in L0:
(d53) drive 0x000f6330: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
s=2048
(d53) drive 0x000f6360: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=4096
(d53) Space available for UMB: ca800-ee800, f5d80-f62d0
(d53) Returned 258048 bytes of ZoneHigh
(d53) e820 map has 6 items:
(d53) 0: - 0009fc00 = 1 RAM
(d53) 1: 0009fc00 - 000a = 2 RESERVED
(d53) 2: 000f - 0010 = 2 RESERVED
(d53) 3: 0010 - bf7ff000 = 1 RAM
(d53) 4: bf7ff000 - bf80 = 2 RESERVED
(d53) 5: fc00 - 0001 = 2 RESERVED
(d53) enter handle_19:
(d53) NULL
(d53) Booting from DVD/CD...
(d53) Boot failed: Could not read from CDROM (code 0004)
(d53) enter handle_18:
(d53) NULL
(d53) Booting from Hard Disk...
(d53) Booting from :7c00
(XEN) irq.c:275: Dom53 PCI link 0 changed 5 -> 0
(XEN) irq.c:275: Dom53 PCI link 1 changed 10 -> 0
(XEN) irq.c:275: Dom53 PCI link 2 changed 11 -> 0
(XEN) irq.c:275: Dom53 PCI link 3 changed 5 -> 0
(XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
(XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> --
> 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTest Nested v12 03/21] Allow runvars to specify guest disk and ram size (turning previous values into defaults) [and 2 more messages]
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Tuesday, October 13, 2015 6:41 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com;
> Jin, Gordon ; Zheng, Di ;
> xen-de...@lists.xenproject.org
> Subject: RE: [OSSTest Nested v12 03/21] Allow runvars to specify guest disk
> and ram size (turning previous values into defaults) [and 2 more messages]
>
> Hu, Robert writes ("RE: [OSSTest Nested v12 03/21] Allow runvars to specify
> guest disk and ram size (turning previous values into defaults)"):
> > And sorry I haven't got a chance to read your replies/patches until now.
> > So many test tasks almost crushed me.
>
> That's fine, of course. We all have other things we are doing.
>
> > I'm going to read your mails in the coming week.
>
> Thanks. I see Ian Campbell has replied to several already.
>
>
> Hu, Robert writes ("RE: [OSSTest Nested v12 16/21] Add PDU power method
> for nested L1 and L2 guest"):
> > Ian Jackson [mailto:ian.jack...@eu.citrix.com]:
> > > Robert Ho writes ("[OSSTest Nested v12 16/21] Add PDU power method
> for
> > > nested L1 and L2 guest"):
> > > > For nested host/guest, its power on/off method shall be
> > > > its host invoke $(toolstack)->create/destroy method.
> > >
> > > Thanks for this patch, which I have substantially edited for my v14.
> > >
> > > However, I notice that it was missing a signed-off-by. Can you please
> > > confirm that I should add your s-o-b ?
> >
> > Sorry I forgot to add my s-o-b. Yes, please add mine.
>
> Of course only one of us ought to be rebasing this series at once,
> because otherwise it will be difficult for us to merge our work.
>
> In my mail
> Subject: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
> Date: Fri, 25 Sep 2015 20:15:05 +0100
> I handed the series back to you.
>
> So I think it is you who need to add your own s-o-b to that patch.
Yes I planned to do so.
>
> (I don't imply any criticism of you with this detailed explanation. I
> just don't want any misunderstandings; nor do I want this minor work
> item to be dropped.)
>
>
> Likewise:
>
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > Sent: Saturday, September 26, 2015 3:15 AM
> > > To: xen-de...@lists.xenproject.org
> > > Cc: Hu, Robert ; Ian Campbell
> > > ; Ian Jackson ;
> Ian
> > > Jackson
> > > Subject: [OSSTEST PATCH 15/26] DhcpWatch::leases: Fix a reporting
> message
> > >
> > > This talks about `guest_check_ip', but this code is now factored out
> > > into a method. Use the correct method name in reporting.
> ...
> > Ack.
>
> If you meant
> Acked-by: Robert Ho
> then it would be better if you wrote that explicitly.
Get it.
>
> And of course as current custodian of the branch, it is up to you to
> record your own ack in it. This may seem a little odd, but it is the
> standard approach when dealing with a series containing contributions
> from multiple people.
Yes, understand. I'm learning the upstream rules.
>
>
> I've read your other emails and Ian's replies and I think you should
> be unblocked now ? So I'm expecting more questions, bug reports,
> etc., and hopefully eventually a v15. Do not hesitate to ask again
> for help.
Yeah, I will report issues I found on each specific patch you posted.
>
>
> Regards,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest standalone script
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Wednesday, October 14, 2015 5:48 PM
> To: Hu, Robert ; ian.jack...@citrix.com
> Cc: xen-devel@lists.xen.org
> Subject: Re: OSSTest standalone script
>
> On Wed, 2015-10-14 at 09:29 +, Hu, Robert wrote:
> > Hi Ian,
> >
> > When I now try to use standalone script for debug, it seems doesn't work
> > as before. Any usage changed?
> >
> > [root@robert-ivt osstest]# ./standalone run-job --dry-run -h dummy test
> > -amd64-amd64-qemuu-nested
> > Could not open a connection to your authentication agent.
> > WARNING: Unable to access ssh-agent. Some tests may fail
>
> It seems you do not have a ssh-agent running.
>
> This isn't strictly needed (i.e if your ssh key has no passphrase) hence
> this is just a warning.
>
> > ./standalone: line 195: savelog: command not found
>
> And this indicates that you need to install the "savelog" command.
>
> In Debian this comes from the 'debianutils' package, so it is probably
> Debian specific, which I had not realised.
>
> If you aren't using Debian then I think the following will help, although
> you won't benefit from the rotation of logs, which is the old behaviour.
>
> -8>
>
> From ed4fd4bf2b175a02b9dbe3e394577b7095a8f3be Mon Sep 17 00:00:00
> 2001
> From: Ian Campbell
> Date: Wed, 14 Oct 2015 10:45:36 +0100
> Subject: [PATCH] standalone: only rotate logs if savelog is available
>
> `savelog' comes from the `debianutils' package and so is unlikely to
> be available elsewhere. Revert to the old behaviour of clobbering the
> logs in this case.
>
> Signed-off-by: Ian Campbell
> ---
> standalone | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/standalone b/standalone
> index 20a6ad5..c804b74 100755
> --- a/standalone
> +++ b/standalone
> @@ -192,7 +192,9 @@ ensure_logs() {
> with_logging() {
> local log=$1; shift
> ensure_logs
> -savelog -c 300 -n "$log" >/dev/null
> +if command -v savelog >/dev/null ; then
> +savelog -c 300 -n "$log" >/dev/null
> +fi
> "$@" 2>&1 | tee "$log"
> rc=${PIPESTATUS[0]}
> if [ $rc -ne 0 ] ; then
Thanks for quick reply! It works!
> --
> 2.5.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] OSSTest standalone script
Hi Ian, When I now try to use standalone script for debug, it seems doesn't work as before. Any usage changed? [root@robert-ivt osstest]# ./standalone run-job --dry-run -h dummy test-amd64-amd64-qemuu-nested Could not open a connection to your authentication agent. WARNING: Unable to access ssh-agent. Some tests may fail ./standalone: line 195: savelog: command not found Best Regards, Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 18/26] LVM: Break out lv_create
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson ; Ian
> Jackson
> Subject: [OSSTEST PATCH 18/26] LVM: Break out lv_create
>
> We are going to want to reuse this.
>
> Signed-off-by: Ian Jackson
> ---
> v14: New patch
> ---
> Osstest/TestSupport.pm | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index ad017a4..2d1db5d 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -62,7 +62,7 @@ BEGIN {
>target_install_packages
> target_install_packages_norec
>target_jobdir target_extract_jobdistpath_subdir
>target_extract_jobdistpath
> - lv_dev_mapper target_guest_lv_name
> + lv_create lv_dev_mapper target_guest_lv_name
>
>poll_loop tcpconnect await_tcp
>contents_make_cpio
> file_simple_write_contents
> @@ -702,6 +702,15 @@ sub poll_loop ($$$&) {
> logm("$what: ok. (${waited}s)");
> }
>
> +sub lv_create ($$$) {
> +my ($ho, $vg, $lv, $mb) = @_;
> +my $lvdev = "/dev/$lv/$vg";
> +target_cmd_root($ho, "lvremove -f $lvdev ||:");
> +target_cmd_root($ho, "lvcreate -L ${mb}M -n $lv $vg");
> +target_cmd_root($ho, "dd if=/dev/zero of=$lvdev count=10");
> +return $lvdev;
> +}
> +
> sub lv_dev_mapper ($$) {
> my ($vg,$lv) = @_;
> $vg =~ s/-/--/g;
> @@ -1685,9 +1694,7 @@ sub prepareguest ($$) {
>
> sub prepareguest_part_lvmdisk ($$$) {
> my ($ho, $gho, $disk_mb) = @_;
> -target_cmd_root($ho, "lvremove -f $gho->{Lvdev} ||:");
> -target_cmd_root($ho, "lvcreate -L ${disk_mb}M -n $gho->{Lv}
> $gho->{Vg}");
> -target_cmd_root($ho, "dd if=/dev/zero of=$gho->{Lvdev} count=10");
> +lvm_lv_create($ho, $gho->{Vg}, $gho->{Lv}, $disk_mb);
And here I guess shall be lv_create($ho, $gho->{Vg}, $gho->{Lv}, $disk_mb)?
> }
>
> sub make_vhd ($$$) {
> --
> 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 19/26] Toolstack::xl: Provide block_attach method
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson ; Ian
> Jackson
> Subject: [OSSTEST PATCH 19/26] Toolstack::xl: Provide block_attach method
>
> It is possible that this may work some of the time with xm, so I have
> taken no measures to prevent it running then.
>
> Signed-off-by: Ian Jackson
>
> v14: New patch
> ---
> Osstest/Toolstack/xl.pm |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
> index 0f8abed..cc26d61 100644
> --- a/Osstest/Toolstack/xl.pm
> +++ b/Osstest/Toolstack/xl.pm
> @@ -109,4 +109,12 @@ sub restore () {
> ." $f", $timeout);
> }
>
> +sub block_attach () {
> +my ($self,$gho,$xldiskspec) = @_;
> +die "quotes in $xldiskspec ?" if $xldiskspec =~ m/'/;
> +my $gn = $gho->{Name};
> +my $cmd = $self->{_VerboseCommand}." block-attach $gn
> '$xldiskspec'";
I guess here lacks of a
my $ho = $self->{Host};
> +target_cmd_root($ho, $cmd, 100);
> +}
> +
> 1;
> --
> 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Monday, October 12, 2015 6:48 PM > To: Hu, Robert ; 'Ian Jackson' > ; 'xen-de...@lists.xenproject.org' > > Subject: Re: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing > > On Mon, 2015-10-12 at 10:23 +, Hu, Robert wrote: > > (please can you trim your quotes) > > > > Some other issue arises: > > 1. pax '-M norm', this option isn't support by my RHEL-distributed pax. > > Shall > I > > simply omit it? or use '-t' substitute it? I tried the latter, seems > > working. > > The purpose of "-M norm" is to make the resulting archive deterministic, > which I don't think -t achieves. > > You can omit it locally I think, but I'd prefer to keep it in git. > Hopefully newer RHEL will eventually support this. Yes I will keep it in git. Just change that locally to align with my environment. > > > > 2. I initially run build-amd64 job, it will firstly re-install host, that's > > right. But > after > > it is installed, it restarts host and again jump into a manual off-on loop. > > Do you know which part of code is controlling this? > > The post install check appears to have failed here: > [...] > > 2015-10-12 09:59:14 Z executing ssh ... root@192.168.199.70 lvdisplay > --colon > > > @@@ > > > @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > > > @@@ > > > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > > Someone could be eavesdropping on you right now (man-in-the-middle > attack)! > > It is also possible that a host key has just been changed. > > The fingerprint for the ECDSA key sent by the remote host is > > 87:a2:7b:8a:73:b4:b4:57:30:15:ee:00:31:df:17:63. > > Please contact your system administrator. > > Add correct host key in tmp/t.known_hosts_standalone.build-amd64 to get > rid of this message. > > Offending ECDSA key in tmp/t.known_hosts_standalone.build-amd64:1 > > Keyboard-interactive authentication is disabled to avoid man-in-the-middle > attacks. > > Permission denied (publickey,password). > > 2015-10-12 09:59:14 Z command nonzero waitstatus 65280: timeout 60 > 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_standalone.build-amd64 > root@192.168.199.70 lvdisplay --colon > > status 65280 at Osstest/TestSupport.pm line 410. > > And therefore ts-host-install-twice is trying again, which begins with a > power off. > > ts-host-install-twice is a workaround for some issues with preseeding LVM > in Debian installer when there is an existing LVM configuration on the > host, but it also means that other failures end up having a second go > (which will probably also fail). > > I think the stuff about known hosts is benign, the "Permission denied > (publickey,password)." is the real issue, it looks like either ssh cannot > find your public key or your private key did not correctly get installed on > the host. > > Looking at patches 10-26 here I don't see anything which I would expect to > effect host installation in this way. Neither ts-host-install nor > Osstest/Debian.pm are touched here. > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Monday, October 12, 2015 6:03 PM > To: Hu, Robert ; 'Ian Jackson' > ; 'xen-de...@lists.xenproject.org' > > Subject: Re: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing > > On Mon, 2015-10-12 at 09:34 +, Hu, Robert wrote: > > > -Original Message- > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > Sent: Monday, October 12, 2015 4:57 PM > > > To: Hu, Robert ; 'Ian Jackson' > > > ; 'xen-de...@lists.xenproject.org' > > > > > > Subject: Re: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing > > > > > > On Mon, 2015-10-12 at 08:04 +, Hu, Robert wrote: > > > > > -Original Message- > > > > > From: Hu, Robert > > > > > Sent: Monday, October 12, 2015 11:36 AM > > > > > To: Ian Jackson ; > > > > > xen-de...@lists.xenproject.org > > > > > Cc: Ian Campbell > > > > > Subject: RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM > testing > > > > > > > > > > > -Original Message- > > > > > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > > > > > > Sent: Saturday, September 26, 2015 3:15 AM > > > > > > To: xen-de...@lists.xenproject.org > > > > > > Cc: Hu, Robert ; Ian Campbell > > > > > > ; Ian Jackson > > > > > > > > > > > > > Subject: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing > > > > > > > > > > > > This is the second part of v14 Robert Ho's osstest patch series > > > > > > to > > > > > > support nested HVM tests. > > > > > > > > > > > > It is also available here: > > > > > > git://xenbits.xen.org/people/iwj/xen.git > > > > > > http://xenbits.xen.org/git-http/people/iwj/xen.git > > > > > > in wip.nested-hvm.v14.part1..wip.nested-hvm.v14 > > > > > > > > > > > > Compared to Robert's v13, which was passed to me by private > > > > > > email, > > > > > > * I have rebased onto current osstest pretest; > > > > > > * I have changed how selecthost() is told it's dealing with > > > > > >a nested host (in practice, L1 guest); > > > > > > * There are a large number of minor cleanups; > > > > > > * There are some new preparatory cleanup and admin patches; > > > > > > * I have rewritten almost all of the commit messages. > > > > > > > > > > > > However, I have done only VERY LIMITED testing. Much of the > code > > > > > > here > > > > > > is UNTESTED since my changes. My testing was confined to: > > > > > > * Verifying that my changes to cs-adjust-flight worked > > > > > > * Checking that ad-hoc runs of ts-host-reboot and > > > ts-host-powercycle > > > > > >seemed to work when a guest was specified on the command > line. > > > > > > > > > > > > Robert, you kindly volunteered to test a revised version of this > > > > > > series. I would appreciate if you would check that all of this > > > > > > still > > > > > > works as you expect. I expect there will be some bugs, perhaps > > > > > > even > > > > > > very silly bugs, introduced by me. > > > > > Sure. > > > > > Am I supposed to test Part 1 together with this Part 2? or each > > > > > individually? > > > > > How's Part 1's status now? pass pretest and in production branch? > > > > > or > > > > > still > > > > > need test? > > > > Seems Part 1 already in production tree. So I directly merged Part 2 > > > > on > > > > latest production master branch. > > > > > > > > However, when I run 'standalone-reset', I get these errors > > > > [root@robert-ivt osstest]# ./standalone-reset > > > > ** need to generate d-i with firmware for armhf > > > > fetching initrd.gz > > > > > > > http://linux-ftp.sh.intel.com/pub/mirrors/debian//dists/wheezy/main/ins > > > ta > > > > ller-armhf/current/images/vexpress/netboot/initrd.gz => initrd.gz
Re: [Xen-devel] [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Monday, October 12, 2015 4:57 PM > To: Hu, Robert ; 'Ian Jackson' > ; 'xen-de...@lists.xenproject.org' > > Subject: Re: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing > > On Mon, 2015-10-12 at 08:04 +, Hu, Robert wrote: > > > -Original Message- > > > From: Hu, Robert > > > Sent: Monday, October 12, 2015 11:36 AM > > > To: Ian Jackson ; > > > xen-de...@lists.xenproject.org > > > Cc: Ian Campbell > > > Subject: RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing > > > > > > > -Original Message- > > > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > > > > Sent: Saturday, September 26, 2015 3:15 AM > > > > To: xen-de...@lists.xenproject.org > > > > Cc: Hu, Robert ; Ian Campbell > > > > ; Ian Jackson > > > > Subject: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing > > > > > > > > This is the second part of v14 Robert Ho's osstest patch series to > > > > support nested HVM tests. > > > > > > > > It is also available here: > > > > git://xenbits.xen.org/people/iwj/xen.git > > > > http://xenbits.xen.org/git-http/people/iwj/xen.git > > > > in wip.nested-hvm.v14.part1..wip.nested-hvm.v14 > > > > > > > > Compared to Robert's v13, which was passed to me by private email, > > > > * I have rebased onto current osstest pretest; > > > > * I have changed how selecthost() is told it's dealing with > > > >a nested host (in practice, L1 guest); > > > > * There are a large number of minor cleanups; > > > > * There are some new preparatory cleanup and admin patches; > > > > * I have rewritten almost all of the commit messages. > > > > > > > > However, I have done only VERY LIMITED testing. Much of the code > > > > here > > > > is UNTESTED since my changes. My testing was confined to: > > > > * Verifying that my changes to cs-adjust-flight worked > > > > * Checking that ad-hoc runs of ts-host-reboot and > ts-host-powercycle > > > >seemed to work when a guest was specified on the command line. > > > > > > > > Robert, you kindly volunteered to test a revised version of this > > > > series. I would appreciate if you would check that all of this still > > > > works as you expect. I expect there will be some bugs, perhaps even > > > > very silly bugs, introduced by me. > > > Sure. > > > Am I supposed to test Part 1 together with this Part 2? or each > > > individually? > > > How's Part 1's status now? pass pretest and in production branch? or > > > still > > > need test? > > Seems Part 1 already in production tree. So I directly merged Part 2 on > > latest production master branch. > > > > However, when I run 'standalone-reset', I get these errors > > [root@robert-ivt osstest]# ./standalone-reset > > ** need to generate d-i with firmware for armhf > > fetching initrd.gz > > > http://linux-ftp.sh.intel.com/pub/mirrors/debian//dists/wheezy/main/insta > > ller-armhf/current/images/vexpress/netboot/initrd.gz => initrd.gz.new > > collecting firmware-bnx2 > > collecting backports initramfs-tools > > collecting backports kernel > > dpkg-deb: error: `backports.deb' is not a debian format archive > > Can you look at the file backports.deb and see what it is? e.g. > $ file backports.deb > might give a clue. For me it says "Debian binary package (format 2.0)". > > My guess is that it will tern out to be some HTML explaining that this file > is not available via your proxy for some reason. Fixed. By moving out 'armhf' in my arch list. > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
> -Original Message- > From: Hu, Robert > Sent: Monday, October 12, 2015 11:36 AM > To: Ian Jackson ; > xen-de...@lists.xenproject.org > Cc: Ian Campbell > Subject: RE: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing > > > -Original Message- > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > > Sent: Saturday, September 26, 2015 3:15 AM > > To: xen-de...@lists.xenproject.org > > Cc: Hu, Robert ; Ian Campbell > > ; Ian Jackson > > Subject: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing > > > > This is the second part of v14 Robert Ho's osstest patch series to > > support nested HVM tests. > > > > It is also available here: > > git://xenbits.xen.org/people/iwj/xen.git > > http://xenbits.xen.org/git-http/people/iwj/xen.git > > in wip.nested-hvm.v14.part1..wip.nested-hvm.v14 > > > > Compared to Robert's v13, which was passed to me by private email, > > * I have rebased onto current osstest pretest; > > * I have changed how selecthost() is told it's dealing with > >a nested host (in practice, L1 guest); > > * There are a large number of minor cleanups; > > * There are some new preparatory cleanup and admin patches; > > * I have rewritten almost all of the commit messages. > > > > However, I have done only VERY LIMITED testing. Much of the code here > > is UNTESTED since my changes. My testing was confined to: > > * Verifying that my changes to cs-adjust-flight worked > > * Checking that ad-hoc runs of ts-host-reboot and ts-host-powercycle > >seemed to work when a guest was specified on the command line. > > > > Robert, you kindly volunteered to test a revised version of this > > series. I would appreciate if you would check that all of this still > > works as you expect. I expect there will be some bugs, perhaps even > > very silly bugs, introduced by me. > Sure. > Am I supposed to test Part 1 together with this Part 2? or each individually? > How's Part 1's status now? pass pretest and in production branch? or still > need test? Seems Part 1 already in production tree. So I directly merged Part 2 on latest production master branch. However, when I run 'standalone-reset', I get these errors [root@robert-ivt osstest]# ./standalone-reset ** need to generate d-i with firmware for armhf fetching initrd.gz http://linux-ftp.sh.intel.com/pub/mirrors/debian//dists/wheezy/main/installer-armhf/current/images/vexpress/netboot/initrd.gz => initrd.gz.new collecting firmware-bnx2 collecting backports initramfs-tools collecting backports kernel dpkg-deb: error: `backports.deb' is not a debian format archive > > > > I noticed that this series lacks guest serial debug keys and log > > collection for the L1 guest, because there is no > > Osstest/Serial/guest.pm. I would appreciate it if you would provide > > one. I don't think it needs to actually collect any logs, because the > > L1 serial output log will be collected as part of the L0 log > > collection. But it ought to support sending debug keys to the L1 > > guest. When you have provided it you can (in the same patch) fix the > > corresponding `todo' in selecthost, changing `noop' to `guest'. > OK, I'll try to add this. > > > > > > Workflow: > > > > Robert: I'm handing this (what I have called `part 2') over to you > > now. > > > > When you make changes, feel free to either rebase, or to make fixup > > commits (perhaps in `git-rebase -i --autosquash' format) on top. If > > you do the latter then you'll probably want to pass that to me as a > > git branch (via git push to xenbits or emailing me a git bundle), > > since `squash!' and `fixup!' commits don't look good in email :-). > > > > If you rebase, please put changes > >v15: > > in the commit messages, as I have done myself in v14. Leave my v14 > > notes in place. > Sure. Thanks for leading the way. > > > > Of course if you have any comments or queries about how I have done > > things, they would be very welcome. > > > > Please do not rebase any of the commits in wip.nested-hvm.v14.part1. > > If you discover bugs in `part 1' please let us know as I have fed that > > into the osstest self-test mill with the expectation that it will go > > into production. > > What's the result now? has it passed pretest and in production now? > > > > > I do not expect you to test the changes to cs-adjust-flight. I have > > done that. Indeed they are not really related to the Nested HVM work > > and Ian C and I may pick them up in another series. > OK, going to bypass it. > > > > > > Ian Campbell: You probably want to defer re-reviewing this until > > Robert reports back. > > > > Signed-off-by: Ian Jackson > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 18/26] LVM: Break out lv_create
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson ; Ian
> Jackson
> Subject: [OSSTEST PATCH 18/26] LVM: Break out lv_create
>
> We are going to want to reuse this.
>
> Signed-off-by: Ian Jackson
> ---
> v14: New patch
> ---
> Osstest/TestSupport.pm | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index ad017a4..2d1db5d 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -62,7 +62,7 @@ BEGIN {
>target_install_packages
> target_install_packages_norec
>target_jobdir target_extract_jobdistpath_subdir
>target_extract_jobdistpath
> - lv_dev_mapper target_guest_lv_name
> + lv_create lv_dev_mapper target_guest_lv_name
'target_guest_lv_name' seems lacking in my work directory. Would you
double check if it is in production tree? I checked, seems not.
>
>poll_loop tcpconnect await_tcp
>contents_make_cpio
> file_simple_write_contents
> @@ -702,6 +702,15 @@ sub poll_loop ($$$&) {
> logm("$what: ok. (${waited}s)");
> }
>
> +sub lv_create ($$$) {
> +my ($ho, $vg, $lv, $mb) = @_;
> +my $lvdev = "/dev/$lv/$vg";
> +target_cmd_root($ho, "lvremove -f $lvdev ||:");
> +target_cmd_root($ho, "lvcreate -L ${mb}M -n $lv $vg");
> +target_cmd_root($ho, "dd if=/dev/zero of=$lvdev count=10");
> +return $lvdev;
> +}
> +
> sub lv_dev_mapper ($$) {
> my ($vg,$lv) = @_;
> $vg =~ s/-/--/g;
> @@ -1685,9 +1694,7 @@ sub prepareguest ($$) {
>
> sub prepareguest_part_lvmdisk ($$$) {
> my ($ho, $gho, $disk_mb) = @_;
> -target_cmd_root($ho, "lvremove -f $gho->{Lvdev} ||:");
> -target_cmd_root($ho, "lvcreate -L ${disk_mb}M -n $gho->{Lv}
> $gho->{Vg}");
> -target_cmd_root($ho, "dd if=/dev/zero of=$gho->{Lvdev} count=10");
> +lvm_lv_create($ho, $gho->{Vg}, $gho->{Lv}, $disk_mb);
> }
>
> sub make_vhd ($$$) {
> --
> 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: Saturday, September 26, 2015 3:15 AM > To: xen-de...@lists.xenproject.org > Cc: Hu, Robert ; Ian Campbell > ; Ian Jackson > Subject: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing > > This is the second part of v14 Robert Ho's osstest patch series to > support nested HVM tests. > > It is also available here: > git://xenbits.xen.org/people/iwj/xen.git > http://xenbits.xen.org/git-http/people/iwj/xen.git > in wip.nested-hvm.v14.part1..wip.nested-hvm.v14 > > Compared to Robert's v13, which was passed to me by private email, > * I have rebased onto current osstest pretest; > * I have changed how selecthost() is told it's dealing with >a nested host (in practice, L1 guest); > * There are a large number of minor cleanups; > * There are some new preparatory cleanup and admin patches; > * I have rewritten almost all of the commit messages. > > However, I have done only VERY LIMITED testing. Much of the code here > is UNTESTED since my changes. My testing was confined to: > * Verifying that my changes to cs-adjust-flight worked > * Checking that ad-hoc runs of ts-host-reboot and ts-host-powercycle >seemed to work when a guest was specified on the command line. > > Robert, you kindly volunteered to test a revised version of this > series. I would appreciate if you would check that all of this still > works as you expect. I expect there will be some bugs, perhaps even > very silly bugs, introduced by me. Sure. Am I supposed to test Part 1 together with this Part 2? or each individually? How's Part 1's status now? pass pretest and in production branch? or still need test? > > I noticed that this series lacks guest serial debug keys and log > collection for the L1 guest, because there is no > Osstest/Serial/guest.pm. I would appreciate it if you would provide > one. I don't think it needs to actually collect any logs, because the > L1 serial output log will be collected as part of the L0 log > collection. But it ought to support sending debug keys to the L1 > guest. When you have provided it you can (in the same patch) fix the > corresponding `todo' in selecthost, changing `noop' to `guest'. OK, I'll try to add this. > > > Workflow: > > Robert: I'm handing this (what I have called `part 2') over to you > now. > > When you make changes, feel free to either rebase, or to make fixup > commits (perhaps in `git-rebase -i --autosquash' format) on top. If > you do the latter then you'll probably want to pass that to me as a > git branch (via git push to xenbits or emailing me a git bundle), > since `squash!' and `fixup!' commits don't look good in email :-). > > If you rebase, please put changes >v15: > in the commit messages, as I have done myself in v14. Leave my v14 > notes in place. Sure. Thanks for leading the way. > > Of course if you have any comments or queries about how I have done > things, they would be very welcome. > > Please do not rebase any of the commits in wip.nested-hvm.v14.part1. > If you discover bugs in `part 1' please let us know as I have fed that > into the osstest self-test mill with the expectation that it will go > into production. What's the result now? has it passed pretest and in production now? > > I do not expect you to test the changes to cs-adjust-flight. I have > done that. Indeed they are not really related to the Nested HVM work > and Ian C and I may pick them up in another series. OK, going to bypass it. > > > Ian Campbell: You probably want to defer re-reviewing this until > Robert reports back. > > Signed-off-by: Ian Jackson > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 15/26] DhcpWatch::leases: Fix a reporting message
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson ; Ian
> Jackson
> Subject: [OSSTEST PATCH 15/26] DhcpWatch::leases: Fix a reporting message
>
> This talks about `guest_check_ip', but this code is now factored out
> into a method. Use the correct method name in reporting.
>
> Signed-off-by: Ian Jackson
> ---
> v14: New patch
> ---
> Osstest/DhcpWatch/leases.pm |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Osstest/DhcpWatch/leases.pm b/Osstest/DhcpWatch/leases.pm
> index 9a74c40..b74ebf0 100644
> --- a/Osstest/DhcpWatch/leases.pm
> +++ b/Osstest/DhcpWatch/leases.pm
> @@ -171,7 +171,7 @@ sub check_ip ($$) {
> }
> $gho->{Ip}= $best->{' addr'};
>
> -report_once($gho, 'guest_check_ip',
> +report_once($gho, 'leases::check_ip',
> "guest $gho->{Name}: $gho->{Ether} $gho->{Ip}");
> return undef;
> }
Ack.
> --
> 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTest Nested v12 19/21] Selecthost uses dynamic IP address if the host is not configured static IP.
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 12:59 AM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com;
> Jin, Gordon ; Zheng, Di
> Subject: Re: [OSSTest Nested v12 19/21] Selecthost uses dynamic IP address
> if the host is not configured static IP.
>
> Robert Ho writes ("[OSSTest Nested v12 19/21] Selecthost uses dynamic IP
> address if the host is not configured static IP."):
> > In this patch
> > 1. in check_ip(), we change $lstash to use {Name} key-value, rather
> > than {Guest}, because {Name} is both usable by $ho and $gho hash.
> > 2. $ho->{Ether} assignment: if configured in host property, good, use
> > it; otherwise, try to see if runvar has the assignment (this is the
> > case of nested test).
>
> I am going to drop this patch from my v14 of the nested HVM tests
> series.
>
> This is not because this change is valueless. But, in the context of
> my other changes, it is no longer needed for supporting L1 guests: L1
> guests do not any longer run through the code path that this patch
> modifies.
>
> This patch might still be valuable in the future to support physical
> hosts without static IP addresses. But AFAIAA none of our
> environments have such things and dropping this patch will avoid me
> having to review this code.
>
> It will also avoid anyone having to test it.
OK. I have no objection if current L1 running around this code path.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTest Nested v12 16/21] Add PDU power method for nested L1 and L2 guest
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 12:36 AM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com;
> Jin, Gordon ; Zheng, Di
> Subject: Re: [OSSTest Nested v12 16/21] Add PDU power method for nested
> L1 and L2 guest
>
> Robert Ho writes ("[OSSTest Nested v12 16/21] Add PDU power method for
> nested L1 and L2 guest"):
> > For nested host/guest, its power on/off method shall be
> > its host invoke $(toolstack)->create/destroy method.
>
> Thanks for this patch, which I have substantially edited for my v14.
>
> However, I notice that it was missing a signed-off-by. Can you please
> confirm that I should add your s-o-b ?
Sorry I forgot to add my s-o-b. Yes, please add mine.
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTest Nested v12 03/21] Allow runvars to specify guest disk and ram size (turning previous values into defaults)
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, September 25, 2015 6:35 PM
> To: Hu, Robert ; xen-devel@lists.xen.org;
> ian.campb...@citrix.com; wei.l...@citrix.com; Jin, Gordon
> ; Zheng, Di
> Subject: Re: [OSSTest Nested v12 03/21] Allow runvars to specify guest disk
> and ram size (turning previous values into defaults)
>
> Ian Jackson writes ("Re: [OSSTest Nested v12 03/21] Allow runvars to specify
> guest disk and ram size (turning previous values into defaults)"):
> > Robert Ho writes ("[OSSTest Nested v12 03/21] Allow runvars to specify
> guest disk and ram size (turning previous values into defaults)"):
> > > 1. The default disk size for guest is '1M' which is not sufficient
> > > for nested HVM guest, using larger disk size for nested guest
> > > to accommodate to nested test requirement, the specific
> disk_size is
> > > defined by make-flight.
> > > 2. Also, also allow ram size to be defined by runvar. It takes
> precedence
> > > over the calculation formula.
> > > 3. Add comment at the interface code.
> > >
> > > Signed-off-by: Robert Ho
> >
> > Acked-by: Ian Jackson
>
> Robert, I see that the v13 of this series you passed me under the
> table does not include this ack.
>
> It is conventional to transcribe an ack when preparing a new version
> of a series. That helps reviewers and other contributors see which
> parts of a series still need attention.
>
Sure. I will remember this in following series.
> I will record the ack in my own git tree.
Thanks.
And sorry I haven't got a chance to read your replies/patches until now.
So many test tasks almost crushed me.
I'm going to read your mails in the coming week.
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTest Nested v12 00/21] Introduction of netsted HVM test job
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, September 16, 2015 10:37 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com;
> Jin, Gordon; Zheng, Di
> Subject: Re: [OSSTest Nested v12 00/21] Introduction of netsted HVM test
> job
>
> Robert Ho writes ("[OSSTest Nested v12 00/21] Introduction of netsted HVM
> test job"):
> > This patch set adds nested HVM test case for osstest.
>
> Sorry for the delay in reviewing the last few patches in this series.
> I've finished with it now. I hope my previous review comments
> etc. have been helpful.
Though just took a quick glance at a few, I believe they are helpful.
>
> Do you intend to resend a v13 soon ? If you are finding my comments
> and suggestions difficult to implement, perhaps it would be better for
> you to give me a git branch for me to work on.
Yes.
That would be a great favor, thank you very very much!
Would you give me a branch I can push my code to? for I'm afraid that company
policy
doesn't allow me to set up git repo for external access.
>
> I would be happy to rework the bits of your series which need the most
> reorganisation, and then pass it back on to you for testing. Would
> that be a good workflow for you ?
Sure, I'd love to.
>
> Regards,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job
Thanks Ian.
So strange, seems this mail was sent ' Tuesday, September 1, 2015 10:42 PM ',
but I
have just received it.
I'm fully occupied by some release test, so have to carefully read your
comments 1 ~2
weeks later. Sorry about this.
Best Regards,
Robert Ho
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, September 1, 2015 9:52 PM
> To: Hu, Robert; Ian Jackson
> Cc: xen-devel@lists.xen.org; wei.l...@citrix.com
> Subject: Re: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of
> nested test job
>
> On Tue, 2015-08-18 at 06:46 +, Hu, Robert wrote:
>
> Sorry for the delay, I've been away.
>
> > > -Original Message-
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > Sent: Thursday, June 25, 2015 6:22 PM
> > > To: Pang, LongtaoX
> > > Cc: Ian Campbell; Hu, Robert; xen-devel@lists.xen.org;
> > > wei.l...@citrix.com
> > > Subject: RE: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe
> of
> > > nested test job
> > >
> > > Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 6/7] Compose
> the
> > > main recipe of nested test job"):
> > > > > -Original Message-
> > > > > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > > ...
> > > > > I think you are correct, the logs capture will fail too.
> > > > >
> > > > > I'll leave it to Ian to suggest a solution since it will no doubt
> > > > > involve some tcl plumbing (I'd be inclined to record 'hosts which
> > > > > are
> > > > > actually guests' somewhere and have the infra clean them up
> > > > > automatically after doing leak check and log collection).
> > >
> > > Sorry I haven't done this yet, it's still on my radar.
> > >
> > > > > I was thinking more along the lines of creating
> > > > > Osstest/PDU/guest.pm
> > > > > with the appropriate methods calling out to toolstack($l0)->foo,
> > > > > setting
> > > > > $ho->{Power} = 'guest $l1guestname' somewhere and allowing
> > > > > power_cycle_host_setup to do it's thing.
> > > >
> > > > I have reviewed power_cycle_host_setup function, inside this
> > > > function will call get_host_method_object, then we could get a $mo
> > > > which will be assigned to $ho->{PowerMethobjs}, right? Inside
> > > > power_state function, it will call pdu_power_state which is defined
> > > > in guest.pm, right?
> > >
> > > Yes.
> > I'm not quite sure about how @$methobjs is obtained.
> > sub power_cycle_host_setup ($) {
> > my ($ho) = @_;
> > my $methobjs = [ ];
> > foreach my $meth (split /\;\s*/, $ho->{Power}) {
> > push @$methobjs, get_host_method_object($ho,'PDU',$meth);
> > }
> > $ho->{PowerMethobjs} = $methobjs;
> > }
> > Seems it is derived from $ho->{Power} while $ho->{Power} is defined by
> > either:
> > 1. selecthost()
> > $ho->{Power}= get_host_property($ho,'power-method');
> > 2. default_methods()
> > $ho->{Power} ||= "statedb $ho->{Asset}";
> > Seems no statedb for standalone mode.
>
> Indeed, statedb is actually peculiar to the old Cambridge instance of
> osstest, it's not used in the production colo. In fact it is also not used
> in Cambridge any more, every host has a power-method host property. In
> standalone mode the default {Power} is "manual" I think, that's the one
> which prompts you to press a key.
>
> The {Power} property is essentially a ";" separated list, each list entry
> is " <...>". is Osstest/PDU/.pm
> and
> <...> are passed to the constructor. These objects are
> constructed by get_host_method_object.
>
> Then on power operation the appropriate method each object is called in
> turn (so you can call multiple modules if needed by the host).
>
> > So how shall I assign $ho->{Power} method? by statically through config
> > file?
> > or some generic way automatically identify $host is some guest, therefore
> > assign 'guest' to $ho->{Power}?
> > Would you give me some idea? thanks.
>
> I'm not sure. Something in selecthost would need to know somehow that the
> host being requested was actually an L1 guest.
>
> Ian, any ideas?
>
> Ian
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job
Thanks Ian.
So strange, seems this mail was sent ' Tuesday, September 1, 2015 10:42 PM ',
but I
have just received it.
I'm fully occupied by some release test, so have to carefully read your
comments 1 ~2
weeks later. Sorry about this.
Best Regards,
Robert Ho
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Tuesday, September 1, 2015 10:42 PM
> To: Ian Campbell
> Cc: Hu, Robert; xen-devel@lists.xen.org; wei.l...@citrix.com
> Subject: Re: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of
> nested test job
>
> Hi Robert. Sorry I haven't had a chance to look at your whole v11
> series properly yet. But I will reply here:
>
> Ian Campbell writes ("Re: [OSSTEST Nested PATCH v11 6/7] Compose the
> main recipe of nested test job"):
> > Then on power operation the appropriate method each object is called in
> > turn (so you can call multiple modules if needed by the host).
>
> Ian's explanation is right.
>
> > > So how shall I assign $ho->{Power} method? by statically through config
> > > file?
> > > or some generic way automatically identify $host is some guest,
> therefore
> > > assign 'guest' to $ho->{Power}?
> > > Would you give me some idea? thanks.
> >
> > I'm not sure. Something in selecthost would need to know somehow that
> the
> > host being requested was actually an L1 guest.
>
> I think this would be correct.
>
> > Ian, any ideas?
>
> I was expecting there to be a runvar which would for an L1 guest give
> the ident of its host. ts-nested-setup would set this runvar and
> selecthost would look at it.
>
> There are various possible exact syntaxes but I think the best one is
> probably that the runvar which ordinarily gives the name of a real
> host instead contains the containing host name and the L1 guest name.
>
> So if you do
> ./ts-nested-setup l0_host l1
> then you get a runvar `l1' with value `l0_host:l1'.
>
> selecthost would see the colon, and set $ho->{Host} to `l0_host', so
> that get_target_property's recursion into containing hosts works
> properly.
>
> selecthost would also be able to see that $ho->{Host} being set meant
> it was a nested guest, and that therefore power operations should be
> done by running toolstack operations on the host. (Rather than
> looking up a host property.)
>
> It also needs to arrange that for an L1 (well, anything with
> $ho->{Host} aka the _nestedhost runvar), the MAC address is read (into
> $ho) from the runvar which is created by the guest creation, rather
> than being looked up as a host property. Then the functions for
> finding the IP address by asking the DHCP server have the right input.
>
> The $ho->{DiskDevice} setting in selecthost is wrong too.
>
> This is all probably most easily achieved by having the part of
> selecthost which deals with L1 guests seed $ho->{Properties} with
> appropriate information.
>
> You want to make "- calculation of the host's properties -"
> conditional, and do something entirely different (ie, populate
> $ho->{Properties} and perhaps some of $ho->{Flags}) when $ho->{Host}
> is set.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Thursday, June 25, 2015 6:22 PM
> To: Pang, LongtaoX
> Cc: Ian Campbell; Hu, Robert; xen-devel@lists.xen.org; wei.l...@citrix.com
> Subject: RE: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of
> nested test job
>
> Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 6/7] Compose the
> main recipe of nested test job"):
> > > -Original Message-
> > > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> ...
> > > I think you are correct, the logs capture will fail too.
> > >
> > > I'll leave it to Ian to suggest a solution since it will no doubt
> > > involve some tcl plumbing (I'd be inclined to record 'hosts which are
> > > actually guests' somewhere and have the infra clean them up
> > > automatically after doing leak check and log collection).
>
> Sorry I haven't done this yet, it's still on my radar.
>
> > > I was thinking more along the lines of creating Osstest/PDU/guest.pm
> > > with the appropriate methods calling out to toolstack($l0)->foo, setting
> > > $ho->{Power} = 'guest $l1guestname' somewhere and allowing
> > > power_cycle_host_setup to do it's thing.
> >
> > I have reviewed power_cycle_host_setup function, inside this
> > function will call get_host_method_object, then we could get a $mo
> > which will be assigned to $ho->{PowerMethobjs}, right? Inside
> > power_state function, it will call pdu_power_state which is defined
> > in guest.pm, right?
>
> Yes.
I'm not quite sure about how @$methobjs is obtained.
sub power_cycle_host_setup ($) {
my ($ho) = @_;
my $methobjs = [ ];
foreach my $meth (split /\;\s*/, $ho->{Power}) {
push @$methobjs, get_host_method_object($ho,'PDU',$meth);
}
$ho->{PowerMethobjs} = $methobjs;
}
Seems it is derived from $ho->{Power} while $ho->{Power} is defined by either:
1. selecthost()
$ho->{Power}= get_host_property($ho,'power-method');
2. default_methods()
$ho->{Power} ||= "statedb $ho->{Asset}";
Seems no statedb for standalone mode.
So how shall I assign $ho->{Power} method? by statically through config file?
or some generic way automatically identify $host is some guest, therefore
assign 'guest' to $ho->{Power}?
Would you give me some idea? thanks.
>
> > So, I need to defined how to power off/on L1 inside pdu_power_state
> > function? I think we need to using 'xl destroy' and 'xl create'
> > command to implement the power method.
>
> Indeed. You'll need to use the appropriate toolstack object, in case
> it's libvirt or something. toolstack($ho) where $ho is the L0.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest RFC: ts-xen-build-prep, lvextend1(), don't call lvextend if "-l 0"
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Sunday, August 16, 2015 5:05 PM
> To: Hu, Robert; 'Ian Jackson'; 'wei.l...@citrix.com'
> Cc: 'xen-devel@lists.xen.org'
> Subject: Re: OSSTest RFC: ts-xen-build-prep, lvextend1(), don't call lvextend
> if
> "-l 0"
>
> On Fri, 2015-08-14 at 03:54 +, Hu, Robert wrote:
> > Hi,
> >
> > lvextend will report error if doing with "-l 0".
> > So I propose to add an judgment regarding $vg_more_free_pe.
> >
> > diff --git a/ts-xen-build-prep b/ts-xen-build-prep
> > index 9a3b523..f1d1255 100755
> > --- a/ts-xen-build-prep
> > +++ b/ts-xen-build-prep
> > @@ -155,7 +155,8 @@ sub lvextend1 ($$$) {
> > logm("$what: unstriped $vg_more_free_pe PEs");
> > overall_limit_pe(\$vg_more_free_pe);
> > $more_pe += $vg_more_free_pe;
> > -target_cmd_root($ho, "lvextend -i1 -l +$vg_more_free_pe $lv");
> > +target_cmd_root($ho, "lvextend -i1 -l +$vg_more_free_pe $lv")
> > + if $vg_more_free_pe != 0;
> > }
>
> In my tree at least the } is closing a "if ($vg_more_free_pe)". Perhaps
> it would make more sense to extend that to also check for ? 0?
I find that $vg_more_free_pe is set to 0 by
'overall_limit_pe(\$vg_more_free_pe);'.
>
> if (($vg_more_free_pe//0) > 0)
>
> is probably nicer than
> if ($vg_more_free_pe && $vg_more_free_pe > 0)
> I suppose.
>
> Or maybe add //0 to the
> my $vg_more_free_pe= $vginfo[15];
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] OSSTest RFC: ts-xen-build-prep, lvextend1(), don't call lvextend if "-l 0"
Hi,
lvextend will report error if doing with "-l 0".
So I propose to add an judgment regarding $vg_more_free_pe.
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 9a3b523..f1d1255 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -155,7 +155,8 @@ sub lvextend1 ($$$) {
logm("$what: unstriped $vg_more_free_pe PEs");
overall_limit_pe(\$vg_more_free_pe);
$more_pe += $vg_more_free_pe;
-target_cmd_root($ho, "lvextend -i1 -l +$vg_more_free_pe $lv");
+target_cmd_root($ho, "lvextend -i1 -l +$vg_more_free_pe $lv")
+ if $vg_more_free_pe != 0;
}
Best Regards,
Robert Ho
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTEST -- nested test case development, RFC: ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed IP
> -Original Message-
> From: Hu, Robert
> Sent: Thursday, August 13, 2015 11:46 AM
> To: Ian Jackson
> Cc: Ian Campbell; wei.l...@citrix.com; xen-devel@lists.xen.org
> Subject: RE: OSSTEST -- nested test case development, RFC: ts-guest-destroy
> doesn't call guest_await_dhcp_tcp() if guest has fixed IP
>
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Wednesday, August 12, 2015 11:27 PM
> > To: Hu, Robert
> > Cc: Ian Campbell; wei.l...@citrix.com; xen-devel@lists.xen.org
> > Subject: RE: OSSTEST -- nested test case development, RFC:
> ts-guest-destroy
> > doesn't call guest_await_dhcp_tcp() if guest has fixed IP
> >
> > Hu, Robert writes ("RE: OSSTEST -- nested test case development, RFC:
> > ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed
> IP"):
> >
> > > So shall I conclude as following?:
> >
> > > 1. Xen install shall create xenbr0 bridge with dhcp mode; Apply to
> > > both L0 and L1.
> >
> > I think ts-xen-install should respect the existing configuration for
> > the primary network device, rather than insisting it be static, or
> > insisting it be dhcp.
> Yes, in fact it is the only network interface (eth0 before Xen intall; xenbr0
> after
> Xen install, eth0 becomes its slave right now).
> So you won't object turn xenbr0 config to 'dhcp' as following, right?
> diff --git a/ts-xen-install b/ts-xen-install
> index 0f53382..74104cb 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -301,10 +301,7 @@ END
> if (m/^\s* iface \s+ (?: $physif | xenbr0 ) \s+ inet \s /x) {
> $suppress= 1;
> print EO < -iface $iface inet static
> -address $ho->{Ip}
> -netmask $netmask
> -gateway $gateway
> +iface $iface inet dhcp
> $bridgex
> END
> }
> >
> > > 2. in each selecthost invoke, query DHCP lease for host's IP. (This
> > > assumes no more fixed IP used in any cases).
> >
> > We should continue to use fixed IP addresses where we have them.
> Then I'm not confident to change selecthost(). Would you help give me
> the patch addressing this?
I changed like this. It works (I tested with both nested case and
test-amd64-amd64-xl-qemuu-debianhvm-amd64). How would you like it?
index e9be7f8..b367cfb 100755
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -875,7 +875,7 @@ sub selecthost ($) {
$ho->{Fqdn} = get_host_property($ho,'fqdn',$defaultfqdn);
-$ho->{Ether}= get_host_property($ho,'ether');
+$ho->{Ether}= get_host_property($ho,'ether') || $r{"$ho->{Ident}_ether"};
$ho->{DiskDevice}= get_host_property($ho,'disk-device');
$ho->{Power}= get_host_property($ho,'power-method');
@@ -886,17 +886,23 @@ sub selecthost ($) {
serial_host_setup($ho);
$ho->{IpStatic} = get_host_property($ho,'ip-addr');
-if (defined $r{"${ident}_ip"}) {
-$ho->{Ip} = $r{"${ident}_ip"};
-} else {
-if (!defined $ho->{IpStatic}) {
- my $ip_packed= gethostbyname($ho->{Fqdn});
- die "$ho->{Fqdn} ?" unless $ip_packed;
+if (!defined $ho->{IpStatic}) {
+ my $ip_packed= gethostbyname($ho->{Fqdn});
+ if (!$ip_packed) {
+ logm("Going to look for $ho->{Name}'s ether: $ho->{Ether}");
+ $ho->{DhcpWatch}->check_ip($ho);
+ $ho->{IpStatic}=$ho->{Ip};
+ }
+# die "$ho->{Fqdn} ?" unless $ip_packed;
+ else {
$ho->{IpStatic}= inet_ntoa($ip_packed);
die "$ho->{Fqdn} ?" unless defined $ho->{IpStatic};
-}
-$ho->{Ip}= $ho->{IpStatic};
+ $ho->{Ip}= $ho->{IpStatic};
+ }
}
> >
> > Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTEST -- nested test case development, RFC: ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed IP
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, August 12, 2015 11:27 PM
> To: Hu, Robert
> Cc: Ian Campbell; wei.l...@citrix.com; xen-devel@lists.xen.org
> Subject: RE: OSSTEST -- nested test case development, RFC: ts-guest-destroy
> doesn't call guest_await_dhcp_tcp() if guest has fixed IP
>
> Hu, Robert writes ("RE: OSSTEST -- nested test case development, RFC:
> ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed IP"):
>
> > So shall I conclude as following?:
>
> > 1. Xen install shall create xenbr0 bridge with dhcp mode; Apply to
> > both L0 and L1.
>
> I think ts-xen-install should respect the existing configuration for
> the primary network device, rather than insisting it be static, or
> insisting it be dhcp.
Yes, in fact it is the only network interface (eth0 before Xen intall; xenbr0
after
Xen install, eth0 becomes its slave right now).
So you won't object turn xenbr0 config to 'dhcp' as following, right?
diff --git a/ts-xen-install b/ts-xen-install
index 0f53382..74104cb 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -301,10 +301,7 @@ END
if (m/^\s* iface \s+ (?: $physif | xenbr0 ) \s+ inet \s /x) {
$suppress= 1;
print EO <{Ip}
-netmask $netmask
-gateway $gateway
+iface $iface inet dhcp
$bridgex
END
}
>
> > 2. in each selecthost invoke, query DHCP lease for host's IP. (This
> > assumes no more fixed IP used in any cases).
>
> We should continue to use fixed IP addresses where we have them.
Then I'm not confident to change selecthost(). Would you help give me
the patch addressing this?
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTEST -- nested test case development, RFC: ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed IP
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Tuesday, August 11, 2015 8:55 PM
> To: Ian Campbell
> Cc: Hu, Robert; wei.l...@citrix.com; xen-devel@lists.xen.org
> Subject: Re: OSSTEST -- nested test case development, RFC: ts-guest-destroy
> doesn't call guest_await_dhcp_tcp() if guest has fixed IP
>
> Ian Campbell writes ("Re: OSSTEST -- nested test case development, RFC:
> ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed IP"):
> > However by reconfiguring things to be static the L1 host will no longer be
> > generating DHCP RENEW requests when the lease times out, so the DHCP
> server
> > is at liberty to release the lease when it times out or, worse, reuse the
> > IP address for something else.
>
> Indeed. This is wrong.
>
> > So I think we do actually need to start supporting a dynamic mode for at
> > least L1 hosts (and that may well easily extend to L0 hosts too). Although
> > it is not 100% accurate I think we can assume that DHCP renewal will
> always
> > work, i.e. once a host is given a particular IP address so long as it keeps
> > renewing the lease it will keep the same address.
>
> It isn't clear to me that we need to make this assumption, in the
> general case. We probably need to assume that the DHCP-assigned IP
> addresses don't change unexpectedly during the execution of a
> particular ts-* script (where `unexpectedly' means `other than as an
> obvious consequence of actions such as rebooting).
>
> > So I think we can still discover the DHCP address assigned to the L1 guest,
> > and propagate it into $r{"${l1ident}_ip"} when we convert it to an L1 host,
> > but we then also need to modify the Xen installation runs to use dhcp
> mode
> > for such cases and not switch to static as we do for an L0 host.
>
> This would be the right approach, but ...
>
> > I'm not quite sure how this should be recorded in the runvars. I think we
> > may want to wait for Ian to return from vacation next week.
>
> ... having looked at it like this, I think recording the L1 IP
> addresss in the runvars is wrong. It should be looked up each time
> (by something called by selecthost).
>
> > The alternative would be that selecthost needs to query the DHCP leases
> > file for these kinds of hosts, that would have the benefit of handling
> > potential lease expiry over a reboot.
>
> Exactly.
So shall I conclude as following?:
1. Xen install shall create xenbr0 bridge with dhcp mode; Apply to both L0 and
L1.
2. in each selecthost invoke, query DHCP lease for host's IP. (This assumes no
more
fixed IP used in any cases).
And who's going to make the patch for these? me or you will help provide?
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] OSSTest-- Leases::check_ip() ignore guest free IP
Hi,
Say such a leases file:
lease 192.168.199.124 {
starts 4 2015/08/06 08:46:50;
ends 4 2015/08/06 08:58:50;
cltt 4 2015/08/06 08:46:50;
binding state active;
next binding state free;
hardware ethernet 5e:36:0e:f5:00:02;
uid "\001^6\016\365\000\002";
}
lease 192.168.199.242 {
starts 4 2015/08/06 08:46:55;
ends 4 2015/08/06 08:58:55;
cltt 4 2015/08/06 08:46:55;
binding state active;
next binding state free;
hardware ethernet 00:04:23:e8:dd:5a;
uid "\001\000\004#\350\335Z";
}
...
lease 192.168.199.124 {
starts 4 2015/08/06 08:46:50;
ends 4 2015/08/06 08:58:50;
tstp 4 2015/08/06 08:58:50;
cltt 4 2015/08/06 08:46:50;
binding state free;
hardware ethernet 5e:36:0e:f5:00:02;
uid "\001^6\016\365\000\002";
}
In Leases::check_ip(), it will ignore the last entry of guest freeing IP
and return last active IP lease entry. Then OSSTest will try to ping that IP
and fails.
Best Regards,
Robert Ho
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTEST -- nested test case development, RFC: ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed IP
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Thursday, August 6, 2015 5:01 PM
> To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com
> Cc: xen-devel@lists.xen.org
> Subject: Re: OSSTEST -- nested test case development, RFC: ts-guest-destroy
> doesn't call guest_await_dhcp_tcp() if guest has fixed IP
>
> On Thu, 2015-08-06 at 01:57 +, Hu, Robert wrote:
> > >
> > > -Original Message-
> > > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > > Sent: Wednesday, August 5, 2015 8:27 PM
> > > To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com
> > > Cc: xen-devel@lists.xen.org
> > > Subject: Re: OSSTEST -- nested test case development, RFC: ts-guest
> > > -destroy
> > > doesn't call guest_await_dhcp_tcp() if guest has fixed IP
> > >
> > > On Wed, 2015-08-05 at 06:22 +, Hu, Robert wrote:
> > > > Hi Ians,
> > >
> > > I don't 100% recall how this is supposed to fit together.
> > >
> > > IIRC:
> > >
> > > 1# L0 is installed as usual
> > >
> > > #2 An L1 guest is installed. That L1 guest gets an IP address from DHCP
> > > in
> > > the normal way.
> > yes
> > >
> > > 3# Then ts-nested setup customises the L1 guest into an L1 host,
> > > storing
> > > the DHCP assigned address in $r{"${l1ident}_ip"}. (I'm not sure if it
> > > is
> > > actually called l1ident, but whatever it is).
> > After l1 installed Xen and turned into Xen environment (12 testid
> xen-install/l1 below),
> > its IP get fixed (this is current normal Xen installation behavior, same in
> > l0's
> Xen install).
>
> Reconfiguring things on a system to be static rather than dynamic has no
> effect on how the network administrator (i.e. the person who operated the
> DHCP server) views the IP address. As far as they are concerned the IP
> address remains part of the dynamic allocation pool.
Yes.
>
> However by reconfiguring things to be static the L1 host will no longer be
> generating DHCP RENEW requests when the lease times out, so the DHCP
> server
> is at liberty to release the lease when it times out or, worse, reuse the
> IP address for something else.
Yeah, this is probably the reason of no findings.
>
> This doesn't apply for L0 in our deployments because we statically assign
> IP addresses to MAC addresses associated with physical network interfaces.
>
> So I think we do actually need to start supporting a dynamic mode for at
> least L1 hosts (and that may well easily extend to L0 hosts too). Although
> it is not 100% accurate I think we can assume that DHCP renewal will always
> work, i.e. once a host is given a particular IP address so long as it keeps
> renewing the lease it will keep the same address.
Well, I'm afraid we cannot assume dhcp server behaves in this way: always assign
its last time IP. You know l1 will reboot after xen install. After reboot, it
shall
'ask for' not renew its IP. Though, in most practices, it will get its last
time IP
but cannot guarantee that.
>
> So I think we can still discover the DHCP address assigned to the L1 guest,
> and propagate it into $r{"${l1ident}_ip"} when we convert it to an L1 host,
> but we then also need to modify the Xen installation runs to use dhcp mode
> for such cases and not switch to static as we do for an L0 host.
This will make current code more complex; while seems no other chooses.
I would suggest unify this: dynamic all cases, no matter L1 or L0 xen install;
since
you can fix L0's IP in server side, it will always get same IP.
>
> I'm not quite sure how this should be recorded in the runvars. I think we
> may want to wait for Ian to return from vacation next week.
OK
>
> The alternative would be that selecthost needs to query the DHCP leases
> file for these kinds of hosts, that would have the benefit of handling
> potential lease expiry over a reboot.
>
> Ian?
>
>
> > See /etc/network/interface in l1:
> > root@l1:~# cat /etc/network/interfaces
> > ...
> > auto xenbr0
> > iface xenbr0 inet static
> > address 192.168.199.175
> > netmask 255.255.255.0
> > gateway 192.168.199.1
> > bridge_ports eth0
> > bridge_fd 0
> > bridge_stp off
> >
> > Then, in guest-destroy, we cannot get its IP by searching lease file.
> > >
> > > 4# Then operations which selecthost(l1ident) see that
> > > $r{"${l1ident}_ip"}
> > > and use it as the $ho->{Ip} instead of looking for
Re: [Xen-devel] OSSTEST -- nested test case development, RFC: ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed IP
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Wednesday, August 5, 2015 8:27 PM
> To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com
> Cc: xen-devel@lists.xen.org
> Subject: Re: OSSTEST -- nested test case development, RFC: ts-guest-destroy
> doesn't call guest_await_dhcp_tcp() if guest has fixed IP
>
> On Wed, 2015-08-05 at 06:22 +, Hu, Robert wrote:
> > Hi Ians,
>
> I don't 100% recall how this is supposed to fit together.
>
> IIRC:
>
> 1# L0 is installed as usual
>
> #2 An L1 guest is installed. That L1 guest gets an IP address from DHCP in
> the normal way.
yes
>
> 3# Then ts-nested setup customises the L1 guest into an L1 host, storing
> the DHCP assigned address in $r{"${l1ident}_ip"}. (I'm not sure if it is
> actually called l1ident, but whatever it is).
After l1 installed Xen and turned into Xen environment (12 testid
xen-install/l1 below),
its IP get fixed (this is current normal Xen installation behavior, same in
l0's Xen install).
See /etc/network/interface in l1:
root@l1:~# cat /etc/network/interfaces
...
auto xenbr0
iface xenbr0 inet static
address 192.168.199.175
netmask 255.255.255.0
gateway 192.168.199.1
bridge_ports eth0
bridge_fd 0
bridge_stp off
Then, in guest-destroy, we cannot get its IP by searching lease file.
>
> 4# Then operations which selecthost(l1ident) see that $r{"${l1ident}_ip"}
> and use it as the $ho->{Ip} instead of looking for it in the host db.
Yes
>
> 5# At some point an L2 guest is installed on the L1 host and it also gets
> an IP from DHCP in the usual way.
Yes, L2 will get IP from dhcp.
>
> Is that all correct?
Here is current test steps
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 1
testid build-check(1) ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 2
testid hosts-allocate ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 3
testid host-install(3) ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 4
testid host-ping-check-native ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 5
testid xen-install ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 6
testid xen-boot ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 7
testid host-ping-check-xen ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 8
testid leak-check/basis(8) ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 9
testid debian-hvm-install ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 10
testid nested-setup ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 11
testid host-ping-check-native/l1 ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 12
testid xen-install/l1 ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 13
testid xen-boot/l1 ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 14
testid host-ping-check-xen/l1 ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 15
testid leak-check/basis/l1(15) ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 16
testid debian-hvm-install/l1/l2 ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 17
testid guest-stop/l1/l2 ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 18
testid guest-destroy ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 19
testid leak-check/check/l1 ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 20
testid capture-logs/l1(20) ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 21
testid final-poweroff/l1 ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 22
testid leak-check/check ==
2015-08-06 01:44:58 Z standalone.test-amd64-amd64-qemuu-nested == 23
testid capture-logs(23) ==
>
> > Current ts-guest-destory will invoke guest_await_dhcp_tcp();
> > but in nested case, after l1 turns into Xen environment, it then has
> > fixed IP address; which in turn has failed at dhcp lease check.
>
> So here are we talking about ts-guest-destroy of an L2 guest on the L1
> host, or of the L1 guest on the L0 host?
l1 on l0.
>
> I think you are talking about the L1 guest on the L0 host.
>
> In that context ts-guest-destroy will be considering the L1 as a guest, so
> I would expect tha
Re: [Xen-devel] OSSTEST -- nested test case development, RFC: ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed IP
> -Original Message-
> From: xen-devel-boun...@lists.xen.org
> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Hu, Robert
> Sent: Wednesday, August 5, 2015 2:22 PM
> To: ian.jack...@eu.citrix.com; Ian Campbell; wei.l...@citrix.com
> Cc: xen-devel@lists.xen.org
> Subject: [Xen-devel] OSSTEST -- nested test case development, RFC:
> ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed IP
>
> Hi Ians,
>
> Current ts-guest-destory will invoke guest_await_dhcp_tcp();
> but in nested case, after l1 turns into Xen environment, it then has
> fixed IP address; which in turn has failed at dhcp lease check.
>
> So, how about if I in ts-guest-destroy bypass guest_await_dhcp_tcp()
> if we have $r{guest->Guest_ip}?
Detailed diff
@@ -1354,6 +1355,8 @@ sub selectguest ($$) {
$gho->{Options}{$opt}++;
}
logm("guest: using $gn on $gho->{Host}{Name}");
+$gho->{Ip} = $r{"$gho->{Guest}_ip"};
+logm("guest: $gn has fixed IP $gho->{Ip}");
guest_find_lv($gho);
guest_find_ether($gho);
guest_find_tcpcheckport($gho);
@@ -1758,7 +1761,7 @@ sub guest_await_dhcp_tcp ($$) {
" $gho->{TcpCheckPort}".
" link/ip/tcp",
sub {
-my $err= guest_check_ip($gho);
+my $err= guest_check_ip($gho) if !$gho->{Ip};
return $err if defined $err;
return
>
> Best Regards,
> Robert Ho
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] OSSTEST -- nested test case development, RFC: ts-guest-destroy doesn't call guest_await_dhcp_tcp() if guest has fixed IP
Hi Ians,
Current ts-guest-destory will invoke guest_await_dhcp_tcp();
but in nested case, after l1 turns into Xen environment, it then has
fixed IP address; which in turn has failed at dhcp lease check.
So, how about if I in ts-guest-destroy bypass guest_await_dhcp_tcp()
if we have $r{guest->Guest_ip}?
Best Regards,
Robert Ho
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Friday, July 31, 2015 4:59 PM > To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com > Cc: xen-devel@lists.xen.org > Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of guest > auto installation > > On Fri, 2015-07-31 at 08:47 +, Hu, Robert wrote: > > > > > > -Original Message- > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > Sent: Friday, July 31, 2015 4:46 PM > > > To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com > > > Cc: xen-devel@lists.xen.org > > > Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of > > > guest > > > auto installation > > > > > > On Fri, 2015-07-31 at 08:29 +, Hu, Robert wrote: > > > > > > Please can you not top post. > > > > > > > Further more, now I see debian-hvm guest boots up. But it hangs at > > > > 'Starting MTA'. > > > > Is MTA necessary? > > > > > > Not really, but it's part of the standard Debian installation. > > > > > > If it is hanging then that usually indicates something is wrong with > > > networking, either connectivity or DNS etc. Removing the MTA would > > > simply > > > be working around that underlying issue > > Do you know how to disable it? seems it is not a service? > > I don't know how to turn off the MTA during install, and like I said that > is not the approach you should be taking to resolve this issue. Instead you > should fix whatever it is that is broken about the network in your test > case. I checked my network environment settings, all common settings are set correctly (dns, routes, gateway, ntp, etc.). I don't see any network configuration shall blocking MTA start up, unless it has some special requirements. > > > > > > > IOW patches to remove the MTA would likely not be accepted. > > I see. Thanks for remind. > > > > > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Friday, July 31, 2015 4:46 PM > To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com > Cc: xen-devel@lists.xen.org > Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of guest > auto installation > > On Fri, 2015-07-31 at 08:29 +, Hu, Robert wrote: > > Please can you not top post. > > > Further more, now I see debian-hvm guest boots up. But it hangs at > > 'Starting MTA'. > > Is MTA necessary? > > Not really, but it's part of the standard Debian installation. > > If it is hanging then that usually indicates something is wrong with > networking, either connectivity or DNS etc. Removing the MTA would simply > be working around that underlying issue Do you know how to disable it? seems it is not a service? > > IOW patches to remove the MTA would likely not be accepted. I see. Thanks for remind. > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
Further more, now I see debian-hvm guest boots up. But it hangs at 'Starting MTA'. Is MTA necessary? > -Original Message----- > From: Hu, Robert > Sent: Friday, July 31, 2015 4:02 PM > To: 'Ian Campbell'; ian.jack...@eu.citrix.com; wei.l...@citrix.com > Cc: xen-devel@lists.xen.org > Subject: RE: OSSTest -- debian-hvm-install, how to see the progress of guest > auto installation > > > -Original Message- > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > Sent: Friday, July 31, 2015 3:53 PM > > To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com > > Cc: xen-devel@lists.xen.org > > Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of > guest > > auto installation > > > > On Fri, 2015-07-31 at 07:20 +, Hu, Robert wrote: > > > Hi, > > > > > > During the hvm guest auto installation, how can I inspect its progress? > > > > It's serial console is logged to the qemu-dm log, something like > > /var/log/xen/qemu-dm-$guestname.log I think. > > > > > Currently I encountered some problems during hvm auto-installation; > > > after waited long time, several minutes, I vnc to it, it is black screen. > > > > Right, I think that's expected because the installer is running on the > > serial console now. > > > > Currently the qemu-dm log is a mess of ANSI escape codes. If you "cat > > /var/log/..." then your terminal will decode it and show the last thing on > > the screen (hopefully an error dialog). > Aha, fortunately, just found 'tail -f ...' output formatted ANSI chart; I can > see its progress now. > > > > My series "fixes to ts-debian-hvm-install" posted to xen-devel on Monday > > incorporates a switch to using DEBIAN_FRONTEND=text which produces a > > more > > useful text log from the installer (the same as is used for host kernel > > today). > > > > > > > > I'm using debian 7.2 for guest installation. And I saw Ian C. 's patch > > > commit c60b6d20b0fd29836a224fdaf9f0d06272144b46 > > > Author: Ian Campbell > > > Date: Mon Jul 6 14:45:12 2015 +0100 > > > > > > ts-debian-hvm-install: Arrange for installed guest to use a serial > > > console > > > > > > So that the guest boot will be logged somewhere useful (the > > qemu-dm > > > log). > > > > > > It still seems to pickup a "quiet" from somewhere, so it's not as > > > useful as it might be, but it is an improvement. > > > > > > debian 7.2 shall using kernel < 3.15, > > > > Debian 7 (and all point releases) is using a 3.2 kernel. > > > > > not sure if this commit causes the problem I'm meeting. > > > > This commit will have changed where the guest console log will go but I > > don't expect it to have caused whatever the underlying problem you are > > seeing is. > > > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
> -Original Message- > From: Wei Liu [mailto:wei.l...@citrix.com] > Sent: Friday, July 31, 2015 3:51 PM > To: Hu, Robert > Cc: Ian Campbell; ian.jack...@eu.citrix.com; wei.l...@citrix.com; > xen-devel@lists.xen.org > Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of guest > auto installation > > On Fri, Jul 31, 2015 at 07:20:46AM +, Hu, Robert wrote: > > Hi, > > > > During the hvm guest auto installation, how can I inspect its progress? > > Currently I encountered some problems during hvm auto-installation; > > after waited long time, several minutes, I vnc to it, it is black screen. > > > > I'm using debian 7.2 for guest installation. And I saw Ian C. 's patch > > commit c60b6d20b0fd29836a224fdaf9f0d06272144b46 > > Author: Ian Campbell > > Date: Mon Jul 6 14:45:12 2015 +0100 > > > > ts-debian-hvm-install: Arrange for installed guest to use a serial > console > > > > So that the guest boot will be logged somewhere useful (the > qemu-dm > > log). > > > > It still seems to pickup a "quiet" from somewhere, so it's not as > > useful as it might be, but it is an improvement. > > > > debian 7.2 shall using kernel < 3.15, not sure if this commit causes the > problem > > I'm meeting. > > > > Anyway, I need to look into its auto-installation process. > > > > /var/log/xen/qemu-blah logs? Seems it works for me. Thanks Wei. > > Wei. > > > Best Regards, > > Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Friday, July 31, 2015 3:53 PM > To: Hu, Robert; ian.jack...@eu.citrix.com; wei.l...@citrix.com > Cc: xen-devel@lists.xen.org > Subject: Re: OSSTest -- debian-hvm-install, how to see the progress of guest > auto installation > > On Fri, 2015-07-31 at 07:20 +, Hu, Robert wrote: > > Hi, > > > > During the hvm guest auto installation, how can I inspect its progress? > > It's serial console is logged to the qemu-dm log, something like > /var/log/xen/qemu-dm-$guestname.log I think. > > > Currently I encountered some problems during hvm auto-installation; > > after waited long time, several minutes, I vnc to it, it is black screen. > > Right, I think that's expected because the installer is running on the > serial console now. > > Currently the qemu-dm log is a mess of ANSI escape codes. If you "cat > /var/log/..." then your terminal will decode it and show the last thing on > the screen (hopefully an error dialog). Aha, fortunately, just found 'tail -f ...' output formatted ANSI chart; I can see its progress now. > > My series "fixes to ts-debian-hvm-install" posted to xen-devel on Monday > incorporates a switch to using DEBIAN_FRONTEND=text which produces a > more > useful text log from the installer (the same as is used for host kernel > today). > > > > > I'm using debian 7.2 for guest installation. And I saw Ian C. 's patch > > commit c60b6d20b0fd29836a224fdaf9f0d06272144b46 > > Author: Ian Campbell > > Date: Mon Jul 6 14:45:12 2015 +0100 > > > > ts-debian-hvm-install: Arrange for installed guest to use a serial > > console > > > > So that the guest boot will be logged somewhere useful (the > qemu-dm > > log). > > > > It still seems to pickup a "quiet" from somewhere, so it's not as > > useful as it might be, but it is an improvement. > > > > debian 7.2 shall using kernel < 3.15, > > Debian 7 (and all point releases) is using a 3.2 kernel. > > > not sure if this commit causes the problem I'm meeting. > > This commit will have changed where the guest console log will go but I > don't expect it to have caused whatever the underlying problem you are > seeing is. > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] OSSTest -- debian-hvm-install, how to see the progress of guest auto installation
Hi, During the hvm guest auto installation, how can I inspect its progress? Currently I encountered some problems during hvm auto-installation; after waited long time, several minutes, I vnc to it, it is black screen. I'm using debian 7.2 for guest installation. And I saw Ian C. 's patch commit c60b6d20b0fd29836a224fdaf9f0d06272144b46 Author: Ian Campbell Date: Mon Jul 6 14:45:12 2015 +0100 ts-debian-hvm-install: Arrange for installed guest to use a serial console So that the guest boot will be logged somewhere useful (the qemu-dm log). It still seems to pickup a "quiet" from somewhere, so it's not as useful as it might be, but it is an improvement. debian 7.2 shall using kernel < 3.15, not sure if this commit causes the problem I'm meeting. Anyway, I need to look into its auto-installation process. Best Regards, Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Status of OSSTest Nested virt test case (Was: Xen 4.6 Development Update (five months reminder, 5 WEEKS TO FREEZE))
> -Original Message- > From: wei.l...@citrix.com [mailto:wei.l...@citrix.com] > Sent: Friday, June 5, 2015 9:54 PM > > Hi all > > We are now four months into 4.6 development window. This is an email to keep > track of all the patch series I gathered. It is by no means complete and / or > acurate. Feel free to reply this email with new projects or correct my > misunderstanding. > > = Timeline = > > We are planning on a 9-month release cycle, but we could also release a bit > earlier if everything goes well (no blocker, no critical bug). > > * Development start: 6 Jan 2015 > <=== We are here ===> > * Feature Freeze: 10 Jul 2015 > * RCs: TBD > * Release Date: 9 Oct 2015 (could release earlier) > > == OSSTEST == > > > * Nested virt test case > > * v8 posted (fair) > - Robert Hu > V11 posted. Now 4 patches get committed. Remaining 4 patches pending in wait list for maintainer's review. (3 of the 4 already got Acked before) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (four months reminder)
> -Original Message- > From: wei.l...@citrix.com [mailto:wei.l...@citrix.com] > Sent: Wednesday, May 13, 2015 1:02 PM > To: xen-de...@lists.xenproject.org; White, Edmund H; > xumengpa...@gmail.com; dgol...@seas.upenn.edu; jtwea...@hawaii.edu; > oleksandr.dmytrys...@globallogic.com; cheg...@amazon.de; > tamas.leng...@zentific.com; daniel.ki...@oracle.com; > george.dun...@eu.citrix.com; rcojoc...@bitdefender.com; > yu.c.zh...@linux.intel.com; Wang, Wei W; Wu, Feng; dario.faggi...@citrix.com; > ross.lagerw...@citrix.com; malcolm.cross...@citrix.com; Chen, Tiejun; > boris.ostrov...@oracle.com; elena.ufimts...@oracle.com; > vijaya.ku...@caviumnetworks.com; parth.di...@linaro.org; > ian.campb...@citrix.com; andrii.tseglyts...@globallogic.com; > suravee.suthikulpa...@amd.com; manishjaggi@gmail.com; > vijay.kil...@gmail.com; andrew.coop...@citrix.com; vkuzn...@redhat.com; > ian.jack...@eu.citrix.com; dsl...@verizon.com; cy...@suse.com; > jgr...@suse.com; o...@aepfle.de; we...@cn.fujitsu.com; > guijianf...@cn.fujitsu.com; yan...@cn.fujitsu.com; david.vra...@citrix.com; > bob@oracle.com; roger@citrix.com; eshel...@pobox.com; > wei.l...@citrix.com; Dong, Eddie; julien.gr...@citrix.com; > anthony.per...@citrix.com; tal...@gmail.com; > artem.myga...@globallogic.com; Hu, Robert; konrad.w...@oracle.com; > julien.gr...@linaro.org; fabio.fant...@m2r.biz; chao.p.p...@linux.intel.com; > kai.hu...@linux.intel.com; wei.l...@citrix.com; edgar.igles...@gmail.com; > frediano.zig...@huawei.com; ard.biesheu...@linaro.org; Xu, Quan; > oleksandr.tyshche...@globallogic.com > Subject: Xen 4.6 Development Update (four months reminder) > > (Note, please trim your quotes when replying, and also trim the CC list if > necessary. You might also consider changing the subject line of your reply to > "Status of (Was: Xen 4.6 Development Update (X months reminder)") > > Hi all > > We are now four months into 4.6 development window. This is an email to keep > track of all the patch series I gathered. It is by no means complete and / or > acurate. Feel free to reply this email with new projects or correct my > misunderstanding. > > = Timeline = > > We are planning on a 9-month release cycle, but we could also release a bit > earlier if everything goes well (no blocker, no critical bug). > > * Development start: 6 Jan 2015 > <=== We are here ===> > * Feature Freeze: 10 Jul 2015 > * RCs: TBD > * Release Date: 9 Oct 2015 (could release earlier) > > The RCs and release will of course depend on stability and bugs, and > will therefore be fairly unpredictable. > > Bug-fixes, if Acked-by by maintainer, can go anytime before the First > RC. Later on we will need to figure out the risk of regression/reward > to eliminate the possiblity of a bug introducing another bug. > > = Prognosis = > > The states are: none -> fair -> ok -> good -> done > > none - nothing yet > fair - still working on it, patches are prototypes or RFC > ok - patches posted, acting on review > good - some last minute pieces > done - all done, might have bugs > > = Bug Fixes = > > Bug fixes can be checked in without a freeze exception throughout the > freeze, unless the maintainer thinks they are particularly high > risk. In later RC's, we may even begin rejecting bug fixes if the > broken functionality is small and the risk to other functionality is > high. > > Document changes can go in anytime if the maintainer is OK with it. > > These are guidelines and principles to give you an idea where we're coming > from; if you think there's a good reason why making an exception for you will > help us make Xen better than not doing so, feel free to make your case. > > == Hypervisor == > > * Alternate p2m: support multiple copies of host p2m (ok) > - Ed White > > * Improve RTDS scheduler (none) >Change RTDS from quantum driven to event driven > - Dagaen Golomb, Meng Xu > > * Credit2: introduce per-vcpu hard and soft affinity (good) > - Justin T. Weaver > > * sndif: add API for para-virtual sound (fair) >v7 posted > - Oleksandr Dmytryshyn > > * gnttab: improve scalability (good) >v5 posted > - Christoph Egger > > * Display IO topology when PXM data is available (good) >v7 posted > - Boris Ostrovsky > > * Clean-up of mem-event subsystem (good) >v9 posted > - Tamas K Lengyel > > * Xen multiboot2-EFI support (fair) >See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html >RFC posted > - Daniel Kiper > > * Credit2 production ready (none) >cpu reservation > - George Dunlap > >
Re: [Xen-devel] [OSSTEST Nested PATCH v8 4/7] Changes on test step of Debian hvm guest install
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Thursday, April 23, 2015 2:53 PM
> To: Hu, Robert
> Cc: Pang, LongtaoX; xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
> wei.l...@citrix.com
> Subject: Re: [OSSTEST Nested PATCH v8 4/7] Changes on test step of Debian
> hvm guest install
>
> On Thu, 2015-04-23 at 13:59 +0800, Robert Hu wrote:
> > On Tue, 2015-04-21 at 11:28 +0100, Ian Campbell wrote:
> > > On Mon, 2015-04-13 at 17:19 -0400, longtao.pang wrote:
> > > > 1. Increase disk size to accommodate to nested test requirement.
> > > > 2. Since 'Debain-xxx-.iso' image will be stored in rootfs of L1 guest,
> > > > therefore needs more disk capacity, increase root partition size in
> > > > preseed generation.
> > > > 3. In L1 installation context, assign more memory to it; Since it
> > > > acts as a nested hypervisor anyway.
> > > > 4. Comment out CDROM entry in sources.list to make HTTP URL entry
> > > > available for L1 hvm guest.
> > > > 5. Enable nestedhvm feature in ExtraConfig for nested job.
> > > >
> > > > Signed-off-by: longtao.pang
> > > > ---
> > > > Changes in v8:
> > > > 1. Update a conventional way to comment out CDROM entry in
> sources.list.
> > > > 2. Enable nestedhvm feature only for the nested job.
> > > > 3. Set nested disk and memroy size to be driven from runvars in
> > > > 'ts-debian-hvm-install'.
> > > > ---
> > > > ts-debian-hvm-install |9 ++---
> > > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
> > > > index cfd5144..13009d0 100755
> > > > --- a/ts-debian-hvm-install
> > > > +++ b/ts-debian-hvm-install
> > > > @@ -36,7 +36,7 @@ our $ho= selecthost($whhost);
> > > >
> > > > # guest memory size will be set based on host free memory, see below
> > > > our $ram_mb;
> > > > -our $disk_mb= 1;
> > > > +our $disk_mb= $r{'nested_disk'} ? $r{'nested_disk'} : 1;
> > >
> > > This shouldn't hardcode 'nested' here, but use the guest ident. (nested
> > > is the wrong name now anyway I think, since it is nestedl1 in this
> > > iteration, which is why we avoid such hardcoding)
> > Right, we shall store this runvar with name of ${l1_ident}_disksize in
> > ts-nested-setup.
>
> This is the sort of thing which needs to be done from make-flight, not
> ts-*.
>
Agree.
> > > So you should arrange to do this somewhere that $gho is in scope and use
> > > guest_var($gho, 'disk', 1). $gho is in scope in $prep where $disk_mb
> > > is used and AFAICT it is only used in that function, so I think you can
> > > move this to a local variable
> > yes, it is supposed to be local of prep(). However, look at other ts-*
> > (ts-debian-install, ts-freebsd-install, etc.), $disk_mb is defined
> > 'our'. They seems to be in alliance, are we going to it specifically in
> > ts-debian-hvm-install? or in some future day, we change these
> > ts-*-install in another patch series?
>
> If/when the other ts-*-install need to support sizing the disk based on
> a runvar they would need similar changes. If you want to make those now
> for consistency then that would be great, but I don't think it needs to
> be mandatory.
I would prefer to leaving $disk_mb 'our' at present; to be consistent with other
ts-*-installs.
Meanwhile do the overriding by runvar value in prepareguest().
Are you OK with this?
>
> > To use guest_var(), it needs $gho in scope as you said. But in prep() we
> > can see until prepareguest() returns, we don't have $gho in scope, while
> > prepareguest() needs $disk_mb as input. So here we get into a loop.
> > I think we shall in prepareguest(), check if $r{${guest_ident}_disksize}
> > is defined, then override passed in $mb value. How would you like this?
>
> Hrm, perhaps this behaviour ought to be pushed down into prepareguest
> itself, IOW the existing $mb argument to that function would become the
> default, but the runvar would take precedence f set? That would mean
> that all ts-*-install would gain support the runvar.
>
> Ian, what do you think of this?
>
> The alternative would be to use $r{${gn}_disksize}.
>
> > >
> > > > more_prepareguest_hvm($ho,$gho, $ram_mb, $disk_mb,
> > > >O
Re: [Xen-devel] [OSSTEST Nested PATCH v8 3/7] Edit some APIs in TestSupport.pm for nested test
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, April 22, 2015 8:50 PM
> To: Ian Campbell
> Cc: Pang, LongtaoX; xen-devel@lists.xen.org; wei.l...@citrix.com; Hu, Robert
> Subject: Re: [OSSTEST Nested PATCH v8 3/7] Edit some APIs in TestSupport.pm
> for nested test
>
> Ian Campbell writes ("Re: [OSSTEST Nested PATCH v8 3/7] Edit some APIs in
> TestSupport.pm for nested test"):
> > It will, I think, need to be integrated with the existing assignment to
> > $ho->{Ip} in select host, so something like:
> >
> > if ( $r{"${ident}_ip"} ) {
> > $ho->{Ip}= $r{"${ident}_ip"};
> > } else {
> > $ho->{Ip}= $ho->{IpStatic};
> > }
>
> Yes.
Yes, otherwise the code would go 'die' somewhere later.
>
> > or perhaps:
> >
> > $ho->{Ip} = $r{"${ident}_ip"} ? $r{"${ident}_ip"} : $ho->{IpStatic};
>
> The shortest way to spell this is to use //, eg:
>
> $ho->{Ip} = $r{"${ident}_ip"} // $ho->{IpStatic};
Ah, yes!
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v7 1/6] parsing grub which has 'submenu' primitive
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, March 31, 2015 9:44 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; wei.l...@citrix.com;
> Hu, Robert
> Subject: Re: [OSSTEST Nested PATCH v7 1/6] parsing grub which has 'submenu'
> primitive
>
> On Fri, 2015-03-27 at 19:06 -0400, longtao.pang wrote:
> > From a hvm kernel build from Linux stable Kernel tree,
> > the auto generated grub2 menu will have 'submenu' primitive, upon the
> > 'menuentry' items. Xen boot entries will be grouped into a submenu. This
> > patch adds capability to support such grub formats.
> >
> > Signed-off-by: longtao.pang
> > ---
> > Changes in v7:
> > Remove the reformatting change for Debian.pm and keep the original format.
>
> Thank you.
>
> > ---
> > Osstest/Debian.pm | 21 -
> > 1 file changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> > index 6784024..35163a0 100644
> > --- a/Osstest/Debian.pm
> > +++ b/Osstest/Debian.pm
> > @@ -398,10 +398,18 @@ sub setupboot_grub2 () {
> >
> > my $count= 0;
> > my $entry;
> > +my $submenu;
> > while (<$f>) {
> > next if m/^\s*\#/ || !m/\S/;
> > if (m/^\s*\}\s*$/) {
> > -die unless $entry;
> > +die unless $entry || $submenu;
> > +if(!defined $entry && defined $submenu){
> > +logm("Met end of a submenu starting from ".
> > +"$submenu->{StartLine}. ".
> > +"Our want kern is $want_kernver");
> > +$submenu=undef;
> > +next;
> > +}
> > my (@missing) =
> > grep { !defined $entry->{$_} }
> > (defined $xenhopt
> > @@ -432,21 +440,24 @@ sub setupboot_grub2 () {
> > $entry= { Title => $1, StartLine => $., Number =>
> $count };
> > $count++;
> > }
> > -if (m/^\s*multiboot\s*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
> > +if (m/^submenu\s+[\'\"](.*)[\'\"].*\{\s*$/) {
> > +$submenu={ StartLine =>$.};
> > +}
>
> This looks reasonable enough to support a single nesting, I suppose we
> can leave more deeply nested submenus for another time.
>
> So in that regard this patch looks ok to me.
>
> > +if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\S+)/) {
> > die unless $entry;
> > $entry->{Hv}= $1;
> > }
> > -if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
> > +if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
>
> What are these changes all about? I think they must be unrelated to the
> use of submenu (perhaps relate to having a separate /boot or not?). If
> so then please do in a separate patch.
>
You're right. This has nothing to do with submenu.
Going to separate it out in another patch.
> If this is somehow to do with submenu then please explain how/why in the
> commit log.
>
> BTW, your regex as it stand will accept /boot/boot/boot/boot/vmlinuz. I
> think you maybe meant to add "(?:\/boot)?" to match zero or one
> occurrences?
Yes, this is a potential bug. Thanks for point out!
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Monday, March 23, 2015 5:50 PM > To: Hu, Robert > Cc: Pang, LongtaoX; xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; > wei.l...@citrix.com > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport > APIs > > On Mon, 2015-03-23 at 06:31 +, Hu, Robert wrote: > > > -Original Message- > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > Sent: Friday, March 20, 2015 8:20 PM > > > To: Pang, LongtaoX > > > Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; > wei.l...@citrix.com; > > > Hu, Robert > > > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport > > > APIs > > > > > > On Fri, 2015-03-20 at 12:09 +, Pang, LongtaoX wrote: > > > > Add xen-devel in mail loop. > > > > > > Here is what I wrong in reply to the private version without noticing > > > that it was private. > > > > > > On Fri, 2015-03-20 at 11:59 +, Pang, LongtaoX wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > > > Sent: Friday, March 20, 2015 12:27 AM > > > > > To: Pang, LongtaoX > > > > > Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; > > > wei.l...@citrix.com; > > > > > Hu, Robert > > > > > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some > testsupport > > > > > APIs > > > > > > > > > > On Tue, 2015-03-17 at 14:16 -0400, longtao.pang wrote: > > > > > > From: "longtao.pang" > > > > > > > > > > > > 1. Designate vif model to 'e1000', otherwise, with default device > > > > > > model, the L1 eth0 interface disappear, hence xenbridge cannot work. > > > > > > Maybe this limitation can be removed later after some fix it. For > > > > > > now, > > > > > > we have to accomodate to it. > > > > > > > > > > You have done this unconditionally, which means it affects all guests. > > > > > You need to make this configurable by the caller, probably by > > > > > plumbing it > > > > > through in $xopts (a hash of extra options). > > > > > > > > > > I see now you were told this last time around by Ian J, please don't > > > > > just > > > resend > > > > > such things without change either fix them, make an argument for doing > it > > > your > > > > > way or ask for clarification if you don't understand the requested > change. > > > > > > > > > > > > > Thanks for your advice, I will try it. But, do you have any idea about > > > > below > > > issue that confused me? > > > > After L1 Debian hvm guest boot into XEN kernel, it failed to load 8139cp > > > driver(Realtek RTL-8139), > > > > that cause L1 guest's network unavailable, and I have to specify > > > 'model=e1000' to make L1's network available. > > > > The issue does not exist in RHEL6u5 OS(L0 and L1 are both RHEL6u5 OS). > > > > > > Could just be a bug in Debian's kernel. Without more information it's > > > rather hard to say. > > > > > Yes, it's hard to identify the root cause and we don't plan to dig out why > > here. > > How about we move this designation to ts-nested-setup, after first step the > normal > > guest was created, we modify guest's configuration then? > > Make it an option to the function which creates the configuration in the > first place. Quoting myself from earlier in this very thread: Then we still need to designate to use e1000 device somewhere; say, in ts-nested-setup, we store this designation in runvar. Then when creating the config, according to your proposal, we plumbing such designation through $xopts, since we see it in runvar. Are you OK with such implementation? But if like above, I would prefer to altering/manipulating guest configation directly in ts-nested-setup after normal guest is setup. Since this is more simple and constrained to nested case only. > > > You have done this unconditionally, which means it affects all guests. > > You need to make this configurable by the caller, probably by plumbing > > it through in $xopts (a hash of extra options). > > > The prer
Re: [Xen-devel] [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Monday, March 23, 2015 5:50 PM > To: Hu, Robert > Cc: Pang, LongtaoX; xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; > wei.l...@citrix.com > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport > APIs > > On Mon, 2015-03-23 at 06:31 +, Hu, Robert wrote: > > > -Original Message- > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > Sent: Friday, March 20, 2015 8:20 PM > > > To: Pang, LongtaoX > > > Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; > wei.l...@citrix.com; > > > Hu, Robert > > > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport > > > APIs > > > > > > On Fri, 2015-03-20 at 12:09 +, Pang, LongtaoX wrote: > > > > Add xen-devel in mail loop. > > > > > > Here is what I wrong in reply to the private version without noticing > > > that it was private. > > > > > > On Fri, 2015-03-20 at 11:59 +, Pang, LongtaoX wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > > > Sent: Friday, March 20, 2015 12:27 AM > > > > > To: Pang, LongtaoX > > > > > Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; > > > wei.l...@citrix.com; > > > > > Hu, Robert > > > > > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some > testsupport > > > > > APIs > > > > > > > > > > On Tue, 2015-03-17 at 14:16 -0400, longtao.pang wrote: > > > > > > From: "longtao.pang" > > > > > > > > > > > > 1. Designate vif model to 'e1000', otherwise, with default device > > > > > > model, the L1 eth0 interface disappear, hence xenbridge cannot work. > > > > > > Maybe this limitation can be removed later after some fix it. For > > > > > > now, > > > > > > we have to accomodate to it. > > > > > > > > > > You have done this unconditionally, which means it affects all guests. > > > > > You need to make this configurable by the caller, probably by > > > > > plumbing it > > > > > through in $xopts (a hash of extra options). > > > > > > > > > > I see now you were told this last time around by Ian J, please don't > > > > > just > > > resend > > > > > such things without change either fix them, make an argument for doing > it > > > your > > > > > way or ask for clarification if you don't understand the requested > change. > > > > > > > > > > > > > Thanks for your advice, I will try it. But, do you have any idea about > > > > below > > > issue that confused me? > > > > After L1 Debian hvm guest boot into XEN kernel, it failed to load 8139cp > > > driver(Realtek RTL-8139), > > > > that cause L1 guest's network unavailable, and I have to specify > > > 'model=e1000' to make L1's network available. > > > > The issue does not exist in RHEL6u5 OS(L0 and L1 are both RHEL6u5 OS). > > > > > > Could just be a bug in Debian's kernel. Without more information it's > > > rather hard to say. > > > > > Yes, it's hard to identify the root cause and we don't plan to dig out why > > here. > > How about we move this designation to ts-nested-setup, after first step the > normal > > guest was created, we modify guest's configuration then? > > Make it an option to the function which creates the configuration in the > first place. Quoting myself from earlier in this very thread: > > > You have done this unconditionally, which means it affects all guests. > > You need to make this configurable by the caller, probably by plumbing > > it through in $xopts (a hash of extra options). > > > The prerequisite here is to get configuration reloaded when guest 'reboot'. > Do you > > know any approach to achieve this? seems 'restart' action on reboot event > > doesn’t read new configuration. > > Look at hos ts-debian-hvm-install does it, it uses OnReboot=preserve > when calling more_prepareguest_hvm, then it waits for the guest to > reboot (which ends up preserved), then it manually destroys it, rewrites > the config and restarts the gue
Re: [Xen-devel] [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Friday, March 20, 2015 8:20 PM > To: Pang, LongtaoX > Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; wei.l...@citrix.com; > Hu, Robert > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport > APIs > > On Fri, 2015-03-20 at 12:09 +, Pang, LongtaoX wrote: > > Add xen-devel in mail loop. > > Here is what I wrong in reply to the private version without noticing > that it was private. > > On Fri, 2015-03-20 at 11:59 +, Pang, LongtaoX wrote: > > > > > > > -Original Message- > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > Sent: Friday, March 20, 2015 12:27 AM > > > To: Pang, LongtaoX > > > Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; > wei.l...@citrix.com; > > > Hu, Robert > > > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport > > > APIs > > > > > > On Tue, 2015-03-17 at 14:16 -0400, longtao.pang wrote: > > > > From: "longtao.pang" > > > > > > > > 1. Designate vif model to 'e1000', otherwise, with default device > > > > model, the L1 eth0 interface disappear, hence xenbridge cannot work. > > > > Maybe this limitation can be removed later after some fix it. For now, > > > > we have to accomodate to it. > > > > > > You have done this unconditionally, which means it affects all guests. > > > You need to make this configurable by the caller, probably by plumbing it > > > through in $xopts (a hash of extra options). > > > > > > I see now you were told this last time around by Ian J, please don't just > resend > > > such things without change either fix them, make an argument for doing it > your > > > way or ask for clarification if you don't understand the requested change. > > > > > > > Thanks for your advice, I will try it. But, do you have any idea about below > issue that confused me? > > After L1 Debian hvm guest boot into XEN kernel, it failed to load 8139cp > driver(Realtek RTL-8139), > > that cause L1 guest's network unavailable, and I have to specify > 'model=e1000' to make L1's network available. > > The issue does not exist in RHEL6u5 OS(L0 and L1 are both RHEL6u5 OS). > > Could just be a bug in Debian's kernel. Without more information it's > rather hard to say. > Yes, it's hard to identify the root cause and we don't plan to dig out why here. How about we move this designation to ts-nested-setup, after first step the normal guest was created, we modify guest's configuration then? The prerequisite here is to get configuration reloaded when guest 'reboot'. Do you know any approach to achieve this? seems 'restart' action on reboot event doesn’t read new configuration. > > > > > > 2. Since reboot L1 guest VM will take more time to boot up, we > > > > increase multi-times for reboot-confirm-booted if test nested job, and > > > > the multi value is stored as a runvar in 'ts-nested-setup' script. > > > > Added another function 'guest_editconfig_cd' and expose it, this > > > > function bascically changes guest boot device sequence, alter its > > > > on_reboot behavior to restart and enabled nestedhvm feature. > > > > > > This looks like two items run together? > > > > > > The multi_reboot_time thing sounds ok, but it should be called > > > reboot_time_factor or something like that. In fact I see that Ian > > > suggested > > > previously that it should have the host ident in it, that makes sense to > > > me. > > > > > I will try it. Also, how do you handle below question after reboot > > host OS during running OSSTest job? > > After finishing L0 and L1 host installation, the OSs will take a lot > > time(about 150s) to start MTA service and NTP service. I know that, > > the poll_loop timeout is 40s of 'reboot-confirm-booted', > > that's why timeout happened when calling 'host_reboot' function after reboot > host OS. > > I'm afraid I don't know what you are asking here. > > > > The editconfig_cd thing -- yet another thing which Ian questioned and > > > which > it > > > was agreed you would change but you haven't. > > > > > For this question, I have sent a mail about it.(2015-03-04) > > After finishing L1 guest VM installation, we need to change L1 guest bo
Re: [Xen-devel] [PATCH OSSTEST 11/12] Changes on test step of debain hvm guest install
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Monday, February 16, 2015 6:17 PM
> To: Hu, Robert
> Cc: Ian Jackson; xen-devel@lists.xen.org; jfeh...@suse.com;
> wei.l...@citrix.com; ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 11/12] Changes on test step of debain hvm guest
> install
>
> On Sun, Feb 15, 2015 at 09:43:33AM +, Hu, Robert wrote:
> > > -Original Message-
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > Sent: Friday, February 13, 2015 8:03 PM
> > > To: Hu, Robert
> > > Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> > > ian.campb...@citrix.com; Pang, LongtaoX
> > > Subject: RE: [PATCH OSSTEST 11/12] Changes on test step of debain hvm
> guest
> > > install
> > >
> > > Hu, Robert writes ("RE: [PATCH OSSTEST 11/12] Changes on test step of
> debain
> > > hvm guest install"):
> > > > [Ian]
> > > > > Firstly, can you please reformat your commit message so that the
> > > > > individual points are separated out into paragraphs. But I think
> > > > > actually that probably some of this wants to go into different commits
> > > > > (and perhaps different places).
> > > >
> > > > You mean dividing this patch into more pieces/commits?
> > >
> > > Yes. At least, that might be a good idea. I'm finding it a bit
> > > difficult to see the wood for the trees.
> > >
> > > I can, however, offer some general guidelines on when to split/merge:
> > >
> > > * Changes must be in the same commit if they are mutually
> > >interdependent, so that the code only works before all of them or
> > >after all of them.
> > >
> > > * Each commit should be the smallest piece which is a coherent and
> > >comprehensible alteration. (Although small changes might be put
> > >together in the same commit, especially if they are conceptually
> > >very similar and/or aren't textually interleaved.)
> > >
> > > * On ordering: it should not normally be necessary to read subsequent
> > >commits to understand earlier ones. So generally that means that
> > >new interfaces should be introduced (with any necessary doc
> > >comments, etc.) earlier and used later.
> > >
> > > * It is a good idea to split out refactoring operations, and code
> > >motion, each into their own patch. That makes it much easier to
> > >review both the refactoring/motion (because it's much easier to
> > >look for unintentional functional changes), and the other patches
> > >(because they don't contain non-functional `noise'). When you do
> > >this, the refactoring/motion should clearly say what if any
> > >functional change is introduced. `No functional change' is the
> > >usual stock phrase for cases when it's true.
> > >
> > > > > I think this should look more like:
> > > > >
> > > > > +run-ts . = ts-debian-hvm-install + host + nested
> > > > > +run-ts . = ts-nested-setup + host + nested
> > > > > +run-ts . = ts-xen-install nested
> > > > > +run-ts . = ts-host-reboot nested
> > > > > +run-ts . = ts-debian-hvm-install nested nested2
> > > > >
> > > > OK. Since we could only try to learn your design arch/hierarchy of
> > > > osstest,
> > > > through code reading, such as terms of test job, test step, recipe,
> > > > etc.,
> > > > we inevitably made some misunderstanding or unawareness.
> > >
> > For example, we don't understand the above why some (the first 2)
> > passing params to ts-* with '+' and the latter 2 doesn't?
>
> sg-run-job is written in tcl. I don't claim to be an expert on this
> language. I spent ~1.5 hour to grasp the basic and was able to decrypt
> this script. The manual and tutorial on tcl official website are quite
> helpful.
>
> All those parameters are passed to the ts-* script. The "+" sign is a
> toggle to control if it should appear in the final report. Have a look
> at spawn-ts, or more preciously, around L123 (it may vary depending on
> your OSSTest tree changeset).
>
> If you look at the actual output of you script, you will see all
> parameters are passed to the script.
Thanks for your help!
I have also spent days on the tcl basic study hal
Re: [Xen-devel] [PATCH OSSTEST 11/12] Changes on test step of debain hvm guest install
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, February 13, 2015 8:03 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: RE: [PATCH OSSTEST 11/12] Changes on test step of debain hvm guest
> install
>
> Hu, Robert writes ("RE: [PATCH OSSTEST 11/12] Changes on test step of debain
> hvm guest install"):
> > [Ian]
> > > Firstly, can you please reformat your commit message so that the
> > > individual points are separated out into paragraphs. But I think
> > > actually that probably some of this wants to go into different commits
> > > (and perhaps different places).
> >
> > You mean dividing this patch into more pieces/commits?
>
> Yes. At least, that might be a good idea. I'm finding it a bit
> difficult to see the wood for the trees.
>
> I can, however, offer some general guidelines on when to split/merge:
>
> * Changes must be in the same commit if they are mutually
>interdependent, so that the code only works before all of them or
>after all of them.
>
> * Each commit should be the smallest piece which is a coherent and
>comprehensible alteration. (Although small changes might be put
>together in the same commit, especially if they are conceptually
>very similar and/or aren't textually interleaved.)
>
> * On ordering: it should not normally be necessary to read subsequent
>commits to understand earlier ones. So generally that means that
>new interfaces should be introduced (with any necessary doc
>comments, etc.) earlier and used later.
>
> * It is a good idea to split out refactoring operations, and code
>motion, each into their own patch. That makes it much easier to
>review both the refactoring/motion (because it's much easier to
>look for unintentional functional changes), and the other patches
>(because they don't contain non-functional `noise'). When you do
>this, the refactoring/motion should clearly say what if any
>functional change is introduced. `No functional change' is the
>usual stock phrase for cases when it's true.
>
> > > I think this should look more like:
> > >
> > > +run-ts . = ts-debian-hvm-install + host + nested
> > > +run-ts . = ts-nested-setup + host + nested
> > > +run-ts . = ts-xen-install nested
> > > +run-ts . = ts-host-reboot nested
> > > +run-ts . = ts-debian-hvm-install nested nested2
> > >
> > OK. Since we could only try to learn your design arch/hierarchy of osstest,
> > through code reading, such as terms of test job, test step, recipe, etc.,
> > we inevitably made some misunderstanding or unawareness.
>
For example, we don't understand the above why some (the first 2)
passing params to ts-* with '+' and the latter 2 doesn't?
> Indeed. That's fine.
>
> > Fortunately getting closer and closer to your mind now.
>
> I think so, yes. Of course if you think there is something in the
> current design/architecture which is wrong or broken, then please do
> say so. We're aware it's not perfect.
>
> Likewise, if something I suggest doesn't make sense or doesn't seem to
> work well, please do feel free to contradict me. We're relying on
> your judgement as well as mine :-).
>
> > Will follow your recipe composing above.
>
> So, yes, please, if you agree that this is a good way to go. I think
> it will reduce the amount of nested-specific code elsewhere.
>
> > > I don't know why you need to use a dedicated VG for your nested
> > > guests's L2 guests - please explain - but if you do, probably
> > > ts-nested-setup could set it up.
> >
> > The existing ts-debian-hvm-install code presume host has vg set
> > for guest installation. To make minimal code change, we'd like
> > to imitate that presumption for L2's host.
>
> Strictly speaking, the existing ts-debian-hvm-install simply expects
> that the host has a VG. The existing ts-host-install code (in
> Debian.pm) sets up the VG (via preseed_create). So I think your
> problem is that ts-debian-hvm-install doesn't set up the guest with
> LVM for its filesystems ?
Yes
>
> I think it would be better to unify the d-i partman-auto/expert_recipe
> in Debian.pm with the one in ts-debian-hvm-install, and make all
> Debian HVM installations use LVM.
>
> Wei, do you agree ? (TBH maybe I should have asked Wei to do that
> when he introduced the new preseed setup
Re: [Xen-devel] [PATCH OSSTEST 06/12] Manipulate $ho IP assignment for nest L2 situation
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, February 11, 2015 10:59 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; jfeh...@suse.com;
> wei.l...@citrix.com; ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 06/12] Manipulate $ho IP assignment for nest L2
> situation
>
> Robert Ho writes ("[PATCH OSSTEST 06/12] Manipulate $ho IP assignment for
> nest L2 situation"):
> > In L2 installation context, its host (L1) IP address is not queried
> > from DNS, but from previous step of L1 installation, in which, L1 IP
> > is stored in run var.
>
> > -$ho->{IpStatic} = get_host_property($ho,'ip-addr');
> > +if ($name eq 'nested') {
>
> This is definitely the wrong test.
>
> It would be easier to read this series if you introduced the framework
> first, and then applied all the specific differences afterwards.
>
> Instead of keying off $name I think you probably need to make a
> variant of selecthost that takes an existing guest ($gho) and converts
> it into a useable host ($ho).
>
> It would probably be necessary to split out the bulk of the existing
> selecthost into a core function.
>
> I think you also want a general way to specify how the L1's host
> properties are set.
Good point! This is indeed my missing point, will fix this.
I didn't get the idea of host property in previous code reading.
Where can I get the idea of what 'host property' is? how it is supposed to
use? Any text I can find introducing it? Or you can give a little
hint on it? thanks.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 03/12] Designate vif device model to e1000
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, February 11, 2015 10:50 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 03/12] Designate vif device model to e1000
>
> Robert Ho writes ("[PATCH OSSTEST 03/12] Designate vif device model to
> e1000"):
> > Designate vif model to 'e1000', otherwise, with default
> > device model, the L1 eth0 interface disappear, hence xenbridge cannot
> work.
> > Maybe this limitation can be removed later after some fix it. For now, we
> > have to accomodate to it.
>
> I don't understand this, I'm afraid. Can you please explain the bug
> in more detail in the commit message ?
I didn't look into details. Just observed the phenomenon if not designate it as
e1000, in L1, we will not have eth0 visible, therefore bridge on it won't work.
As long as we designate vif to e1000, it works.
But this is not a problem in our test environment in
which we don't use Debian as nested Dom0. So I guess this is Debian-specific
bug.
>
> It is definitely not acceptable to change the default network card for
> all guests in prepareguest_part_xencfg. It would be OK to provide a
> guest-specific runvar to specify the guest network card, and it might
> be OK to set that in the nested-specific test job creation.
OK, will use this approach to walk around and for the consideration of
future test scope scaling.
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 05/12] Add and expose some testsupport APIs
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, February 11, 2015 10:54 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 05/12] Add and expose some testsupport APIs
>
> Robert Ho writes ("[PATCH OSSTEST 05/12] Add and expose some testsupport
> APIs"):
> > When install L2 guest, we will need to invoke
> > 'select_ether' to get guest MAC address. So here expose select_ether().
>
> I'm not sure whether you actually need to do this. I will look at the
> rest of your series to see why prepareguest() isn't suitable. But
> this part of the patch is fine in principle.
>
> > And
>
> These seem like two indepenedent patches. They should be split up.
>
> > also, we added another function 'guest_editconfig_cd' and expose it.
> > This function bascically changes guest boot device sequence and
> > alter its on_reboot behavior to restart.
>
> I don't understand why guest_editconfig_nocd isn't sufficient.
Em..., seems guest_editconfig_nocd can achieve my purpose as well.
I would try to reuse it in next sending.
I guess, originally I composed another function was to avoid the risk
of breaking down existing functions, given the situation I know little about
your
design mind. Now that we changed our mind to
reuse existing functions as much as possible, I should have eliminated
these old-time addings.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 02/12] Increase boot timer to accomodate to nest test
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, February 11, 2015 10:47 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 02/12] Increase boot timer to accomodate to nest
> test
>
> Robert Ho writes ("[PATCH OSSTEST 02/12] Increase boot timer to accomodate
> to nest test"):
> > In nested test case, guest boot will take more time.
> > Increase the timer to 200 seconds.
>
> Can we make this conditional somehow ?
>
> I think it should probably be picked up from a runvar.
>
> We don't currently have timeouts directly in runvars and we probably
> don't want them in make-flight. So perhaps we should have a runvar
> named after the host indicating that it is a nested virt host.
So how about reconsider this? I would suggest that just increase the
timer here, since, though it is increased, the timer gets return as long as
guest boots up, no impact to existing test cases.
>
> Obviously that would mean this patch would have to come later in the
> series. I'll have to look at the rest of the series to have a clearer
> idea what the right thing looks like.
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 07/12] For hvm guest configuration, config console to 'hvc0'
Best Regards,
Robert Ho
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Thursday, February 12, 2015 1:04 AM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 07/12] For hvm guest configuration, config
> console to 'hvc0'
>
> Robert Ho writes ("[PATCH OSSTEST 07/12] For hvm guest configuration, config
> console to 'hvc0'"):
> > ---
> > Osstest/TestSupport.pm | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > index c23bbc7..864805e 100644
> > --- a/Osstest/TestSupport.pm
> > +++ b/Osstest/TestSupport.pm
> > @@ -1753,7 +1753,11 @@ sub target_kernkind_check ($) {
> > if ($kernkind eq 'pvops') {
> > store_runvar($pfx."rootdev", 'xvda') if $isguest;
> > store_runvar($pfx."console", 'hvc0');
> > -} elsif ($kernkind !~ m/2618/) {
> > +}
> > +elsif ($kernkind eq 'hvm'){
> > +store_runvar($pfx."console", 'hvc0'); #nested hvm guest
> shall not append console=xvc0; I guess this applies to all hvm guests.
> > +}
> > +elsif ($kernkind !~ m/2618/) {
>
> I don't understand why this is necessary. Surely all the kernels here
> are pvops so the kernkind should be 'pvops' in all cases and the
> console will be set to hvc0 anyway ?
Oh, this is my mistake. Will revert.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 10/12] Compose the main body of test-nested test job.
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Thursday, February 12, 2015 1:07 AM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 10/12] Compose the main body of test-nested
> test job.
>
> Robert Ho writes ("[PATCH OSSTEST 10/12] Compose the main body of
> test-nested test job."):
> > Compose the main body of test-nested test job.
>
> Ah, this is what I was missing earlier. You really need to order this
> so that things come after things which depend on them.
>
> Typically:
> * cleanups
> * define new TestSupport facilities
> * define new ts-* scripts if any
> * define new recipies
> * updates to make-flight to define new jobs.
>
OK, will follow this order.
> > +proc need-hosts/test-nested {} {return host}
> > +proc run-job/test-nested {} {
> > +run-ts . = ts-debian-hvm-install + host + nested + nested_L1
>
> ts-debian-hvm-install takes only two arguments. You are passing 3.
> I guess this is in further patches...
sure:)
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 01/12] Add support of parsing grub which has 'submenu' primitive
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, February 13, 2015 2:32 AM
> To: Wei Liu
> Cc: Hu, Robert; xen-devel@lists.xen.org; jfeh...@suse.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 01/12] Add support of parsing grub which has
> 'submenu' primitive
>
> Wei Liu writes ("Re: [PATCH OSSTEST 01/12] Add support of parsing grub which
> has 'submenu' primitive"):
> > On Thu, Feb 12, 2015 at 02:01:59AM +, Hu, Robert wrote:
> > > Yes, this minor change just get 'parsemenu' subroutine capability of
> recognizing 'submenu'.
> > > The outer layer logic isn't affected.
> > > Actually, the Xen boot menuentry we choose, is inside a submenu. It works
> and /etc/default/grub
> > > is assigned properly.
>
> Great.
>
> > In any case this is a very useful improvement.
>
> Yes, indeed!
>
> > Out of interest what Linux are you running? If you're running Debian
> > and the overlay 20_linux_xen (inside $OSSTEST/overlay/etc/etc/grub.d) is
> > copied to your test host, there shouldn't be any submenu entries in your
> > grub.cfg, I think.
>
> I consider that a workaround (and I think so do you).
>
> So I think subject to the (rather daft) argument we are having over
> whitespace this is a really useful patch.
>
> > > > Can you please not adjust the whitespace ? osstest in general doesn't
> > > > have a requirement for any particular whitespace use, and certainly if
> > > > there are to be any whitespace changes they ought to be in a separate
> > > > patch.
> > >
> > > I adjust those because some one in last version's reply told us that
> > > osstest prefers white space substitution to tab,
>
> I'm sorry that we seem to be having a disagreement over this. That's
> not very helpful for you, I realise!
>
> I hope that whoever made those comments would agree that whitespace
> cleanups should at least be in a separate patch. So please when you
> resubmit can you split them out ?
Sure, will separate white space change and indentation adjustments out.
>
> I can't seem to find the email you refer to. Do you happen to be able
> to give me a reference ?
>
> > > and traditionally 4 white space of 1 tab. (This align with my
> > > previous coding experience as well)
>
> 4-character tabs are quite unusual in the Free Software world. 8 is
> usual.
>
> > > And I indeed find that this hunk of code doesn't looks well in my editor.
> > > Its unalignment increases difficulty of reading.
>
> Since evidently this is annoying to you I won't stand in the way of
> your effort to clean this up, even though I don't much care about it.
> So if you submit this as a separate patch I won't block it.
Thanks for your understanding.
>
> But maybe simply configuring your editor to use 8-character tabs will
> fix the problem for you ? That would be less work than preparing
> whitespace adjustment patches.
OK, will have a try first. :)
>
> Thanksw,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 12/12] Changes to test step of xen install
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, February 13, 2015 2:21 AM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; jfeh...@suse.com;
> wei.l...@citrix.com; ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 12/12] Changes to test step of xen install
>
> Robert Ho writes ("[PATCH OSSTEST 12/12] Changes to test step of xen
> install"):
> > This patch accomodates ts-xen-install to nested L1 xen installation
> > usage. Its change is relatively simpler than
> > ts-debain-hvm-install. We simply alter '$ho' usage to 'w_ho', which
> > is assigned to '$ho' in original L0 installation context, while
> > assigned to '$gho' in L1 Xen installation context.
>
> Certainly I think we should use ts-xen-install for installing Xen on
> the L1. But I think that ts-xen-install should probably think almost
> entirely about the L1 and $ho should be the L1.
>
> I think if you followed the suggestion for the structure that I made
> in my previous patch, very little of the changes here would be
> necessary.
>
> It's not clear to me that _anything_ would need to change in
> ts-xen-install, in fact. (Although I may be wrong.)
Going to read selecthost() and its relative callers deeper, I think you
are right.
What needs to be change is the selecthost() not xen install.
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 11/12] Changes on test step of debain hvm guest install
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Friday, February 13, 2015 2:17 AM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 11/12] Changes on test step of debain hvm guest
> install
>
> Robert Ho writes ("[PATCH OSSTEST 11/12] Changes on test step of debain hvm
> guest install"):
> > This patch is to make ts-debian-hvm-install accomodate
>
> Ah yes here is the meat.
>
> Firstly, can you please reformat your commit message so that the
> individual points are separated out into paragraphs. But I think
> actually that probably some of this wants to go into different commits
> (and perhaps different places).
You mean dividing this patch into more pieces/commits?
>
> > diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
> > index 37eade2..e905698 100755
> > --- a/ts-debian-hvm-install
> > +++ b/ts-debian-hvm-install
> > @@ -28,22 +28,30 @@ if (@ARGV && $ARGV[0] =~ m/^--stage(\d+)$/)
> { $stage=$1; shift @ARGV; }
> ...
> > +if ($nested eq 'nested_L1') {
> > +$gn ||= 'nested';
> > +$guesthost ||= "$gn.l1.osstest";
> > +} elsif ($nested eq 'nested_L2') {
> > +$whhost = 'L1_host';
> > +$gn ||= 'nested2';
> > +$guesthost ||= "$gn.l2.osstest";
> > +} else {
> > +$gn ||= 'debianhvm';
> > +$guesthost= "$gn.guest.osstest";
> > +}
>
> I don't think this is the right way to control the nestedness.
> Also your test recipe seems wrong. You write:
>
> +run-ts . = ts-debian-hvm-install + host + nested + nested_L1
> +run-ts . = ts-xen-install + host + nested + nested_build
> +run-ts . = ts-debian-hvm-install + host + nested2 + nested_L2
> +run-ts . = ts-guest-destroy + host + nested
>
> I think this should look more like:
>
> +run-ts . = ts-debian-hvm-install + host + nested
> +run-ts . = ts-nested-setup + host + nested
> +run-ts . = ts-xen-install nested
> +run-ts . = ts-host-reboot nested
> +run-ts . = ts-debian-hvm-install nested nested2
>
OK. Since we could only try to learn your design arch/hierarchy of osstest,
through code reading, such as terms of test job, test step, recipe, etc.,
we inevitably made some misunderstanding or unawareness.
Fortunately getting closer and closer to your mind now.
Will follow your recipe composing above.
> ts-nested-setup would turn on nested HVM support in the domain config,
> figures out the hostname etc. and makes some appropriate runvars which
> selecthost would recognise.
>
Thanks for this help.
> I don't know why you need to use a dedicated VG for your nested
> guests's L2 guests - please explain - but if you do, probably
> ts-nested-setup could set it up.
The existing ts-debian-hvm-install code presume host has vg set
for guest installation. To make minimal code change, we'd like
to imitate that presumption for L2's host.
>
> > @@ -63,7 +71,7 @@ d-i partman-auto/expert_recipe string \\
> > use_filesystem{ } filesystem{ vfat } \\
> > mountpoint{ /boot/efi } \\
> > . \\
> > -5000 50 5000 ext4 \\
> > +1 50 1 ext4 \\
>
> I think this needs an explanation. You mentioned it in your commit
> message but didn't give reasons. I think this should perhaps be done
> in a different way.
You mean not increase the size uniformly, but conditionally only for
L1?
>
> > +if ($nested eq 'nested_L2') {
> > +my $L2_disk_mb = 2;
> > +my $L0= selecthost($r{'L0_Ident'});
>
> As a style matter, runvars and perl local variable generally have
> all-lowercase names.
Sure, will follow the convention.
>
> > +if ($nested eq 'nested_L2') {
> > +target_cmd_root($gho, "init 0");
> > +target_await_down($gho,60);
> > +target_ping_check_down($gho);
> > +}
> > +if ($nested eq 'nested_L1') {
> > +store_runvar("L1_host", $gn);
> > +store_runvar("L1_IP", $gho->{Ip});
> > +store_runvar("L0_Ident", $whhost);
> > +target_cmd_root($gho, "mkdir -p /home/osstest/.ssh && cp
> /root/.ssh/authorized_keys /home/osstest/.ssh/");
> > +}
>
> I don't understand the purpose behind these special cases.
The first block is shut down L2 guest after proving it boots up.
The second block is in L1 context, that store run vars to pass down
information to L2.
To follow your recipe, these parts shall be moved to other ts-*.
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 01/12] Add support of parsing grub which has 'submenu' primitive
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, February 12, 2015 6:13 PM
> To: Hu, Robert
> Cc: Ian Jackson; xen-devel@lists.xen.org; jfeh...@suse.com;
> wei.l...@citrix.com; ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 01/12] Add support of parsing grub which has
> 'submenu' primitive
>
> On Thu, Feb 12, 2015 at 02:01:59AM +, Hu, Robert wrote:
> >
> > > -Original Message-
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > Sent: Wednesday, February 11, 2015 10:44 PM
> > > To: Hu, Robert
> > > Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> > > ian.campb...@citrix.com; Pang, LongtaoX
> > > Subject: Re: [PATCH OSSTEST 01/12] Add support of parsing grub which has
> > > 'submenu' primitive
> > >
> > > Robert Ho writes ("[PATCH OSSTEST 01/12] Add support of parsing grub
> which
> > > has 'submenu' primitive"):
> > > > From a hvm kernel build from Linux stable Kernel tree,
> > > > the auto generated grub2 menu will have 'submenu' primitive, upon the
> > > > 'menuentry' items. Xen boot entries will be grouped into a submenu.
> This
> > > > patch adds capability to support such grub formats. Also, this patch
> adjust
> > > > some indent alignments.
> > >
> > > Thanks for this submission. Dealing with submenus is definitely
> > > something we want to do.
> > >
> > > I haven't looked at the code in detail yet but I have a general
> > > question: we currently count menu entries and eventually write
> > > GRUB_DEFAULT= into /etc/default/grub.
> > >
> > > Does this work properly if the entry is in a submenu ? I guess you
> > > have probably tested this but I thought I should ask...
> > >
> > Yes, this minor change just get 'parsemenu' subroutine capability of
> recognizing 'submenu'.
> > The outer layer logic isn't affected.
> > Actually, the Xen boot menuentry we choose, is inside a submenu. It works
> and /etc/default/grub
> > is assigned properly.
>
> In any case this is a very useful improvement.
>
> Out of interest what Linux are you running? If you're running Debian
> and the overlay 20_linux_xen (inside $OSSTEST/overlay/etc/etc/grub.d) is
> copied to your test host, there shouldn't be any submenu entries in your
> grub.cfg, I think.
>
> Wei.
We use Debian + linux-stable kernel in the test.
Didn't look into details of the grub generating procedure, but my observation
is that it does have the submenu.
>
> > > Can you please not adjust the whitespace ? osstest in general doesn't
> > > have a requirement for any particular whitespace use, and certainly if
> > > there are to be any whitespace changes they ought to be in a separate
> > > patch.
> > I adjust those because some one in last version's reply told us that
> > osstest prefers white space substitution to tab, and traditionally 4
> > white space of 1 tab. (This align with my previous coding experience as
> > well)
> > And I indeed find that this hunk of code doesn't looks well in my editor.
> > Its unalignment increases difficulty of reading.
> > I would suggest to adjust the this hunk's indentation and use white space
> > substitution to tab to have best suitability across different editors.
> > >
> > > Thanks,
> > > Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 01/12] Add support of parsing grub which has 'submenu' primitive
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, February 11, 2015 10:44 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 01/12] Add support of parsing grub which has
> 'submenu' primitive
>
> Robert Ho writes ("[PATCH OSSTEST 01/12] Add support of parsing grub which
> has 'submenu' primitive"):
> > From a hvm kernel build from Linux stable Kernel tree,
> > the auto generated grub2 menu will have 'submenu' primitive, upon the
> > 'menuentry' items. Xen boot entries will be grouped into a submenu. This
> > patch adds capability to support such grub formats. Also, this patch adjust
> > some indent alignments.
>
> Thanks for this submission. Dealing with submenus is definitely
> something we want to do.
>
> I haven't looked at the code in detail yet but I have a general
> question: we currently count menu entries and eventually write
> GRUB_DEFAULT= into /etc/default/grub.
>
> Does this work properly if the entry is in a submenu ? I guess you
> have probably tested this but I thought I should ask...
>
Yes, this minor change just get 'parsemenu' subroutine capability of
recognizing 'submenu'.
The outer layer logic isn't affected.
Actually, the Xen boot menuentry we choose, is inside a submenu. It works and
/etc/default/grub
is assigned properly.
> Can you please not adjust the whitespace ? osstest in general doesn't
> have a requirement for any particular whitespace use, and certainly if
> there are to be any whitespace changes they ought to be in a separate
> patch.
I adjust those because some one in last version's reply told us that
osstest prefers white space substitution to tab, and traditionally 4
white space of 1 tab. (This align with my previous coding experience as well)
And I indeed find that this hunk of code doesn't looks well in my editor.
Its unalignment increases difficulty of reading.
I would suggest to adjust the this hunk's indentation and use white space
substitution to tab to have best suitability across different editors.
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, December 11, 2014 7:46 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
> ian.campb...@citrix.com; wei.l...@citrix.com; Hu, Robert; Zheng, Di
> Subject: Re: [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
>
> On Wed, Dec 10, 2014 at 04:07:40PM +0800, longtao.pang wrote:
> > From: "longtao.pang"
> >
> > This patch is used for inserting nested test job name and runvars into
> > standalone.db database after execute command './standalone-reset'.
> >
> > ---
> > make-flight | 19 +++
> > mfi-common |8
> > 2 files changed, 27 insertions(+)
> >
> > diff --git a/make-flight b/make-flight
> > index 9963a46..fe64237 100755
> > --- a/make-flight
> > +++ b/make-flight
> > @@ -197,6 +197,24 @@ do_hvm_win7_x64_tests () {
> > all_hostflags=$most_hostflags,hvm
> > }
> >
> > +do_hvm_debian_nested_tests () {
> > + if [ $xenarch != amd64 ]; then
> > +return
> > + fi
> > + if [ $dom0arch != amd64 ]; then
> > +return
> > + fi
> > +
> > + job_create_test test-$xenarch$kern-$dom0arch-nested test-nested xl \
> > + $xenarch $dom0arch \
> > +nested_image=debian-7.6.0-amd64-DVD-1.iso \
> > + bios=seabios \
> > + kernbuildjob=build-amd64-hvm \
> > + kernkind=hvm \
> > + device_model_version=qemu-xen \
> > +all_hostflags=$most_hostflags,hvm
> > +}
> > +
> > do_hvm_debian_test_one () {
> >testname=$1
> >bios=$2
> > @@ -364,6 +382,7 @@ test_matrix_do_one () {
> >
> >fi
> >
> > + do_hvm_debian_nested_tests
> >do_passthrough_tests
> > }
> >
> > diff --git a/mfi-common b/mfi-common
> > index 5c4f5d5..b65f0b5 100644
> > --- a/mfi-common
> > +++ b/mfi-common
> > @@ -166,6 +166,14 @@ create_build_jobs () {
> > revision_qemu=$REVISION_QEMU
> \
> > revision_qemuu=$REVISION_QEMU_UPSTREAM
> > fi
> > +./cs-job-create $flight build-$arch-hvm build-kern
> \
> > +arch=$arch kconfighow=xen-enable-xen-config
> \
> > +$RUNVARS $BUILD_RUNVARS $BUILD_LINUX_RUNVARS
> $arch_runvars \
> > +$suite_runvars
> \
> > +host_hostflags=$build_hostflags
> \
> > +revision_linux=v3.16
> \
> > +
> tree_linux=git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> \
>
> Please don't hard code tree and revision.
>
> You can specify tree and revision in you test configuration.
Can you help more on details regarding to 'test configuration'? Thanks.
>
> Wei.
>
> > +${TREEVCS_LINUX:+treevcs_linux=}${TREEVCS_LINUX}
> >
> > ./cs-job-create $flight build-$arch-pvops build-kern
> \
> > arch=$arch kconfighow=xen-enable-xen-config
> \
> > --
> > 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for L1 guest VM
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Tuesday, January 27, 2015 7:01 PM > To: Hu, Robert > Cc: Wei Liu; Pang, LongtaoX; xen-devel@lists.xen.org; > ian.jack...@eu.citrix.com; Zheng, Di > Subject: Re: [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for L1 guest > VM > > On Tue, 2015-01-27 at 08:33 +, Hu, Robert wrote: > [...] please trim quotes. > > > > > > FWIW, OSSTest has a bunch of overlay files (look at overlay directory), > > > which includes an init script called xenbridge. In theory if you're > > > reusing this script (ts-xen-install) then you don't need to worry about > > > setting up bridge? > > I tried this approach, using xenbridge init scripts, it can work. > > However, in original xen install, it seems not used. I don't see 'xenbridge' > > in /etc/rc2.d/ > > xenbridge is only enabled if OldSeparateBridgeInitd is set, which it is > not for a modern Xen install so I think this is a red-herring. > > > Shall I know the xenbr0 is created? I think not by xenbridge init service. > > The host networking is configured by the function nodhcp in > ts-xen-install. yeah, I get it now. Thanks. > > Per our previous conversations once the L1 guest is installed you can > mostly treat it as a if it were an L0 host wrt configuring it. In other > words there should be no need for a separate setup_l1_bridge function, > just some minor modifications to ts-xen-install. I'll reuse this nodhcp() subroutine, rather than my setup_l1_bridge() nor xenbridge init script. > > Ian. > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for L1 guest VM
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, December 11, 2014 7:25 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
> ian.campb...@citrix.com; wei.l...@citrix.com; Hu, Robert; Zheng, Di
> Subject: Re: [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for L1 guest
> VM
>
> On Wed, Dec 10, 2014 at 04:07:38PM +0800, longtao.pang wrote:
> > From: "longtao.pang"
> >
> > This patch is used for building XEN and HVM Dom0 kernel for L1 guest VM,
> > and then reboot L1 guest into xen kernel.
> >
>
> I think you can just use the L0 Xen and Dom0 kernel, that would save you
> lots of time running this test case. It can also help simplifies this
> patch, maybe?
>
> > ---
> > sg-run-job |1 +
> > ts-xen-install | 149
> +---
> > 2 files changed, 111 insertions(+), 39 deletions(-)
> >
> > diff --git a/sg-run-job b/sg-run-job
> > index 8dcf7af..e513bd1 100755
> > --- a/sg-run-job
> > +++ b/sg-run-job
> > @@ -291,6 +291,7 @@ proc run-job/test-pair {} {
> > proc need-hosts/test-nested {} {return host}
> > proc run-job/test-nested {} {
> > run-ts . = ts-debian-hvm-install + host + nested + nested_L1
> > +run-ts . = ts-xen-install + host + nested + nested_build
> > }
> >
> > proc test-guest-migr {g} {
> > diff --git a/ts-xen-install b/ts-xen-install
> > index 4d34d1f..c175d6d 100755
> > --- a/ts-xen-install
> > +++ b/ts-xen-install
> > @@ -28,19 +28,25 @@ use Osstest::CXFabric;
> > my $checkmode= 0;
> >
> > tsreadconfig();
> > -
> > +our $w_ho;
> > our @hos;
> > -
> > -if (@ARGV and $ARGV[0] eq '--check') {
> > -$checkmode= 1;
> > -shift @ARGV;
> > -logm("checking builds are done...");
> > +our ($whhost,$gn,$nested_build) = @ARGV;
> > +$nested_build ||= '';
> > +if ($nested_build eq 'nested_build') {
> > +$whhost ||= 'host';
> > +$gn ||= 'nested';
> > } else {
> > -if (!@ARGV) {
> > - push @ARGV, 'host';
> > -}
> > -foreach my $k (@ARGV) {
> > -push @hos, selecthost($k);
> > +if (@ARGV and $ARGV[0] eq '--check') {
> > +$checkmode= 1;
> > +shift @ARGV;
> > +logm("checking builds are done...");
> > +} else {
> > +if (!@ARGV) {
> > +push @ARGV, 'host';
> > +}
> > +foreach my $k (@ARGV) {
> > +push @hos, selecthost($k);
> > +}
> > }
> > }
> >
> > @@ -49,18 +55,18 @@ our $ho;
> > my %distpath;
> >
> > sub packages () {
> > -target_install_packages($ho,
> > +target_install_packages($w_ho,
> > qw(bridge-utils vncsnapshot libaio1
> libpixman-1-0
> > libsdl1.2debian libglib2.0-0
> liblzma5));
> > -target_install_packages($ho,
> > +target_install_packages($w_ho,
> > $ho->{Suite} =~ /squeeze/ ? "libyajl1" :
> > "libyajl2");
> > if ($ho->{Suite} !~ m/lenny|squeeze/) {
> > -target_install_packages($ho, 'libfdt1');
> > +target_install_packages($w_ho, 'libfdt1');
> > }
> > if ($r{arch} eq 'i386') {
> > - target_install_packages($ho, 'libc6-xen');
> > + target_install_packages($w_ho, 'libc6-xen');
> > }
> > -target_install_packages($ho, @{toolstack()->{ExtraPackages}})
> > +target_install_packages($w_ho, @{toolstack()->{ExtraPackages}})
> > if toolstack()->{ExtraPackages};
> > }
> >
> > @@ -69,14 +75,14 @@ sub extract () {
> > push @parts, 'libvirt' if $r{toolstack} eq "libvirt";
> >
> > foreach my $part (@parts) {
> > -target_extract_jobdistpath($ho, $part, "path_${part}dist",
> > +target_extract_jobdistpath($w_ho, $part, "path_${part}dist",
> >$r{"${part}buildjob"}, \%distpath);
> > }
> > -target_cmd_root($ho, '/sbin/ldconfig');
> > +target_cmd_root($w_ho, '/sbin/ldconfig');
> > }
> >
> > sub adjustconfig () {
> > -target_editfile_root($ho, "/etc/xen/xend-config.sxp",
> >
[Xen-devel] [Testday]Xen 4.5 RC4
Hi This is test report on Xen 4.5 RC4, from Intel OTC VMM Team. Platform: Grantley-EP, Ivytown-EP We found these issue blow. Hoping corresponding patches can be committed in Xen 4.5 release. Issue 1 -- detach a vt-d assigned device from guest, then reattach it to guest, will fail. http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html Issue 2 -- attach/detach vt-d devices (both physical and virtual fucntions) to domain, more than 1 time, will fail with errors http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg02016.html Note: this depends on issue 1. need to apply issue 1's patch to get it. Issue 3 -- 1GB hugepage support on X86_64 with HVM guest requires hacks in the guest config http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg02624.html Best Regards, Robert Ho ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by Intel.Was:Re: [TestDay] VMX test report for Xen 4.5.0-rc1
> -Original Message- > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: Monday, November 24, 2014 11:13 PM > To: Konrad Rzeszutek Wilk; Hu, Robert; ian.jack...@eu.citrix.com; > ian.campb...@citrix.com > Cc: xen-devel@lists.xen.org; jbeul...@suse.com > Subject: Re: Is: Fixes for xl pci-attach for Xen 4.5 confirmed to fix by > Intel.Was:Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1 > > On 11/24/2014 09:54 AM, Konrad Rzeszutek Wilk wrote: > > On Mon, Nov 24, 2014 at 07:43:49AM +, Hu, Robert wrote: > >>> -Original Message- > >>> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > >>> Sent: Wednesday, November 12, 2014 8:39 PM > >>> To: Hu, Robert; xen-devel@lists.xen.org > >>> Cc: jbeul...@suse.com > >>> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1 > >>> > >>> > >>> On 11/12/2014 01:58 AM, Hu, Robert wrote: > >>>> 2. Failed to hotplug a VT-d device with XEN4.5-RC1 > >>>> > http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894 > >>> > >>> This should be addressed by these two: > >>> > http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00875.html > >>> > http://lists.xenproject.org/archives/html/xen-devel/2014-11/msg00874.html > >> Tried, these patches works. When will they get in? > > > They won't get in in the form that they are now. I will need to rework them. > > For this specific problem though I think > > http://lists.xen.org/archives/html/xen-devel/2014-11/msg01342.html We verified this on RC4, it works. Will your patch get in Xen 4.5 release? Otherwise hotplug vt-d device with a running guest will not work properly. > > should be sufficient. Please give it a try. > > Thanks. > -boris > > > > CC-ed Ian's so they are aware of the independent testing done by Intel. > > > > Thank you! > >>> -boris > >> ___ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
