[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [OSSTEST Nested PATCH v11 5/7] Add new script to customize nested test configuration
> -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx] > Sent: Wednesday, June 10, 2015 9:59 PM > To: Pang, LongtaoX > Cc: xen-devel@xxxxxxxxxxxxx; Ian.Campbell@xxxxxxxxxx; wei.liu2@xxxxxxxxxx; Hu, > Robert > Subject: Re: [OSSTEST Nested PATCH v11 5/7] Add new script to customize nested > test configuration > > longtao.pang writes ("[OSSTEST Nested PATCH v11 5/7] Add new script to > customize nested test configuration"): > > 1. In this script, make some appropriate runvars which selecthost would > > recognise. > > 2. Prepare the configurations for installing L2 guest VM. > > 3. Create a lv disk in L0 and hot-attach it to L1; Inside L1, using this > > new added disk to create a VG which will be used for installing L2 guest. > ... > > Thanks. This is roughly the right approach. I have some minor > comments. > > > > +target_cmd_root($l1, "update-rc.d osstest-confirm-booted start 99 2 ."); > > This is an open coded copy of the code from ts-host-install. It > should be broken out, I think. > I am sorry, could you please make it more clear? Thanks. > > > +target_install_packages_norec($l1, qw(lvm2 rsync genisoimage)); > > Do we need to install genisoimage here ? The guest install scripts do > it. Or are we just doing it here for efficiency reasons ? In fact, there is no need to install ' genisoimage' here. It's just for efficiency reason, since if install this package here, it will not be installed in 'ts-debian-hvm-install' script again. So, do you prefer to discard it or keep it here? I think there is no harmful to install this package here. > > > +# We need to attach an extra disk to the L1 guest to be used as L2 > > +# guest storage. > > +# > > +# When running in a nested HVM environment the L1 domain is acting > > +# as both a guest to L0 and a host to L2 guests and therefore potentially > > +# sees connections to two independent xenstore instances, one provided by > > +# the L0 host and one which is provided by the L1 instance of xenstore. > > +# > > +# Unfortunately the kernel is not capable of dealing with this and is only > > +# able to cope with a single xenstore connection. Since the L1 toolstack > > and > > +# L2 guests absolutely require xenstore to function we therefore cannot use > > +# the L0 xenstore and therefore cannot use PV devices (xvdX etc) in the L1 > > +# guest and must use emulated devices (sdX etc). > > +# > > +# However at the moment we have not yet rebooted L1 into Xen and so it does > > +# have PV devices available and sdb actually appears as xvdb. We could > > +# disable the Xen platform device and use emulated devices for the install > > +# phase too but that would be needlessly slow. > > + > > +my $vgname = $l1->{Vg}; > > +my $guest_storage_lv_name = "${l1_ident}_guest_storage"; > > +my $guest_storage_lv_size = guest_var($l1,'guest_storage_size',undef); > > +die "guest_storage_lv_size is undefined" unless $guest_storage_lv_size; > > +my $guest_storage_lvdev = "/dev/${vgname}/${guest_storage_lv_name}"; > > + > > +die "toolstack $r{toolstack}" unless $r{toolstack} eq "xl"; > > +target_cmd_root($l0, <<END); > > + lvremove -f $guest_storage_lvdev ||: > > + lvcreate -L ${guest_storage_lv_size}M -n $guest_storage_lv_name > $vgname > > + dd if=/dev/zero of=$guest_storage_lvdev count=10 > > + xl block-attach $l1->{Name} ${guest_storage_lvdev},raw,sdb,rw > > +END > > + > > +# Create a vg in L1 guest and vg name is ${l1_gn}-disk > > +target_cmd_root($l1, "pvcreate /dev/xvdb && vgcreate ${l1_gn}-disk > /dev/xvdb"); > > We would avoid having to mention /dev/xvdb if we created the VG in the > host, before doing block-attach. I'm not sure whether that's an > improvement. > I am sorry, I cannot get your point. Could you please make it more clear? Thanks. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |