[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [OSSTest Nested v12 08/21] Add new script to customize nested test configuration

    1. In this script, make some appropriate runvars which selecthost would
    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.pang@xxxxxxxxx>
Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
Signed-off-by: Robert Ho <robert.hu@xxxxxxxxx>
 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
+# 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;
+# 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);
+# L1 guest's ident is same as guestname
+our $l1_ident = $l1->{Guest};
+# 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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.