Re: [Xen-devel] OSSTest nested patch PART2 -- L2 installation failure [and 1 more messages]

["Hu, Robert" <robert.hu@xxxxxxxxx>]

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: Wednesday, October 28, 2015 7:53 PM
> To: Hu, Robert <robert.hu@xxxxxxxxx>
> Cc: 'Ian Campbell' <ian.campbell@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxx
> Subject: RE: OSSTest nested patch PART2 -- L2 installation failure [and 1 more
> messages]
> 
> Hu, Robert writes ("RE: OSSTest nested patch PART2 -- L2 installation
> failure"):
> > Now another issue: after attach lvm to L1, cannot see it inside.
> > vgdisplay shows nothing.
> >
> > My manual test like this:
> > xl block-attach 13 /dev/osstest-host2/test_l2,raw,sdc,rw
> >
> > xl block-list can see it, while inside L1 cannot.
> 
> Hu, Robert writes ("RE: OSSTest nested patch PART2 -- L2 installation
> failure"):
> > Tried:
> > After attach, in L1 cannot see the additional disk, if L1 is nested
> > Xen. After reboot, can see it.  If L1 is booted as normal guest, it
> > can see the additional disk at once, after attachment.
> 
> So your two tests are:
> 
>                                         case A         case B
> 
>    1.   boot L1                         nestedhvm=1
> nestedhvm=0
>         without additional disk
> 
>    2.   xl block-attach in L0
> 
>    3.   xl block-list in L0 shows it
> 
>    4.   ??? in L1 to look for disk      not visible    visible
> 
>    5.   reboot L1 with same nestedhvm
>         setting
> 
>    6.   ??? in L1 to look for disk      visible        visible
> 
> Is that right ?
[Hu, Robert] 

No. Both 2 cases with nestedhvm=1, just different boot entries I select:
one is boot directly from Dom0 kernel, the other from Xen.

> 
> I think this may be because the L1 booted with nestedhvm=1 gets its
> disks solely via the emulated IDE controller supplied by qemu in L0.
> And that IDE controller does not support hotplug.
> 
> (I don't quite understand why merely setting nestedhvm=1 stops the L1
> from finding its Xen platform PCI device and initialising itself as a
> Xen guest in a way that would prevent it also being a host.  I'm not
> sure this is relevant, though.)
> 
> Ian.

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