Re: [Xen-devel] [OSSTEST Nested PATCH v11 5/7] Add new script to customize nested test configuration

["Pang, LongtaoX" <longtaox.pang@xxxxxxxxx>]

> -----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