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

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

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> Sent: Wednesday, May 06, 2015 7:37 PM
> To: Pang, LongtaoX
> Cc: xen-devel@xxxxxxxxxxxxx; Ian.Jackson@xxxxxxxxxxxxx; wei.liu2@xxxxxxxxxx; 
> Hu,
> Robert
> Subject: Re: [OSSTEST Nested PATCH v9 7/9] Add new script to customize nested
> test configuration
> 
> On Sat, 2015-05-02 at 14:28 +0800, longtao.pang wrote:
> > +# Since Ian Campbell's v5_patch[04,05,06] has a bug that the
> > +# 'preseed/late_command' are unavailable, so add below line here to
> > +# make HTTP URL entry available in sources.list for L1 hvm guest.
> > +# Onece the bug is fiexed, this line code could be removed.
> > +target_cmd_root($l1, "sed -i 's/^deb *cdrom/#&/g' /etc/apt/sources.list");
> 
> This should be fixed in my v6 posting of that series.
> 
> > +target_cmd_root($l1, "update-rc.d osstest-confirm-booted start 99 2 .");
> > +
> > +# Inside L0, create storage lv, attach this lv to L1, and then inside L1 
> > using the
> storage for installing L2
> > +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);
> > +my $guest_storage_lvdev = "/dev/${vgname}/${guest_storage_lv_name}";
> 
> Perhaps:
>         die "guest_storage_lv_size" unless $guest_storage_lv_size;
> ?
> 
> > +
> > +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
> 
> I have some ideas/plans on how to refactor things so we can use
> prepareguest_part_lvmdisk for secondary disks too, but this is OK as it
> is for now IMHO.
> 
> > +    xl block-attach $l1->{Name} ${guest_storage_lvdev},raw,sdb,rw
> 
> This relies on/assumes the toolstack is xl (sorry for not spotting this
> before).
> 
> Really it should use a new block_attach method on toolstack($ho) (i.e.
> Osstest/Toolstack/*.pm) so it can work with libvirt etc.
> 
> However I think this hardcoding is tolerable for now (you've encoded
> that it is xl only in make-flight already), but please could you add
> near the top of this script:
> 
>         die "toolstack $r{toolstack}" unless $r{toolstack} eq "xl";
> 
> so it fails in an immediately obvious way if someone tries this with
> another toolstack.
> 
> Ian: Is that OK with you?
> 
> > +END
> > +# This is probably a bug here, if we use 'xvdx' as block 'dev'
> > +# after installing xen and boot into xen kernel, the disk will not be
> > +# recognized by OS. Also, if we use 'sde' instead of 'sdb' as block 'dev',
> > +# after installing xen and boot into xen kernel, the disk will be 
> > recognized
> > +# as 'sdb' not 'sde', so we will have to use 'sdb' here.
> > +
> > +target_install_packages_norec($l1, qw(lvm2 rsync genisoimage));
> 
> Please can you put this above, just after the osstest-confirm-started
> stuff so that it is not mixed in with the stuff dealing with the
> additional disk.
> 
> > +# After block-attach lvdev to L1, need to reboot L1 to make the attach
> > +# to take effect. I think this is a bug for kernel.
> 
> I've just tried this and it worked for me, i.e. /dev/xvdb appears
> immediately after xl block-attach with no reboot required. Perhaps this
> was an artefact of a bug in some previous iteration of the series?
> 
Thanks for trying, I tried it in my environment, a reboot is not required now.
I think this bug happened just because I have used ' 
Debian-7.6.0-amd64-DVD-1.iso ' as installing L1's guest OS before, 
it did required a reboot and I assumed it's as a kernel bug. 
According to you former comment, I change to use ' Debian-7.2.0-amd64-CD-1.iso' 
as installing L1's guest OS. 
I assumed that the bug still exist and keep to reboot L1 after block-attach 
'lvdev'. 
In fact, I should take a try for that, but I missed. Sorry for that.
So, the reboot action is no need now.

> I would replace this comment, and the "This is probably a bug here" and
> "Inside L0, create storage lv" ones above with a single (long) comment
> before all of this disk stuff which explains:
> 
>         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.
> 
> It's a bit long (to say the least) but I think it is worth explaining
> since limitation of nestedhvm isn't obvious without thinking about it a
> bit...
> 
> > +target_reboot($l1);
> > +# 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");
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel