Re: [Xen-devel] [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs

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

> -----Original Message-----
> From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> Sent: Monday, March 23, 2015 5:50 PM
> To: Hu, Robert
> Cc: Pang, LongtaoX; xen-devel@xxxxxxxxxxxxx; Ian.Jackson@xxxxxxxxxxxxx;
> wei.liu2@xxxxxxxxxx
> Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport
> APIs
> 
> On Mon, 2015-03-23 at 06:31 +0000, Hu, Robert wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> > > Sent: Friday, March 20, 2015 8:20 PM
> > > To: Pang, LongtaoX
> > > Cc: xen-devel@xxxxxxxxxxxxx; Ian.Jackson@xxxxxxxxxxxxx;
> wei.liu2@xxxxxxxxxx;
> > > Hu, Robert
> > > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport
> > > APIs
> > >
> > > On Fri, 2015-03-20 at 12:09 +0000, Pang, LongtaoX wrote:
> > > > Add xen-devel in mail loop.
> > >
> > > Here is what I wrong in reply to the private version without noticing
> > > that it was private.
> > >
> > > On Fri, 2015-03-20 at 11:59 +0000, Pang, LongtaoX wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> > > > > Sent: Friday, March 20, 2015 12:27 AM
> > > > > To: Pang, LongtaoX
> > > > > Cc: xen-devel@xxxxxxxxxxxxx; Ian.Jackson@xxxxxxxxxxxxx;
> > > wei.liu2@xxxxxxxxxx;
> > > > > Hu, Robert
> > > > > Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some
> testsupport
> > > > > APIs
> > > > >
> > > > > On Tue, 2015-03-17 at 14:16 -0400, longtao.pang wrote:
> > > > > > From: "longtao.pang" <longtaox.pang@xxxxxxxxx>
> > > > > >
> > > > > > 1. Designate vif model to 'e1000', otherwise, with default device
> > > > > > model, the L1 eth0 interface disappear, hence xenbridge cannot work.
> > > > > > Maybe this limitation can be removed later after some fix it. For 
> > > > > > now,
> > > > > > we have to accomodate to it.
> > > > >
> > > > > You have done this unconditionally, which means it affects all guests.
> > > > > You need to make this configurable by the caller, probably by 
> > > > > plumbing it
> > > > > through in $xopts (a hash of extra options).
> > > > >
> > > > > I see now you were told this last time around by Ian J, please don't 
> > > > > just
> > > resend
> > > > > such things without change either fix them, make an argument for doing
> it
> > > your
> > > > > way or ask for clarification if you don't understand the requested
> change.
> > > > >
> > > >
> > > > Thanks for your advice, I will try it. But, do you have any idea about 
> > > > below
> > > issue that confused me?
> > > > After L1 Debian hvm guest boot into XEN kernel, it failed to load 8139cp
> > > driver(Realtek RTL-8139),
> > > > that cause L1 guest's network unavailable, and I have to specify
> > > 'model=e1000' to make L1's network available.
> > > > The issue does not exist in RHEL6u5 OS(L0 and L1 are both RHEL6u5 OS).
> > >
> > > Could just be a bug in Debian's kernel. Without more information it's
> > > rather hard to say.
> > >
> > Yes, it's hard to identify the root cause and we don't plan to dig out why 
> > here.
> > How about we move this designation to ts-nested-setup, after first step the
> normal
> > guest was created, we modify guest's configuration then?
> 
> Make it an option to the function which creates the configuration in the
> first place. Quoting myself from earlier in this very thread:
Then we still need to designate to use e1000 device somewhere; say, in
ts-nested-setup, we store this designation in runvar.
Then when creating the config, according to your proposal, we plumbing
such designation through $xopts, since we see it in runvar. Are you OK
with such implementation?
But if like above, I would prefer to altering/manipulating guest configation 
directly in ts-nested-setup after normal guest is setup. Since this is more
simple and constrained to nested case only.
> 
> > You have done this unconditionally, which means it affects all guests.
> > You need to make this configurable by the caller, probably by plumbing
> > it through in $xopts (a hash of extra options).
> 
> > The prerequisite here is to get configuration reloaded when guest 'reboot'.
> Do you
> > know any approach to achieve this? seems 'restart' action on reboot event
> > doesnât read new configuration.
> 
> Look at hos ts-debian-hvm-install does it, it uses OnReboot=preserve
> when calling more_prepareguest_hvm, then it waits for the guest to
> reboot (which ends up preserved), then it manually destroys it, rewrites
> the config and restarts the guest.
> 
> AFAICT this is exactly what you need.
Then we're going to substitute ts-host-reboot with guest destroy and create
guest. Are you OK with this?
> 
> > > Anyway, it's not clear why you need to edit this into the nestedhvm
> > > configuration, instead of adding it when the configuration is created
> > > via more_prepareguest_hvm. What harm is there in enabling this during
> > > guest install?
> > Seems no harm if when create a normal guest with 'nestedhvm' in its config.
> > So
> > 1. we have this option enabled in guest configure ever since.
> > 2. We add in this primitive after first step (normal guest setup),
> > in ts-nested-setup.
> >
> > Which would you prefer?
> 
> If there is no harm in it then I don't see why you wouldn't just do #1.
> 
> Ian.
> 

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