* [OSSTEST PATCH 1/4] Add nested testcase of preparing and installing L1 guest VM
2014-12-10 8:07 [OSSTEST PATCH 0/4] Introduction of the patches longtao.pang
@ 2014-12-10 8:07 ` longtao.pang
2014-12-11 11:06 ` Wei Liu
2014-12-10 8:07 ` [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for " longtao.pang
` (3 subsequent siblings)
4 siblings, 1 reply; 32+ messages in thread
From: longtao.pang @ 2014-12-10 8:07 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, Ian.Campbell, Ian.Jackson, robert.hu, longtaox.pang,
di.zheng
From: "longtao.pang" <longtaox.pang@intel.com>
This patch is used for preparing and installing L1 guest VM inside L0 system
on testhost machine.
---
Osstest/Debian.pm | 27 ++++++++++++++++++---------
Osstest/TestSupport.pm | 31 ++++++++++++++++++++++++++-----
sg-run-job | 5 +++++
ts-debian-hvm-install | 34 ++++++++++++++++++++++++----------
4 files changed, 73 insertions(+), 24 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c8db601..a671d20 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 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
@@ -34,6 +35,7 @@ BEGIN {
@EXPORT = qw(debian_boot_setup
%preseed_cmds
preseed_base
+ setupboot_grub2
preseed_create
preseed_hook_command preseed_hook_installscript
di_installcmdline_core
@@ -286,15 +288,18 @@ sub setupboot_grub2 ($$$) {
my $count= 0;
my $entry;
+ my $submenu;
while (<$f>) {
next if m/^\s*\#/ || !m/\S/;
if (m/^\s*\}\s*$/) {
- die unless $entry;
+ die unless $entry || $submenu;
+ if(!defined $entry && defined $submenu){
+ logm("Met end of a submenu starting from $submenu->{StartLine}.Our want kern is $want_kernver");
+ $submenu=undef;
+ next;
+ }
my (@missing) =
- grep { !defined $entry->{$_} }
- (defined $xenhopt
- ? qw(Title Hv KernDom0 KernVer)
- : qw(Title Hv KernOnly KernVer));
+ 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)");
@@ -317,21 +322,25 @@ sub setupboot_grub2 ($$$) {
$entry= { Title => $1, StartLine => $., Number => $count };
$count++;
}
- if (m/^\s*multiboot\s*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
+ if(m/^submenu\s+[\'\"](.*)[\'\"].*\{\s*$/){
+ $submenu={ StartLine =>$.};
+ }
+ if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\S+)/) {
+# if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
die unless $entry;
$entry->{Hv}= $1;
}
- if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
+ if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
die unless $entry;
$entry->{KernOnly}= $1;
$entry->{KernVer}= $2;
}
- if (m/^\s*module\s*\/(vmlinu[xz]-(\S+))/) {
+ if (m/^\s*module\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
die unless $entry;
$entry->{KernDom0}= $1;
$entry->{KernVer}= $2;
}
- if (m/^\s*module\s*\/(initrd\S+)/) {
+ if (m/^\s*module\s*(?:\/boot)*\/(initrd\S+)/) {
$entry->{Initrd}= $1;
}
}
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index a3b6936..1e47039 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -55,8 +55,9 @@ BEGIN {
target_putfilecontents_stash
target_putfilecontents_root_stash
target_put_guest_image target_editfile
- target_editfile_root target_file_exists
- target_run_apt
+ target_editfile_root target_file_exists
+ target_file_exists_root
+ target_run_apt
target_install_packages target_install_packages_norec
target_jobdir target_extract_jobdistpath_subdir
target_extract_jobdistpath target_guest_lv_name
@@ -67,7 +68,7 @@ BEGIN {
selecthost get_hostflags get_host_property
get_host_native_linux_console
power_state power_cycle power_cycle_time
- serial_fetch_logs
+ serial_fetch_logs select_ether
propname_massage
get_stashed open_unique_stashfile compress_stashed
@@ -109,6 +110,7 @@ BEGIN {
iso_gen_flags_basic
iso_copy_content_from_image
guest_editconfig_nocd
+ guest_editconfig_cd
);
%EXPORT_TAGS = ( );
@@ -481,6 +483,14 @@ sub target_file_exists ($$) {
die "$rfile $out ?";
}
+sub target_file_exists_root ($$) {
+ my ($ho,$rfile) = @_;
+ my $out= target_cmd_output_root($ho, "if test -e $rfile; then echo y; fi");
+ return 1 if $out =~ m/^y$/;
+ return 0 if $out !~ m/\S/;
+ die "$rfile $out ?";
+}
+
sub teditfileex {
my $user= shift @_;
my $code= pop @_;
@@ -717,6 +727,7 @@ sub power_cycle_time ($) {
sub power_cycle ($) {
my ($ho) = @_;
$mjobdb->host_check_allocated($ho);
+ $mjobdb->xen_check_installed($ho);
die "refusing to set power state for host $ho->{Name}".
" possibly shared with other jobs\n"
if $ho->{SharedMaybeOthers};
@@ -937,7 +948,7 @@ sub compress_stashed($) {
sub host_reboot ($) {
my ($ho) = @_;
target_reboot($ho);
- poll_loop(40,2, 'reboot-confirm-booted', sub {
+ poll_loop(200,2, 'reboot-confirm-booted', sub {
my $output;
if (!eval {
$output= target_cmd_output($ho, <<END, 40);
@@ -1465,7 +1476,7 @@ sub prepareguest_part_xencfg ($$$$$) {
my $xencfg= <<END;
name = '$gho->{Name}'
memory = ${ram_mb}
-vif = [ 'type=ioemu,mac=$gho->{Ether}' ]
+vif = [ 'type=ioemu,model=e1000,mac=$gho->{Ether}' ]
#
on_poweroff = 'destroy'
on_reboot = '$onreboot'
@@ -2063,4 +2074,14 @@ sub guest_editconfig_nocd ($$) {
});
}
+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'/;
+ });
+}
+
1;
diff --git a/sg-run-job b/sg-run-job
index 2cf810a..8dcf7af 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -288,6 +288,11 @@ 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 + nested + nested_L1
+}
+
proc test-guest-migr {g} {
if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 37eade2..6dcec3c 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -28,22 +28,24 @@ if (@ARGV && $ARGV[0] =~ m/^--stage(\d+)$/) { $stage=$1; shift @ARGV; }
defined($r{bios}) or die "Need to define which bios to use";
-our ($whhost,$gn) = @ARGV;
+our ($whhost,$gn,$nested_L1,$guesthost) = @ARGV;
$whhost ||= 'host';
-$gn ||= 'debianhvm';
-
+$nested_L1 ||= '';
+if ($nested_L1 eq 'nested_L1') {
+ $gn ||= 'nested';
+ $guesthost ||= "$gn.l1.osstest";
+} else {
+ $gn ||= 'debianhvm';
+ $guesthost= "$gn.guest.osstest";
+}
our $ho= selecthost($whhost);
-
+our $disk_mb= 50000;
# guest memory size will be set based on host free memory, see below
our $ram_mb;
-our $disk_mb= 10000;
-
-our $guesthost= "$gn.guest.osstest";
our $gho;
our $toolstack= toolstack()->{Command};
-
sub preseed () {
my $preseed_file = preseed_base('wheezy','',());
@@ -63,7 +65,7 @@ d-i partman-auto/expert_recipe string \\
use_filesystem{ } filesystem{ vfat } \\
mountpoint{ /boot/efi } \\
. \\
- 5000 50 5000 ext4 \\
+ 25000 50 25000 ext4 \\
method{ format } format{ } \\
use_filesystem{ } filesystem{ ext4 } \\
mountpoint{ / } \\
@@ -155,6 +157,8 @@ sub prep () {
more_prepareguest_hvm($ho,$gho, $ram_mb, $disk_mb,
OnReboot => 'preserve',
Bios => $r{bios},
+ DefVcpus => 4,
+ ExtraConfig => '#nestedhvm=1',
PostImageHook => sub {
my $cmds = iso_copy_content_from_image($gho, $newiso);
$cmds .= prepare_initrd($initrddir,$newiso,$preseed_file_path);
@@ -176,6 +180,8 @@ my $ram_minslop = 100;
my $ram_lots = 5000;
if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
$ram_mb = $ram_lots;
+} elsif ($nested_L1 eq 'nested_L1') {
+ $ram_mb = 2048;
} else {
$ram_mb = 768;
}
@@ -192,7 +198,15 @@ if ($stage<2) {
guest_destroy($ho,$gho);
}
-guest_editconfig_nocd($gho,$emptyiso);
+if ($nested_L1 eq 'nested_L1') {
+ guest_editconfig_cd($gho);
+} else {
+ guest_editconfig_nocd($gho,$emptyiso);
+}
guest_create($gho,$toolstack);
guest_await_dhcp_tcp($gho,300);
guest_check_up($gho);
+if ($nested_L1 eq 'nested_L1') {
+ target_cmd_root($gho, "mkdir -p /home/osstest/.ssh && cp /root/.ssh/authorized_keys /home/osstest/.ssh/");
+}
+
--
1.7.10.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 1/4] Add nested testcase of preparing and installing L1 guest VM
2014-12-10 8:07 ` [OSSTEST PATCH 1/4] Add nested testcase of preparing and installing L1 guest VM longtao.pang
@ 2014-12-11 11:06 ` Wei Liu
2014-12-26 5:13 ` Robert Hu
0 siblings, 1 reply; 32+ messages in thread
From: Wei Liu @ 2014-12-11 11:06 UTC (permalink / raw)
To: longtao.pang
Cc: wei.liu2, Ian.Campbell, Ian.Jackson, xen-devel, robert.hu,
di.zheng
On Wed, Dec 10, 2014 at 04:07:37PM +0800, longtao.pang wrote:
> From: "longtao.pang" <longtaox.pang@intel.com>
>
> This patch is used for preparing and installing L1 guest VM inside L0 system
> on testhost machine.
>
> ---
> Osstest/Debian.pm | 27 ++++++++++++++++++---------
> Osstest/TestSupport.pm | 31 ++++++++++++++++++++++++++-----
> sg-run-job | 5 +++++
> ts-debian-hvm-install | 34 ++++++++++++++++++++++++----------
> 4 files changed, 73 insertions(+), 24 deletions(-)
>
> diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> index c8db601..a671d20 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 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
> @@ -34,6 +35,7 @@ BEGIN {
> @EXPORT = qw(debian_boot_setup
> %preseed_cmds
> preseed_base
> + setupboot_grub2
Why do you want to export this helper? I think debian_setup_boot will
just choose the right one amongst uboot, grub1 and grub2.
> preseed_create
> preseed_hook_command preseed_hook_installscript
> di_installcmdline_core
> @@ -286,15 +288,18 @@ sub setupboot_grub2 ($$$) {
>
> my $count= 0;
> my $entry;
> + my $submenu;
> while (<$f>) {
> next if m/^\s*\#/ || !m/\S/;
> if (m/^\s*\}\s*$/) {
> - die unless $entry;
> + die unless $entry || $submenu;
> + if(!defined $entry && defined $submenu){
> + logm("Met end of a submenu starting from $submenu->{StartLine}.Our want kern is $want_kernver");
> + $submenu=undef;
> + next;
> + }
> my (@missing) =
> - grep { !defined $entry->{$_} }
> - (defined $xenhopt
> - ? qw(Title Hv KernDom0 KernVer)
> - : qw(Title Hv KernOnly KernVer));
> + grep { !defined $entry->{$_} } (defined $xenhopt ? qw(Title Hv KernDom0 KernVer) : qw(Title Hv KernOnly KernVer));
Please don't make non-functional change like this.
> if (@missing) {
> logm("(skipping entry at $entry->{StartLine};".
> " no @missing)");
> @@ -317,21 +322,25 @@ sub setupboot_grub2 ($$$) {
> $entry= { Title => $1, StartLine => $., Number => $count };
> $count++;
> }
> - if (m/^\s*multiboot\s*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
> + if(m/^submenu\s+[\'\"](.*)[\'\"].*\{\s*$/){
> + $submenu={ StartLine =>$.};
> + }
> + if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\S+)/) {
> +# if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
And if this line is redundant, remove it. What's the reason of changing
this regex? Are you using non-debian based distro?
> die unless $entry;
> $entry->{Hv}= $1;
> }
> - if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
> + if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
And this?
> die unless $entry;
> $entry->{KernOnly}= $1;
> $entry->{KernVer}= $2;
> }
> - if (m/^\s*module\s*\/(vmlinu[xz]-(\S+))/) {
> + if (m/^\s*module\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
?
> die unless $entry;
> $entry->{KernDom0}= $1;
> $entry->{KernVer}= $2;
> }
> - if (m/^\s*module\s*\/(initrd\S+)/) {
> + if (m/^\s*module\s*(?:\/boot)*\/(initrd\S+)/) {
> $entry->{Initrd}= $1;
> }
> }
As I said before, this hunk should be in its own patch.
Just FYI, there are multiple people (Dario, you and I) touching this
piece of code. You might want to keep an eye on main OSSTest git tree
and rebase before reposting (and so do Dario and I).
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index a3b6936..1e47039 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -55,8 +55,9 @@ BEGIN {
> target_putfilecontents_stash
> target_putfilecontents_root_stash
> target_put_guest_image target_editfile
> - target_editfile_root target_file_exists
> - target_run_apt
> + target_editfile_root target_file_exists
> + target_file_exists_root
> + target_run_apt
Please don't just change white spaces. This makes patches hard to
review.
> target_install_packages target_install_packages_norec
> target_jobdir target_extract_jobdistpath_subdir
> target_extract_jobdistpath target_guest_lv_name
> @@ -67,7 +68,7 @@ BEGIN {
> selecthost get_hostflags get_host_property
> get_host_native_linux_console
> power_state power_cycle power_cycle_time
> - serial_fetch_logs
> + serial_fetch_logs select_ether
> propname_massage
>
> get_stashed open_unique_stashfile compress_stashed
> @@ -109,6 +110,7 @@ BEGIN {
> iso_gen_flags_basic
> iso_copy_content_from_image
> guest_editconfig_nocd
> + guest_editconfig_cd
Indentation. I think we mostly use space instead of hard tab. Ian?
> );
> %EXPORT_TAGS = ( );
>
> @@ -481,6 +483,14 @@ sub target_file_exists ($$) {
> die "$rfile $out ?";
> }
>
> +sub target_file_exists_root ($$) {
> + my ($ho,$rfile) = @_;
> + my $out= target_cmd_output_root($ho, "if test -e $rfile; then echo y; fi");
> + return 1 if $out =~ m/^y$/;
> + return 0 if $out !~ m/\S/;
> + die "$rfile $out ?";
> +}
> +
> sub teditfileex {
> my $user= shift @_;
> my $code= pop @_;
> @@ -717,6 +727,7 @@ sub power_cycle_time ($) {
> sub power_cycle ($) {
> my ($ho) = @_;
> $mjobdb->host_check_allocated($ho);
> + $mjobdb->xen_check_installed($ho);
And this is? I don't see implementation in this patch set.
Also this routine is called by ts-host-install, which doesn't necessary
require Xen to be installed.
> die "refusing to set power state for host $ho->{Name}".
> " possibly shared with other jobs\n"
> if $ho->{SharedMaybeOthers};
> @@ -937,7 +948,7 @@ sub compress_stashed($) {
> sub host_reboot ($) {
> my ($ho) = @_;
> target_reboot($ho);
> - poll_loop(40,2, 'reboot-confirm-booted', sub {
> + poll_loop(200,2, 'reboot-confirm-booted', sub {
This should go into its own patch as well. I think it's probably nested
virt is slower than real hardware so you need some more time?
> my $output;
> if (!eval {
> $output= target_cmd_output($ho, <<END, 40);
> @@ -1465,7 +1476,7 @@ sub prepareguest_part_xencfg ($$$$$) {
> my $xencfg= <<END;
> name = '$gho->{Name}'
> memory = ${ram_mb}
> -vif = [ 'type=ioemu,mac=$gho->{Ether}' ]
> +vif = [ 'type=ioemu,model=e1000,mac=$gho->{Ether}' ]
What is this needed? If it's necessary, please use a single commit and
state the reason in commit log.
> #
> on_poweroff = 'destroy'
> on_reboot = '$onreboot'
> @@ -2063,4 +2074,14 @@ sub guest_editconfig_nocd ($$) {
> });
> }
>
> +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/;
This pattern is different than the one used to match. This should also
go into its own commit -- "Introduce guest_editconfig_cd".
> + }
> + s/^on_reboot.*/on_reboot='restart'/;
> + });
> +}
> +
> 1;
> diff --git a/sg-run-job b/sg-run-job
> index 2cf810a..8dcf7af 100755
> --- a/sg-run-job
> +++ b/sg-run-job
> @@ -288,6 +288,11 @@ 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 + nested + nested_L1
> +}
> +
> proc test-guest-migr {g} {
> if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
>
This hunk should go into its own commit.
> diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
> index 37eade2..6dcec3c 100755
> --- a/ts-debian-hvm-install
> +++ b/ts-debian-hvm-install
The modification of debian-hvm-install should also go into a single
commit.
> @@ -28,22 +28,24 @@ if (@ARGV && $ARGV[0] =~ m/^--stage(\d+)$/) { $stage=$1; shift @ARGV; }
>
> defined($r{bios}) or die "Need to define which bios to use";
>
> -our ($whhost,$gn) = @ARGV;
> +our ($whhost,$gn,$nested_L1,$guesthost) = @ARGV;
> $whhost ||= 'host';
> -$gn ||= 'debianhvm';
> -
> +$nested_L1 ||= '';
> +if ($nested_L1 eq 'nested_L1') {
> + $gn ||= 'nested';
> + $guesthost ||= "$gn.l1.osstest";
> +} else {
> + $gn ||= 'debianhvm';
> + $guesthost= "$gn.guest.osstest";
> +}
> our $ho= selecthost($whhost);
> -
> +our $disk_mb= 50000;
> # guest memory size will be set based on host free memory, see below
> our $ram_mb;
> -our $disk_mb= 10000;
> -
> -our $guesthost= "$gn.guest.osstest";
> our $gho;
>
> our $toolstack= toolstack()->{Command};
>
> -
Stray blank line change. Please avoid this kind of changes.
> sub preseed () {
>
> my $preseed_file = preseed_base('wheezy','',());
> @@ -63,7 +65,7 @@ d-i partman-auto/expert_recipe string \\
> use_filesystem{ } filesystem{ vfat } \\
> mountpoint{ /boot/efi } \\
> . \\
> - 5000 50 5000 ext4 \\
> + 25000 50 25000 ext4 \\
> method{ format } format{ } \\
> use_filesystem{ } filesystem{ ext4 } \\
> mountpoint{ / } \\
> @@ -155,6 +157,8 @@ sub prep () {
> more_prepareguest_hvm($ho,$gho, $ram_mb, $disk_mb,
> OnReboot => 'preserve',
> Bios => $r{bios},
> + DefVcpus => 4,
And where is this handled?
Wei.
> + ExtraConfig => '#nestedhvm=1',
> PostImageHook => sub {
> my $cmds = iso_copy_content_from_image($gho, $newiso);
> $cmds .= prepare_initrd($initrddir,$newiso,$preseed_file_path);
> @@ -176,6 +180,8 @@ my $ram_minslop = 100;
> my $ram_lots = 5000;
> if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
> $ram_mb = $ram_lots;
> +} elsif ($nested_L1 eq 'nested_L1') {
> + $ram_mb = 2048;
> } else {
> $ram_mb = 768;
> }
> @@ -192,7 +198,15 @@ if ($stage<2) {
> guest_destroy($ho,$gho);
> }
>
> -guest_editconfig_nocd($gho,$emptyiso);
> +if ($nested_L1 eq 'nested_L1') {
> + guest_editconfig_cd($gho);
> +} else {
> + guest_editconfig_nocd($gho,$emptyiso);
> +}
> guest_create($gho,$toolstack);
> guest_await_dhcp_tcp($gho,300);
> guest_check_up($gho);
> +if ($nested_L1 eq 'nested_L1') {
> + target_cmd_root($gho, "mkdir -p /home/osstest/.ssh && cp /root/.ssh/authorized_keys /home/osstest/.ssh/");
> +}
> +
> --
> 1.7.10.4
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 1/4] Add nested testcase of preparing and installing L1 guest VM
2014-12-11 11:06 ` Wei Liu
@ 2014-12-26 5:13 ` Robert Hu
2015-01-02 9:51 ` Dario Faggioli
0 siblings, 1 reply; 32+ messages in thread
From: Robert Hu @ 2014-12-26 5:13 UTC (permalink / raw)
To: Wei Liu
Cc: Ian.Campbell, Ian.Jackson, xen-devel, robert.hu, longtao.pang,
di.zheng
On Thu, 2014-12-11 at 11:06 +0000, Wei Liu wrote:
> On Wed, Dec 10, 2014 at 04:07:37PM +0800, longtao.pang wrote:
> > From: "longtao.pang" <longtaox.pang@intel.com>
> >
> > This patch is used for preparing and installing L1 guest VM inside L0 system
> > on testhost machine.
> >
> > ---
> > Osstest/Debian.pm | 27 ++++++++++++++++++---------
> > Osstest/TestSupport.pm | 31 ++++++++++++++++++++++++++-----
> > sg-run-job | 5 +++++
> > ts-debian-hvm-install | 34 ++++++++++++++++++++++++----------
> > 4 files changed, 73 insertions(+), 24 deletions(-)
> >
> > diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> > index c8db601..a671d20 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 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
> > @@ -34,6 +35,7 @@ BEGIN {
> > @EXPORT = qw(debian_boot_setup
> > %preseed_cmds
> > preseed_base
> > + setupboot_grub2
>
> Why do you want to export this helper? I think debian_setup_boot will
> just choose the right one amongst uboot, grub1 and grub2.
>
> > preseed_create
> > preseed_hook_command preseed_hook_installscript
> > di_installcmdline_core
> > @@ -286,15 +288,18 @@ sub setupboot_grub2 ($$$) {
> >
> > my $count= 0;
> > my $entry;
> > + my $submenu;
> > while (<$f>) {
> > next if m/^\s*\#/ || !m/\S/;
> > if (m/^\s*\}\s*$/) {
> > - die unless $entry;
> > + die unless $entry || $submenu;
> > + if(!defined $entry && defined $submenu){
> > + logm("Met end of a submenu starting from $submenu->{StartLine}.Our want kern is $want_kernver");
> > + $submenu=undef;
> > + next;
> > + }
> > my (@missing) =
> > - grep { !defined $entry->{$_} }
> > - (defined $xenhopt
> > - ? qw(Title Hv KernDom0 KernVer)
> > - : qw(Title Hv KernOnly KernVer));
> > + grep { !defined $entry->{$_} } (defined $xenhopt ? qw(Title Hv KernDom0 KernVer) : qw(Title Hv KernOnly KernVer));
>
> Please don't make non-functional change like this.
>
> > if (@missing) {
> > logm("(skipping entry at $entry->{StartLine};".
> > " no @missing)");
> > @@ -317,21 +322,25 @@ sub setupboot_grub2 ($$$) {
> > $entry= { Title => $1, StartLine => $., Number => $count };
> > $count++;
> > }
> > - if (m/^\s*multiboot\s*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
> > + if(m/^submenu\s+[\'\"](.*)[\'\"].*\{\s*$/){
> > + $submenu={ StartLine =>$.};
> > + }
> > + if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\S+)/) {
> > +# if (m/^\s*multiboot\s*(?:\/boot)*\/(xen\-[0-9][-+.0-9a-z]*\S+)/) {
>
> And if this line is redundant, remove it. What's the reason of changing
> this regex? Are you using non-debian based distro?
>
> > die unless $entry;
> > $entry->{Hv}= $1;
> > }
> > - if (m/^\s*multiboot\s*\/(vmlinu[xz]-(\S+))/) {
> > + if (m/^\s*multiboot\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
>
> And this?
>
> > die unless $entry;
> > $entry->{KernOnly}= $1;
> > $entry->{KernVer}= $2;
> > }
> > - if (m/^\s*module\s*\/(vmlinu[xz]-(\S+))/) {
> > + if (m/^\s*module\s*(?:\/boot)*\/(vmlinu[xz]-(\S+))/) {
>
> ?
>
> > die unless $entry;
> > $entry->{KernDom0}= $1;
> > $entry->{KernVer}= $2;
> > }
> > - if (m/^\s*module\s*\/(initrd\S+)/) {
> > + if (m/^\s*module\s*(?:\/boot)*\/(initrd\S+)/) {
> > $entry->{Initrd}= $1;
> > }
> > }
>
> As I said before, this hunk should be in its own patch.
>
> Just FYI, there are multiple people (Dario, you and I) touching this
> piece of code. You might want to keep an eye on main OSSTest git tree
> and rebase before reposting (and so do Dario and I).
>
> > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > index a3b6936..1e47039 100644
> > --- a/Osstest/TestSupport.pm
> > +++ b/Osstest/TestSupport.pm
> > @@ -55,8 +55,9 @@ BEGIN {
> > target_putfilecontents_stash
> > target_putfilecontents_root_stash
> > target_put_guest_image target_editfile
> > - target_editfile_root target_file_exists
> > - target_run_apt
> > + target_editfile_root target_file_exists
> > + target_file_exists_root
> > + target_run_apt
>
> Please don't just change white spaces. This makes patches hard to
> review.
>
> > target_install_packages target_install_packages_norec
> > target_jobdir target_extract_jobdistpath_subdir
> > target_extract_jobdistpath target_guest_lv_name
> > @@ -67,7 +68,7 @@ BEGIN {
> > selecthost get_hostflags get_host_property
> > get_host_native_linux_console
> > power_state power_cycle power_cycle_time
> > - serial_fetch_logs
> > + serial_fetch_logs select_ether
> > propname_massage
> >
> > get_stashed open_unique_stashfile compress_stashed
> > @@ -109,6 +110,7 @@ BEGIN {
> > iso_gen_flags_basic
> > iso_copy_content_from_image
> > guest_editconfig_nocd
> > + guest_editconfig_cd
>
> Indentation. I think we mostly use space instead of hard tab. Ian?
So what's the convention in Xen code writing? use space instead of tab?
And how many space to substitute 1 tab? I used to use 4.
>
> > );
> > %EXPORT_TAGS = ( );
> >
> > @@ -481,6 +483,14 @@ sub target_file_exists ($$) {
> > die "$rfile $out ?";
> > }
> >
> > +sub target_file_exists_root ($$) {
> > + my ($ho,$rfile) = @_;
> > + my $out= target_cmd_output_root($ho, "if test -e $rfile; then echo y; fi");
> > + return 1 if $out =~ m/^y$/;
> > + return 0 if $out !~ m/\S/;
> > + die "$rfile $out ?";
> > +}
> > +
> > sub teditfileex {
> > my $user= shift @_;
> > my $code= pop @_;
> > @@ -717,6 +727,7 @@ sub power_cycle_time ($) {
> > sub power_cycle ($) {
> > my ($ho) = @_;
> > $mjobdb->host_check_allocated($ho);
> > + $mjobdb->xen_check_installed($ho);
>
> And this is? I don't see implementation in this patch set.
>
> Also this routine is called by ts-host-install, which doesn't necessary
> require Xen to be installed.
>
> > die "refusing to set power state for host $ho->{Name}".
> > " possibly shared with other jobs\n"
> > if $ho->{SharedMaybeOthers};
> > @@ -937,7 +948,7 @@ sub compress_stashed($) {
> > sub host_reboot ($) {
> > my ($ho) = @_;
> > target_reboot($ho);
> > - poll_loop(40,2, 'reboot-confirm-booted', sub {
> > + poll_loop(200,2, 'reboot-confirm-booted', sub {
>
> This should go into its own patch as well. I think it's probably nested
> virt is slower than real hardware so you need some more time?
>
> > my $output;
> > if (!eval {
> > $output= target_cmd_output($ho, <<END, 40);
> > @@ -1465,7 +1476,7 @@ sub prepareguest_part_xencfg ($$$$$) {
> > my $xencfg= <<END;
> > name = '$gho->{Name}'
> > memory = ${ram_mb}
> > -vif = [ 'type=ioemu,mac=$gho->{Ether}' ]
> > +vif = [ 'type=ioemu,model=e1000,mac=$gho->{Ether}' ]
>
> What is this needed? If it's necessary, please use a single commit and
> state the reason in commit log.
>
> > #
> > on_poweroff = 'destroy'
> > on_reboot = '$onreboot'
> > @@ -2063,4 +2074,14 @@ sub guest_editconfig_nocd ($$) {
> > });
> > }
> >
> > +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/;
>
> This pattern is different than the one used to match. This should also
> go into its own commit -- "Introduce guest_editconfig_cd".
>
> > + }
> > + s/^on_reboot.*/on_reboot='restart'/;
> > + });
> > +}
> > +
> > 1;
> > diff --git a/sg-run-job b/sg-run-job
> > index 2cf810a..8dcf7af 100755
> > --- a/sg-run-job
> > +++ b/sg-run-job
> > @@ -288,6 +288,11 @@ 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 + nested + nested_L1
> > +}
> > +
> > proc test-guest-migr {g} {
> > if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
> >
>
> This hunk should go into its own commit.
>
> > diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
> > index 37eade2..6dcec3c 100755
> > --- a/ts-debian-hvm-install
> > +++ b/ts-debian-hvm-install
>
> The modification of debian-hvm-install should also go into a single
> commit.
>
> > @@ -28,22 +28,24 @@ if (@ARGV && $ARGV[0] =~ m/^--stage(\d+)$/) { $stage=$1; shift @ARGV; }
> >
> > defined($r{bios}) or die "Need to define which bios to use";
> >
> > -our ($whhost,$gn) = @ARGV;
> > +our ($whhost,$gn,$nested_L1,$guesthost) = @ARGV;
> > $whhost ||= 'host';
> > -$gn ||= 'debianhvm';
> > -
> > +$nested_L1 ||= '';
> > +if ($nested_L1 eq 'nested_L1') {
> > + $gn ||= 'nested';
> > + $guesthost ||= "$gn.l1.osstest";
> > +} else {
> > + $gn ||= 'debianhvm';
> > + $guesthost= "$gn.guest.osstest";
> > +}
> > our $ho= selecthost($whhost);
> > -
> > +our $disk_mb= 50000;
> > # guest memory size will be set based on host free memory, see below
> > our $ram_mb;
> > -our $disk_mb= 10000;
> > -
> > -our $guesthost= "$gn.guest.osstest";
> > our $gho;
> >
> > our $toolstack= toolstack()->{Command};
> >
> > -
>
> Stray blank line change. Please avoid this kind of changes.
>
> > sub preseed () {
> >
> > my $preseed_file = preseed_base('wheezy','',());
> > @@ -63,7 +65,7 @@ d-i partman-auto/expert_recipe string \\
> > use_filesystem{ } filesystem{ vfat } \\
> > mountpoint{ /boot/efi } \\
> > . \\
> > - 5000 50 5000 ext4 \\
> > + 25000 50 25000 ext4 \\
> > method{ format } format{ } \\
> > use_filesystem{ } filesystem{ ext4 } \\
> > mountpoint{ / } \\
> > @@ -155,6 +157,8 @@ sub prep () {
> > more_prepareguest_hvm($ho,$gho, $ram_mb, $disk_mb,
> > OnReboot => 'preserve',
> > Bios => $r{bios},
> > + DefVcpus => 4,
>
> And where is this handled?
>
> Wei.
>
> > + ExtraConfig => '#nestedhvm=1',
> > PostImageHook => sub {
> > my $cmds = iso_copy_content_from_image($gho, $newiso);
> > $cmds .= prepare_initrd($initrddir,$newiso,$preseed_file_path);
> > @@ -176,6 +180,8 @@ my $ram_minslop = 100;
> > my $ram_lots = 5000;
> > if ($host_freemem_mb > $ram_lots * 2 + $ram_minslop) {
> > $ram_mb = $ram_lots;
> > +} elsif ($nested_L1 eq 'nested_L1') {
> > + $ram_mb = 2048;
> > } else {
> > $ram_mb = 768;
> > }
> > @@ -192,7 +198,15 @@ if ($stage<2) {
> > guest_destroy($ho,$gho);
> > }
> >
> > -guest_editconfig_nocd($gho,$emptyiso);
> > +if ($nested_L1 eq 'nested_L1') {
> > + guest_editconfig_cd($gho);
> > +} else {
> > + guest_editconfig_nocd($gho,$emptyiso);
> > +}
> > guest_create($gho,$toolstack);
> > guest_await_dhcp_tcp($gho,300);
> > guest_check_up($gho);
> > +if ($nested_L1 eq 'nested_L1') {
> > + target_cmd_root($gho, "mkdir -p /home/osstest/.ssh && cp /root/.ssh/authorized_keys /home/osstest/.ssh/");
> > +}
> > +
> > --
> > 1.7.10.4
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 1/4] Add nested testcase of preparing and installing L1 guest VM
2014-12-26 5:13 ` Robert Hu
@ 2015-01-02 9:51 ` Dario Faggioli
0 siblings, 0 replies; 32+ messages in thread
From: Dario Faggioli @ 2015-01-02 9:51 UTC (permalink / raw)
To: robert.hu
Cc: Wei Liu, Ian.Campbell, Ian.Jackson, xen-devel, longtao.pang,
di.zheng
[-- Attachment #1.1: Type: text/plain, Size: 3717 bytes --]
On Fri, 2014-12-26 at 13:13 +0800, Robert Hu wrote:
> On Thu, 2014-12-11 at 11:06 +0000, Wei Liu wrote:
> > ?
> >
> > > die unless $entry;
> > > $entry->{KernDom0}= $1;
> > > $entry->{KernVer}= $2;
> > > }
> > > - if (m/^\s*module\s*\/(initrd\S+)/) {
> > > + if (m/^\s*module\s*(?:\/boot)*\/(initrd\S+)/) {
> > > $entry->{Initrd}= $1;
> > > }
> > > }
> >
> > As I said before, this hunk should be in its own patch.
> >
> > Just FYI, there are multiple people (Dario, you and I) touching this
> > piece of code. You might want to keep an eye on main OSSTest git tree
> > and rebase before reposting (and so do Dario and I).
>
Indeed. :-)
> > > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > > @@ -55,8 +55,9 @@ BEGIN {
> > > target_putfilecontents_stash
> > > target_putfilecontents_root_stash
> > > target_put_guest_image target_editfile
> > > - target_editfile_root target_file_exists
> > > - target_run_apt
> > > + target_editfile_root target_file_exists
> > > + target_file_exists_root
> > > + target_run_apt
> >
> > Please don't just change white spaces. This makes patches hard to
> > review.
> >
> > > target_install_packages target_install_packages_norec
> > > target_jobdir target_extract_jobdistpath_subdir
> > > target_extract_jobdistpath target_guest_lv_name
> > > @@ -67,7 +68,7 @@ BEGIN {
> > > selecthost get_hostflags get_host_property
> > > get_host_native_linux_console
> > > power_state power_cycle power_cycle_time
> > > - serial_fetch_logs
> > > + serial_fetch_logs select_ether
> > > propname_massage
> > >
> > > get_stashed open_unique_stashfile compress_stashed
> > > @@ -109,6 +110,7 @@ BEGIN {
> > > iso_gen_flags_basic
> > > iso_copy_content_from_image
> > > guest_editconfig_nocd
> > > + guest_editconfig_cd
> >
> > Indentation. I think we mostly use space instead of hard tab. Ian?
> So what's the convention in Xen code writing? use space instead of tab?
> And how many space to substitute 1 tab? I used to use 4.
>
Xen's coding style is described in various CODING_STYLE files, within
the Xen's tree.
For example, for the hypervisor, this one:
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=CODING_STYLE;h=95842e39c967ec0c100f9337ad4b245fbff1a53f;hb=refs/heads/staging
For libxl, this other one:
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/CODING_STYLE;h=f5b58909b34d158f4c06bb3e279f6648b1aa01ec;hb=refs/heads/staging
However, OSSTest is not Xen, so whatever Xen coding style is, it does
not really matter here. :-)
There actually is no formally defined coding style, and in fact, there
is no CODING_STYLE file in OSSTest's tree. The idea is to follow the
prevalent style of the file you're modifying.
For instance, in case of TestSupport.pm it seems that spaces are used,
and that indentation happens by means of 4 spaces.
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 32+ messages in thread
* [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for L1 guest VM
2014-12-10 8:07 [OSSTEST PATCH 0/4] Introduction of the patches longtao.pang
2014-12-10 8:07 ` [OSSTEST PATCH 1/4] Add nested testcase of preparing and installing L1 guest VM longtao.pang
@ 2014-12-10 8:07 ` longtao.pang
2014-12-11 11:25 ` Wei Liu
2014-12-10 8:07 ` [OSSTEST PATCH 3/4] Add nested testcase of installing L2 " longtao.pang
` (2 subsequent siblings)
4 siblings, 1 reply; 32+ messages in thread
From: longtao.pang @ 2014-12-10 8:07 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, Ian.Campbell, Ian.Jackson, robert.hu, longtaox.pang,
di.zheng
From: "longtao.pang" <longtaox.pang@intel.com>
This patch is used for building XEN and HVM Dom0 kernel for L1 guest VM,
and then reboot L1 guest into xen kernel.
---
sg-run-job | 1 +
ts-xen-install | 149 +++++++++++++++++++++++++++++++++++++++++---------------
2 files changed, 111 insertions(+), 39 deletions(-)
diff --git a/sg-run-job b/sg-run-job
index 8dcf7af..e513bd1 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -291,6 +291,7 @@ proc run-job/test-pair {} {
proc need-hosts/test-nested {} {return host}
proc run-job/test-nested {} {
run-ts . = ts-debian-hvm-install + host + nested + nested_L1
+ run-ts . = ts-xen-install + host + nested + nested_build
}
proc test-guest-migr {g} {
diff --git a/ts-xen-install b/ts-xen-install
index 4d34d1f..c175d6d 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -28,19 +28,25 @@ use Osstest::CXFabric;
my $checkmode= 0;
tsreadconfig();
-
+our $w_ho;
our @hos;
-
-if (@ARGV and $ARGV[0] eq '--check') {
- $checkmode= 1;
- shift @ARGV;
- logm("checking builds are done...");
+our ($whhost,$gn,$nested_build) = @ARGV;
+$nested_build ||= '';
+if ($nested_build eq 'nested_build') {
+ $whhost ||= 'host';
+ $gn ||= 'nested';
} else {
- if (!@ARGV) {
- push @ARGV, 'host';
- }
- foreach my $k (@ARGV) {
- push @hos, selecthost($k);
+ if (@ARGV and $ARGV[0] eq '--check') {
+ $checkmode= 1;
+ shift @ARGV;
+ logm("checking builds are done...");
+ } else {
+ if (!@ARGV) {
+ push @ARGV, 'host';
+ }
+ foreach my $k (@ARGV) {
+ push @hos, selecthost($k);
+ }
}
}
@@ -49,18 +55,18 @@ our $ho;
my %distpath;
sub packages () {
- target_install_packages($ho,
+ target_install_packages($w_ho,
qw(bridge-utils vncsnapshot libaio1 libpixman-1-0
libsdl1.2debian libglib2.0-0 liblzma5));
- target_install_packages($ho,
+ target_install_packages($w_ho,
$ho->{Suite} =~ /squeeze/ ? "libyajl1" : "libyajl2");
if ($ho->{Suite} !~ m/lenny|squeeze/) {
- target_install_packages($ho, 'libfdt1');
+ target_install_packages($w_ho, 'libfdt1');
}
if ($r{arch} eq 'i386') {
- target_install_packages($ho, 'libc6-xen');
+ target_install_packages($w_ho, 'libc6-xen');
}
- target_install_packages($ho, @{toolstack()->{ExtraPackages}})
+ target_install_packages($w_ho, @{toolstack()->{ExtraPackages}})
if toolstack()->{ExtraPackages};
}
@@ -69,14 +75,14 @@ sub extract () {
push @parts, 'libvirt' if $r{toolstack} eq "libvirt";
foreach my $part (@parts) {
- target_extract_jobdistpath($ho, $part, "path_${part}dist",
+ target_extract_jobdistpath($w_ho, $part, "path_${part}dist",
$r{"${part}buildjob"}, \%distpath);
}
- target_cmd_root($ho, '/sbin/ldconfig');
+ target_cmd_root($w_ho, '/sbin/ldconfig');
}
sub adjustconfig () {
- target_editfile_root($ho, "/etc/xen/xend-config.sxp",
+ target_editfile_root($w_ho, "/etc/xen/xend-config.sxp",
"xend-config.sxp", sub {
my (@domains) = (qw(localhost localhost.localdomain),
".".$c{DnsDomain}, ".".$c{TestHostDomain});
@@ -108,13 +114,13 @@ sub adjustconfig () {
/etc/sysconfig/xencommons
/etc/default/xend
/etc/sysconfig/xend)) {
- next unless target_file_exists($ho, $try);
+ next unless target_file_exists($w_ho, $try);
$trace_config_file= $try;
last;
}
die unless defined $trace_config_file;
- target_editfile_root($ho, $trace_config_file, sub {
+ target_editfile_root($w_ho, $trace_config_file, sub {
my $prnow;
$prnow= sub {
print EO "XENCONSOLED_TRACE=guest\n" or die $!;
@@ -128,7 +134,7 @@ sub adjustconfig () {
$prnow->();
});
- target_cmd_root($ho, 'mkdir -p /var/log/xen/console');
+ target_cmd_root($w_ho, 'mkdir -p /var/log/xen/console');
setup_cxfabric($ho);
}
@@ -156,19 +162,19 @@ sub setupboot () {
$xenhopt .= " $append" if defined $append;
my @hooks;
-
+
if (host_involves_pcipassthrough($ho)) {
push @hooks, {
EditBootOptions => sub {
my ($ho,$hopt,$kopt) = @_;
$$hopt .= ' iommu=on';
my $hide= ' xen-pciback.hide='. join '',map { "($_->{Bdf})" }
- host_get_pcipassthrough_devs($ho);
+ host_get_pcipassthrough_devs($ho);
logm("pci passthrough: hiding in dom0: $hide");
$$kopt .= $hide;
- }
- };
- }
+ }
+ };
+ }
my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
@@ -182,7 +188,7 @@ sub setupinitd () {
my $ts= toolstack();
my $xencommons= '/etc/init.d/xencommons';
my $have_xencommons=
- !!target_cmd_output_root($ho, <<END);
+ !!target_cmd_output_root($w_ho, <<END);
if test -f $xencommons && ! grep 'FOR USE WITH LIBXL' $xencommons >/dev/null
then
echo y
@@ -211,7 +217,33 @@ END
$updatercd->($initd,93) if defined $initd;
$updatercd->('xenbridge',38) if $ts->{OldSeparateBridgeInitd};
}
- target_cmd_root($ho, $cmd);
+ target_cmd_root($w_ho, $cmd);
+}
+
+sub setup_l1_bridge($)
+{
+ my ($ho)=@_;
+ my $bridge_port;
+ my $route_output=target_cmd_output_root($ho,"route -n");
+ foreach my $line (split /\n/, $route_output){
+ if($line =~ m/^\s*(?:(?:0\.0\.0\.0)|default).*\s(\w+)\s*$/ai){
+ $bridge_port=$1;
+ logm("get L1 bridge phy port $bridge_port");
+ last;
+ }
+ }
+ die "cannot find L1 port for xenbr0 bridge" if !defined $bridge_port;
+
+ target_editfile_root($ho, "/etc/network/interfaces",
+ "etc-network-interfaces",
+ sub {
+ while(<EI>){
+ s/^\s*iface\s*$bridge_port\s*inet.*dhcp\s*$/iface $bridge_port inet manual\nauto xenbr0\niface xenbr0 inet dhcp\n\tbridge_ports $bridge_port\n/;
+ s/^\s*auto\s*$bridge_port/#auto\t$bridge_port/;
+ print EO;
+ }
+ });
+ target_cmd_root($ho,"brctl addbr xenbr0; brctl addif xenbr0 $bridge_port; init 6");
}
sub nodhcp () {
@@ -322,17 +354,56 @@ sub forbidden () {
END
}
-if ($checkmode) {
- extract();
-} else {
- die if @hos > 1;
- $ho= $hos[0];
-
+if ($nested_build eq 'nested_build') {
+ our $gho;
+ $ho= selecthost($whhost);
+ $gho= selectguest($gn,$ho);
+ $w_ho = $gho;
+ store_runvar("$gho->{Guest}_kernkind",$r{'kernkind'});
+ $gho->{Suite}=$ho->{Suite};
+
+ guest_check_ip($gho);
packages();
extract();
- forbidden();
adjustconfig();
- setupboot();
- setupinitd();
- nodhcp();
+ my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
+ my $bootloader;
+ $bootloader=setupboot_grub2($gho, $want_kernver, "");
+
+
+ target_cmd_root($gho,
+ "update-initramfs -k $want_kernver -c ||".
+ " update-initramfs -k $want_kernver -u",
+ 200);
+ $bootloader->{UpdateConfig}($gho); #so that /boot/grub/grub.cfg have new kernel and xen
+ $bootloader->{PreFinalUpdate}(); #update /etc/default/grub, by setting default entry we want
+
+ setupinitd ();
+ $bootloader->{UpdateConfig}($gho); #use the default entry, apply it to /boot/grub/grub.cfg
+ guest_editconfig($gho->{Host}, $gho, sub {
+ s/#nestedhvm/nestedhvm/;
+ });
+ target_cmd_root($gho,"sync");
+ setup_l1_bridge($gho); #after setup L1 bridge, it will reboot for network settiings to take effect
+ logm("ready to reboot L1 Xen");
+ guest_await($gho, target_var($gho,'boot_timeout'));
+ guest_check_up($gho);
+
+
+} else {
+
+ if ($checkmode) {
+ extract();
+ } else {
+ die if @hos > 1;
+ $ho= $hos[0];
+ $w_ho = $ho;
+ packages();
+ extract();
+ forbidden();
+ adjustconfig();
+ setupboot();
+ setupinitd();
+ nodhcp();
+ }
}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for L1 guest VM
2014-12-10 8:07 ` [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for " longtao.pang
@ 2014-12-11 11:25 ` Wei Liu
2015-01-27 8:33 ` Hu, Robert
0 siblings, 1 reply; 32+ messages in thread
From: Wei Liu @ 2014-12-11 11:25 UTC (permalink / raw)
To: longtao.pang
Cc: wei.liu2, Ian.Campbell, Ian.Jackson, xen-devel, robert.hu,
di.zheng
On Wed, Dec 10, 2014 at 04:07:38PM +0800, longtao.pang wrote:
> From: "longtao.pang" <longtaox.pang@intel.com>
>
> This patch is used for building XEN and HVM Dom0 kernel for L1 guest VM,
> and then reboot L1 guest into xen kernel.
>
I think you can just use the L0 Xen and Dom0 kernel, that would save you
lots of time running this test case. It can also help simplifies this
patch, maybe?
> ---
> sg-run-job | 1 +
> ts-xen-install | 149 +++++++++++++++++++++++++++++++++++++++++---------------
> 2 files changed, 111 insertions(+), 39 deletions(-)
>
> diff --git a/sg-run-job b/sg-run-job
> index 8dcf7af..e513bd1 100755
> --- a/sg-run-job
> +++ b/sg-run-job
> @@ -291,6 +291,7 @@ proc run-job/test-pair {} {
> proc need-hosts/test-nested {} {return host}
> proc run-job/test-nested {} {
> run-ts . = ts-debian-hvm-install + host + nested + nested_L1
> + run-ts . = ts-xen-install + host + nested + nested_build
> }
>
> proc test-guest-migr {g} {
> diff --git a/ts-xen-install b/ts-xen-install
> index 4d34d1f..c175d6d 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -28,19 +28,25 @@ use Osstest::CXFabric;
> my $checkmode= 0;
>
> tsreadconfig();
> -
> +our $w_ho;
> our @hos;
> -
> -if (@ARGV and $ARGV[0] eq '--check') {
> - $checkmode= 1;
> - shift @ARGV;
> - logm("checking builds are done...");
> +our ($whhost,$gn,$nested_build) = @ARGV;
> +$nested_build ||= '';
> +if ($nested_build eq 'nested_build') {
> + $whhost ||= 'host';
> + $gn ||= 'nested';
> } else {
> - if (!@ARGV) {
> - push @ARGV, 'host';
> - }
> - foreach my $k (@ARGV) {
> - push @hos, selecthost($k);
> + if (@ARGV and $ARGV[0] eq '--check') {
> + $checkmode= 1;
> + shift @ARGV;
> + logm("checking builds are done...");
> + } else {
> + if (!@ARGV) {
> + push @ARGV, 'host';
> + }
> + foreach my $k (@ARGV) {
> + push @hos, selecthost($k);
> + }
> }
> }
>
> @@ -49,18 +55,18 @@ our $ho;
> my %distpath;
>
> sub packages () {
> - target_install_packages($ho,
> + target_install_packages($w_ho,
> qw(bridge-utils vncsnapshot libaio1 libpixman-1-0
> libsdl1.2debian libglib2.0-0 liblzma5));
> - target_install_packages($ho,
> + target_install_packages($w_ho,
> $ho->{Suite} =~ /squeeze/ ? "libyajl1" : "libyajl2");
> if ($ho->{Suite} !~ m/lenny|squeeze/) {
> - target_install_packages($ho, 'libfdt1');
> + target_install_packages($w_ho, 'libfdt1');
> }
> if ($r{arch} eq 'i386') {
> - target_install_packages($ho, 'libc6-xen');
> + target_install_packages($w_ho, 'libc6-xen');
> }
> - target_install_packages($ho, @{toolstack()->{ExtraPackages}})
> + target_install_packages($w_ho, @{toolstack()->{ExtraPackages}})
> if toolstack()->{ExtraPackages};
> }
>
> @@ -69,14 +75,14 @@ sub extract () {
> push @parts, 'libvirt' if $r{toolstack} eq "libvirt";
>
> foreach my $part (@parts) {
> - target_extract_jobdistpath($ho, $part, "path_${part}dist",
> + target_extract_jobdistpath($w_ho, $part, "path_${part}dist",
> $r{"${part}buildjob"}, \%distpath);
> }
> - target_cmd_root($ho, '/sbin/ldconfig');
> + target_cmd_root($w_ho, '/sbin/ldconfig');
> }
>
> sub adjustconfig () {
> - target_editfile_root($ho, "/etc/xen/xend-config.sxp",
> + target_editfile_root($w_ho, "/etc/xen/xend-config.sxp",
> "xend-config.sxp", sub {
> my (@domains) = (qw(localhost localhost.localdomain),
> ".".$c{DnsDomain}, ".".$c{TestHostDomain});
> @@ -108,13 +114,13 @@ sub adjustconfig () {
> /etc/sysconfig/xencommons
> /etc/default/xend
> /etc/sysconfig/xend)) {
> - next unless target_file_exists($ho, $try);
> + next unless target_file_exists($w_ho, $try);
> $trace_config_file= $try;
> last;
> }
> die unless defined $trace_config_file;
>
> - target_editfile_root($ho, $trace_config_file, sub {
> + target_editfile_root($w_ho, $trace_config_file, sub {
> my $prnow;
> $prnow= sub {
> print EO "XENCONSOLED_TRACE=guest\n" or die $!;
> @@ -128,7 +134,7 @@ sub adjustconfig () {
> $prnow->();
> });
>
> - target_cmd_root($ho, 'mkdir -p /var/log/xen/console');
> + target_cmd_root($w_ho, 'mkdir -p /var/log/xen/console');
>
> setup_cxfabric($ho);
> }
> @@ -156,19 +162,19 @@ sub setupboot () {
> $xenhopt .= " $append" if defined $append;
>
> my @hooks;
> -
> +
> if (host_involves_pcipassthrough($ho)) {
> push @hooks, {
> EditBootOptions => sub {
> my ($ho,$hopt,$kopt) = @_;
> $$hopt .= ' iommu=on';
> my $hide= ' xen-pciback.hide='. join '',map { "($_->{Bdf})" }
> - host_get_pcipassthrough_devs($ho);
> + host_get_pcipassthrough_devs($ho);
> logm("pci passthrough: hiding in dom0: $hide");
> $$kopt .= $hide;
> - }
> - };
> - }
> + }
> + };
> + }
>
> my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
> debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath, \@hooks);
> @@ -182,7 +188,7 @@ sub setupinitd () {
> my $ts= toolstack();
> my $xencommons= '/etc/init.d/xencommons';
> my $have_xencommons=
> - !!target_cmd_output_root($ho, <<END);
> + !!target_cmd_output_root($w_ho, <<END);
> if test -f $xencommons && ! grep 'FOR USE WITH LIBXL' $xencommons >/dev/null
> then
> echo y
> @@ -211,7 +217,33 @@ END
> $updatercd->($initd,93) if defined $initd;
> $updatercd->('xenbridge',38) if $ts->{OldSeparateBridgeInitd};
> }
> - target_cmd_root($ho, $cmd);
> + target_cmd_root($w_ho, $cmd);
> +}
> +
> +sub setup_l1_bridge($)
> +{
> + my ($ho)=@_;
> + my $bridge_port;
> + my $route_output=target_cmd_output_root($ho,"route -n");
> + foreach my $line (split /\n/, $route_output){
> + if($line =~ m/^\s*(?:(?:0\.0\.0\.0)|default).*\s(\w+)\s*$/ai){
> + $bridge_port=$1;
> + logm("get L1 bridge phy port $bridge_port");
> + last;
> + }
> + }
> + die "cannot find L1 port for xenbr0 bridge" if !defined $bridge_port;
> +
> + target_editfile_root($ho, "/etc/network/interfaces",
> + "etc-network-interfaces",
> + sub {
> + while(<EI>){
> + s/^\s*iface\s*$bridge_port\s*inet.*dhcp\s*$/iface $bridge_port inet manual\nauto xenbr0\niface xenbr0 inet dhcp\n\tbridge_ports $bridge_port\n/;
> + s/^\s*auto\s*$bridge_port/#auto\t$bridge_port/;
> + print EO;
> + }
> + });
> + target_cmd_root($ho,"brctl addbr xenbr0; brctl addif xenbr0 $bridge_port; init 6");
> }
FWIW, OSSTest has a bunch of overlay files (look at overlay directory),
which includes an init script called xenbridge. In theory if you're
reusing this script (ts-xen-install) then you don't need to worry about
setting up bridge?
>
> sub nodhcp () {
> @@ -322,17 +354,56 @@ sub forbidden () {
> END
> }
>
> -if ($checkmode) {
> - extract();
> -} else {
> - die if @hos > 1;
> - $ho= $hos[0];
> -
> +if ($nested_build eq 'nested_build') {
> + our $gho;
> + $ho= selecthost($whhost);
> + $gho= selectguest($gn,$ho);
> + $w_ho = $gho;
> + store_runvar("$gho->{Guest}_kernkind",$r{'kernkind'});
> + $gho->{Suite}=$ho->{Suite};
> +
> + guest_check_ip($gho);
> packages();
> extract();
> - forbidden();
> adjustconfig();
> - setupboot();
> - setupinitd();
> - nodhcp();
> + my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
> + my $bootloader;
> + $bootloader=setupboot_grub2($gho, $want_kernver, "");
> +
> +
> + target_cmd_root($gho,
> + "update-initramfs -k $want_kernver -c ||".
> + " update-initramfs -k $want_kernver -u",
> + 200);
> + $bootloader->{UpdateConfig}($gho); #so that /boot/grub/grub.cfg have new kernel and xen
> + $bootloader->{PreFinalUpdate}(); #update /etc/default/grub, by setting default entry we want
> +
> + setupinitd ();
> + $bootloader->{UpdateConfig}($gho); #use the default entry, apply it to /boot/grub/grub.cfg
> + guest_editconfig($gho->{Host}, $gho, sub {
> + s/#nestedhvm/nestedhvm/;
> + });
> + target_cmd_root($gho,"sync");
> + setup_l1_bridge($gho); #after setup L1 bridge, it will reboot for network settiings to take effect
> + logm("ready to reboot L1 Xen");
> + guest_await($gho, target_var($gho,'boot_timeout'));
> + guest_check_up($gho);
> +
This hunk is copied from Debian.pm. If debian_setup_boot cannot meet
your requirement, please refactor it.
Wei.
> +
> +} else {
> +
> + if ($checkmode) {
> + extract();
> + } else {
> + die if @hos > 1;
> + $ho= $hos[0];
> + $w_ho = $ho;
> + packages();
> + extract();
> + forbidden();
> + adjustconfig();
> + setupboot();
> + setupinitd();
> + nodhcp();
> + }
> }
> --
> 1.7.10.4
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for L1 guest VM
2014-12-11 11:25 ` Wei Liu
@ 2015-01-27 8:33 ` Hu, Robert
2015-01-27 11:01 ` Ian Campbell
0 siblings, 1 reply; 32+ messages in thread
From: Hu, Robert @ 2015-01-27 8:33 UTC (permalink / raw)
To: Wei Liu, Pang, LongtaoX
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Zheng, Di,
xen-devel@lists.xen.org
> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Thursday, December 11, 2014 7:25 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> Ian.Campbell@citrix.com; wei.liu2@citrix.com; Hu, Robert; Zheng, Di
> Subject: Re: [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for L1 guest
> VM
>
> On Wed, Dec 10, 2014 at 04:07:38PM +0800, longtao.pang wrote:
> > From: "longtao.pang" <longtaox.pang@intel.com>
> >
> > This patch is used for building XEN and HVM Dom0 kernel for L1 guest VM,
> > and then reboot L1 guest into xen kernel.
> >
>
> I think you can just use the L0 Xen and Dom0 kernel, that would save you
> lots of time running this test case. It can also help simplifies this
> patch, maybe?
>
> > ---
> > sg-run-job | 1 +
> > ts-xen-install | 149
> +++++++++++++++++++++++++++++++++++++++++---------------
> > 2 files changed, 111 insertions(+), 39 deletions(-)
> >
> > diff --git a/sg-run-job b/sg-run-job
> > index 8dcf7af..e513bd1 100755
> > --- a/sg-run-job
> > +++ b/sg-run-job
> > @@ -291,6 +291,7 @@ proc run-job/test-pair {} {
> > proc need-hosts/test-nested {} {return host}
> > proc run-job/test-nested {} {
> > run-ts . = ts-debian-hvm-install + host + nested + nested_L1
> > + run-ts . = ts-xen-install + host + nested + nested_build
> > }
> >
> > proc test-guest-migr {g} {
> > diff --git a/ts-xen-install b/ts-xen-install
> > index 4d34d1f..c175d6d 100755
> > --- a/ts-xen-install
> > +++ b/ts-xen-install
> > @@ -28,19 +28,25 @@ use Osstest::CXFabric;
> > my $checkmode= 0;
> >
> > tsreadconfig();
> > -
> > +our $w_ho;
> > our @hos;
> > -
> > -if (@ARGV and $ARGV[0] eq '--check') {
> > - $checkmode= 1;
> > - shift @ARGV;
> > - logm("checking builds are done...");
> > +our ($whhost,$gn,$nested_build) = @ARGV;
> > +$nested_build ||= '';
> > +if ($nested_build eq 'nested_build') {
> > + $whhost ||= 'host';
> > + $gn ||= 'nested';
> > } else {
> > - if (!@ARGV) {
> > - push @ARGV, 'host';
> > - }
> > - foreach my $k (@ARGV) {
> > - push @hos, selecthost($k);
> > + if (@ARGV and $ARGV[0] eq '--check') {
> > + $checkmode= 1;
> > + shift @ARGV;
> > + logm("checking builds are done...");
> > + } else {
> > + if (!@ARGV) {
> > + push @ARGV, 'host';
> > + }
> > + foreach my $k (@ARGV) {
> > + push @hos, selecthost($k);
> > + }
> > }
> > }
> >
> > @@ -49,18 +55,18 @@ our $ho;
> > my %distpath;
> >
> > sub packages () {
> > - target_install_packages($ho,
> > + target_install_packages($w_ho,
> > qw(bridge-utils vncsnapshot libaio1
> libpixman-1-0
> > libsdl1.2debian libglib2.0-0
> liblzma5));
> > - target_install_packages($ho,
> > + target_install_packages($w_ho,
> > $ho->{Suite} =~ /squeeze/ ? "libyajl1" : "libyajl2");
> > if ($ho->{Suite} !~ m/lenny|squeeze/) {
> > - target_install_packages($ho, 'libfdt1');
> > + target_install_packages($w_ho, 'libfdt1');
> > }
> > if ($r{arch} eq 'i386') {
> > - target_install_packages($ho, 'libc6-xen');
> > + target_install_packages($w_ho, 'libc6-xen');
> > }
> > - target_install_packages($ho, @{toolstack()->{ExtraPackages}})
> > + target_install_packages($w_ho, @{toolstack()->{ExtraPackages}})
> > if toolstack()->{ExtraPackages};
> > }
> >
> > @@ -69,14 +75,14 @@ sub extract () {
> > push @parts, 'libvirt' if $r{toolstack} eq "libvirt";
> >
> > foreach my $part (@parts) {
> > - target_extract_jobdistpath($ho, $part, "path_${part}dist",
> > + target_extract_jobdistpath($w_ho, $part, "path_${part}dist",
> > $r{"${part}buildjob"}, \%distpath);
> > }
> > - target_cmd_root($ho, '/sbin/ldconfig');
> > + target_cmd_root($w_ho, '/sbin/ldconfig');
> > }
> >
> > sub adjustconfig () {
> > - target_editfile_root($ho, "/etc/xen/xend-config.sxp",
> > + target_editfile_root($w_ho, "/etc/xen/xend-config.sxp",
> > "xend-config.sxp", sub {
> > my (@domains) = (qw(localhost localhost.localdomain),
> > ".".$c{DnsDomain}, ".".$c{TestHostDomain});
> > @@ -108,13 +114,13 @@ sub adjustconfig () {
> > /etc/sysconfig/xencommons
> > /etc/default/xend
> > /etc/sysconfig/xend)) {
> > - next unless target_file_exists($ho, $try);
> > + next unless target_file_exists($w_ho, $try);
> > $trace_config_file= $try;
> > last;
> > }
> > die unless defined $trace_config_file;
> >
> > - target_editfile_root($ho, $trace_config_file, sub {
> > + target_editfile_root($w_ho, $trace_config_file, sub {
> > my $prnow;
> > $prnow= sub {
> > print EO "XENCONSOLED_TRACE=guest\n" or die $!;
> > @@ -128,7 +134,7 @@ sub adjustconfig () {
> > $prnow->();
> > });
> >
> > - target_cmd_root($ho, 'mkdir -p /var/log/xen/console');
> > + target_cmd_root($w_ho, 'mkdir -p /var/log/xen/console');
> >
> > setup_cxfabric($ho);
> > }
> > @@ -156,19 +162,19 @@ sub setupboot () {
> > $xenhopt .= " $append" if defined $append;
> >
> > my @hooks;
> > -
> > +
> > if (host_involves_pcipassthrough($ho)) {
> > push @hooks, {
> > EditBootOptions => sub {
> > my ($ho,$hopt,$kopt) = @_;
> > $$hopt .= ' iommu=on';
> > my $hide= ' xen-pciback.hide='. join '',map
> { "($_->{Bdf})" }
> > - host_get_pcipassthrough_devs($ho);
> > + host_get_pcipassthrough_devs($ho);
> > logm("pci passthrough: hiding in dom0: $hide");
> > $$kopt .= $hide;
> > - }
> > - };
> > - }
> > + }
> > + };
> > + }
> >
> > my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
> > debian_boot_setup($ho, $want_kernver, $xenhopt, \%distpath,
> \@hooks);
> > @@ -182,7 +188,7 @@ sub setupinitd () {
> > my $ts= toolstack();
> > my $xencommons= '/etc/init.d/xencommons';
> > my $have_xencommons=
> > - !!target_cmd_output_root($ho, <<END);
> > + !!target_cmd_output_root($w_ho, <<END);
> > if test -f $xencommons && ! grep 'FOR USE WITH LIBXL'
> $xencommons >/dev/null
> > then
> > echo y
> > @@ -211,7 +217,33 @@ END
> > $updatercd->($initd,93) if defined $initd;
> > $updatercd->('xenbridge',38) if $ts->{OldSeparateBridgeInitd};
> > }
> > - target_cmd_root($ho, $cmd);
> > + target_cmd_root($w_ho, $cmd);
> > +}
> > +
> > +sub setup_l1_bridge($)
> > +{
> > + my ($ho)=@_;
> > + my $bridge_port;
> > + my $route_output=target_cmd_output_root($ho,"route -n");
> > + foreach my $line (split /\n/, $route_output){
> > + if($line =~ m/^\s*(?:(?:0\.0\.0\.0)|default).*\s(\w+)\s*$/ai){
> > + $bridge_port=$1;
> > + logm("get L1 bridge phy port $bridge_port");
> > + last;
> > + }
> > + }
> > + die "cannot find L1 port for xenbr0 bridge" if !defined
> $bridge_port;
> > +
> > + target_editfile_root($ho, "/etc/network/interfaces",
> > + "etc-network-interfaces",
> > + sub {
> > + while(<EI>){
> > +
> s/^\s*iface\s*$bridge_port\s*inet.*dhcp\s*$/iface $bridge_port inet
> manual\nauto xenbr0\niface xenbr0 inet dhcp\n\tbridge_ports
> $bridge_port\n/;
> > +
> s/^\s*auto\s*$bridge_port/#auto\t$bridge_port/;
> > + print EO;
> > + }
> > + });
> > + target_cmd_root($ho,"brctl addbr xenbr0; brctl addif xenbr0
> $bridge_port; init 6");
> > }
>
> FWIW, OSSTest has a bunch of overlay files (look at overlay directory),
> which includes an init script called xenbridge. In theory if you're
> reusing this script (ts-xen-install) then you don't need to worry about
> setting up bridge?
I tried this approach, using xenbridge init scripts, it can work.
However, in original xen install, it seems not used. I don't see 'xenbridge'
in /etc/rc2.d/
root@osstest-host2:/etc/rc2.d# ls /etc/rc2.d/
README S13rpcbind S16rsyslog S18acpid S18cron S18exim4 S18rsync S18xencommons S21osstest-confirm-booted S21rmnologin
S01motd S14nfs-common S17apache2 S18atd S18dbus S18ntp S18ssh S20bootlogs S21rc.local
Here is the related piece of code, from ts-xen-install
sub setupinitd () {
my $ts= toolstack();
my $xencommons= '/etc/init.d/xencommons';
my $have_xencommons=
!!target_cmd_output_root($w_ho, <<END);
if test -f $xencommons && ! grep 'FOR USE WITH LIBXL' $xencommons >/dev/null
then
echo y
fi
END
$initscripts_nobridge= !defined($ts->{OldDaemonInitd}) || $have_xencommons;
logm("init.d scripts ".
($initscripts_nobridge
? 'do not mess with bridge, doing it in interfaces(5)'
: '_do_ mess with bridge, letting them handle it'));
my $cmd= '';
my $updatercd= sub {
my ($script,$start) = @_;
$cmd .= "\n update-rc.d $script start $start 2 .";
};
if ($initscripts_nobridge) {
my $script= $have_xencommons ? 'xencommons' : 'xenlightdaemons';
$updatercd->($script,92);
my $pri= 93;
foreach my $d (@{ $ts->{NewDaemons} }) {
$updatercd->("$d",$pri);
$pri++;
}
} else {
my $initd= $ts->{OldDaemonInitd};
$updatercd->($initd,93) if defined $initd;
$updatercd->('xenbridge',38) if $ts->{OldSeparateBridgeInitd};
}
target_cmd_root($w_ho, $cmd);
}
seems as long as xencommons is there, the $initscripts_nobridge will be true, i.e
xenbridge service will not be inited.
But normal ts-xen-install indeed created a bridge named 'xenbr0' (xenbridge will named
it to 'peth0' if called).
Shall I know the xenbr0 is created? I think not by xenbridge init service.
>
> >
> > sub nodhcp () {
> > @@ -322,17 +354,56 @@ sub forbidden () {
> > END
> > }
> >
> > -if ($checkmode) {
> > - extract();
> > -} else {
> > - die if @hos > 1;
> > - $ho= $hos[0];
> > -
> > +if ($nested_build eq 'nested_build') {
> > + our $gho;
> > + $ho= selecthost($whhost);
> > + $gho= selectguest($gn,$ho);
> > + $w_ho = $gho;
> > + store_runvar("$gho->{Guest}_kernkind",$r{'kernkind'});
> > + $gho->{Suite}=$ho->{Suite};
> > +
> > + guest_check_ip($gho);
> > packages();
> > extract();
> > - forbidden();
> > adjustconfig();
> > - setupboot();
> > - setupinitd();
> > - nodhcp();
> > + my $want_kernver = get_runvar('kernel_ver',$r{'kernbuildjob'});
> > + my $bootloader;
> > + $bootloader=setupboot_grub2($gho, $want_kernver, "");
> > +
> > +
> > + target_cmd_root($gho,
> > + "update-initramfs -k $want_kernver -c ||".
> > + " update-initramfs -k $want_kernver -u",
> > + 200);
> > + $bootloader->{UpdateConfig}($gho); #so that /boot/grub/grub.cfg have
> new kernel and xen
> > + $bootloader->{PreFinalUpdate}(); #update /etc/default/grub,
> by setting default entry we want
> > +
> > + setupinitd ();
> > + $bootloader->{UpdateConfig}($gho); #use the default entry,
> apply it to /boot/grub/grub.cfg
> > + guest_editconfig($gho->{Host}, $gho, sub {
> > + s/#nestedhvm/nestedhvm/;
> > + });
> > + target_cmd_root($gho,"sync");
> > + setup_l1_bridge($gho); #after setup L1 bridge, it will
> reboot for network settiings to take effect
> > + logm("ready to reboot L1 Xen");
> > + guest_await($gho, target_var($gho,'boot_timeout'));
> > + guest_check_up($gho);
> > +
>
> This hunk is copied from Debian.pm. If debian_setup_boot cannot meet
> your requirement, please refactor it.
>
> Wei.
>
> > +
> > +} else {
> > +
> > + if ($checkmode) {
> > + extract();
> > + } else {
> > + die if @hos > 1;
> > + $ho= $hos[0];
> > + $w_ho = $ho;
> > + packages();
> > + extract();
> > + forbidden();
> > + adjustconfig();
> > + setupboot();
> > + setupinitd();
> > + nodhcp();
> > + }
> > }
> > --
> > 1.7.10.4
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for L1 guest VM
2015-01-27 8:33 ` Hu, Robert
@ 2015-01-27 11:01 ` Ian Campbell
2015-01-29 6:05 ` Hu, Robert
0 siblings, 1 reply; 32+ messages in thread
From: Ian Campbell @ 2015-01-27 11:01 UTC (permalink / raw)
To: Hu, Robert
Cc: Ian.Jackson@eu.citrix.com, Pang, LongtaoX, Wei Liu, Zheng, Di,
xen-devel@lists.xen.org
On Tue, 2015-01-27 at 08:33 +0000, Hu, Robert wrote:
[...] please trim quotes.
> >
> > FWIW, OSSTest has a bunch of overlay files (look at overlay directory),
> > which includes an init script called xenbridge. In theory if you're
> > reusing this script (ts-xen-install) then you don't need to worry about
> > setting up bridge?
> I tried this approach, using xenbridge init scripts, it can work.
> However, in original xen install, it seems not used. I don't see 'xenbridge'
> in /etc/rc2.d/
xenbridge is only enabled if OldSeparateBridgeInitd is set, which it is
not for a modern Xen install so I think this is a red-herring.
> Shall I know the xenbr0 is created? I think not by xenbridge init service.
The host networking is configured by the function nodhcp in
ts-xen-install.
Per our previous conversations once the L1 guest is installed you can
mostly treat it as a if it were an L0 host wrt configuring it. In other
words there should be no need for a separate setup_l1_bridge function,
just some minor modifications to ts-xen-install.
Ian.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for L1 guest VM
2015-01-27 11:01 ` Ian Campbell
@ 2015-01-29 6:05 ` Hu, Robert
0 siblings, 0 replies; 32+ messages in thread
From: Hu, Robert @ 2015-01-29 6:05 UTC (permalink / raw)
To: Ian Campbell
Cc: Ian.Jackson@eu.citrix.com, Pang, LongtaoX, Wei Liu, Zheng, Di,
xen-devel@lists.xen.org
> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, January 27, 2015 7:01 PM
> To: Hu, Robert
> Cc: Wei Liu; Pang, LongtaoX; xen-devel@lists.xen.org;
> Ian.Jackson@eu.citrix.com; Zheng, Di
> Subject: Re: [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for L1 guest
> VM
>
> On Tue, 2015-01-27 at 08:33 +0000, Hu, Robert wrote:
> [...] please trim quotes.
> > >
> > > FWIW, OSSTest has a bunch of overlay files (look at overlay directory),
> > > which includes an init script called xenbridge. In theory if you're
> > > reusing this script (ts-xen-install) then you don't need to worry about
> > > setting up bridge?
> > I tried this approach, using xenbridge init scripts, it can work.
> > However, in original xen install, it seems not used. I don't see 'xenbridge'
> > in /etc/rc2.d/
>
> xenbridge is only enabled if OldSeparateBridgeInitd is set, which it is
> not for a modern Xen install so I think this is a red-herring.
>
> > Shall I know the xenbr0 is created? I think not by xenbridge init service.
>
> The host networking is configured by the function nodhcp in
> ts-xen-install.
yeah, I get it now. Thanks.
>
> Per our previous conversations once the L1 guest is installed you can
> mostly treat it as a if it were an L0 host wrt configuring it. In other
> words there should be no need for a separate setup_l1_bridge function,
> just some minor modifications to ts-xen-install.
I'll reuse this nodhcp() subroutine, rather than my setup_l1_bridge() nor xenbridge init script.
>
> Ian.
>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2014-12-10 8:07 [OSSTEST PATCH 0/4] Introduction of the patches longtao.pang
2014-12-10 8:07 ` [OSSTEST PATCH 1/4] Add nested testcase of preparing and installing L1 guest VM longtao.pang
2014-12-10 8:07 ` [OSSTEST PATCH 2/4] Build XEN and HVM Dom0 kernel for " longtao.pang
@ 2014-12-10 8:07 ` longtao.pang
2014-12-11 11:43 ` Wei Liu
2014-12-10 8:07 ` [OSSTEST PATCH 4/4] Insert nested test job name and runvars into longtao.pang
2014-12-11 10:38 ` [OSSTEST PATCH 0/4] Introduction of the patches Wei Liu
4 siblings, 1 reply; 32+ messages in thread
From: longtao.pang @ 2014-12-10 8:07 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, Ian.Campbell, Ian.Jackson, robert.hu, longtaox.pang,
di.zheng
From: "longtao.pang" <longtaox.pang@intel.com>
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
}
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= 10000;
-
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) {
+ $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
+ $kernver ||= target_cmd_output($ho, 'uname -r');
+ $kernpath = "/boot/vmlinuz-$kernver";
+ $initrd ||= "/boot/initrd.img-$kernver";
+ }
+ }
my $archarg= defined($arch) ? "--arch $arch" : '';
- my $gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
-
- my $kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
- my $initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
- if (!$kernpath) {
- my $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
- $kernver ||= target_cmd_output($ho, 'uname -r');
- $kernpath = "/boot/vmlinuz-$kernver";
- $initrd ||= "/boot/initrd.img-$kernver";
- }
if (!$initrd) {
$initrd = $kernpath;
$initrd =~ s,/vmlinuz-,/initrd.img-, or die "$initrd ?";
@@ -76,23 +96,97 @@ sub ginstall () {
fi
END
}
- target_cmd_root($ho, <<END, 2000);
- xen-create-image \\
- --dhcp --mac $gho->{Ether} \\
- --memory ${ram_mb}Mb --swap ${swap_mb}Mb \\
- --dist $gsuite \\
- --mirror http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
- --hostname $gho->{Name} \\
- --lvm $gho->{Vg} --force \\
- --kernel $kernpath \\
- --genpass 0 --password xenroot \\
- $initrd_opt \\
- $archarg
+ if($nested_L2 eq 'nested_L2') {
+ target_cmd_root($ho, <<END, 2000);
+ xen-create-image \\
+ --dhcp --mac=$L2_MAC \\
+ --size=${disk_mb}Mb --memory=${ram_mb}Mb --swap=${swap_mb}Mb \\
+ --mirror=http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
+ --hostname $guesthost \\
+ --dir=/testnested \\
+ --kernel=$kernpath \\
+ --genpass 0 --password xenroot \\
+ $initrd_opt \\
+ $gsuite \\
+ $archarg
+END
+ } else {
+ target_cmd_root($ho, <<END, 2000);
+ xen-create-image \\
+ --dhcp --mac $gho->{Ether} \\
+ --memory ${ram_mb}Mb --swap ${swap_mb}Mb \\
+ --dist $gsuite \\
+ --mirror http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
+ --hostname $gho->{Name} \\
+ --lvm $gho->{Vg} --force \\
+ --kernel $kernpath \\
+ --genpass 0 --password xenroot \\
+ $initrd_opt \\
+ $archarg
END
- my $cfg_xend= "/etc/xen/$gho->{Name}.cfg";
- store_runvar("$gho->{Guest}_cfgpath", $cfg_xend);
- store_runvar("$gho->{Guest}_swap_lv", "$gho->{Name}-swap");
+ my $cfg_xend= "/etc/xen/$gho->{Name}.cfg";
+ store_runvar("$gho->{Guest}_cfgpath", $cfg_xend);
+ store_runvar("$gho->{Guest}_swap_lv", "$gho->{Name}-swap");
+ }
+}
+
+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");
+}
+
+sub get_VM_IP {
+ my $IP;
+ my $leases;
+ my $dhcpf = $c{HostProp_DhcpWatchMethod};
+ my @meth = split /\s+/, $dhcpf;
+ if ($dhcpf =~ m,/,) {
+ $leases= new IO::File $meth[2], 'r';
+ if (!defined $leases) { return "open $meth[2]: $!"; }
+ } else {
+ $leases= new IO::Socket::INET(PeerAddr => $meth[2]);
+ }
+ while (<$leases>) {
+ my @lines = <$leases>;
+ my @newlines = reverse(@lines);
+ for(my $i=0;$i<@newlines;$i++) {
+ next if($newlines[$i] !~ /$_[0]/);
+ for($i;$i<@newlines;$i++) {
+ next if ($newlines[$i] !~ /^lease\s+(\d+\.\d+\.\d+\.\d+)\s*/);
+ $IP = $1;
+ return $IP;
+ }
+ last;
+ }
+ }
+}
+
+sub check_VM_up {
+ my ($g_ip) = @_;
+ my $ping_out = `ping -c 5 $g_ip 2>&1`;
+ if($ping_out =~ m/5 received/) {
+ logm("$guesthost is up and ping is OK!");
+ } else {
+ logm("Failed to boot up $guesthost");
+ }
+}
+
+sub stop_guest {
+ logm("shutdown L2 guest!");
+ target_cmd_root($ho,toolstack()->{Command}." shutdown -w ".$guesthost,100);
}
prep();
ginstall();
+if($nested_L2 eq 'nested_L2') {
+ start();
+ logm("waiting for 15's to boot up L2 guest!");
+ sleep(15);
+ my $L2_IP = get_VM_IP("$L2_MAC");
+ logm("L2 guest's IP is $L2_IP and try to ping it!");
+ check_VM_up($L2_IP);
+ stop_guest();
+}
--
1.7.10.4
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2014-12-10 8:07 ` [OSSTEST PATCH 3/4] Add nested testcase of installing L2 " longtao.pang
@ 2014-12-11 11:43 ` Wei Liu
2015-01-06 3:28 ` Pang, LongtaoX
0 siblings, 1 reply; 32+ messages in thread
From: Wei Liu @ 2014-12-11 11:43 UTC (permalink / raw)
To: longtao.pang
Cc: wei.liu2, Ian.Campbell, Ian.Jackson, xen-devel, robert.hu,
di.zheng
On Wed, Dec 10, 2014 at 04:07:39PM +0800, longtao.pang wrote:
> From: "longtao.pang" <longtaox.pang@intel.com>
>
> 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.
> }
>
> 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= 10000;
> -
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) {
> + $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
> + $kernver ||= target_cmd_output($ho, 'uname -r');
> + $kernpath = "/boot/vmlinuz-$kernver";
> + $initrd ||= "/boot/initrd.img-$kernver";
> + }
> + }
To be honest, this looks convoluted. Special casing needs better
explanation.
> my $archarg= defined($arch) ? "--arch $arch" : '';
> - my $gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
> -
> - my $kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
> - my $initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
> - if (!$kernpath) {
> - my $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
> - $kernver ||= target_cmd_output($ho, 'uname -r');
> - $kernpath = "/boot/vmlinuz-$kernver";
> - $initrd ||= "/boot/initrd.img-$kernver";
> - }
> if (!$initrd) {
> $initrd = $kernpath;
> $initrd =~ s,/vmlinuz-,/initrd.img-, or die "$initrd ?";
> @@ -76,23 +96,97 @@ sub ginstall () {
> fi
> END
> }
> - target_cmd_root($ho, <<END, 2000);
> - xen-create-image \\
> - --dhcp --mac $gho->{Ether} \\
> - --memory ${ram_mb}Mb --swap ${swap_mb}Mb \\
> - --dist $gsuite \\
> - --mirror http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
> - --hostname $gho->{Name} \\
> - --lvm $gho->{Vg} --force \\
> - --kernel $kernpath \\
> - --genpass 0 --password xenroot \\
> - $initrd_opt \\
> - $archarg
> + if($nested_L2 eq 'nested_L2') {
> + target_cmd_root($ho, <<END, 2000);
> + xen-create-image \\
> + --dhcp --mac=$L2_MAC \\
> + --size=${disk_mb}Mb --memory=${ram_mb}Mb --swap=${swap_mb}Mb \\
> + --mirror=http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
> + --hostname $guesthost \\
> + --dir=/testnested \\
> + --kernel=$kernpath \\
> + --genpass 0 --password xenroot \\
> + $initrd_opt \\
> + $gsuite \\
> + $archarg
> +END
> + } else {
> + target_cmd_root($ho, <<END, 2000);
> + xen-create-image \\
> + --dhcp --mac $gho->{Ether} \\
> + --memory ${ram_mb}Mb --swap ${swap_mb}Mb \\
> + --dist $gsuite \\
> + --mirror http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
> + --hostname $gho->{Name} \\
> + --lvm $gho->{Vg} --force \\
> + --kernel $kernpath \\
> + --genpass 0 --password xenroot \\
> + $initrd_opt \\
> + $archarg
As far as I can tell, the only difference is a few variables.
You can set up variables in
if ($nested_L2) {
var = foo;
} else {
var = bar;
}
target_cmd_root($ho, var ... );
Just like you did in previous hunk. Please add in some comments where
necessary.
> END
> - my $cfg_xend= "/etc/xen/$gho->{Name}.cfg";
> - store_runvar("$gho->{Guest}_cfgpath", $cfg_xend);
> - store_runvar("$gho->{Guest}_swap_lv", "$gho->{Name}-swap");
> + my $cfg_xend= "/etc/xen/$gho->{Name}.cfg";
> + store_runvar("$gho->{Guest}_cfgpath", $cfg_xend);
> + store_runvar("$gho->{Guest}_swap_lv", "$gho->{Name}-swap");
> + }
> +}
> +
> +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).
> +
> +sub get_VM_IP {
> + my $IP;
> + my $leases;
> + my $dhcpf = $c{HostProp_DhcpWatchMethod};
> + my @meth = split /\s+/, $dhcpf;
> + if ($dhcpf =~ m,/,) {
> + $leases= new IO::File $meth[2], 'r';
> + if (!defined $leases) { return "open $meth[2]: $!"; }
> + } else {
> + $leases= new IO::Socket::INET(PeerAddr => $meth[2]);
> + }
> + while (<$leases>) {
> + my @lines = <$leases>;
> + my @newlines = reverse(@lines);
> + for(my $i=0;$i<@newlines;$i++) {
> + next if($newlines[$i] !~ /$_[0]/);
> + for($i;$i<@newlines;$i++) {
> + next if ($newlines[$i] !~ /^lease\s+(\d+\.\d+\.\d+\.\d+)\s*/);
> + $IP = $1;
> + return $IP;
> + }
> + last;
> + }
> + }
> +}
> +
> +sub check_VM_up {
> + my ($g_ip) = @_;
> + my $ping_out = `ping -c 5 $g_ip 2>&1`;
> + if($ping_out =~ m/5 received/) {
> + logm("$guesthost is up and ping is OK!");
> + } else {
> + logm("Failed to boot up $guesthost");
> + }
> +}
> +
target_ping_check_{up,down} may be suitable?
Wei.
> +sub stop_guest {
> + logm("shutdown L2 guest!");
> + target_cmd_root($ho,toolstack()->{Command}." shutdown -w ".$guesthost,100);
> }
>
> prep();
> ginstall();
> +if($nested_L2 eq 'nested_L2') {
> + start();
> + logm("waiting for 15's to boot up L2 guest!");
> + sleep(15);
> + my $L2_IP = get_VM_IP("$L2_MAC");
> + logm("L2 guest's IP is $L2_IP and try to ping it!");
> + check_VM_up($L2_IP);
> + stop_guest();
> +}
> --
> 1.7.10.4
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2014-12-11 11:43 ` Wei Liu
@ 2015-01-06 3:28 ` Pang, LongtaoX
2015-01-06 16:52 ` Wei Liu
2015-01-08 17:20 ` Dario Faggioli
0 siblings, 2 replies; 32+ messages in thread
From: Pang, LongtaoX @ 2015-01-06 3:28 UTC (permalink / raw)
To: Wei Liu
Cc: Hu, Robert, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
Zheng, Di, xen-devel@lists.xen.org
> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Thursday, December 11, 2014 7:44 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> Ian.Campbell@citrix.com; wei.liu2@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" <longtaox.pang@intel.com>
> >
> > 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= 10000;
> > -
>
> 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) {
> > + $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
> > + $kernver ||= target_cmd_output($ho, 'uname -r');
> > + $kernpath = "/boot/vmlinuz-$kernver";
> > + $initrd ||= "/boot/initrd.img-$kernver";
> > + }
> > + }
>
> To be honest, this looks convoluted. Special casing needs better explanation.
[Pang, LongtaoX] Thanks for checking, I will try to adjust it.
>
> > my $archarg= defined($arch) ? "--arch $arch" : '';
> > - my $gsuite= guest_var($gho,'suite',$c{GuestDebianSuite});
> > -
> > - my $kernpath = guest_var($gho,'kernel_path',$r{xen_kernel_path});
> > - my $initrd = guest_var($gho,'initrd_path',$r{xen_initrd_path});
> > - if (!$kernpath) {
> > - my $kernver= guest_var($gho,'kernel_ver',$r{xen_kernel_ver});
> > - $kernver ||= target_cmd_output($ho, 'uname -r');
> > - $kernpath = "/boot/vmlinuz-$kernver";
> > - $initrd ||= "/boot/initrd.img-$kernver";
> > - }
> > if (!$initrd) {
> > $initrd = $kernpath;
> > $initrd =~ s,/vmlinuz-,/initrd.img-, or die "$initrd ?"; @@ -76,23
> > +96,97 @@ sub ginstall () {
> > fi
> > END
> > }
> > - target_cmd_root($ho, <<END, 2000);
> > - xen-create-image \\
> > - --dhcp --mac $gho->{Ether} \\
> > - --memory ${ram_mb}Mb --swap ${swap_mb}Mb \\
> > - --dist $gsuite \\
> > - --mirror
> http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
> > - --hostname $gho->{Name} \\
> > - --lvm $gho->{Vg} --force \\
> > - --kernel $kernpath \\
> > - --genpass 0 --password xenroot \\
> > - $initrd_opt \\
> > - $archarg
> > + if($nested_L2 eq 'nested_L2') {
> > + target_cmd_root($ho, <<END, 2000);
> > + xen-create-image \\
> > + --dhcp --mac=$L2_MAC \\
> > + --size=${disk_mb}Mb --memory=${ram_mb}Mb
> --swap=${swap_mb}Mb \\
> > +
> --mirror=http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
> > + --hostname $guesthost \\
> > + --dir=/testnested \\
> > + --kernel=$kernpath \\
> > + --genpass 0 --password xenroot \\
> > + $initrd_opt \\
> > + $gsuite \\
> > + $archarg
> > +END
> > + } else {
> > + target_cmd_root($ho, <<END, 2000);
> > + xen-create-image \\
> > + --dhcp --mac $gho->{Ether} \\
> > + --memory ${ram_mb}Mb --swap ${swap_mb}Mb \\
> > + --dist $gsuite \\
> > + --mirror
> http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath} \\
> > + --hostname $gho->{Name} \\
> > + --lvm $gho->{Vg} --force \\
> > + --kernel $kernpath \\
> > + --genpass 0 --password xenroot \\
> > + $initrd_opt \\
> > + $archarg
>
> As far as I can tell, the only difference is a few variables.
>
> You can set up variables in
>
> if ($nested_L2) {
> var = foo;
> } else {
> var = bar;
> }
> target_cmd_root($ho, var ... );
>
> Just like you did in previous hunk. Please add in some comments where
> necessary.
[Pang, LongtaoX] Thanks for checking, I will try to modify this.
>
> > END
> > - my $cfg_xend= "/etc/xen/$gho->{Name}.cfg";
> > - store_runvar("$gho->{Guest}_cfgpath", $cfg_xend);
> > - store_runvar("$gho->{Guest}_swap_lv", "$gho->{Name}-swap");
> > + my $cfg_xend= "/etc/xen/$gho->{Name}.cfg";
> > + store_runvar("$gho->{Guest}_cfgpath", $cfg_xend);
> > + store_runvar("$gho->{Guest}_swap_lv", "$gho->{Name}-swap");
> > + }
> > +}
> > +
> > +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.
> > +
> > +sub get_VM_IP {
> > + my $IP;
> > + my $leases;
> > + my $dhcpf = $c{HostProp_DhcpWatchMethod};
> > + my @meth = split /\s+/, $dhcpf;
> > + if ($dhcpf =~ m,/,) {
> > + $leases= new IO::File $meth[2], 'r';
> > + if (!defined $leases) { return "open $meth[2]: $!"; }
> > + } else {
> > + $leases= new IO::Socket::INET(PeerAddr => $meth[2]);
> > + }
> > + while (<$leases>) {
> > + my @lines = <$leases>;
> > + my @newlines = reverse(@lines);
> > + for(my $i=0;$i<@newlines;$i++) {
> > + next if($newlines[$i] !~ /$_[0]/);
> > + for($i;$i<@newlines;$i++) {
> > + next if ($newlines[$i] !~
> /^lease\s+(\d+\.\d+\.\d+\.\d+)\s*/);
> > + $IP = $1;
> > + return $IP;
> > + }
> > + last;
> > + }
> > + }
> > +}
> > +
> > +sub check_VM_up {
> > + my ($g_ip) = @_;
> > + my $ping_out = `ping -c 5 $g_ip 2>&1`;
> > + if($ping_out =~ m/5 received/) {
> > + logm("$guesthost is up and ping is OK!");
> > + } else {
> > + logm("Failed to boot up $guesthost");
> > + }
> > +}
> > +
>
> target_ping_check_{up,down} may be suitable?
[Pang, LongtaoX] Thanks for checking, I will try to modify this.
>
>
> Wei.
>
>
> > +sub stop_guest {
> > + logm("shutdown L2 guest!");
> > + target_cmd_root($ho,toolstack()->{Command}." shutdown -w
> > +".$guesthost,100);
> > }
> >
> > prep();
> > ginstall();
> > +if($nested_L2 eq 'nested_L2') {
> > + start();
> > + logm("waiting for 15's to boot up L2 guest!");
> > + sleep(15);
> > + my $L2_IP = get_VM_IP("$L2_MAC");
> > + logm("L2 guest's IP is $L2_IP and try to ping it!");
> > + check_VM_up($L2_IP);
> > + stop_guest();
> > +}
> > --
> > 1.7.10.4
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2015-01-06 3:28 ` Pang, LongtaoX
@ 2015-01-06 16:52 ` Wei Liu
2015-01-07 3:52 ` Pang, LongtaoX
2015-01-08 7:34 ` Pang, LongtaoX
2015-01-08 17:20 ` Dario Faggioli
1 sibling, 2 replies; 32+ messages in thread
From: Wei Liu @ 2015-01-06 16:52 UTC (permalink / raw)
To: Pang, LongtaoX
Cc: Wei Liu, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
xen-devel@lists.xen.org, Hu, Robert, Zheng, Di
On Tue, Jan 06, 2015 at 03:28:43AM +0000, Pang, LongtaoX wrote:
>
>
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: Thursday, December 11, 2014 7:44 PM
> > To: Pang, LongtaoX
> > Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> > Ian.Campbell@citrix.com; wei.liu2@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" <longtaox.pang@intel.com>
> > >
> > > 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.
[...]
> > > +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.
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2015-01-06 16:52 ` Wei Liu
@ 2015-01-07 3:52 ` Pang, LongtaoX
2015-01-08 7:34 ` Pang, LongtaoX
1 sibling, 0 replies; 32+ messages in thread
From: Pang, LongtaoX @ 2015-01-07 3:52 UTC (permalink / raw)
To: Wei Liu
Cc: Hu, Robert, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
Zheng, Di, xen-devel@lists.xen.org
> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Wednesday, January 07, 2015 12:52 AM
> To: Pang, LongtaoX
> Cc: Wei Liu; xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> Ian.Campbell@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 +0000, Pang, LongtaoX wrote:
> >
> >
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: Thursday, December 11, 2014 7:44 PM
> > > To: Pang, LongtaoX
> > > Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> > > Ian.Campbell@citrix.com; wei.liu2@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" <longtaox.pang@intel.com>
> > > >
> > > > 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.
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2015-01-06 16:52 ` Wei Liu
2015-01-07 3:52 ` Pang, LongtaoX
@ 2015-01-08 7:34 ` Pang, LongtaoX
2015-01-08 10:48 ` Wei Liu
1 sibling, 1 reply; 32+ messages in thread
From: Pang, LongtaoX @ 2015-01-08 7:34 UTC (permalink / raw)
To: Wei Liu
Cc: Hu, Robert, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
Zheng, Di, xen-devel@lists.xen.org
> -----Original Message-----
> From: Pang, LongtaoX
> Sent: Wednesday, January 07, 2015 11:53 AM
> To: 'Wei Liu'
> Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> Ian.Campbell@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.liu2@citrix.com]
> > Sent: Wednesday, January 07, 2015 12:52 AM
> > To: Pang, LongtaoX
> > Cc: Wei Liu; xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> > Ian.Campbell@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 +0000, Pang, LongtaoX wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > > Sent: Thursday, December 11, 2014 7:44 PM
> > > > To: Pang, LongtaoX
> > > > Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> > > > Ian.Campbell@citrix.com; wei.liu2@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" <longtaox.pang@intel.com>
> > > > >
> > > > > 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.
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2015-01-08 7:34 ` Pang, LongtaoX
@ 2015-01-08 10:48 ` Wei Liu
2015-01-08 11:12 ` Ian Campbell
2015-01-08 11:22 ` Robert Hu
0 siblings, 2 replies; 32+ messages in thread
From: Wei Liu @ 2015-01-08 10:48 UTC (permalink / raw)
To: Pang, LongtaoX
Cc: Wei Liu, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
xen-devel@lists.xen.org, Hu, Robert, Zheng, Di
On Thu, Jan 08, 2015 at 07:34:39AM +0000, Pang, LongtaoX wrote:
[...]
> > > 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.
Some foreseeable variables I can think of are bios, disk size and ram
size, which can be easily grouped together. Though you may also need
things like checking whether L2 guest is up and reachable etc.
I'm not too convinced that you really need a new script. But OSSTest
maintainers may disagree with me. Please wait for them to reply before
implementing any change.
Wei.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2015-01-08 10:48 ` Wei Liu
@ 2015-01-08 11:12 ` Ian Campbell
2015-01-08 11:16 ` Ian Jackson
2015-01-08 11:22 ` Robert Hu
1 sibling, 1 reply; 32+ messages in thread
From: Ian Campbell @ 2015-01-08 11:12 UTC (permalink / raw)
To: Wei Liu
Cc: Hu, Robert, Pang, LongtaoX, Ian.Jackson@eu.citrix.com, Zheng, Di,
xen-devel@lists.xen.org
On Thu, 2015-01-08 at 10:48 +0000, Wei Liu wrote:
> On Thu, Jan 08, 2015 at 07:34:39AM +0000, Pang, LongtaoX wrote:
> [...]
> > > > 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.
FWIW I think it's probably worth testing both (after all an L1
hypervisor should be as functional as an L0 one). Although L2 HVM does
seem more important at first.
> > > [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 ,
Why would an L2 guest be any different from an L1 guest from the PoV of
the test harness? Are you working around limitations in the nested
virtualisation functionality?
Once the L1 hypervisor is up and running shouldn't we mostly be treating
it as if it were an L0 hypervisor for the purposes of testing its
functionality, up to and including the types of guest we test and their
parameters?
> > 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.
>
> Some foreseeable variables I can think of are bios, disk size and ram
> size, which can be easily grouped together. Though you may also need
> things like checking whether L2 guest is up and reachable etc.
>
> I'm not too convinced that you really need a new script.
Me neither, at least not from the information quoted in this mail (I
must confess I didn't backtrack up the thread).
> But OSSTest
> maintainers may disagree with me. Please wait for them to reply before
> implementing any change.
>
> Wei.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2015-01-08 11:12 ` Ian Campbell
@ 2015-01-08 11:16 ` Ian Jackson
0 siblings, 0 replies; 32+ messages in thread
From: Ian Jackson @ 2015-01-08 11:16 UTC (permalink / raw)
To: Ian Campbell
Cc: Hu, Robert, Pang, LongtaoX, Wei Liu, Zheng, Di,
xen-devel@lists.xen.org
Ian Campbell writes ("Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM"):
> Once the L1 hypervisor is up and running shouldn't we mostly be treating
> it as if it were an L0 hypervisor for the purposes of testing its
> functionality, up to and including the types of guest we test and their
> parameters?
Quite.
> On Thu, 2015-01-08 at 10:48 +0000, Wei Liu wrote:
> > I'm not too convinced that you really need a new script.
I don't think we should have a new script. If the existing script
isn't flexible enough it should be enhanced to have the relevant
capabilities, which can then be invoked with different command line
arguments or different runvars.
Thanks,
Ian.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2015-01-08 10:48 ` Wei Liu
2015-01-08 11:12 ` Ian Campbell
@ 2015-01-08 11:22 ` Robert Hu
2015-01-08 11:26 ` Ian Campbell
1 sibling, 1 reply; 32+ messages in thread
From: Robert Hu @ 2015-01-08 11:22 UTC (permalink / raw)
To: Wei Liu
Cc: Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
xen-devel@lists.xen.org, Hu, Robert, Pang, LongtaoX, Zheng, Di
On Thu, 2015-01-08 at 10:48 +0000, Wei Liu wrote:
> On Thu, Jan 08, 2015 at 07:34:39AM +0000, Pang, LongtaoX wrote:
> [...]
> > > > 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.
>
> Some foreseeable variables I can think of are bios, disk size and ram
> size, which can be easily grouped together. Though you may also need
> things like checking whether L2 guest is up and reachable etc.
ts-debian-hvm-install has already been reused/modified to accommodate
nested L1 installation. Adding L2 installation in will make it further
more complex; not good for read and maintenance.
And different from L1 installation, L2 installation will not need too
many packages, just a minimal installation is sufficient. If resued,
preseed configuration will also need to be branched from L1. This is
also for the sake of save time; L2 guest installation shall take more
time, as it's nested.
I would also propose to separate another ts- for L2 installation; don't
spoils ts-debian-hvm-install to be too complex.
>
> I'm not too convinced that you really need a new script. But OSSTest
> maintainers may disagree with me. Please wait for them to reply before
> implementing any change.
>
> Wei.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2015-01-08 11:22 ` Robert Hu
@ 2015-01-08 11:26 ` Ian Campbell
0 siblings, 0 replies; 32+ messages in thread
From: Ian Campbell @ 2015-01-08 11:26 UTC (permalink / raw)
To: robert.hu
Cc: Ian.Jackson@eu.citrix.com, Pang, LongtaoX, Wei Liu, Zheng, Di,
xen-devel@lists.xen.org
On Thu, 2015-01-08 at 19:22 +0800, Robert Hu wrote:
> On Thu, 2015-01-08 at 10:48 +0000, Wei Liu wrote:
> > On Thu, Jan 08, 2015 at 07:34:39AM +0000, Pang, LongtaoX wrote:
> > [...]
> > > > > 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.
> >
> > Some foreseeable variables I can think of are bios, disk size and ram
> > size, which can be easily grouped together. Though you may also need
> > things like checking whether L2 guest is up and reachable etc.
> ts-debian-hvm-install has already been reused/modified to accommodate
> nested L1 installation.
I think this might be where the complication has come from.
ts-debian-hvm-install (and ts-debian-install) should be about installing
a basic guest with parameters (disk, memory, vcpus) and the basic OS
install, not about tailoring that guest for a particular use. Any
tailoring should be done by a separate step.
Take the L0 case, where we have ts-host-install to install the machine
with a basic OS and then ts-xen-install or ts-xen-build-prep depending
on what it is to be used for.
The L1 hypervisor should be handled similarly, install a basic OS with
ts-debian-hvm-install and then tailor, ideally with a ts-xen-install
which is enhanced to work for both L0 and L1.
In effect after ts-debian-hvm-install we should be treat the resulting
VM as if it were a host which was installed with ts-host-install.
Given that ts-debian-hvm-install is now only about installing a basic
guest OS, it now remains suitable for use as the L2 guest installer as
well.
I suppose there might be some differences in the result of
ts-debian-hvm-install and ts-host-install, which we should resolve by
making the results more similar by modifying one or both to use more
common/helper code.
Ian.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2015-01-06 3:28 ` Pang, LongtaoX
2015-01-06 16:52 ` Wei Liu
@ 2015-01-08 17:20 ` Dario Faggioli
2015-01-08 17:25 ` Ian Campbell
2015-01-09 2:46 ` Pang, LongtaoX
1 sibling, 2 replies; 32+ messages in thread
From: Dario Faggioli @ 2015-01-08 17:20 UTC (permalink / raw)
To: Pang, LongtaoX
Cc: Wei Liu, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
xen-devel@lists.xen.org, Hu, Robert, Zheng, Di
[-- Attachment #1.1: Type: text/plain, Size: 798 bytes --]
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
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2015-01-08 17:20 ` Dario Faggioli
@ 2015-01-08 17:25 ` Ian Campbell
2015-01-09 2:46 ` Pang, LongtaoX
1 sibling, 0 replies; 32+ messages in thread
From: Ian Campbell @ 2015-01-08 17:25 UTC (permalink / raw)
To: Dario Faggioli
Cc: Wei Liu, Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org,
Hu, Robert, Pang, LongtaoX, Zheng, Di
On Thu, 2015-01-08 at 18:20 +0100, Dario Faggioli wrote:
> 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)?
Indeed, building inside the L1 guest seems like a waste of CPU time when
the bits are already built natively in the flights build-* jobs.
Even if it was desired for some reason then the right approach would be
to point ts-{xen,linux}-build{,-prep} at the L1 guest, not to duplicate
the functionality in ts-debian-hvm-install (see my earlier reply to
Robert regarding what ts-debian-hvm-install's scope should be).
Ian.
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
2015-01-08 17:20 ` Dario Faggioli
2015-01-08 17:25 ` Ian Campbell
@ 2015-01-09 2:46 ` Pang, LongtaoX
1 sibling, 0 replies; 32+ messages in thread
From: Pang, LongtaoX @ 2015-01-09 2:46 UTC (permalink / raw)
To: Dario Faggioli
Cc: Wei Liu, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
xen-devel@lists.xen.org, Hu, Robert, Zheng, Di
> -----Original Message-----
> From: Dario Faggioli [mailto:dario.faggioli@citrix.com]
> Sent: Friday, January 09, 2015 1:20 AM
> To: Pang, LongtaoX
> Cc: Wei Liu; Hu, Robert; Ian.Jackson@eu.citrix.com; Ian.Campbell@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.
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer,
> Citrix Systems R&D Ltd., Cambridge (UK)
^ permalink raw reply [flat|nested] 32+ messages in thread
* [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
2014-12-10 8:07 [OSSTEST PATCH 0/4] Introduction of the patches longtao.pang
` (2 preceding siblings ...)
2014-12-10 8:07 ` [OSSTEST PATCH 3/4] Add nested testcase of installing L2 " longtao.pang
@ 2014-12-10 8:07 ` longtao.pang
2014-12-11 11:46 ` Wei Liu
2014-12-11 10:38 ` [OSSTEST PATCH 0/4] Introduction of the patches Wei Liu
4 siblings, 1 reply; 32+ messages in thread
From: longtao.pang @ 2014-12-10 8:07 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, Ian.Campbell, Ian.Jackson, robert.hu, longtaox.pang,
di.zheng
From: "longtao.pang" <longtaox.pang@intel.com>
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 \
+ ${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
^ permalink raw reply related [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
2014-12-10 8:07 ` [OSSTEST PATCH 4/4] Insert nested test job name and runvars into longtao.pang
@ 2014-12-11 11:46 ` Wei Liu
2015-01-06 3:31 ` Pang, LongtaoX
2015-01-29 9:57 ` Hu, Robert
0 siblings, 2 replies; 32+ messages in thread
From: Wei Liu @ 2014-12-11 11:46 UTC (permalink / raw)
To: longtao.pang
Cc: wei.liu2, Ian.Campbell, Ian.Jackson, xen-devel, robert.hu,
di.zheng
On Wed, Dec 10, 2014 at 04:07:40PM +0800, longtao.pang wrote:
> From: "longtao.pang" <longtaox.pang@intel.com>
>
> 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.
> + ${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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
2014-12-11 11:46 ` Wei Liu
@ 2015-01-06 3:31 ` Pang, LongtaoX
2015-01-29 9:57 ` Hu, Robert
1 sibling, 0 replies; 32+ messages in thread
From: Pang, LongtaoX @ 2015-01-06 3:31 UTC (permalink / raw)
To: Wei Liu
Cc: Hu, Robert, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
Zheng, Di, xen-devel@lists.xen.org
> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Thursday, December 11, 2014 7:46 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> Ian.Campbell@citrix.com; wei.liu2@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" <longtaox.pang@intel.com>
> >
> > 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
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
2014-12-11 11:46 ` Wei Liu
2015-01-06 3:31 ` Pang, LongtaoX
@ 2015-01-29 9:57 ` Hu, Robert
2015-01-29 10:42 ` Wei Liu
1 sibling, 1 reply; 32+ messages in thread
From: Hu, Robert @ 2015-01-29 9:57 UTC (permalink / raw)
To: Wei Liu, Pang, LongtaoX
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, Zheng, Di,
xen-devel@lists.xen.org
> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: Thursday, December 11, 2014 7:46 PM
> To: Pang, LongtaoX
> Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com;
> Ian.Campbell@citrix.com; wei.liu2@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" <longtaox.pang@intel.com>
> >
> > This patch is used for inserting nested test job name and runvars into
> > standalone.db database after execute command './standalone-reset'.
> >
> > ---
> > make-flight | 19 +++++++++++++++++++
> > mfi-common | 8 ++++++++
> > 2 files changed, 27 insertions(+)
> >
> > diff --git a/make-flight b/make-flight
> > index 9963a46..fe64237 100755
> > --- a/make-flight
> > +++ b/make-flight
> > @@ -197,6 +197,24 @@ do_hvm_win7_x64_tests () {
> > all_hostflags=$most_hostflags,hvm
> > }
> >
> > +do_hvm_debian_nested_tests () {
> > + if [ $xenarch != amd64 ]; then
> > + return
> > + fi
> > + if [ $dom0arch != amd64 ]; then
> > + return
> > + fi
> > +
> > + job_create_test test-$xenarch$kern-$dom0arch-nested test-nested xl \
> > + $xenarch $dom0arch \
> > + nested_image=debian-7.6.0-amd64-DVD-1.iso \
> > + bios=seabios \
> > + kernbuildjob=build-amd64-hvm \
> > + kernkind=hvm \
> > + device_model_version=qemu-xen \
> > + all_hostflags=$most_hostflags,hvm
> > +}
> > +
> > do_hvm_debian_test_one () {
> > testname=$1
> > bios=$2
> > @@ -364,6 +382,7 @@ test_matrix_do_one () {
> >
> > fi
> >
> > + do_hvm_debian_nested_tests
> > do_passthrough_tests
> > }
> >
> > diff --git a/mfi-common b/mfi-common
> > index 5c4f5d5..b65f0b5 100644
> > --- a/mfi-common
> > +++ b/mfi-common
> > @@ -166,6 +166,14 @@ create_build_jobs () {
> > revision_qemu=$REVISION_QEMU
> \
> > revision_qemuu=$REVISION_QEMU_UPSTREAM
> > fi
> > + ./cs-job-create $flight build-$arch-hvm build-kern
> \
> > + arch=$arch kconfighow=xen-enable-xen-config
> \
> > + $RUNVARS $BUILD_RUNVARS $BUILD_LINUX_RUNVARS
> $arch_runvars \
> > + $suite_runvars
> \
> > + host_hostflags=$build_hostflags
> \
> > + revision_linux=v3.16
> \
> > +
> tree_linux=git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> \
>
> Please don't hard code tree and revision.
>
> You can specify tree and revision in you test configuration.
Can you help more on details regarding to 'test configuration'? Thanks.
>
> Wei.
>
> > + ${TREEVCS_LINUX:+treevcs_linux=}${TREEVCS_LINUX}
> >
> > ./cs-job-create $flight build-$arch-pvops build-kern
> \
> > arch=$arch kconfighow=xen-enable-xen-config
> \
> > --
> > 1.7.10.4
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
2015-01-29 9:57 ` Hu, Robert
@ 2015-01-29 10:42 ` Wei Liu
2015-01-29 10:52 ` Ian Campbell
0 siblings, 1 reply; 32+ messages in thread
From: Wei Liu @ 2015-01-29 10:42 UTC (permalink / raw)
To: Hu, Robert
Cc: Wei Liu, Ian.Campbell@citrix.com, Ian.Jackson@eu.citrix.com,
xen-devel@lists.xen.org, Pang, LongtaoX, Zheng, Di
On Thu, Jan 29, 2015 at 09:57:43AM +0000, Hu, Robert wrote:
[...]
> > > diff --git a/mfi-common b/mfi-common
> > > index 5c4f5d5..b65f0b5 100644
> > > --- a/mfi-common
> > > +++ b/mfi-common
> > > @@ -166,6 +166,14 @@ create_build_jobs () {
> > > revision_qemu=$REVISION_QEMU
> > \
> > > revision_qemuu=$REVISION_QEMU_UPSTREAM
> > > fi
> > > + ./cs-job-create $flight build-$arch-hvm build-kern
> > \
> > > + arch=$arch kconfighow=xen-enable-xen-config
> > \
> > > + $RUNVARS $BUILD_RUNVARS $BUILD_LINUX_RUNVARS
> > $arch_runvars \
> > > + $suite_runvars
> > \
> > > + host_hostflags=$build_hostflags
> > \
> > > + revision_linux=v3.16
> > \
> > > +
> > tree_linux=git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > \
> >
> > Please don't hard code tree and revision.
> >
> > You can specify tree and revision in you test configuration.
> Can you help more on details regarding to 'test configuration'? Thanks.
If you look at other tree_linux= in mfi-common, you can see they are
assigned to $TREE_LINUX, which is in fact just a shell variable. There
are also other variables that you might be interested in, say
revision_linux.
If you're using standalone mode, you can specify those variables in
.standalone.config then ./standalone-reset. Those trees will then be
imported to standalone.db (which is a sqlite3 db) and used during the
test.
If you're using production mode, I think there is another way to
configure that. I've never setup production mode myself so I cannot say
for sure.
Wei.
> >
> > Wei.
> >
> > > + ${TREEVCS_LINUX:+treevcs_linux=}${TREEVCS_LINUX}
> > >
> > > ./cs-job-create $flight build-$arch-pvops build-kern
> > \
> > > arch=$arch kconfighow=xen-enable-xen-config
> > \
> > > --
> > > 1.7.10.4
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
2015-01-29 10:42 ` Wei Liu
@ 2015-01-29 10:52 ` Ian Campbell
2015-01-29 10:55 ` Ian Campbell
0 siblings, 1 reply; 32+ messages in thread
From: Ian Campbell @ 2015-01-29 10:52 UTC (permalink / raw)
To: Wei Liu
Cc: Hu, Robert, Pang, LongtaoX, Ian.Jackson@eu.citrix.com, Zheng, Di,
xen-devel@lists.xen.org
On Thu, 2015-01-29 at 10:42 +0000, Wei Liu wrote:
> On Thu, Jan 29, 2015 at 09:57:43AM +0000, Hu, Robert wrote:
> [...]
> > > > diff --git a/mfi-common b/mfi-common
> > > > index 5c4f5d5..b65f0b5 100644
> > > > --- a/mfi-common
> > > > +++ b/mfi-common
> > > > @@ -166,6 +166,14 @@ create_build_jobs () {
> > > > revision_qemu=$REVISION_QEMU
> > > \
> > > > revision_qemuu=$REVISION_QEMU_UPSTREAM
> > > > fi
> > > > + ./cs-job-create $flight build-$arch-hvm build-kern
> > > \
> > > > + arch=$arch kconfighow=xen-enable-xen-config
> > > \
> > > > + $RUNVARS $BUILD_RUNVARS $BUILD_LINUX_RUNVARS
> > > $arch_runvars \
> > > > + $suite_runvars
> > > \
> > > > + host_hostflags=$build_hostflags
> > > \
> > > > + revision_linux=v3.16
> > > \
> > > > +
> > > tree_linux=git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > > \
> > >
> > > Please don't hard code tree and revision.
> > >
> > > You can specify tree and revision in you test configuration.
> > Can you help more on details regarding to 'test configuration'? Thanks.
>
> If you look at other tree_linux= in mfi-common, you can see they are
> assigned to $TREE_LINUX, which is in fact just a shell variable. There
> are also other variables that you might be interested in, say
> revision_linux.
>
> If you're using standalone mode, you can specify those variables in
> .standalone.config then ./standalone-reset. Those trees will then be
> imported to standalone.db (which is a sqlite3 db) and used during the
> test.
>
> If you're using production mode, I think there is another way to
> configure that. I've never setup production mode myself so I cannot say
> for sure.
cr-daily-branch sets all this stuff up depending on the branch name and
they get put into the runvars by make-flight (or the mfi-common helper
library).
create_build_jobs already has a load of stuff using tree_linux, I'd
expect you could just copy it and use the same stuff as L0, unless there
is some reason for differing? In which case we need to have a
conversation about what each branch should be testing wrt the L1
hypervisor and dom0.
Ian.
^ permalink raw reply [flat|nested] 32+ messages in thread* Re: [OSSTEST PATCH 4/4] Insert nested test job name and runvars into
2015-01-29 10:52 ` Ian Campbell
@ 2015-01-29 10:55 ` Ian Campbell
0 siblings, 0 replies; 32+ messages in thread
From: Ian Campbell @ 2015-01-29 10:55 UTC (permalink / raw)
To: Wei Liu
Cc: Hu, Robert, Pang, LongtaoX, Ian.Jackson@eu.citrix.com, Zheng, Di,
xen-devel@lists.xen.org
On Thu, 2015-01-29 at 10:52 +0000, Ian Campbell wrote:
> On Thu, 2015-01-29 at 10:42 +0000, Wei Liu wrote:
> > On Thu, Jan 29, 2015 at 09:57:43AM +0000, Hu, Robert wrote:
> > [...]
> > > > > diff --git a/mfi-common b/mfi-common
> > > > > index 5c4f5d5..b65f0b5 100644
> > > > > --- a/mfi-common
> > > > > +++ b/mfi-common
> > > > > @@ -166,6 +166,14 @@ create_build_jobs () {
> > > > > revision_qemu=$REVISION_QEMU
> > > > \
> > > > > revision_qemuu=$REVISION_QEMU_UPSTREAM
> > > > > fi
> > > > > + ./cs-job-create $flight build-$arch-hvm build-kern
> > > > \
> > > > > + arch=$arch kconfighow=xen-enable-xen-config
> > > > \
> > > > > + $RUNVARS $BUILD_RUNVARS $BUILD_LINUX_RUNVARS
> > > > $arch_runvars \
> > > > > + $suite_runvars
> > > > \
> > > > > + host_hostflags=$build_hostflags
> > > > \
> > > > > + revision_linux=v3.16
> > > > \
> > > > > +
> > > > tree_linux=git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > > > \
> > > >
> > > > Please don't hard code tree and revision.
> > > >
> > > > You can specify tree and revision in you test configuration.
> > > Can you help more on details regarding to 'test configuration'? Thanks.
> >
> > If you look at other tree_linux= in mfi-common, you can see they are
> > assigned to $TREE_LINUX, which is in fact just a shell variable. There
> > are also other variables that you might be interested in, say
> > revision_linux.
> >
> > If you're using standalone mode, you can specify those variables in
> > .standalone.config then ./standalone-reset. Those trees will then be
> > imported to standalone.db (which is a sqlite3 db) and used during the
> > test.
> >
> > If you're using production mode, I think there is another way to
> > configure that. I've never setup production mode myself so I cannot say
> > for sure.
>
> cr-daily-branch sets all this stuff up depending on the branch name and
> they get put into the runvars by make-flight (or the mfi-common helper
> library).
>
> create_build_jobs already has a load of stuff using tree_linux, I'd
> expect you could just copy it and use the same stuff as L0, unless there
> is some reason for differing? In which case we need to have a
> conversation about what each branch should be testing wrt the L1
> hypervisor and dom0.
... although, did we not decide earlier that the nested test jobs should
reuse the output of the existing build-* jobs, rather than rebuilding?
Ian.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [OSSTEST PATCH 0/4] Introduction of the patches.
2014-12-10 8:07 [OSSTEST PATCH 0/4] Introduction of the patches longtao.pang
` (3 preceding siblings ...)
2014-12-10 8:07 ` [OSSTEST PATCH 4/4] Insert nested test job name and runvars into longtao.pang
@ 2014-12-11 10:38 ` Wei Liu
4 siblings, 0 replies; 32+ messages in thread
From: Wei Liu @ 2014-12-11 10:38 UTC (permalink / raw)
To: longtao.pang
Cc: wei.liu2, Ian.Campbell, Ian.Jackson, xen-devel, robert.hu,
di.zheng
Please use clear subject line in the future. Currently it's not very
descriptive. Something like "Introduction of netsted HVM test case" is
better.
Wei.
^ permalink raw reply [flat|nested] 32+ messages in thread