Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Wednesday, June 17, 2015 5:35 PM > To: Pang, LongtaoX > Cc: Hu, Robert; Ian Jackson; 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 Wed, 2015-06-17 at 08:54 +, Pang, LongtaoX wrote: > > > After executing command ' ./standalone run-job --simulate -h dummy > test-amd64-amd64-qemuu-nested | grep testid', > > get below information: > > root@OSSTEST:~/v11_pretest_3/osstest_v11# ./standalone run-job --simulate -h > dummy test-amd64-amd64-qemuu-nested | grep testid > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 1 testid build-check(1) == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 2 testid hosts-allocate == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 3 testid host-install(3) == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 4 testid host-ping-check-native == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 5 testid xen-install == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 6 testid xen-boot == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 7 testid host-ping-check-xen == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 8 testid leak-check/basis(8) == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 9 testid debian-hvm-install == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 10 testid nested-setup == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 11 testid xen-install/nestedl1 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 12 testid host-reboot/nestedl1 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 13 testid leak-check/basis/nestedl1 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 14 testid debian-hvm-install/nestedl1/nestedl2 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 15 testid guest-stop/nestedl1/nestedl2 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 16 testid guest-destroy == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 17 testid leak-check/check == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 18 testid leak-check/check/nestedl1 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 19 testid capture-logs(19) == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 20 testid capture-logs/nestedl1(20) == > > root@OSSTEST:~/v11_pretest_3/osstest_v11# > > > > But, for testid of '18', I think it will failed to execute > > 'leak-check/check/nestedl1', > since > > 'nestedl1' has been destroyed via the action of 'run-ts . = > > ts-guest-destroy + host > nestedl1'. > > Please correct me if I am wrong. > > 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). > > > Another question, after execute testid of '13'(leak-check/basis/nestedl1), > > the > testing will fail and exit with below message. > > Something wrong with my test environment? > > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 xl list > > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 ps -wwef > > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 ps -wwef > > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 xenstore-ls -fp > > 2015-06-17 08:10:26 Z executing ssh ... root@192.168.199.25 find /tmp > > /var/run > /var/tmp /var/lib/xen /var/core ! -type d -print0 -ls -printf '\0' > > find: `/var/core': No such file or directory > > /var/core is created by ts-host-install. I think the tail end of the > function sub in there which does that and populates /etc/sysctl.
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: Friday, June 12, 2015 11:27 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com; Hu,
> Robert
> 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"):
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> ...
> > > leak-check compares the set of objects present at the `leak-check
> > > check' step with the set of objects present at the `basis' step, and
> > > the check fails if there are any new objects. For this purpose,
> > > objects includes domains, corefiles, etc.
> > >
> > OK, so the recipe in sg-run-job should be like below, please correct me if
> something wrong.
> > proc need-hosts/test-nested {} {return host}
> > proc run-job/test-nested {} {
>
> This is roughly right, but thinking about it, you want ts-logs-capture
> to run even if the previous steps fail.
>
> I think it might be better to reuse (subvert?) the existing machinery
> in sg-run-job, by adding the l1 to need_xen_hosts.
>
> Maybe something like
>
> proc add-xen-host-retrospectively {ident} {
> global need_xen_hosts
> ts-leak-check $ident + basis
> lappend need_xen_hosts $ident
> }
>
> ?
>
> And then call
>
> add-xen-host-retrospectively l1
>
> at the appropriate point.
>
> If you do this then the main run-job proc will automatically do the
> leak-check and the logs-capture for you.
>
I have tried your suggestion, call 'add-xen-host- retrospectively l1' just
after L1 has booted into XEN.
leak-check and logs-capture will be done automatically at final stage, but this
happened after L1 guest destroyed
and it will failed obviously(I have mentioned this in previous mail).
So, may I implement these action via below recipe in sg-run-job? Since, this
would be less code to
be changed and we want to avoid to involve tcl plumbing in sg-run-job. Also, I
think there is no harmful.
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 + host l1
run-ts . = ts-xen-install l1
run-ts . = ts-host-reboot l1
run-ts . = ts-leak-check basis l1
run-ts . = ts-debian-hvm-install l1 l2
run-ts . = ts-guest-stop l1 l2
run-ts . = ts-leak-check check l1
run-ts . = ts-logs-capture l1
run-ts . = ts-guest-destroy + host l1
}
>
> Thinking about this leads me to ask another question. Suppose that a
> bug causes the l1 to lock up completely. ts-logs-capture will attempt
> to hard reboot a locked-up host. If it can't fetch any logs, it calls
> target_reboot_hard($ho);
>
> What will that do if $ho refers to the l1 ? It relies on the power
> method. Does your nested l1 "host" have a power method ?
>
> 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 Campbell [mailto:ian.campb...@citrix.com] > Sent: Thursday, June 18, 2015 5:23 PM > To: Pang, LongtaoX > Cc: Hu, Robert; Ian Jackson; wei.l...@citrix.com; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main > recipe of nested test job > > On Thu, 2015-06-18 at 09:16 +, Pang, LongtaoX wrote: > > > > > -Original Message- > > > From: Ian Campbell [mailto:ian.campb...@citrix.com] > > > Sent: Wednesday, June 17, 2015 7:49 PM > > > To: Pang, LongtaoX > > > Cc: Hu, Robert; Ian Jackson; 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 Wed, 2015-06-17 at 11:00 +, Pang, LongtaoX wrote: > > > > > > 2015-06-17 08:10:26 Z executing ssh ... root@192.168.199.25 find > > > > > > /tmp > > > /var/run > > > > > /var/tmp /var/lib/xen /var/core ! -type d -print0 -ls -printf '\0' > > > > > > find: `/var/core': No such file or directory > > > > > > > > > > /var/core is created by ts-host-install. I think the tail end of the > > > > > function sub in there which does that and populates /etc/sysctl.conf > > > > > and /etc/security/limits.d/coredumps.conf should be refactored > > > > > probably > > > > > to be alongside the osstest-confirm-booted thing which IIRC you are > > > > > already going to refactor in the next version. > > > > > > > > > I reviewed related code in 'ts-host-install'. But I am not very clear, > > > > the below > > > code will be executed > > > > in 'ts-debian-hvm-install' too? Or refactor 'osstest-confirm-booted' > > > > and the > > > below action should be finished inside this shell script? > > > > Since, it need '/var/core' directory in L1, please correct me. > > > > > > I think you've already arranged for the osstest-confirm-booted stuff to > > > happen for the L1 host too, but that Ian J has requested it be done > > > differently such that it is not duplicated in two places. > > > > > Yes, I have arranged for osstest-confirm-booted stuff to happen for the L1 > > host > via call > > function in 'ts-nested-setup' script. So, the setup of /var/core and the > > associated > sysctl.conf > > and limits.d changes should be done in 'ts-nested-setup' too? Or be done in > > 'ts-debian-hvm-install' script? Which do you prefer? I prefer to > > 'ts-nested-setup'. > > Ian has already indicated in > <21880.17044.20906.699...@mariner.uk.xensource.com> that the > osstest-confirm-booted stuff should be broken out and not duplicated > into ts-nested-setup. Once you have followed that request then you will > also have an ideal place to do the core dump setup too. > Thanks, I get it. > 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 Campbell [mailto:ian.campb...@citrix.com] > Sent: Wednesday, June 17, 2015 7:49 PM > To: Pang, LongtaoX > Cc: Hu, Robert; Ian Jackson; 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 Wed, 2015-06-17 at 11:00 +, Pang, LongtaoX wrote: > > > > 2015-06-17 08:10:26 Z executing ssh ... root@192.168.199.25 find /tmp > /var/run > > > /var/tmp /var/lib/xen /var/core ! -type d -print0 -ls -printf '\0' > > > > find: `/var/core': No such file or directory > > > > > > /var/core is created by ts-host-install. I think the tail end of the > > > function sub in there which does that and populates /etc/sysctl.conf > > > and /etc/security/limits.d/coredumps.conf should be refactored probably > > > to be alongside the osstest-confirm-booted thing which IIRC you are > > > already going to refactor in the next version. > > > > > I reviewed related code in 'ts-host-install'. But I am not very clear, the > > below > code will be executed > > in 'ts-debian-hvm-install' too? Or refactor 'osstest-confirm-booted' and the > below action should be finished inside this shell script? > > Since, it need '/var/core' directory in L1, please correct me. > > I think you've already arranged for the osstest-confirm-booted stuff to > happen for the L1 host too, but that Ian J has requested it be done > differently such that it is not duplicated in two places. > Yes, I have arranged for osstest-confirm-booted stuff to happen for the L1 host via call function in 'ts-nested-setup' script. So, the setup of /var/core and the associated sysctl.conf and limits.d changes should be done in 'ts-nested-setup' too? Or be done in 'ts-debian-hvm-install' script? Which do you prefer? I prefer to 'ts-nested-setup'. > The code to setup /var/core and the associated sysctl.conf and limits.d > changes should be done in the same manner as osstest-confirm-booted > eventually is based on Ian's suggestion, whatever that was. > > 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 Campbell [mailto:ian.campb...@citrix.com] > Sent: Wednesday, June 17, 2015 5:35 PM > To: Pang, LongtaoX > Cc: Hu, Robert; Ian Jackson; 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 Wed, 2015-06-17 at 08:54 +, Pang, LongtaoX wrote: > > > After executing command ' ./standalone run-job --simulate -h dummy > test-amd64-amd64-qemuu-nested | grep testid', > > get below information: > > root@OSSTEST:~/v11_pretest_3/osstest_v11# ./standalone run-job --simulate -h > dummy test-amd64-amd64-qemuu-nested | grep testid > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 1 testid build-check(1) == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 2 testid hosts-allocate == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 3 testid host-install(3) == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 4 testid host-ping-check-native == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 5 testid xen-install == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 6 testid xen-boot == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 7 testid host-ping-check-xen == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 8 testid leak-check/basis(8) == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 9 testid debian-hvm-install == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 10 testid nested-setup == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 11 testid xen-install/nestedl1 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 12 testid host-reboot/nestedl1 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 13 testid leak-check/basis/nestedl1 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 14 testid debian-hvm-install/nestedl1/nestedl2 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 15 testid guest-stop/nestedl1/nestedl2 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 16 testid guest-destroy == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 17 testid leak-check/check == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 18 testid leak-check/check/nestedl1 == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 19 testid capture-logs(19) == > > 2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested > == 20 testid capture-logs/nestedl1(20) == > > root@OSSTEST:~/v11_pretest_3/osstest_v11# > > > > But, for testid of '18', I think it will failed to execute > > 'leak-check/check/nestedl1', > since > > 'nestedl1' has been destroyed via the action of 'run-ts . = > > ts-guest-destroy + host > nestedl1'. > > Please correct me if I am wrong. > > 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). > > > Another question, after execute testid of '13'(leak-check/basis/nestedl1), > > the > testing will fail and exit with below message. > > Something wrong with my test environment? > > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 xl list > > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 ps -wwef > > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 ps -wwef > > 2015-06-17 08:10:25 Z executing ssh ... root@192.168.199.25 xenstore-ls -fp > > 2015-06-17 08:10:26 Z executing ssh ... root@192.168.199.25 find /tmp > > /var/run > /var/tmp /var/lib/xen /var/core ! -type d -print0 -ls -printf '\0' > > find: `/var/core': No such file or directory > > /var/core is created by ts-host-install. I think the tail end of the > function sub in there which does that and populates /etc
Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job
> > >
> > > Thinking about this leads me to ask another question. Suppose that a
> > > bug causes the l1 to lock up completely. ts-logs-capture will attempt
> > > to hard reboot a locked-up host. If it can't fetch any logs, it calls
> > > target_reboot_hard($ho);
> > >
> > > What will that do if $ho refers to the l1 ? It relies on the power
> > > method. Does your nested l1 "host" have a power method ?
> > I'm afraid l1 won't like normal hosts has power cycle operations. Maybe
> > we need to simulate it?
>
> Perhaps arrange for an appropriate PowerMethod for "hosts which are
> actually guests"?
>
Update.
I think maybe we need to refactor 'power_cycle' function in TestSupport.pm. I
have not try it, something like below?
sub power_cycle ($) {
my ($ho) = @_;
+if (guest_var($ho,"enable_nestedhvm",'') =~ m/true/) {
+guest_destroy($ho);
+guest_create($ho);
+guest_await_dhcp_tcp($ho,300);
+guest_check_up($ho);
+} else {
$mjobdb->host_check_allocated($ho);
die "refusing to set power state for host $ho->{Name}".
" possibly shared with other jobs\n"
if $ho->{SharedMaybeOthers};
power_state($ho, 0);
power_cycle_sleep($ho);
power_state($ho, 1);
+}
}
> 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 Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, June 15, 2015 5:08 PM
> To: Hu, Robert
> Cc: Ian Jackson; Pang, LongtaoX; 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 Sun, 2015-06-14 at 20:51 +0800, Robert Hu wrote:
> > On Fri, 2015-06-12 at 16:27 +0100, Ian Jackson wrote:
> > > Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 6/7] Compose the
> main recipe of nested test job"):
> > > > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > ...
> > > > > leak-check compares the set of objects present at the `leak-check
> > > > > check' step with the set of objects present at the `basis' step, and
> > > > > the check fails if there are any new objects. For this purpose,
> > > > > objects includes domains, corefiles, etc.
> > > > >
> > > > OK, so the recipe in sg-run-job should be like below, please correct me
> > > > if
> something wrong.
> > > > proc need-hosts/test-nested {} {return host}
> > > > proc run-job/test-nested {} {
> > >
> > > This is roughly right, but thinking about it, you want ts-logs-capture
> > > to run even if the previous steps fail.
> > >
> > > I think it might be better to reuse (subvert?) the existing machinery
> > > in sg-run-job, by adding the l1 to need_xen_hosts.
> > >
> > > Maybe something like
> > >
> > > proc add-xen-host-retrospectively {ident} {
> > > global need_xen_hosts
> > > ts-leak-check $ident + basis
> > > lappend need_xen_hosts $ident
> > > }
> > >
> > > ?
> > >
> > > And then call
> > >
> > > add-xen-host-retrospectively l1
> > >
> > > at the appropriate point.
> > Thanks Ian J.. Since I'm not familiar with tcl and your sg-run-job
> > framework, does here 'appropriate point' refers to before
> > per-host-ts . =(*) {ts-leak-check basis}
> > in proc run-job {job}? but then l1 doesn't exist yet I'm afraid.
> > If after that point, the l1 has missd check basis step.
>
> Note that Ian included a ts-leak-check in his
> add-xen-host-retrospectively function, so you needn't worry about this,
> you should do it jsut after the L1 has booted into Xen, I think.
>
> What you get automatically here is the final leak check (i.e. the
> comparison against the basis).
Thanks Ian C.
So, I modify the nested job recipe in sg-run-job as below.
proc add-xen-host-retrospectively {ident} {
global need_xen_hosts
run-ts . = ts-leak-check basis $ident
lappend need_xen_hosts $ident
}
proc need-hosts/test-nested {} {return host}
proc run-job/test-nested {} {
run-ts . = ts-debian-hvm-install + host nestedl1
run-ts . = ts-nested-setup + host nestedl1
run-ts . = ts-xen-install nestedl1
run-ts . = ts-host-reboot nestedl1
add-xen-host-retrospectively nestedl1
run-ts . = ts-debian-hvm-install nestedl1 nestedl2
run-ts . = ts-guest-stop nestedl1 nestedl2
run-ts . = ts-guest-destroy + host nestedl1
}
After executing command ' ./standalone run-job --simulate -h dummy
test-amd64-amd64-qemuu-nested | grep testid',
get below information:
root@OSSTEST:~/v11_pretest_3/osstest_v11# ./standalone run-job --simulate -h
dummy test-amd64-amd64-qemuu-nested | grep testid
2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested == 1
testid build-check(1) ==
2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested == 2
testid hosts-allocate ==
2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested == 3
testid host-install(3) ==
2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested == 4
testid host-ping-check-native ==
2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested == 5
testid xen-install ==
2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested == 6
testid xen-boot ==
2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested == 7
testid host-ping-check-xen ==
2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested == 8
testid leak-check/basis(8) ==
2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested == 9
testid debian-hvm-install ==
2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested == 10
testid nested-setup ==
2015-06-17 07:33:35 Z standalone.test-amd64-amd64-qemuu-nested == 11
testid xen-
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 11, 2015 11:20 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com; Hu,
> Robert
> 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"):
> ...
>
> (Ian C has answered some of your comments. On the others:)
>
> > > I think you probably want to run leak-check on the L1.
> > >
> > I have noticed the logs which printed on screen during job running, the
> leak-check will
> > be run on L1 at the end of testing.
> > Or, do you mean that I should run leak-check on L1 after the L1 HVM guest
> finishing installation?
>
> Maybe I am confused.
>
> I think that with your patches, leak-check would be run on the L0
> only.
>
> But leak-check ought to be run on the L1 as well. The basis would be
> after nested-setup, xen-install and reboot I think (similar to the
> position for the L0 basis).
>
> leak-check compares the set of objects present at the `leak-check
> check' step with the set of objects present at the `basis' step, and
> the check fails if there are any new objects. For this purpose,
> objects includes domains, corefiles, etc.
>
OK, so the recipe in sg-run-job should be like below, please correct me if
something wrong.
proc need-hosts/test-nested {} {return host}
proc run-job/test-nested {} {
run-ts . = ts-debian-hvm-install + host nestedl1
run-ts . = ts-nested-setup + host nestedl1
run-ts . = ts-xen-install nestedl1
run-ts . = ts-host-reboot nestedl1
run-ts . = ts-leak-check nestedl1 + basis
run-ts . = ts-debian-hvm-install nestedl1 nestedl2
run-ts . = ts-guest-stop nestedl1 nestedl2
run-ts . = ts-leak-check nestedl1 + check
run-ts . = ts-logs-capture nestedl1
run-ts . = ts-guest-destroy + host nestedl1
}
> > > Do you not want to run the steps in test-guest ? Perhaps it would be
> > > better to add a host ident argument to test-guest{,-migr,-nomigr} ?
> > >
> > We do not plan to run the steps in test-guest currently.
>
> Why not ?
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v11 5/7] Add new script to customize nested test configuration
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Thursday, June 11, 2015 11:15 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com; Hu,
> Robert
> Subject: RE: [OSSTEST Nested PATCH v11 5/7] Add new script to customize nested
> test configuration
>
> Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 5/7] Add new script to
> customize nested test configuration"):
> > [Ian Jackson [mailto:ian.jack...@eu.citrix.com]]
>
> > > We would avoid having to mention /dev/xvdb if we created the VG in the
> > > host, before doing block-attach. I'm not sure whether that's an
> > > improvement.
> >
> > I am sorry, I cannot get your point. Could you please make it more
> > clear? Thanks.
>
> As you explain in the comment, you have to mention /dev/xvdb here even
> though after rebooting into Xen this will be /dev/sdb.
>
> This wrinkle would become invisible if you did pvcreate and vgcreate
> in the L0 (before attach), rather than the L1 (after attach).
> Because, then none of your operations on L1 would not need to name the
> physical device.
>
Thanks for your explanation.
For nested job, we will install L2 guest inside L1 reuse
'ts-debian-hvm-install' script.
But according to recent code design, inside L1 HVM guest, there is no vg group,
so that we need to
create a vg group for L2 installation.
So, inside L0, we create storage lv(lvcreate -L ${guest_storage_lv_size}M -n
$guest_storage_lv_name $vgname),
attach this lv to L1. Then inside L1, using the attached disk to create a
pv(pvcreate /dev/xvdb),
then create a vg(vgcreate ${l1_gn}-disk /dev/xvdb) base on the pv. Then, using
this vg for installing L2.
I think '/dev/xvdb' is necessary when create vg inside L1, using command
'vgcreate ${l1_gn}-disk /dev/xvdb' .
Please correct me if I am wrong.
> 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 Campbell [mailto:ian.campb...@citrix.com]
> Sent: Thursday, June 11, 2015 4:40 PM
> To: Pang, LongtaoX
> Cc: Ian Jackson; xen-devel@lists.xen.org; wei.l...@citrix.com; Hu, Robert
> Subject: Re: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested
> test job
>
> On Thu, 2015-06-11 at 07:41 +, Pang, LongtaoX wrote:
> >
> > > -Original Message-
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > Sent: Wednesday, June 10, 2015 11:42 PM
> > > To: Pang, LongtaoX
> > > Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com;
> Hu,
> > > Robert
> > > Subject: Re: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of
> nested
> > > test job
> > >
> > > longtao.pang writes ("[OSSTEST Nested PATCH v11 6/7] Compose the main
> recipe
> > > of nested test job"):
> > > > The ident and guestname are same of 'nestedl1' for L1 guest VM.
> > >
> > > This is going in the right direction.
> > >
> > > I think arrangements need to be made to capture the logs for
> > > nestedl1.
> > >
> > I am sorry, what logs do you mean?
>
> I think the ones gathered from a host by ts-logs-capture, which should
> be made to run against an L1 hypervisor and added to the job recipe.
>
I have checked nested job testid, as below:
#./standalone run-job --simulate -h dummy test-amd64-amd64-qemuu-nested | grep
testid
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 1
testid build-check(1) ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 2
testid hosts-allocate ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 3
testid host-install(3) ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 4
testid host-ping-check-native ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 5
testid xen-install ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 6
testid xen-boot ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 7
testid host-ping-check-xen ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 8
testid leak-check/basis(8) ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 9
testid debian-hvm-install/nestedl1 ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 10
testid nested-setup/nestedl1 ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 11
testid xen-install/nestedl1 ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 12
testid host-reboot/nestedl1 ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 13
testid debian-hvm-install/nestedl1/nestedl2 ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 14
testid guest-stop/nestedl1/nestedl2 ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 15
testid guest-destroy/nestedl1 ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 16
testid leak-check/check ==
2015-06-11 09:46:37 Z standalone.test-amd64-amd64-qemuu-nested == 17
testid capture-logs(17) ==
Sorry, I am confused, ' capture-logs' has already been added in job, do we need
to add it again?
> > > I think some extra +s in the l2 install and start operations might be
> > > useful, because the testid probably doesn't need to mention nestedl1.
> > >
> > I am sorry, do you mean that I should add '+' for l2 installation,
> > such as ' ts-debian-hvm-install + nestedl1 + nestedl2' ?
>
> You can use standalone --dry-run to see all the testid's generated by
> your job and then adjust the +'s until they are as desired (in this case
> Ian is suggesting to omit nestedl1 from the testid).
>
Thanks Ian C.
So, the expect requirement is like below in 'sg-run-job', right? (I will try to
change
idents/guest names as `l1' and `l2' later as Ian Jackson's suggestion)
proc need-hosts/test-nested {} {return host}
proc run-job/test-nested {} {
run-ts . = ts-debian-hvm-install + host nestedl1
run-ts . = ts-nested-setup + host nestedl1
run-ts . = ts-xen-install nestedl1
run-ts . = ts-host-reboot nestedl1
run-ts . = ts-debian-hvm-install nestedl1 nestedl2
run-ts . = ts-guest-stop nestedl1 nestedl2
run-ts . = ts-guest-destroy + host nestedl1
}
> 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: Wednesday, June 10, 2015 11:42 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com; Hu,
> Robert
> Subject: Re: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested
> test job
>
> longtao.pang writes ("[OSSTEST Nested PATCH v11 6/7] Compose the main recipe
> of nested test job"):
> > The ident and guestname are same of 'nestedl1' for L1 guest VM.
>
> This is going in the right direction.
>
> I think arrangements need to be made to capture the logs for
> nestedl1.
>
I am sorry, what logs do you mean? I noticed that there is one
'logs/standalone' directory
inside osstest repo. There are job logs that already have run.
> > +proc need-hosts/test-nested {} {return host}
> > +proc run-job/test-nested {} {
> > +run-ts . = ts-debian-hvm-install + host + nestedl1
> > +run-ts . = ts-nested-setup + host + nestedl1
> > +run-ts . = ts-xen-install nestedl1
> > +run-ts . = ts-host-reboot nestedl1
> > +run-ts . = ts-debian-hvm-install nestedl1 nestedl2
> > +run-ts . = ts-guest-stop nestedl1 nestedl2
> > +run-ts . = ts-guest-destroy + host + nestedl1
> > +}
>
> Very much a matter of taste, but can I suggest that `l1' and `l2'
> might be better idents/guest names names ?
>
Yes, I will try it.
> I think some extra +s in the l2 install and start operations might be
> useful, because the testid probably doesn't need to mention nestedl1.
>
I am sorry, do you mean that I should add '+' for l2 installation,
such as ' ts-debian-hvm-install + nestedl1 + nestedl2' ?
> I think you probably want to run leak-check on the L1.
>
I have noticed the logs which printed on screen during job running, the
leak-check will
be run on L1 at the end of testing.
Or, do you mean that I should run leak-check on L1 after the L1 HVM guest
finishing installation?
> Do you not want to run the steps in test-guest ? Perhaps it would be
> better to add a host ident argument to test-guest{,-migr,-nomigr} ?
>
We do not plan to run the steps in test-guest currently.
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v11 7/7] Add test job for nest test case
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, June 10, 2015 11:46 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com; Hu,
> Robert
> Subject: Re: [OSSTEST Nested PATCH v11 7/7] Add test job for nest test case
>
> longtao.pang writes ("[OSSTEST Nested PATCH v11 7/7] Add test job for nest
> test
> case"):
> > 1. This patch adds creation of the nested test job, when job creation
> > procedure is invoked.
> > 2. Set nested L1's vif model, nestedhvm feature, set specific disk
> > size and memory size for nested test by make-flight.
> ...
>
> This is nearly right, I think.
>
> > + job_create_test test-$xenarch$kern-$dom0arch$qemuu_suffix-nested \
> > +test-nested xl $xenarch $dom0arch $qemuu_runvar \
> > +nestedl1_image=debian-7.2.0-amd64-CD-1.iso \
> > +nestedl1_vifmodel='e1000' \
> > +nestedl1_disksize='15000' \
> > +nestedl1_memsize='3072' \
> > +nestedl1_enable_nestedhvm='true' \
> > +nestedl1_guest_storage_size='2' \
> > +nestedl2_image=debian-7.2.0-amd64-CD-1.iso \
> > +nestedl2_disksize='15000' \
> > +bios=$bios
> > +all_hostflags=$most_hostflags,hvm
>
> Some observations:
> * The \ should be aligned to a column at the RHS. If you did that
>you would have noticed that:
> * You are missing a \
> * Most of the '' are unnecessary.
Thanks for pointing out these.
> * Why do you specify the l2 disk size explicitly ?
Just for some configure rule in our lab, we assign at least '15000M' disk size
for nested L2 guest,
since it's no harmful, I think.
Actually, it works fine if not specify the l2 disk size and using default
'1M'.
So, you prefer to use default disk size for l2 guest, right?
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v11 5/7] Add new script to customize nested test configuration
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, June 10, 2015 9:59 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com; Hu,
> Robert
> Subject: Re: [OSSTEST Nested PATCH v11 5/7] Add new script to customize nested
> test configuration
>
> longtao.pang writes ("[OSSTEST Nested PATCH v11 5/7] Add new script to
> customize nested test configuration"):
> > 1. In this script, make some appropriate runvars which selecthost would
> > recognise.
> > 2. Prepare the configurations for installing L2 guest VM.
> > 3. Create a lv disk in L0 and hot-attach it to L1; Inside L1, using this
> > new added disk to create a VG which will be used for installing L2 guest.
> ...
>
> Thanks. This is roughly the right approach. I have some minor
> comments.
>
>
> > +target_cmd_root($l1, "update-rc.d osstest-confirm-booted start 99 2 .");
>
> This is an open coded copy of the code from ts-host-install. It
> should be broken out, I think.
>
I am sorry, could you please make it more clear? Thanks.
>
> > +target_install_packages_norec($l1, qw(lvm2 rsync genisoimage));
>
> Do we need to install genisoimage here ? The guest install scripts do
> it. Or are we just doing it here for efficiency reasons ?
In fact, there is no need to install ' genisoimage' here.
It's just for efficiency reason, since if install this package here, it will
not
be installed in 'ts-debian-hvm-install' script again.
So, do you prefer to discard it or keep it here? I think there is no harmful to
install this package here.
>
> > +# We need to attach an extra disk to the L1 guest to be used as L2
> > +# guest storage.
> > +#
> > +# When running in a nested HVM environment the L1 domain is acting
> > +# as both a guest to L0 and a host to L2 guests and therefore potentially
> > +# sees connections to two independent xenstore instances, one provided by
> > +# the L0 host and one which is provided by the L1 instance of xenstore.
> > +#
> > +# Unfortunately the kernel is not capable of dealing with this and is only
> > +# able to cope with a single xenstore connection. Since the L1 toolstack
> > and
> > +# L2 guests absolutely require xenstore to function we therefore cannot use
> > +# the L0 xenstore and therefore cannot use PV devices (xvdX etc) in the L1
> > +# guest and must use emulated devices (sdX etc).
> > +#
> > +# However at the moment we have not yet rebooted L1 into Xen and so it does
> > +# have PV devices available and sdb actually appears as xvdb. We could
> > +# disable the Xen platform device and use emulated devices for the install
> > +# phase too but that would be needlessly slow.
> > +
> > +my $vgname = $l1->{Vg};
> > +my $guest_storage_lv_name = "${l1_ident}_guest_storage";
> > +my $guest_storage_lv_size = guest_var($l1,'guest_storage_size',undef);
> > +die "guest_storage_lv_size is undefined" unless $guest_storage_lv_size;
> > +my $guest_storage_lvdev = "/dev/${vgname}/${guest_storage_lv_name}";
> > +
> > +die "toolstack $r{toolstack}" unless $r{toolstack} eq "xl";
> > +target_cmd_root($l0, < > +lvremove -f $guest_storage_lvdev ||:
> > +lvcreate -L ${guest_storage_lv_size}M -n $guest_storage_lv_name
> $vgname
> > +dd if=/dev/zero of=$guest_storage_lvdev count=10
> > +xl block-attach $l1->{Name} ${guest_storage_lvdev},raw,sdb,rw
> > +END
> > +
> > +# Create a vg in L1 guest and vg name is ${l1_gn}-disk
> > +target_cmd_root($l1, "pvcreate /dev/xvdb && vgcreate ${l1_gn}-disk
> /dev/xvdb");
>
> We would avoid having to mention /dev/xvdb if we created the VG in the
> host, before doing block-attach. I'm not sure whether that's an
> improvement.
>
I am sorry, I cannot get your point. Could you please make it more clear?
Thanks.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v11 4/7] Changes on test step of Debian hvm guest install
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Wednesday, June 10, 2015 9:41 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com; Hu,
> Robert
> Subject: Re: [OSSTEST Nested PATCH v11 4/7] Changes on test step of Debian hvm
> guest install
>
> longtao.pang writes ("[OSSTEST Nested PATCH v11 4/7] Changes on test step of
> Debian hvm guest install"):
> ...
> > 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. In L1 installation context, assign more memory (defined in runvar) to
> > it; Since it acts as a nested hypervisor anyway.
> > 3. Comment out CDROM entry in sources.list to make HTTP URL entry
> > available for L1 hvm guest.
> > 4. Enable nestedhvm feature in 'ExtraConfig' for nested job.
>
> I think this should be 3 separate patches:
>
> - Allow runvars to specify guest disk and ram size (turning
> previous values into defaults)
>
> - Comment out CDROM entry. This needs better motivation. I think
> your motivation is that the CDROM is removed and that therefore
> this line does not work ?
>
> - Honour $xopts{ExtraConfig} and use it to enable nestedhvm.
>
OK, we will try it.
>
> > +my $extra_config='';
> > +$extra_config .="nestedhvm=1\n"
> > +if guest_var($gho,"enable_nestedhvm",'false') eq 'true';
>
> Idiom elsewhere is =~ m/true/ rather than eq 'true'
> although maybe Wei will provide a guest_var_boolean (see my comments
> on his "[PATCH OSSTEST v3] Stubdom test case".
>
Yes, we will try it.
> > +# Use guest_var to get specific disk size, or will use default $disk_mb
> > +$disk_mb= guest_var($gho,'disksize',$disk_mb);
>
> I would prefer this comment and the one about RAM to be expressed,
> instead, like this:
>
> sub more_prepareguest_hvm (;@) {
> my ($ho, $gho, $ram_mb, $disk_mb, %xopts) = @_;
> + # $ram_mb and $disk_mb are defaults, used if runvars don't say
>
I am sorry, do you mean that I should add another more comment you preferred
in 'more_prepareguest_hvm (;@)' function inside TestSupport.pm?
>
> Thanks,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v11 4/7] Changes on test step of Debian hvm guest install
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, June 09, 2015 4:08 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 v11 4/7] Changes on test step of Debian hvm
> guest install
>
> On Tue, 2015-06-09 at 05:29 +, Pang, LongtaoX wrote:
> >
> >
> > > -Original Message-
> > > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > > Sent: Monday, June 08, 2015 6:31 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 v11 4/7] Changes on test step of Debian
> hvm
> > > guest install
> > >
> > > On Tue, 2015-05-26 at 17:08 +0800, longtao.pang wrote:
> > > > 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. In L1 installation context, assign more memory (defined in runvar) to
> > > > it; Since it acts as a nested hypervisor anyway.
> > > > 3. Comment out CDROM entry in sources.list to make HTTP URL entry
> > > > available for L1 hvm guest.
> > > > 4. Enable nestedhvm feature in 'ExtraConfig' for nested job.
> > > >
> > > > Signed-off-by: longtao.pang
> > >
> > > Acked-by: Ian Campbell
> > >
> > > One query:
> > > [...]
> > > > @@ -174,13 +185,18 @@ sub prep () {
> > > > if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
> > > > $ram_mb = $ram_lots;
> > > > } else {
> > > > -$ram_mb = 768;
> > > > +# Use guest_var to get specific memsize, or will use default
> > > > '768'
> > > > +$ram_mb= guest_var($gho,'memsize',768);
> > >
> > > I think this only happens if the host has less than "$ram_lots * 2 +
> > > $ram_minslop" (==10100M) free, otherwise you get $ram_lots (5000M),
> > > which might be less than the runvar asked for...
> > >
> > For nested job, the specific 'memsize' for L1 guest is 3072M which is
> > defined by
> make-flight.
> > If the "$ram_lots" equal to 5000M which is larger than 3072M, that's
> > suitable
> for nested L1 guest.
> > The condition for nested L1 guest's memory size that should not be less than
> 3072M, that's why we
> > add the code of "$ram_mb =guest_var($gho,'memsize',768)" here.
>
> I was talking about the general case, which is broken for any guest
> configured to have RAM > $ram_lots.
>
Thanks Ian, I get your point now.
>
> > > Perhaps what we really want (maybe in a followup patch is):
> > >
> > > $ram_mb = guest_var($gho,'memsize',undef);
> > > if (!$ram_mb) {
> > > if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
> > > $ram_mb = $ram_lots;
> > > } else {
> > > $ram_mb = 768;
> > > }
> > > }
> > > ?
> > >
> > So, I think maybe it's no need to change that.
> > Please correct me, if I am wrong.
>
Yes, your above patch is more suitable here and it's necessary to change the
code.
Could you please change this query in your branch, so that I will not summit
another version of nested patch to you?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v11 4/7] Changes on test step of Debian hvm guest install
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, June 08, 2015 6:31 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 v11 4/7] Changes on test step of Debian hvm
> guest install
>
> On Tue, 2015-05-26 at 17:08 +0800, longtao.pang wrote:
> > 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. In L1 installation context, assign more memory (defined in runvar) to
> > it; Since it acts as a nested hypervisor anyway.
> > 3. Comment out CDROM entry in sources.list to make HTTP URL entry
> > available for L1 hvm guest.
> > 4. Enable nestedhvm feature in 'ExtraConfig' for nested job.
> >
> > Signed-off-by: longtao.pang
>
> Acked-by: Ian Campbell
>
> One query:
> [...]
> > @@ -174,13 +185,18 @@ sub prep () {
> > if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
> > $ram_mb = $ram_lots;
> > } else {
> > -$ram_mb = 768;
> > +# Use guest_var to get specific memsize, or will use default '768'
> > +$ram_mb= guest_var($gho,'memsize',768);
>
> I think this only happens if the host has less than "$ram_lots * 2 +
> $ram_minslop" (==10100M) free, otherwise you get $ram_lots (5000M),
> which might be less than the runvar asked for...
>
For nested job, the specific 'memsize' for L1 guest is 3072M which is defined
by make-flight.
If the "$ram_lots" equal to 5000M which is larger than 3072M, that's suitable
for nested L1 guest.
The condition for nested L1 guest's memory size that should not be less than
3072M, that's why we
add the code of "$ram_mb =guest_var($gho,'memsize',768)" here.
> Perhaps what we really want (maybe in a followup patch is):
>
> $ram_mb = guest_var($gho,'memsize',undef);
> if (!$ram_mb) {
> if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
> $ram_mb = $ram_lots;
> } else {
> $ram_mb = 768;
> }
> }
> ?
>
So, I think maybe it's no need to change that.
Please correct me, if I am wrong.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v10 6/9] Changes on test step of Debian hvm guest install
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Wednesday, May 20, 2015 9:56 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 v10 6/9] Changes on test step of Debian hvm
> guest install
>
> On Wed, 2015-05-13 at 11:36 +0800, longtao.pang wrote:
> > @@ -59,7 +59,7 @@ d-i partman-auto/expert_recipe string \\
> > use_filesystem{ } filesystem{ vfat } \\
> > mountpoint{ /boot/efi } \\
> > . \\
> > -5000 50 5000 ext4 \\
> > +1 50 1 ext4 \\
>
> These three numbers are
>
> ::=___
>
> (from
> http://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/doc/devel/partman-a
> uto-recipe.txt)
>
> So here you are increasing the minimum size of the root partition for
> all debianhvm domains (including non-nested ones and L2 guests) from 5G
> to 10G.
>
> Did you test this with a normal L1 debianhvm guest (not one destined to
> be an L1 host). i.e. using test-amd64-amd64-xl-qemuu-debianhvm-amd64 ?
>
> The new size you have given is the same size as the entire disk in that
> case. I'm not sure what will then happen...
>
> Perhaps "5000 50 -1 ext4" does what you need, namely leaves the minimum
> alone and sets the maximum to unlimited, which I think will end up
> making this partition as big as the disk less the configured swap space.
>
> Ian.
I have ever used 'Debian-7.6.0-amd64-DVD-1.iso' as debianhvm_image which is
3.7G.
At that time, it's necessary to extend L1 guest's rootf size to '1' to
store the image.
Currently, I use 'Debian-7.2.0-amd64-CD-1.iso' as debianhvm_image which is just
624M,
the origin rootfs size of '5000' is sufficient to store this image and I have
tried that it works fine for nested job.
So, it's no need to extend guest's rootfs size anymore.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v10 0/9] Introduction of netsted HVM test job
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Wednesday, May 20, 2015 11:39 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 v10 0/9] Introduction of netsted HVM test
> job
>
> On Wed, 2015-05-13 at 11:36 +0800, longtao.pang wrote:
> > parsing grub which has 'submenu' primitive
> > Changes to support '/boot' leading paths of kernel, xen, in grub
> > Refactor installation of overlays for guest used
> > Edit some APIs in TestSupport.pm for nested test
> > Move the codes about memory size setting into prep()
>
> I've pushed the patches up to here into the osstest pretest branch from
> where it will be tested before becoming the production version of
> osstest.
>
> The next patch had a couple of comments which is why I stopped here.
> Also it is useful to let refactoring type stuff go through in a flight
> of its own.
>
> I made a couple of mods as I applied:
>
> In the first patch I adjusted an "if(stuff){" into "if (stuff) {"
>
> In the fourth patch I had to resolve a conflict with the newly added
> ${viftype} code. Since I was there I also made ${vifmodel} a prefixing
> thing like ${viftype} is for consistency.
>
I have git clone osstest source from
'git://xenbits.xen.org/people/ianc/osstest.git',
checkout ' nestedhvm-v10-pretest' branch. Is it a typo in
'Osstest/TestSupport.pm' or not?
vif = [ '${viftype}${vidmodel}mac=$gho->{Ether}' ]
I think it should be:
vif = [ '${viftype}${vifmodel}mac=$gho->{Ether}' ]
> I also included my "grub: remove patch to disable submenu from
> 20_linux_xen overlay" patch since it shouldn't be needed after your
> first change.
>
> I've pushed the resulting branch to:
> git://xenbits.xen.org/people/ianc/osstest.git
> nestedhvm-v10-pretest
>
> since you can't see it otherwise. If the tests don't pass for some
> reason we may need to rewind and try again, in which case you'll want to
> start with those versions.
>
> Test reports for osstest's own gate only go to Ian and myself, I'll copy
> the list and you as necessary, otherwise keep an eye on
> http://xenbits.xen.org/gitweb/?p=osstest.git;a=summary for your stuff
> showing up in master in a day or two.
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v9 7/9] Add new script to customize nested test configuration
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Wednesday, May 06, 2015 7:37 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 v9 7/9] Add new script to customize nested
> test configuration
>
> On Sat, 2015-05-02 at 14:28 +0800, longtao.pang wrote:
> > +# Since Ian Campbell's v5_patch[04,05,06] has a bug that the
> > +# 'preseed/late_command' are unavailable, so add below line here to
> > +# make HTTP URL entry available in sources.list for L1 hvm guest.
> > +# Onece the bug is fiexed, this line code could be removed.
> > +target_cmd_root($l1, "sed -i 's/^deb *cdrom/#&/g' /etc/apt/sources.list");
>
> This should be fixed in my v6 posting of that series.
>
> > +target_cmd_root($l1, "update-rc.d osstest-confirm-booted start 99 2 .");
> > +
> > +# Inside L0, create storage lv, attach this lv to L1, and then inside L1
> > using the
> storage for installing L2
> > +my $vgname = $l1->{Vg};
> > +my $guest_storage_lv_name = "${l1_ident}_guest_storage";
> > +my $guest_storage_lv_size = guest_var($l1,'guest_storage_size',undef);
> > +my $guest_storage_lvdev = "/dev/${vgname}/${guest_storage_lv_name}";
>
> Perhaps:
> die "guest_storage_lv_size" unless $guest_storage_lv_size;
> ?
>
> > +
> > +target_cmd_root($l0, < > +lvremove -f $guest_storage_lvdev ||:
> > +lvcreate -L ${guest_storage_lv_size}M -n $guest_storage_lv_name
> $vgname
> > +dd if=/dev/zero of=$guest_storage_lvdev count=10
>
> I have some ideas/plans on how to refactor things so we can use
> prepareguest_part_lvmdisk for secondary disks too, but this is OK as it
> is for now IMHO.
>
> > +xl block-attach $l1->{Name} ${guest_storage_lvdev},raw,sdb,rw
>
> This relies on/assumes the toolstack is xl (sorry for not spotting this
> before).
>
> Really it should use a new block_attach method on toolstack($ho) (i.e.
> Osstest/Toolstack/*.pm) so it can work with libvirt etc.
>
> However I think this hardcoding is tolerable for now (you've encoded
> that it is xl only in make-flight already), but please could you add
> near the top of this script:
>
> die "toolstack $r{toolstack}" unless $r{toolstack} eq "xl";
>
> so it fails in an immediately obvious way if someone tries this with
> another toolstack.
>
> Ian: Is that OK with you?
>
> > +END
> > +# This is probably a bug here, if we use 'xvdx' as block 'dev'
> > +# after installing xen and boot into xen kernel, the disk will not be
> > +# recognized by OS. Also, if we use 'sde' instead of 'sdb' as block 'dev',
> > +# after installing xen and boot into xen kernel, the disk will be
> > recognized
> > +# as 'sdb' not 'sde', so we will have to use 'sdb' here.
> > +
> > +target_install_packages_norec($l1, qw(lvm2 rsync genisoimage));
>
> Please can you put this above, just after the osstest-confirm-started
> stuff so that it is not mixed in with the stuff dealing with the
> additional disk.
>
> > +# After block-attach lvdev to L1, need to reboot L1 to make the attach
> > +# to take effect. I think this is a bug for kernel.
>
> I've just tried this and it worked for me, i.e. /dev/xvdb appears
> immediately after xl block-attach with no reboot required. Perhaps this
> was an artefact of a bug in some previous iteration of the series?
>
Thanks for trying, I tried it in my environment, a reboot is not required now.
I think this bug happened just because I have used '
Debian-7.6.0-amd64-DVD-1.iso ' as installing L1's guest OS before,
it did required a reboot and I assumed it's as a kernel bug.
According to you former comment, I change to use ' Debian-7.2.0-amd64-CD-1.iso'
as installing L1's guest OS.
I assumed that the bug still exist and keep to reboot L1 after block-attach
'lvdev'.
In fact, I should take a try for that, but I missed. Sorry for that.
So, the reboot action is no need now.
> I would replace this comment, and the "This is probably a bug here" and
> "Inside L0, create storage lv" ones above with a single (long) comment
> before all of this disk stuff which explains:
>
> We need to attach an extra disk to the L1 guest to be used as L2
> guest storage.
>
> When running in a nested HVM environment the L1 domain is acting
> as both
Re: [Xen-devel] [PATCH OSSTEST v5 04/24] Debian: refactor code to add preseed commands to the preseed file
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Friday, May 01, 2015 7:07 PM > To: ian.jack...@eu.citrix.com > Cc: Hu, Robert; Pang, LongtaoX; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH OSSTEST v5 04/24] Debian: refactor code to add > preseed commands to the preseed file > > On Wed, 2015-04-29 at 03:32 +0100, Ian Campbell wrote: > > On Wed, 2015-04-15 at 11:35 +0100, Ian Campbell wrote: > > > > > diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install > > > index cfd5144..95fce9a 100755 > > > --- a/ts-debian-hvm-install > > > +++ b/ts-debian-hvm-install > > > @@ -77,6 +77,9 @@ d-i preseed/late_command string \\ > > > in-target mkdir -p /root/.ssh; \\ > > > in-target sh -c "echo -e '$authkeys'> > > > /root/.ssh/authorized_keys"; > > > END > > > + > > > +$preseed_file .= preseed_hook_cmds(); > > > > Longtao reused this patch for his nestedhvm testing series and > > discovered a bug. The use of preseed_hook_cmds shadows the > > preseed/late_command which is just visible here in the patch context > > meaning that the authorized keys and update-rc.d are not actually run. > > > > The code snippet needs to use a "preseed_hook_command($ho, > > 'late_command', $sfx, < > > > I'll fix this up in the next iteration. > > I intend to squash the following incremental patch into "Debian: > refactor code to add preseed commands to the preseed file" in the next > posting. I've not yet tested it, I'll kick something off over the > weekend and hopefully repost next week. > > commit c663ce9b76dc3b2c2e1d900d65b58f50f2ee36c5 > Author: Ian Campbell > Date: Fri May 1 12:01:47 2015 +0100 > > squash!Debian: refactor code to add preseed commands to the preseed file > > v6: Use preseed_hook_command rather than an "d-i preseed/late_comman" > entry in the preseed file in ts-debian-hvm-install. The former is > overwritten by the result of preseed_hook_cmds. > > diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install > index 0085d82..98e5d76 100755 > --- a/ts-debian-hvm-install > +++ b/ts-debian-hvm-install > @@ -69,10 +69,11 @@ d-i partman-auto/expert_recipe string \\ > . > > d-i apt-setup/cdrom/set-first boolean false > +END > > -d-i preseed/late_command string \\ > -in-target mkdir -p /boot/efi/EFI/boot; \\ > -in-target cp /boot/efi/EFI/debian/grubx64.efi > /boot/efi/EFI/boot/bootx64.efi ;\\ > +preseed_hook_command($ho, 'late_command', '', < +in-target mkdir -p /boot/efi/EFI/boot > +in-target cp /boot/efi/EFI/debian/grubx64.efi > /boot/efi/EFI/boot/bootx64.efi > END > > $preseed_file .= preseed_hook_cmds(); > I have verified this squash patch in my environment. After push in this patch based on your former v5_patch [04,05,06], the 'late_command' work fine. So, I could add ' in-target sed -i 's/^deb *cdrom/#&/g' /etc/apt/sources.list;' code in late_command to disable 'cdrom' entry to make HTTP URL entry available in sources.list for L1 hvm guest. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v8 5/7] Add new script to customize nested test configuration
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Thursday, April 23, 2015 7:30 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 5/7] Add new script to customize nested
> test configuration
>
> On Thu, 2015-04-23 at 17:38 +0800, Robert Hu wrote:
> > > > As mentioned in [ Patch], 'nested_l1' is ident for L1 guest VM,
> > > > 'nestedl1' is hostname for L1 guest VM.
> > > > ' store_runvar('nested_l1',$l1->{Guest});' is used to store L1's ident
> > > > and L1's hostname to database, that will be used for 'selecthost()'
> > > > function in later script.
> > >
> > > Having a runvar with the bare ident as a name doesn't seem right.
> > > Perhaps you want to be writing to $r{"${ident}_hostname"} or some such?
> > >
> > > What do you actually need the hostname for anyway?
> > Look at selecthost()
> > sub selecthost ($) {
> > my ($ident) = @_;
> > # must be run outside transaction
> > my $name;
> > if ($ident =~ m/=/) {
> > $ident= $`;
> > $name= $'; #'
> > $r{$ident}= $name;
> > } else {
> > $name= $r{$ident};
> > die "no specified $ident" unless defined $name;
> > }
> > ...
> >
> > When in L1 iteration invocation of ts-debian-hvm-install(), the ident
> > passed in is L1 ident ("nested_l1"). Here the 'else' branch will need
> > $r{$ident}, whose value shall be L1's name. Therefore we prepare this
> > runvar in advance.
>
> Ah I see, today usually the ident is "host" or "dst_host" or "src_host"
> so I got confused by it just being "nested_l1" here.
>
> In the normal case today the ident runvars are set by ts-hosts-allocate.
> That can't apply to the nested case since it is allocating a guest and
> not a host, so your ts-nested-setup seems like a reasonable enough place
> to do it.
>
> However, I don't think there is any reason for the indent, hostname and
> guest name to differ, and I think perhaps it would be clearer to write
> this as:
> our $l1_ident = $gho->{Guest};
> store_runvar($l1_ident, $gho->{Guest});
> So that it is clear to the reader that this runvar is an ident. I
> suppose a code comment would work as well (or in addition perhaps).
>
> > >
> > > > > Most places you seem to use nestedl1, not nested_l1. I think you ended
> > > > > up with this due to not using guest_var and the various hardcoding
> > > > > you've done elsewhere. I suspect with all that fixed and make-flight
> > > > > updated accordingly you won't need this var any more.
> > > > >
> > > > I think I should define L1 ident with " my $l1_ident = 'nested_l1' in
> 'ts-nested-setup'
> > >
> > > Hardcoding anything like that in ts-nested-setup seems wrong to me.
> > >
> > > The ident should come from the script's parameters (i.e. be part of the
> > > sg-run-job invocation of the script).
> > >
> > > Imagine a hypothetical nested-virt migration test, in that scenario you
> > > would want to run ts-nested-setup on two hosts, both nestedl1src and
> > > nestedl2dst in order to configure things. That's why we don't hardcode
> > > such things.
> > >
> > so to summarize, ts-nested-setup will be invoked with parameters of
> > $l0_ident, $l1_ident and $l1_name?
> > or only parameters of $l0_ident and $l1_ident, if we have setup
> > $l1_ident->$l1_name mapping in runvar when in l0's iteration of
> > ts-debian-hvm-install.
> > which would you prefer?
>
> $l1_ident and $l1_name should be the same, I think. Semantically the
> script should be taking $l0_ident and $l1_ident, where $l0 here is a
> host and $l1 here is a guest, so infact isn't $l1_nae just $l1->{Guest}?
>
> (Things get confusing because $l1 can be a Guest or a Host depending on
> which test script we are in)
>
> > > > > > +store_runvar("$l1->{Guest}_ip",$l1->{Ip});
> > > > > > +
> > > > > > +my $l2_disk_mb = 2;
> > > > > > +my $l2_lv_name = 'nestedl2-disk';
> > > > > > +my $vgname = $l0->{Name};
> > > > > > +$vgname .= ".$c
Re: [Xen-devel] [OSSTEST Nested PATCH v8 6/7] Compose the main recipe of nested test job
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Wednesday, April 22, 2015 7:24 PM
> To: Pang, LongtaoX
> Cc: wei.l...@citrix.com; Hu, Robert; ian.jack...@eu.citrix.com;
> xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [OSSTEST Nested PATCH v8 6/7] Compose the main recipe
> of nested test job
>
> On Wed, 2015-04-22 at 12:04 +0100, Ian Campbell wrote:
> > On Wed, 2015-04-22 at 08:38 +, Pang, LongtaoX wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > > > Sent: Tuesday, April 21, 2015 6:49 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 v8 6/7] Compose the main recipe of
> nested
> > > > test job
> > > >
> > > > On Mon, 2015-04-13 at 17:19 -0400, longtao.pang wrote:
> > > > > Signed-off-by: longtao.pang
> > > > > ---
> > > > > Changes in v8:
> > > > > Change the patch order from 6 to 5.
> > > > > ---
> > > > > sg-run-job | 11 +++
> > > > > 1 file changed, 11 insertions(+)
> > > > >
> > > > > diff --git a/sg-run-job b/sg-run-job
> > > > > index eae159d..2ca5ebf 100755
> > > > > --- a/sg-run-job
> > > > > +++ b/sg-run-job
> > > > > @@ -299,6 +299,17 @@ proc run-job/test-pair {} {
> > > > > #run-ts . remus-failover ts-remus-check src_host dst_host
> +
> > > > debian
> > > > > }
> > > > >
> > > > > +proc need-hosts/test-nested {} {return host}
> > > > > +proc run-job/test-nested {} {
> > > > > +run-ts . = ts-debian-hvm-install + host + nestedl1
> > > > > +run-ts . = ts-nested-setup + host + nestedl1
> > > > > +run-ts . = ts-xen-install nested_l1
> > > > > +run-ts . = ts-host-reboot nested_l1
> > > > > +run-ts . = ts-debian-hvm-install nested_l1 nestedl2
> > > > > +run-ts . = ts-guest-stop nested_l1 nestedl2
> > > > > +run-ts . = ts-guest-destroy host nestedl1
> > > >
> > > > Based on my comments to previous patches I think you'll want to use
> > > > nestedl1 and nestedl2 consistently and never nested_l1/nested_l2.
> > > >
> > > nestedl1 nestedl2 are hostname for L1 guest VM and L2 guest VM,
> > > nested_l1 and nested_l2 are ident for L1 and L2.
> >
> > Hostnames shouldn't be appearing in this script, I don't think,
> > certainly not bare like that.
> >
> > For the physical i.e. l0 case I think what happens is that
> > need-hosts/foo ends up returning a bunch of $ident=$an_actual_host. i.e.
> > srchost=$hosta and dsthost=$hostb.
> >
> > I'm not sure how that would work in the nested world, but maybe you
> > should be writing $ident=$guestname (i.e. nested_l1=nestedl1)?
> >
> > Ian?
>
> Ian is still plugging in his computers after moving desks. But having
> spoken to him IRL it seems I'm not quite right above.
>
> The arguments passed to ts-* in sg-run-job should _always_ be just a
> bare indent. The ident=foo thing is a special case for standalone mode.
>
Do you means that the parameter passed to ts-* in sg-run-job should _always_ be
just a bare ident?
If yes. I think it needs to pass l1's '$gn' which is not a bare ident to
'ts-debian-hvm-install' for installing L1 guest VM, since the default '$gn ||=
'debianhvm' if no other '$gn' was passed to this script, but for nested job we
expect a different '$gn' from 'debianhvm', such as 'nestedl1'. So it need to
pass 'host' and 'nestedl1' to 'ts-debian-hvm-install' script.
+run-ts . = ts-debian-hvm-install + host + nestedl1
For 'ts-nested-setup' script, it need to call 'ts_get_host_guest' which need
two parameters 'host' and 'nestedl1' to get $l0 and $l1 scope, so it also need
to pass 'nestedl1' to this script.
For ' ts-guest-destroy', it also need two parameters of 'host' and 'nestedl1'
which is L1's '$gn'.
> However, Ian did also say (and I agreed) that there really isn't any
> reason why the ident and the hostname should differ here (or indeed the
> guest name from l0's point of view, modulo the suffix osstest sometimes
> adds).
>
> Ian.
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v8 5/7] Add new script to customize nested test configuration
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, April 21, 2015 6:40 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 v8 5/7] Add new script to customize nested
> test configuration
> > Signed-off-by: longtao.pang
> > ---
> > Changes in v8:
> > 1. Replace '$nested_host' by '$l1->{Guest}'.
> > ---
> > ts-nested-setup | 52
>
> > 1 file changed, 52 insertions(+)
> > create mode 100755 ts-nested-setup
> >
> > diff --git a/ts-nested-setup b/ts-nested-setup
> > new file mode 100755
> > index 000..41d5e80
> > --- /dev/null
> > +++ b/ts-nested-setup
> > @@ -0,0 +1,52 @@
> > +#!/usr/bin/perl -w
> > +
> > +use strict qw(vars);
> > +use DBI;
> > +use Osstest;
> > +use Osstest::Debian;
> > +use Osstest::TestSupport;
> > +
> > +tsreadconfig();
> > +our ($l0,$l1) = ts_get_host_guest(@ARGV);
> > +
> > +guest_check_ip($l1);
> > +target_cmd_root($l1, "mkdir -p /home/osstest/.ssh && cp
> /root/.ssh/authorized_keys /home/osstest/.ssh/");
> > +my $url =
> $c{WebspaceUrl}.$c{WebspaceCommon}.$l0->{Name}."_".'overlay.tar';
> > +target_cmd_root($l1, < > +wget -O overlay.tar $url
> > +tar -xf overlay.tar -C /
> > +rm overlay.tar -f
> > +update-rc.d osstest-confirm-booted start 99 2 .
> > +END
>
> I cc'd you on some patches which I think should help avoid this
> duplication.
>
For this question, I have merged the v5_patches[04,05,06] which you CC'd to me.
Based on your patches, after finishing installing L1 hvm guest VM with
'ts-debian-hvm-install' script, I could ssh into L1 guest as 'osstest' user
without password, that means I will not need to use below code anymore
target_cmd_root($l1, "mkdir -p /home/osstest/.ssh && cp
/root/.ssh/authorized_keys /home/osstest/.ssh/");
But, inside L1 guest VM, the overly files(osstest-confirm-booted, xenbridge,
xenlightdaemons ) does not exist at " /etc/init.d" directory. Since
'ts-host-reboot' script will use 'osstest-confirm-booted' shell script to
confirm whether L1 guest boot up normally, these overlay files are necessary
here.
If I add below patch based on your patches, and install L1 hvm guest VM again,
all the overly files exist in "/etc/init.d" directory inside L1 guest.
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 6691ff6..4af6957 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -624,6 +624,7 @@ sub preseed_base (;@) {
preseed_ssh($ho, $sfx);
preseed_hook_overlay($ho, $sfx, $c{OverlayLocal}, 'overlay-local.tar');
+preseed_hook_overlay($ho, $sfx, 'overlay', 'overlay.tar');
my $preseed = <<"END";
d-i mirror/suite string $suite
Another question, based on your patches, I find that the below commands under '
d-i preseed/late_command string \\' do not work anymore in preseed () ' of
'ts-debian-hvm-install' script. For example, after finishing installing L1
guest, there is no directory of '/boot/efi/EFI/boot' created and 'sources.list'
does not be edited by sed inside L1 guest. I think you have verified this,
maybe something wrong of my test environment to cause the question?
d-i preseed/late_command string \\
in-target mkdir -p /boot/efi/EFI/boot; \\
in-target cp /boot/efi/EFI/debian/grubx64.efi
/boot/efi/EFI/boot/bootx64.efi ;\\
in-target sed -i 's/^deb *cdrom/#&/g' /etc/apt/sources.list;
END
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v8 6/7] Compose the main recipe of nested test job
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, April 21, 2015 6:49 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 v8 6/7] Compose the main recipe of nested
> test job
>
> On Mon, 2015-04-13 at 17:19 -0400, longtao.pang wrote:
> > Signed-off-by: longtao.pang
> > ---
> > Changes in v8:
> > Change the patch order from 6 to 5.
> > ---
> > sg-run-job | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/sg-run-job b/sg-run-job
> > index eae159d..2ca5ebf 100755
> > --- a/sg-run-job
> > +++ b/sg-run-job
> > @@ -299,6 +299,17 @@ proc run-job/test-pair {} {
> > #run-ts . remus-failover ts-remus-check src_host dst_host +
> debian
> > }
> >
> > +proc need-hosts/test-nested {} {return host}
> > +proc run-job/test-nested {} {
> > +run-ts . = ts-debian-hvm-install + host + nestedl1
> > +run-ts . = ts-nested-setup + host + nestedl1
> > +run-ts . = ts-xen-install nested_l1
> > +run-ts . = ts-host-reboot nested_l1
> > +run-ts . = ts-debian-hvm-install nested_l1 nestedl2
> > +run-ts . = ts-guest-stop nested_l1 nestedl2
> > +run-ts . = ts-guest-destroy host nestedl1
>
> Based on my comments to previous patches I think you'll want to use
> nestedl1 and nestedl2 consistently and never nested_l1/nested_l2.
>
nestedl1 nestedl2 are hostname for L1 guest VM and L2 guest VM, nested_l1 and
nested_l2 are ident for L1 and L2.
> You may also need to pass an extra nestedl2 to ts-nested-setup based on
> my feedback there.
>
> What testid's does this all generate? If you run
> ./standalone run-job --simulate | grep testid
> (If your osstest doesn't include the --simulate option yet then either
> upgrade or set OSSTEST_SIMULATE=1 in your environment)
>
Could you please make it clear, since I failed to run the above command, or do
I need some other settings?
For example: './standalone run-job --simulate test-amd64-amd64-xl | grep
testid', just get below messages:
#./standalone run-job --simulate test-amd64-amd64-xl | grep testid
Could not open a connection to your authentication agent.
WARNING: Unable to access ssh-agent. Some tests may fail
run-job: Need a host
> Then it will include a load of lines like
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 1
> testid build-check(1) ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 2
> testid hosts-allocate ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 3
> testid host-install(3) ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 4
> testid host-ping-check-native ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 5
> testid xen-install ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 6
> testid xen-boot ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 7
> testid host-ping-check-xen ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 8
> testid leak-check/basis(8) ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 9
> testid debian-install ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 10
> testid debian-fixup ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 11
> testid guest-start ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 12
> testid migrate-support-check ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 13
> testid guest-saverestore ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 14
> testid guest-localmigrate ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 15
> testid guest-saverestore.2 ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 16
> testid guest-localmigrate.2 ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 17
> testid guest-localmigrate/x10 ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 18
> testid guest-stop ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 19
> testid guest-start.2 ==
> 2015-04-21 10:44:57 Z standalone.test-amd64-amd64-xl == 20
> testid guest-start/debian.repeat =
Re: [Xen-devel] [OSSTEST Nested PATCH v8 5/7] Add new script to customize nested test configuration
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, April 21, 2015 6:40 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 v8 5/7] Add new script to customize nested
> test configuration
>
> On Mon, 2015-04-13 at 17:19 -0400, longtao.pang wrote:
> > 1. In this script, make some appropriate runvars which selecthost would
> > recognise.
> > 2. Prepare the configurations for installing L2 guest VM.
> > 3. Create a lv disk in L0 and hot-attach it to L1, need to restart L1 to
> > make the block disk to be recognized by L1 system, then using this disk
> > to create a VG that used for installing L2.
> >
> > Signed-off-by: longtao.pang
> > ---
> > Changes in v8:
> > 1. Replace '$nested_host' by '$l1->{Guest}'.
> > ---
> > ts-nested-setup | 52
>
> > 1 file changed, 52 insertions(+)
> > create mode 100755 ts-nested-setup
> >
> > diff --git a/ts-nested-setup b/ts-nested-setup
> > new file mode 100755
> > index 000..41d5e80
> > --- /dev/null
> > +++ b/ts-nested-setup
> > @@ -0,0 +1,52 @@
> > +use strict qw(vars);
> > +use DBI;
> > +use Osstest;
> > +use Osstest::Debian;
> > +use Osstest::TestSupport;
> > +
> > +tsreadconfig();
> > +our ($l0,$l1) = ts_get_host_guest(@ARGV);
> > +
> > +guest_check_ip($l1);
> > +target_cmd_root($l1, "mkdir -p /home/osstest/.ssh && cp
> /root/.ssh/authorized_keys /home/osstest/.ssh/");
> > +my $url =
> $c{WebspaceUrl}.$c{WebspaceCommon}.$l0->{Name}."_".'overlay.tar';
> > +target_cmd_root($l1, < > +wget -O overlay.tar $url
> > +tar -xf overlay.tar -C /
> > +rm overlay.tar -f
> > +update-rc.d osstest-confirm-booted start 99 2 .
> > +END
>
> I cc'd you on some patches which I think should help avoid this
> duplication.
>
I am trying that.
> > +
> > +store_runvar('nested_l1',$l1->{Guest});
>
> I'm not sure what this is for and it would normally be wrong to hardcode
> nested_l1 like that, where is it used?
>
As mentioned in [ Patch], 'nested_l1' is ident for L1 guest VM, 'nestedl1'
is hostname for L1 guest VM.
' store_runvar('nested_l1',$l1->{Guest});' is used to store L1's ident and L1's
hostname to database, that will be used for 'selecthost()' function in later
script.
> Most places you seem to use nestedl1, not nested_l1. I think you ended
> up with this due to not using guest_var and the various hardcoding
> you've done elsewhere. I suspect with all that fixed and make-flight
> updated accordingly you won't need this var any more.
>
I think I should define L1 ident with " my $l1_ident = 'nested_l1' in
'ts-nested-setup'
> > +store_runvar("$l1->{Guest}_ip",$l1->{Ip});
> > +
> > +my $l2_disk_mb = 2;
> > +my $l2_lv_name = 'nestedl2-disk';
> > +my $vgname = $l0->{Name};
> > +$vgname .= ".$c{TestHostDomain}" if ($l0->{Suite} =~ m/lenny/);
> > +target_cmd_root($l0, < > +lvremove -f /dev/${vgname}/${l2_lv_name} ||:
> > +lvcreate -L ${l2_disk_mb}M -n $l2_lv_name $vgname
> > +dd if=/dev/zero of=/dev/${vgname}/${l2_lv_name} count=10
>
> I think you can do all of this by passing a suitable l2 $gho to
> prepareguest_part_lvmdisk, can't you?
>
> I think you can get that by my $l2 = selectguest($ARGV[], $l1).
>
I think I could try it, that means I will add more parameters for
'ts-nested-setup' script, not just 'host' and 'nestedl1'.
> Where ARGV[] is a new parameter passed by sg-run-job i.e. nestedl2,
> i.e. the one after whatever ts_get_host_guest consumes at the top of the
> file (so ARGV[2] perhaps?).
>
Also, I think if use ' prepareguest_part_lvmdisk', I need set 'nestedl2_vg' and
'nestedl2 _disk_lv' by make-flight.
But, when reuse 'ts-debian-hvm-install' to install L2, the '
prepareguest_part_lvmdisk' will be executed again(in 'more_prepareguest_hvm'
function), then there will be multi runvars for 'nestedl2_vg' and
'nestedl2_disk_lv' in standalone.db, is that OK? Please correct me if I am
wrong.
> Once you have that $l2 you can then use guest_var for e.g. the size,
> which will be good because it will be picked up by your modifications to
> ts-debian-hvm-install such that they automatically match.
>
> > +xl block-attach $l1->{Name} /dev/${vgname}/${l2_lv_name},raw,sdb,rw
>
> You use sdb here, but xvdb below. I think xvdb would work here, or to
> avoid HVM confusion wrt SCSI vs PV perhaps use xvde throughout (since it
> has no emulated counterpart by default IIRC)?
>
I think so, need a try.
> > +END
> > +target_install_packages_norec($l1, qw(lvm2 rsync genisoimage));
> > +target_reboot($l1);
> > +target_cmd_root($l1, "pvcreate /dev/xvdb && vgcreate ${l2_lv_name}_vg
> /dev/xvdb");
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v8 3/7] Edit some APIs in TestSupport.pm for nested test
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, April 21, 2015 10:44 PM
> To: Ian Jackson
> 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
>
> On Tue, 2015-04-21 at 15:30 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [OSSTEST Nested PATCH v8 3/7] Edit some APIs in
> TestSupport.pm for nested test"):
> > > On Tue, 2015-04-21 at 14:28 +0100, Ian Jackson wrote:
> > > > I'm only objecting to the involvement of the host property machinery.
> > >
> > > I'm afraid I'm not 100% sure I understand, but do you just mean that
> > > longtao should assign to $ho->{Ip} directly within selecthost instead of
> > > using $setprop to set the IpAddr hostprop and therefore indirectly
> > > ->{Ip}?
> >
> > Yes.
> >
> > > IOW the existing code in selecthost which looks up the IpAddr host prop
> > > into $ho->{IpStatic} and then into $ho->{Ip} should prefer the runvar to
> > > the host db if it is set?
> >
> > Yes.
>
> Good. Longtao, do you understand what is needed here?
>
I think I get it, use ${ident} rather than ${name} and assign L1's IP to
$ho->{Ip} directly.
The code will be like:
if ( $r{"${ident}_ip"} ) {
$ho->{Ip}= $r{"${ident}_ip"};
}
> > > BTW, what is the difference between ->{Ip} and ->{IpStatic} and should
> > > the runvar be reflected in both or just in ->{Ip}?
> >
> > AFAICT the only difference is that only IpStatic is used for expanding
> > `ipaddr' and `ipaddrhex' in the patterns for dhcp pxe configurations.
> >
> > There is an incipient problem here: our existing setup does not
> > require that osstest has complete control of the pxe config file for
> > every host on the network. And indeed the Citrix (Cambridge) instance
> > lacks such control.
> >
> > Instead there are some symlinks etc. The mg-hosts mkpxedir subcommand
> > arranges to delegate the DHCP from root to the osstest user (and
> > group), by making an appropriate subdirectory with the right
> > permissions, and a suitable symlink.
> >
> > It's not quite clear to me how this should work for nested HVM hosts.
>
> I think this is OK with the current design because the nested HVM host
> is not PXE booted, it is installed as a guest but preseeded to look a
> lot like a host (quite a lot of sharing in the preseed creation) and
> then tailored into a more host-like thing by things like this IP addr
> runvar.
>
> So I think from what you are saying that the ->{Ip} and ->{IpStatic}
> distinction here is correct and a host which is really a guest should
> not have nor use ->{IpStatic} (we want e.g. attempts to create a pxe dir
> to fail).
>
> Longtao, the conclusion is that the runvar should only appear in ->{Ip}.
>
> ->{IpStatic} should be left untouched (i.e. not initialised).
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v7 4/6] Add new script to custmize nested test configuration
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Wednesday, April 01, 2015 4:59 PM > To: Pang, LongtaoX; ian.jack...@eu.citrix.com > Cc: xen-devel@lists.xen.org; wei.l...@citrix.com; Hu, Robert > Subject: Re: [OSSTEST Nested PATCH v7 4/6] Add new script to custmize nested > test configuration > > On Wed, 2015-04-01 at 08:45 +, Pang, LongtaoX wrote: > > > As it happens I was rebasing that series this morning but due to > > > other issues I've not managed to run it yet. Once I've managed to at > > > least smoke test I'll CC you on the repost. > > > > > OK. What's more, for the below codes which is used for starting > > 'osstest-confirm-booted' script to confirm whether L1 is fully booted > > after reboot it. I think it's necessary here. > > > +target_cmd_root($l1, < > +wget -O overlay.tar $url > > +tar -xf overlay.tar -C / > > +rm overlay.tar -f > > +update-rc.d osstest-confirm-booted start 99 2 . > > +END > > In my distro series I also have some patches refactoring the overlay stuff, > which > would mean you could reuse that. > http://article.gmane.org/gmane.comp.emulators.xen.devel/224433 > I'll CC you on that one too. > > I don't think there would be any harm in adding those overlays for all guests > and enabling the initscript, but Ian may disagree or know something which I > don't. > I have modified and updated the v7 patches that according to your reply. It seems that your patchs[v4 04,05,06] has not been pushed into OSSTest master tree, should I waiting for that till these patches pushed or release my v8 nested patches to you firstly? Since we prepared this for a long time. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v7 5/6] Add test job for nest test case
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, March 31, 2015 10:23 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 5/6] Add test job for nest test case
>
> On Fri, 2015-03-27 at 19:06 -0400, longtao.pang wrote:
> > Changes in v7:
> > diff --git a/make-flight b/make-flight index 8ac3a87..b8f266f 100755
> > --- a/make-flight
> > +++ b/make-flight
> > @@ -204,6 +204,26 @@ 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
>
> You can do these on a line each, or even combine into one test. i.e.
>
> if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then return; fi
>
I'm sorry I find that the 'if' condition is not appropriate in v7 patch, it
should be
if [ $xenarch != amd64 -a $dom0arch != amd64 ]; then return; fi
> > +
> > + job_create_test test-$xenarch$kern-$dom0arch-nested test-nested xl \
> > + $xenarch $dom0arch \
> > +nested_image=$NESTED_OS_IMAGE \
> > +nested2_image=$NESTED_OS_IMAGE \
>
> I think for clarity you should use something like nestedl1 and nestedl2 for
> the
> runvar names.
>
'nested' and 'nested2' are guest name of L1 and L2 guest VM. Since "$specimage"
is accessed from "$r{"$gho->{Guest}_image"}" which defined in the function of '
target_put_guest_image'. So, maybe 'nested' and 'nested2' are available here, I
think.
> > +bios=seabios \
> > +kernbuildjob=build-amd64-pvops \
> > +kernkind=pvops \
> > +nested_vifmodel='e1000' \
> > +device_model_version=qemu-xen \
> > +all_hostflags=$most_hostflags,hvm }
> > +
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v7 4/6] Add new script to custmize nested test configuration
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, March 31, 2015 10:14 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 4/6] Add new script to custmize nested
> test configuration
>
> On Fri, 2015-03-27 at 19:06 -0400, longtao.pang wrote:
> > 1. In this script, make some appropriate runvars which selecthost
> > would recognise.
> > 2. Prepare the configurations for installing L2 guest VM.
> > 3. Create a lv disk in L0 and hot-attach it to L1, need to restart L1
> > to make the block disk to be recognized by L1 system, then using this
> > disk to create a VG that used for installing L2.
> >
> > Signed-off-by: longtao.pang
> > ---
> > Changes in v7:
> > Add new ts script for nested configuration according maintainer's reply.
> > ---
> > ts-nested-setup | 54
> ++
> > 1 file changed, 54 insertions(+)
> > create mode 100755 ts-nested-setup
> >
> > diff --git a/ts-nested-setup b/ts-nested-setup new file mode 100755
> > index 000..153c4a3
> > --- /dev/null
> > +++ b/ts-nested-setup
> > @@ -0,0 +1,54 @@
> > +#!/usr/bin/perl -w
> > +# This is part of "osstest", an automated testing framework for Xen.
> > +# Copyright (C) 2015 Intel Inc.
> > +#
> > +# 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/>.
> > +
> > +use strict qw(vars);
> > +use DBI;
> > +use Osstest;
> > +use Osstest::Debian;
> > +use Osstest::TestSupport;
> > +
> > +tsreadconfig();
> > +our ($ident_l0,$nested_host) = @ARGV;
>
> You don't used $ident and I think all your uses of $nested_host can be
> replaced
> by $l1->{Guest} using the result of the ts_get_host_guest.
>
> > +our ($l0,$l1) = ts_get_host_guest(@ARGV);
> > +
> > +guest_check_ip($l1);
> > +target_cmd_root($l1, "mkdir -p /home/osstest/.ssh && cp
> > +/root/.ssh/authorized_keys /home/osstest/.ssh/"); my $url =
> > +$c{WebspaceUrl}.$c{WebspaceCommon}.$l0->{Name}."_".'overlay.tar';
> > +target_cmd_root($l1, < > +wget -O overlay.tar $url
> > +tar -xf overlay.tar -C /
> > +rm overlay.tar -f
> > +update-rc.d osstest-confirm-booted start 99 2 .
> > +END
>
> I think the need for this goes away with
> http://article.gmane.org/gmane.comp.emulators.xen.devel/224420
> from my distro test flight series.
>
> As it happens I was rebasing that series this morning but due to other issues
> I've not managed to run it yet. Once I've managed to at least smoke test I'll
> CC
> you on the repost.
>
OK. What's more, for the below codes which is used for starting
'osstest-confirm-booted' script to confirm whether L1 is fully booted after
reboot it. I think it's necessary here.
+target_cmd_root($l1, < > +store_runvar('nested_l1',$nested_host);
> > +store_runvar("${nested_host}_ip",$l1->{Ip});
> > +store_runvar('multi_reboot_time',5);
>
> I think you said in a previous patch that this last one isn't needed any more?
>
> > +my $l2_disk_mb = 2;
> > +my $l2_lv_name = 'nestedl2';
> > +my $vgname = $l0->{Name};
> > +$vgname .= ".$c{TestHostDomain}" if ($l0->{Suite} =~ m/lenny/);
> > +target_cmd_root($l0, < > +lvremove -f /dev/${vgname}/${l2_lv_name} ||:
> > +lvcreate -L ${l2_disk_mb}M -n $l2_lv_name $vgname
> > +dd if=/dev/zero of=/dev/${vgname}/${l2_lv_name} count=10
> > +xl block-attach $l1->{Name}
> > +/dev/${vgname}/${l2_lv_name},raw,sdb,rw
>
> This attach won't be persistent over domain destroy, is that expected?
>
We need create a logical volume in L0 and attach it to L1 for L2 VM installing.
Before creating, it will remove the logical volume with the same "$l2_lv_name"
that has already existed.
Yes, after destroyed L1 VM, the logical volume will still exist inside L0, but
there is no harm, I think.
> > +END
> > +target_install_packages_norec($l1, qw(lvm2 rsync genisoimage));
> > +target_reboot($l1); target_cmd_root($l1, "pvcreate /dev/xvdb &&
> > +vgcreate ${l2_lv_name}_vg /dev/xvdb");
>
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v7 5/6] Add test job for nest test case
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, March 31, 2015 10:23 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 5/6] Add test job for nest test case
>
> On Fri, 2015-03-27 at 19:06 -0400, longtao.pang wrote:
> > 1. This patch adds creation of the nested test job, when job creation
> > procedure is invoked.
> > 2. 'NESTED_OS_IMAGE' is the name of 'Debian ISO Images', which defined
> > in standalone.config.
>
> It will need to be defined in production-config too, and it will need to be
> made
> available on the infra, which probably involves you telling us which ISO is
> needed.
>
> Or even better, use the same value as the existing Debian test, i.e.
> debian-7.2.0-amd64-CD-1.iso which is hardcoded in make-flight but would be
> better off refactored into production-config
>
We create a 'standalone.config' and defined 'export
NESTED_OS_IMAGE=debian-7.6.0-amd64-DVD-1.iso' in this config.
I'm sorry, what's 'production-config' used for? It seems that we have not used
it before. Could you please make it more clearly?
> > 3. Set nested L1's vif model as e1000 by make-flight.
> >
> > Signed-off-by: longtao.pang
>
> I think this needs to go after the next patch, else the recipe doesn't exist
> yet.
>
I'm sorry, I don't understand your meaning. Could you please make it more
clearly?
> > ---
> > Changes in v7:
> > Set L1's vif model as e1000 in runvar by make-flight.
> > ---
> > make-flight | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/make-flight b/make-flight index 8ac3a87..b8f266f 100755
> > --- a/make-flight
> > +++ b/make-flight
> > @@ -204,6 +204,26 @@ 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
>
> You can do these on a line each, or even combine into one test. i.e.
>
> if [ $xenarch != amd64 -o $dom0arch != amd64 ]; then return; fi
>
> > +
> > + job_create_test test-$xenarch$kern-$dom0arch-nested test-nested xl \
> > + $xenarch $dom0arch \
> > +nested_image=$NESTED_OS_IMAGE \
> > +nested2_image=$NESTED_OS_IMAGE \
>
> I think for clarity you should use something like nestedl1 and nestedl2 for
> the
> runvar names.
>
> > +bios=seabios \
> > +kernbuildjob=build-amd64-pvops \
> > +kernkind=pvops \
> > +nested_vifmodel='e1000' \
> > +device_model_version=qemu-xen \
> > +all_hostflags=$most_hostflags,hvm }
> > +
> > do_hvm_debian_test_one () {
> >testname=$1
> >bios=$2
> > @@ -430,6 +450,7 @@ test_matrix_do_one () {
> > done
> >
> >fi
> > + do_hvm_debian_nested_tests
> >do_passthrough_tests
> > }
> >
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v7 3/6] Changes on test step of debain hvm guest install
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, March 31, 2015 9:56 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 3/6] Changes on test step of debain
> hvm guest install
>
> On Fri, 2015-03-27 at 19:06 -0400, longtao.pang wrote:
> > 1. Increase disk size to accomodate to nested test requirment.
>
> "accommodate" and "requirement"
>
> Ian, are you OK with this generic change or would you prefer a runvar? I
> suspect the answer is going to be runvar.
>
So, should I waiting for Ian Jackson's reply and then take next action?
> > 2. Since 'Debain-xxx-.iso' image will be stored there, therefore needs
> > more disk capacity, increase root partition size in preseed generation.
>
> "Debian".
>
> I'm not sure I follow what this one is saying though, does "there" refer to
> the
> rootfs of the VM which is being built here?
Yes.
>
> > @@ -75,6 +75,7 @@ d-i preseed/late_command string \\
> > in-target mkdir -p /boot/efi/EFI/boot; \\
> > in-target cp /boot/efi/EFI/debian/grubx64.efi
> /boot/efi/EFI/boot/bootx64.efi ;\\
> > in-target mkdir -p /root/.ssh; \\
> > +in-target sed -i '/^deb *cdrom/s/^/#/' /etc/apt/sources.list;
> > + \\
>
> I think a more conventional way to do this would be to use:
> s/^deb *cdrom/#&/g
>
> > in-target sh -c "echo -e '$authkeys'>
> > /root/.ssh/authorized_keys"; END
> > return $preseed_file;
> > @@ -152,6 +153,7 @@ sub prep () {
> > more_prepareguest_hvm($ho,$gho, $ram_mb, $disk_mb,
> >OnReboot => 'preserve',
> >Bios => $r{bios},
> > + ExtraConfig => 'nestedhvm=1',
>
> Please do only for the nested job i.e. using a runvar.
I remembered in previous mail you mentioned as below:
"One good thing about just enabling it from the start is that we get some
testing of normal guest installation while nestedhvm happens to be installed,
which might help catch regressions."
Therefore, I enabled 'nestedhvm' feature as generally.
>
> >PostImageHook => sub {
> > my $cmds = iso_copy_content_from_image($gho, $newiso);
> > $cmds .=
> > prepare_initrd($initrddir,$newiso,$preseed_file_path);
> > @@ -173,6 +175,8 @@ my $ram_minslop = 100; my $ram_lots = 5000; if
> > ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
> > $ram_mb = $ram_lots;
> > +} elsif ($gn eq 'nested') {
> > +$ram_mb = 3072;
>
> I think this ought to be driven from a runvar as well, e.g. _minram.
>
> > } else {
> > $ram_mb = 768;
> > }
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v7 2/6] Edit some testsupport APIs for nested test
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Tuesday, March 31, 2015 9:50 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 2/6] Edit some testsupport APIs for > nested test > > On Fri, 2015-03-27 at 19:06 -0400, longtao.pang wrote: > > 1. Designate vif model to 'e1000' by make-flight. > > Strictly you could s/to 'e1000'// here since the make-flight changes are > elsewhere and that would better describe the generic change. > Do you mean that I should change the description from "Designate vif model to 'e1000' by make-flight" to "Designate vif model by make-flight"? > > 2. In L2 installation context, its host (L1) IP address is not queried > > from DNS, but after running "ts-nested-setup + host + nested", L1 IP > > is stored in runvar. > > > > Signed-off-by: longtao.pang > > Acked-by: Ian Campbell > ___ 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: Tuesday, March 24, 2015 1:37 AM > To: Wei Liu > Cc: Pang, LongtaoX; Hu, Robert; ian.jack...@eu.citrix.com; > xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [OSSTEST Nested PATCH 2/6] Add and expose some > testsupport APIs > > On Mon, 2015-03-23 at 17:29 +, Wei Liu wrote: > > On Mon, Mar 23, 2015 at 04:45:55PM +, Ian Campbell wrote: > > > On Mon, 2015-03-23 at 16:20 +, Pang, LongtaoX wrote: > > > > > > > > > > > > > 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 boot sequence from ISO image to hard disk, we need > > > > > > > modify the "boot=cd" , > > > > > > > > > > > > Do you? As Ian asked before, why is guest_editconfig_nocd not > > > > > > sufficient? It removes the CD from the virtual drive, meaning > > > > > > that "boot=dc" will fail to boot from d and fallthru to c. > > > > > > > > > > > > > also need to enable 'nestedhvm' feature in hvm configure > > > > > > > file, > > > > > > > > > > > > This certainly doesn't belong in a function called > > > > > > guest_editconfig_cd, since it has nothing to do with cds at all. > > > > > > > > > > > > Anyway, it's not clear why you need to edit this into the > > > > > > nestedhvm configuration, instead of adding it when the > > > > > > configuration is created via more_prepareguest_hvm. What harm > > > > > > is there in enabling this during guest install? > > > > > > > > > > > I will try it. > > > > > > > > > Re-use 'guest_ediconfig_nocd', after finishing L1 installation, it > > > > could boot into L1 OS, but failed to install packages( such as > > > > lvm2, rsync, bridge-utils ) via Debian repo in L1, as below msg: > > > > > > Oh dear. Things really ought to be tailored on install to use the > > > network repositories for the apt sources, not the cdrom. > > > > When I wrote ts-debian-hvm-install, one of the problems (if I remember > > correctly) was that our network infrastructure didn't support booting > > EFI from PXE boot. I ended up making that disk image to sort of work > > around this. > > > > > > > > Installing from netboot rather than netinst media ought to achieve > > > that, I'm not sure with ts-debian-hvm-install uses though or how to > > > achieve it via preseeding if it isn't the default for the given media. > > > > > > > Per https://www.debian.org/releases/stable/example-preseed.txt, > > these runes look interesting. > > > > # Additional repositories, local[0-9] available #d-i > > apt-setup/local0/repository string \ > > # http://local.server/debian stable main > > #d-i apt-setup/local0/comment string local server # Enable deb-src > > lines #d-i apt-setup/local0/source boolean true # URL to the public > > key of the local repository; you must provide a key # or # apt will > > complain about the unauthenticated repository and so the # > > sources.list line will be left commented out #d-i apt-setup/local0/key > > string http://local.server/key > > > > Not sure if they will really end up in source.list though. > > My expectation is that the existing preseed will have resulted in both http > and > cdrom entries, and all that is needed is to comment out the cdrom ones so the > network ones take precedence. > > Lets wait for an answer to my question about what is in sources.list on these > VMs before speculating further on how to fix this though. > > Ian. I have checked the sources.list file in L1 guest, it contains both CDROM repo entry and URL entry(Debian repository mirror location), Such as below: deb cdrom:[Debian GNU/Linux 7.6.0 _Wheezy_ - Official amd64 DVD Binary-1 20140712-14:11]/ wheezy contrib main deb http://linux-ftp.sh.intel.com//pub/mirrors/debian wheezy main deb-src http://linux-ftp.sh.intel.com//pub/mirrors/debian wheezy main It seems that CDROM repo entry take effect, but it definitely unavailable, because ISO image is removed. If I comment out the CDROM repo entry manually, and then try to 'apt-get install', it works fine. For wei's first solution that change boot sequence from cd_disc to HDD, it does works and I have created a 'guest_ediconfig_nocd' function about that in previously patchs, maybe it's not preferred according to Ian Campbell's opinion. So, maybe I should write some code in 'ts-nested-setup' script to implement ssh into L1, edit sources.list and comment out the CDROM repo entry. Or, do your have some easy ways? ___ 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
>
> > > > 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 boot
> > > sequence from ISO image to hard disk, we need modify the "boot=cd" ,
> >
> > Do you? As Ian asked before, why is guest_editconfig_nocd not
> > sufficient? It removes the CD from the virtual drive, meaning that
> > "boot=dc" will fail to boot from d and fallthru to c.
> >
> > > also need to enable 'nestedhvm' feature in hvm configure file,
> >
> > This certainly doesn't belong in a function called
> > guest_editconfig_cd, since it has nothing to do with cds at all.
> >
> > Anyway, it's not clear why you need to edit this into the nestedhvm
> > configuration, instead of adding it when the configuration is created
> > via more_prepareguest_hvm. What harm is there in enabling this during
> > guest install?
> >
> I will try it.
>
Re-use 'guest_ediconfig_nocd', after finishing L1 installation, it could boot
into L1 OS, but failed to install packages( such as lvm2, rsync, bridge-utils
) via Debian repo in L1, as below msg:
root@nested:~# apt-get install lvm2 --no-install-recommends -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libdevmapper-event1.02.1 libreadline5
The following NEW packages will be installed:
libdevmapper-event1.02.1 libreadline5 lvm2
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/767 kB of archives.
After this operation, 1,521 kB of additional disk space will be used.
Media change: please insert the disc labeled
'Debian GNU/Linux 7.6.0 _Wheezy_ - Official amd64 DVD Binary-1 20140712-14:11'
in the drive '/media/cdrom/' and press enter
I checked the 'sources.list' file in L1, because L1 Debian OS assume that ISO
Image as repo, but the ISO image does not exist actually.
Since '$gho->{Rimage}' is replaced as ' $emptyiso' in ' guest_ediconfig_nocd',
maybe it is not sufficient for nested test.
If keep to re-use ' guest_ediconfig_nocd' , is there any approach to setting
guest's repo in osstest system?
___
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: 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. > > > > > > > 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. > When rebooting Debian L0 or Debian L1 guest, during booting, it will take a lot of time(about 150s) to starting MTA and NTP service, and then boot into Debian OS. But, only boot into OS completely, ' osstest-confirm-booted' shell script in '/etc/init.d' will start and generate 'reboot-confirm-booted' file at '/dev/shm' directory, only if the ' reboot-confirm-booted' file exist, then the function of 'host_reboot' is called successfully. As 'host_reboot' function in TestSupport.pm, the 'poll_loop' timeout is 40s, in my osstest env, after reboot L0 or L1 and then calling 'host_reboot' function, always cause the 'poll_loop' timeout and exit test. > > > The editconfig_cd thing -- yet another thin
Re: [Xen-devel] [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs
Add xen-devel in mail loop.
> -Original Message-
> From: Pang, LongtaoX
> Sent: Friday, March 20, 2015 7:59 PM
> To: 'Ian Campbell'
> Cc: ian.jack...@eu.citrix.com; wei.l...@citrix.com; Hu, Robert
> Subject: RE: [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 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).
>
> > > 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.
>
> > 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 boot
sequence from ISO image to hard disk, we need modify the "boot=cd" , also need
to enable 'nestedhvm' feature in hvm configure file, So, we added
'guest_editconfig_cd' function.
Since, 'guest_editconfig_nocd' could not get this point, if we change it, will
affect all guest, that not our expected.
+sub guest_editconfig_cd ($) {
+my ($gho) = @_;
+guest_editconfig($gho->{Host}, $gho, sub {
+if (m/^\s*boot\s*= '\s*d\s*c\s*'/) {
+s/dc/cd/;
+}
+s/^on_reboot.*/on_reboot='restart'/;
+s/#nestedhvm/nestedhvm/;
+});
+}
> > I think perhaps you have accidentally resent an older version of the
> > series. If not then please go back and ensure you have addressed all
> > of the feedback given on the last iteration before sending another version.
> >
> > Ian.
> >
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH 1/6] parsing grub which has 'submenu' primitive
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Friday, March 20, 2015 12:17 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 1/6] parsing grub which has 'submenu'
> primitive
>
> On Tue, 2015-03-17 at 14:16 -0400, longtao.pang wrote:
> > From: "longtao.pang"
> >
> > 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.
>
> This is missing a Signed-off-by per
> http://wiki.xen.org/wiki/Submitting_Xen_Patches#Signing_off_a_patch
>
I will add it next time.
> I think this also means that the current patching of the grub.cfg which Wei
> added for the host level stuff can be reverted.
>
> > ---
> > Osstest/Debian.pm | 52
>
> > 1 file changed, 32 insertions(+), 20 deletions(-)
> >
> > diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm index
> > e3e1c90..9fdacd7 100644
> > --- a/Osstest/Debian.pm
> > +++ b/Osstest/Debian.pm
> > @@ -1,5 +1,6 @@
> > # This is part of "osstest", an automated testing framework for Xen.
> > # Copyright (C) 2009-2013 Citrix Inc.
> > +# Copyright (C) 2014-2015 Intel Inc.
> > #
> > # 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 @@ -362,26 +363,34 @@ 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
> > -? qw(Title Hv KernDom0 KernVer)
> > -: qw(Title Hv KernOnly KernVer));
> > - if (@missing) {
> > - logm("(skipping entry at $entry->{StartLine};".
> > -" no @missing)");
> > - } elsif (defined $want_kernver &&
> > -$entry->{KernVer} ne $want_kernver) {
> > - logm("(skipping entry at $entry->{StartLine};".
> > -" kernel $entry->{KernVer}, not $want_kernver)");
> > - } else {
> > - # yes!
> > - last;
> > - }
> > +grep { !defined $entry->{$_} }
> > +(defined $xenhopt
> > + ? qw(Title Hv KernDom0 KernVer)
> > + : qw(Title Hv KernOnly KernVer));
> > +if (@missing) {
> > +logm("(skipping entry at $entry->{StartLine};".
> > + " no @missing)");
> > +} elsif (defined $want_kernver &&
> > + $entry->{KernVer} ne $want_kernver) {
> > +logm("(skipping entry at $entry->{StartLine};".
> > + " kernel $entry->{KernVer}, not
> $want_kernver)");
> > +} else {
> > +# yes!
> > +last;
> > +}
>
> Please avoid unnecessary reindentation or code reformatting mixed with
> functional changes. Otherwise you just obscure the actual changes you are
> making. If something is wrongly indented or formatted then please fix in
> another patch first.
>
> As it is I'm afraid this patch is basically unreviewable.
I will keep the original coding format next time.
>
> > $entry= undef;
> > next;
> >
Re: [Xen-devel] [OSSTEST Nested PATCH 0/6] Introduction of netsted HVM test job
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Friday, March 20, 2015 12:32 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 0/6] Introduction of netsted HVM test job > > On Tue, 2015-03-17 at 14:16 -0400, longtao.pang wrote: > > This patch set adds nested HVM test case for osstest. > > I've now looked at the first two patches in this series and I've found that > in both > patches you have consistently not reacted to the review comments made the > first time around, so I'm not going to read the rest of the series now since > it > would appear to be a waste of my time if I'm just going to end up repeating > things which were said last time. > I am sorry that this version still does not reach the requirement and take your time to review it. Actually, this version of patches change a lot according Ian Jackson's last useful comments. > Please resend a 3rd version when you have made sure that you have addressed > the previous feedback. > Actually, this is the sixth version, the next version will be seventh, I will mark the version number of patches next time. > Please also: > > * Use "git send-email --reroll-count=N" (or with older git > --subject-prefix including vN) to indicate which revision of the > patch series this is (i.e. here you should have used > --reroll-count=2 and next time 3) > * Add a miniture changelog to each patch indication what has > changed in this iteration, this should go after the commit > message, S-o-b and a "---" marker. > > See the "[PATCH v2] foobar: Add a new trondle calls" example in > http://wiki.xen.org/wiki/Submitting_Xen_Patches#Review.2C_Rinse_.26_Repe > at for example of both of these. > > In fact please read wiki.xen.org/wiki/Submitting_Xen_Patches for lots of hints > on all of this stuff. > This suggestion is really very useful to me, because I am not familiar with that. > 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: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Tuesday, February 17, 2015 6:47 PM
> To: Hu, Robert
> Cc: Wei Liu; Ian Jackson; xen-devel@lists.xen.org; jfeh...@suse.com;
> ian.campb...@citrix.com; Pang, LongtaoX
> Subject: Re: [PATCH OSSTEST 11/12] Changes on test step of debain hvm guest
> install
>
> On Tue, Feb 17, 2015 at 10:37:39AM +, Wei Liu wrote:
> > On Tue, Feb 17, 2015 at 12:45:34AM +, Hu, Robert wrote:
> > [...]
> > > >
> > > > > Am I supposed to wait for Wei's patch or use my approach for a
> > > > > while and revert to Wei's patch afterwards?
> > > >
> > > > What patch do you expect from me?
> > > That Ian mentioned above
> > > '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.'
> >
> > I'm afraid I don't have time to do the refactoring and testing any
> > time soon.
> >
> > I had a look at d-i's preseed documentation. And this is what I come
> > up with. Note it's untested patch, just a proof-of-concept what the
> > final recipe might look like.
> >
> > A proper upstream patch will require factoring out the common bits
> > first (/boot, / and swap) and then append test case specific bits (in
> > this case, the EFI boot partition) later.
> >
> > Wei.
> >
> > diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install index
> > 449b96c..e87a2c0 100755
> > --- a/ts-debian-hvm-install
> > +++ b/ts-debian-hvm-install
> > @@ -54,6 +54,12 @@ d-i partman-auto/method string regular
> >
> > d-i partman-auto/expert_recipe string \\
> > boot-root :: \\
> > +100 50 100 ext4
> > + \$primary{ } \$bootable{ }
> \\
> > + method{ format } format{ }
> \\
> > + use_filesystem{ } filesystem{ ext3 }
> \\
> ext4
>
> Copy and paste error, sorry.
>
> > + mountpoint{ /boot }
> \\
> > + .
> \\
> > 512 50 512 vfat \\
> > \$primary{ } \$bootable{ } \\
> And you might
> want to get rid of this bootable flag.
>
> The testing of this patch will require you to run at least
> test-amd64-amd64-xl-qemuu-{debianhvm,ovmf}-amd64.
>
Since this is just a proof-of-concept patch, could you provide a workable one
based on latest OSSTest master branch,
and make all Debian HVM installations use LVM?
> Wei.
___
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.
>
After finishing L1 guest VM installation, we need to change L1 guest boot
sequence from ISO image to hard disk,
so we will edit the "boot=cd" in hvm configure file and we added
'guest_editconfig_cd'. But, guest_editconfig_nocd could not get
this point.
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
> -Original Message- > From: Dario Faggioli [mailto:dario.faggi...@citrix.com] > Sent: Friday, January 09, 2015 1:20 AM > To: Pang, LongtaoX > Cc: Wei Liu; Hu, Robert; ian.jack...@eu.citrix.com; ian.campb...@citrix.com; > Zheng, Di; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [OSSTEST PATCH 3/4] Add nested testcase of installing > L2 guest VM > > On Tue, 2015-01-06 at 03:28 +0000, Pang, LongtaoX wrote: > > [Pang, LongtaoX] > > [Pang, LongtaoX] Thanks for checking. We used ts-debian-hvm-install > > for installing L1 HVM guest via ISO Image, because we will build XEN, > XEN-Tools and dom0 kernel inside it, and then we will install L2 guest inside > L1. > > > This has been asked already, and so far, I haven't seen an answer: why do you > want to rebuild Xen, the toolstack, and even Dom0 kernel inside the L1 guest, > instead than just installing them (with ts-xen-install)? > > Dario Sorry, it's my mistake that I did not describe that clearly and make your confused. Actually, we install XEN and HVM kernel to L1 guest instead of rebuilding them in L1. > > -- > <> (Raistlin Majere) > - > Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, > Citrix Systems R&D Ltd., Cambridge (UK) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
> -Original Message-
> From: Pang, LongtaoX
> Sent: Wednesday, January 07, 2015 11:53 AM
> To: 'Wei Liu'
> Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
> ian.campb...@citrix.com; Hu, Robert; Zheng, Di
> Subject: RE: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
>
>
>
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: Wednesday, January 07, 2015 12:52 AM
> > To: Pang, LongtaoX
> > Cc: Wei Liu; xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
> > ian.campb...@citrix.com; Hu, Robert; Zheng, Di
> > Subject: Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2
> > guest VM
> >
> > On Tue, Jan 06, 2015 at 03:28:43AM +, Pang, LongtaoX wrote:
> > >
> > >
> > > > -Original Message-----
> > > > From: Wei Liu [mailto:wei.l...@citrix.com]
> > > > Sent: Thursday, December 11, 2014 7:44 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 3/4] Add nested testcase of installing
> > > > L2 guest VM
> > > >
> > > > On Wed, Dec 10, 2014 at 04:07:39PM +0800, longtao.pang wrote:
> > > > > From: "longtao.pang"
> > > > >
> > > > > This patch is used for installing L2 guest VM inside L1 guest VM.
> > > > >
> > > > > ---
> > > > > sg-run-job|2 +
> > > > > ts-debian-install | 166
> > > > > +
> > > > > 2 files changed, 132 insertions(+), 36 deletions(-)
> > > > >
> > > > > diff --git a/sg-run-job b/sg-run-job index e513bd1..85f7b22
> > > > > 100755
> > > > > --- a/sg-run-job
> > > > > +++ b/sg-run-job
> > > > > @@ -292,6 +292,8 @@ 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
> > > > > +run-ts . = ts-debian-install + host + nested + amd64 + nested_L2
> > > > > +run-ts . = ts-guest-destroy + host nested
> > > >
> > > > It would also be possible to run ts-debian-hvm-install as L2. That
> > > > would suite this test case better -- it's testing nested HVM.
> > > >
> > > > There's no need to remove the PV test case though.
> > >
> > > [Pang, LongtaoX]
> > > [Pang, LongtaoX] Thanks for checking. We used ts-debian-hvm-install
> > > for installing L1 HVM guest via ISO Image, because we will build
> > > XEN,
> > XEN-Tools and dom0 kernel inside it, and then we will install L2 guest
> > inside
> L1.
> > > But, L2 guest is just a native OS, so we think use ts-debian-install
> > > is enough
> > for installing L2 and will make it easy to control.
> > >
> >
> > ts-debian-install installs a L2 PV guest, which should work even
> > without nested HVM enabled for your L1 HVM guest. You're testing
> > nested HVM I think it makes more sense to install a L2 HVM guest.
> >
> [Pang, LongtaoX] Thanks Wei, I will try to re-use the script of
> ts-debian-hvm-install as L2, maybe it will make this script become
> complicated.
> If it works, there will not be necessary to modify and use ts-debian-install
> anymore.
[Pang, LongtaoX] Hi Wei, for script of ts-debian-hvm-install, as too many
parameters, functions, structure and variables are not suit for L2 installing ,
if I re-use and modify as L2, it will make the script become more convoluted
and hard to maintain in later days.
So, I plant to write a new script similar to ts-debian-hvm-install, called
ts-debian-hvm-install-L2 for L2 guest installing.
If you have any concern or other opinions, please tell me, thanks.
> > [...]
> > > > > +sub start () {
> > > > > +my $cfg_xend= "/etc/xen/$guesthost.cfg";
> > > > > +my $cmd= toolstack()->{Command}." create ".$cfg_xend;
> > > > > +target_cmd_root($ho, $cmd, 30);
> > > > > +my $domains = target_cmd_output_root($ho,
> > > > toolstack()->{Command}." list");
> > > > > +logm("guest state is\n$domains"); }
> > > >
> > > > I think we already have a guest start script?
> > > >
> > > > This hunk is going to break easily if we're more flexible about
> > > > the toolstack (we already have a partially working libvirt test case).
> > > >
> > >
> > > [Pang, LongtaoX] Thanks for checking, I have tried to use
> > > ts-guest-start to start guest, but it maybe not suit for here,
> > > because some
> > function and parameters in the script is not necessary here, If we use
> > the script we will modify it again and may impact other test jobs.
> > > So I create a function here to start L2 guest.
> > >
> >
> > Then you need to keep an eye on the ongoing work from Ian Campbell to
> > factor out abstraction layer of toolstack and rebase accordingly.
> >
> > Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Wednesday, January 07, 2015 12:52 AM
> To: Pang, LongtaoX
> Cc: Wei Liu; xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
> ian.campb...@citrix.com; Hu, Robert; Zheng, Di
> Subject: Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
>
> On Tue, Jan 06, 2015 at 03:28:43AM +, Pang, LongtaoX wrote:
> >
> >
> > > -Original Message-
> > > From: Wei Liu [mailto:wei.l...@citrix.com]
> > > Sent: Thursday, December 11, 2014 7:44 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 3/4] Add nested testcase of installing
> > > L2 guest VM
> > >
> > > On Wed, Dec 10, 2014 at 04:07:39PM +0800, longtao.pang wrote:
> > > > From: "longtao.pang"
> > > >
> > > > This patch is used for installing L2 guest VM inside L1 guest VM.
> > > >
> > > > ---
> > > > sg-run-job|2 +
> > > > ts-debian-install | 166
> > > > +
> > > > 2 files changed, 132 insertions(+), 36 deletions(-)
> > > >
> > > > diff --git a/sg-run-job b/sg-run-job index e513bd1..85f7b22 100755
> > > > --- a/sg-run-job
> > > > +++ b/sg-run-job
> > > > @@ -292,6 +292,8 @@ 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
> > > > + run-ts . = ts-debian-install + host + nested + amd64 + nested_L2
> > > > +run-ts . = ts-guest-destroy + host nested
> > >
> > > It would also be possible to run ts-debian-hvm-install as L2. That
> > > would suite this test case better -- it's testing nested HVM.
> > >
> > > There's no need to remove the PV test case though.
> >
> > [Pang, LongtaoX]
> > [Pang, LongtaoX] Thanks for checking. We used ts-debian-hvm-install
> > for installing L1 HVM guest via ISO Image, because we will build XEN,
> XEN-Tools and dom0 kernel inside it, and then we will install L2 guest inside
> L1.
> > But, L2 guest is just a native OS, so we think use ts-debian-install is
> > enough
> for installing L2 and will make it easy to control.
> >
>
> ts-debian-install installs a L2 PV guest, which should work even without
> nested
> HVM enabled for your L1 HVM guest. You're testing nested HVM I think it
> makes more sense to install a L2 HVM guest.
>
[Pang, LongtaoX] Thanks Wei, I will try to re-use the script of
ts-debian-hvm-install as L2, maybe it will make
this script become complicated. If it works, there will not be necessary to
modify and use ts-debian-install anymore.
> [...]
> > > > +sub start () {
> > > > + my $cfg_xend= "/etc/xen/$guesthost.cfg";
> > > > +my $cmd= toolstack()->{Command}." create ".$cfg_xend;
> > > > +target_cmd_root($ho, $cmd, 30);
> > > > +my $domains = target_cmd_output_root($ho,
> > > toolstack()->{Command}." list");
> > > > +logm("guest state is\n$domains"); }
> > >
> > > I think we already have a guest start script?
> > >
> > > This hunk is going to break easily if we're more flexible about the
> > > toolstack (we already have a partially working libvirt test case).
> > >
> >
> > [Pang, LongtaoX] Thanks for checking, I have tried to use
> > ts-guest-start to start guest, but it maybe not suit for here, because some
> function and parameters in the script is not necessary here, If we use the
> script
> we will modify it again and may impact other test jobs.
> > So I create a function here to start L2 guest.
> >
>
> Then you need to keep an eye on the ongoing work from Ian Campbell to
> factor out abstraction layer of toolstack and rebase accordingly.
>
> Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Thursday, December 11, 2014 7:44 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 3/4] Add nested testcase of installing L2 guest VM
>
> On Wed, Dec 10, 2014 at 04:07:39PM +0800, longtao.pang wrote:
> > From: "longtao.pang"
> >
> > This patch is used for installing L2 guest VM inside L1 guest VM.
> >
> > ---
> > sg-run-job|2 +
> > ts-debian-install | 166
> > +
> > 2 files changed, 132 insertions(+), 36 deletions(-)
> >
> > diff --git a/sg-run-job b/sg-run-job
> > index e513bd1..85f7b22 100755
> > --- a/sg-run-job
> > +++ b/sg-run-job
> > @@ -292,6 +292,8 @@ 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
> > +run-ts . = ts-debian-install + host + nested + amd64 + nested_L2
> > +run-ts . = ts-guest-destroy + host nested
>
> It would also be possible to run ts-debian-hvm-install as L2. That would suite
> this test case better -- it's testing nested HVM.
>
> There's no need to remove the PV test case though.
[Pang, LongtaoX]
[Pang, LongtaoX] Thanks for checking. We used ts-debian-hvm-install for
installing L1 HVM guest via ISO Image,
because we will build XEN, XEN-Tools and dom0 kernel inside it, and then we
will install L2 guest inside L1.
But, L2 guest is just a native OS, so we think use ts-debian-install is enough
for installing L2 and will make it easy to control.
>
> > }
> >
> > proc test-guest-migr {g} {
> > diff --git a/ts-debian-install b/ts-debian-install index
> > 58ea743..2ca54e8 100755
> > --- a/ts-debian-install
> > +++ b/ts-debian-install
> > @@ -22,41 +22,61 @@ use Osstest::TestSupport;
> >
> > tsreadconfig();
> >
> > -our ($whhost,$gn) = @ARGV;
> > -$whhost ||= 'host';
> > -$gn ||= 'debian';
> > +our ($whhost,$gn,$arch,$nested_L2) = @ARGV;
> > +$nested_L2 ||= '';
> >
> > -our $ho= selecthost($whhost);
> > +if($nested_L2 eq 'nested_L2') {
> > +my $L1_IP = &get_VM_IP($r{'nested_ether'});
> > +$whhost = "host=$L1_IP";
> > +$gn ||= 'nested';
> > +$arch ||= 'amd64';
> > +} else {
> > +$whhost ||= 'host';
> > +$gn ||= 'debian';
> > +}
> >
> > +our $ho= selecthost($whhost);
> > our $ram_mb=512;
> > our $swap_mb= 1000;
> > our $disk_mb= 1;
> > -
>
> Stray blank line.
>
> > our $guesthost= "$gn.guest.osstest";
> > our $gho;
> > +our $L2_MAC = select_ether($ho,"L2_ether");
> >
> > sub prep () {
> > target_install_packages_norec($ho, qw(lvm2 xen-tools));
> > -
> > -$gho= prepareguest($ho, $gn, $guesthost, 22,
> > - $swap_mb + $disk_mb + 2,
> > - 40);
> > -target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
> > +unless($nested_L2 eq 'nested_L2') {
> > + $gho= prepareguest($ho, $gn, $guesthost, 22,
> > + $swap_mb + $disk_mb + 2,
> > + 40);
> > + target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
> > +}
> > }
> >
> > sub ginstall () {
> > -my $arch= $r{"$gho->{Guest}_arch"};
> > +my $gsuite;
> > +my $kernpath;
> > +my $initrd;
> > +my $kernver;
> > +if($nested_L2 eq 'nested_L2'){
> > +my $suite= "$c{DebianSuite}";
> > +$gsuite= defined($suite) ? "--dist=$suite" : '';
> > +$kernver ||= target_cmd_output_root($ho, 'uname -r');
> > +$kernpath = "/boot/vmlinuz-$kernver";
> > +$initrd ||= "/boot/initrd.img-$kernver";
> > +} else {
> > +my $arch= $r{"$gho->{Guest}_arch"};
> > +$gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
> > +$kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
> > +$initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
> > +if (!$kernpath) {
> > +
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.
>
> Wei.
[Pang, LongtaoX] Thanks for checking, I will try to modify it.
>
> > +${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
