1. In this script, make some appropriate runvars which selecthost would
recognise.
2. Prepare the configurations for installing L2 guest VM.
3. Create a lv disk (and create vg inside) in L0 and
hot-attach it to L1. The VG which will later be used for
installing L2 guest.
Changes since last version:
1. don't store l1 IP in runvar
2. create vg in the lv disk in l0; not bother to do this inside l1.
Signed-off-by: longtao.pang <longtaox.p...@intel.com>
Acked-by: Ian Campbell <ian.campb...@citrix.com>
Signed-off-by: Robert Ho <robert...@intel.com>
---
ts-nested-setup | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
create mode 100755 ts-nested-setup
diff --git a/ts-nested-setup b/ts-nested-setup
new file mode 100755
index 0000000..207ec85
--- /dev/null
+++ b/ts-nested-setup
@@ -0,0 +1,77 @@
+#!/usr/bin/perl -w
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2015 Intel Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+use strict qw(vars);
+use DBI;
+use Osstest;
+use Osstest::Debian;
+use Osstest::TestSupport;
+
+tsreadconfig();
+# Pass L0's ident and L1's guestname
+our ($l0_ident,$l1_gn) = @ARGV;
+our ($l0,$l1) = ts_get_host_guest($l0_ident,$l1_gn);
+
+guest_check_ip($l1);
+
+# L1 guest's ident is same as guestname
+our $l1_ident = $l1->{Guest};
+
+store_runvar($l1_ident,$l1->{Guest});
+
+host_install_postboot_complete($l1);
+
+# Just for efficiency reason to install genisoimage here
+target_install_packages_norec($l1, qw(lvm2 rsync genisoimage));
+
+# We need to attach an extra disk to the L1 guest to be used as L2
+# guest storage.
+#
+# When running in a nested HVM environment the L1 domain is acting
+# as both a guest to L0 and a host to L2 guests and therefore potentially
+# sees connections to two independent xenstore instances, one provided by
+# the L0 host and one which is provided by the L1 instance of xenstore.
+#
+# Unfortunately the kernel is not capable of dealing with this and is only
+# able to cope with a single xenstore connection. Since the L1 toolstack and
+# L2 guests absolutely require xenstore to function we therefore cannot use
+# the L0 xenstore and therefore cannot use PV devices (xvdX etc) in the L1
+# guest and must use emulated devices (sdX etc).
+#
+# However at the moment we have not yet rebooted L1 into Xen and so it does
+# have PV devices available and sdb actually appears as xvdb. We could
+# disable the Xen platform device and use emulated devices for the install
+# phase too but that would be needlessly slow.
+#
+# To avoid the confusion on xvdb and sdb, we here according to Ian J.'s
+# advice, create vg in l0.
+my $vgname = $l1->{Vg};
+my $guest_storage_lv_name = "${l1_ident}_guest_storage";
+my $guest_storage_lv_size = guest_var($l1,'guest_storage_size',undef);
+die "guest_storage_lv_size is undefined" unless $guest_storage_lv_size;
+my $guest_storage_lvdev = "/dev/${vgname}/${guest_storage_lv_name}";
+
+die "toolstack $r{toolstack}" unless $r{toolstack} eq "xl";
+target_cmd_root($l0, <<END);
+ vgremove -f ${l1_gn}-disk ||:
+ lvremove -f $guest_storage_lvdev ||:
+ lvcreate -L ${guest_storage_lv_size}M -n $guest_storage_lv_name $vgname
+ dd if=/dev/zero of=$guest_storage_lvdev count=10
+ pvcreate $guest_storage_lvdev
+ vgcreate ${l1_gn}-disk $guest_storage_lvdev
+ xl block-attach $l1->{Name} ${guest_storage_lvdev},raw,sdb,rw
+END
--
1.8.3.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
