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: 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?
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.
> >
> > > > 2. Since reboot L1 guest VM will take more time to boot up, we
> > > > increase multi-times for reboot-confirm-booted if test nested job, and
> > > > the multi value is stored as a runvar in 'ts-nested-setup' script.
> > > > Added another function 'guest_editconfig_cd' and expose it, this
> > > > function bascically changes guest boot device sequence, alter its
> > > > on_reboot behavior to restart and enabled nestedhvm feature.
> > >
> > > This looks like two items run together?
> > >
> > > The multi_reboot_time thing sounds ok, but it should be called
> > > reboot_time_factor or something like that. In fact I see that Ian 
> > > suggested
> > > previously that it should have the host ident in it, that makes sense to 
> > > me.
> > >
> > I will try it. Also, how do you handle below question after reboot
> > host OS during running OSSTest job?
> > After finishing L0 and L1 host installation, the OSs will take a lot
> > time(about 150s) to start MTA service and NTP service. I know that,
> > the poll_loop timeout is 40s of 'reboot-confirm-booted',
> > that's why timeout happened when calling 'host_reboot' function after reboot
> host OS.
> 
> I'm afraid I don't know what you are asking here.
> 
> > > The editconfig_cd thing -- yet another thing which Ian questioned and 
> > > which
> it
> > > was agreed you would change but you haven't.
> > >
> > For this question, I have sent a mail about it.(2015-03-04)
> > After finishing L1 guest VM installation, we need to change L1 guest boot
> sequence from ISO image to hard disk,
> > we need modify the "boot=cd" ,
> 
> Do you? As Ian asked before, why is guest_editconfig_nocd  not
> sufficient? It removes the CD from the virtual drive, meaning that
> "boot=dc" will fail to boot from d and fallthru to c.
> 
> >  also need to enable 'nestedhvm' feature in hvm configure file,
> 
> This certainly doesn't belong in a function called guest_editconfig_cd,
> since it has nothing to do with cds at all.
> 
> 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?
> 
> Ian.

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