From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Pang, LongtaoX" Subject: Re: [OSSTEST Nested PATCH 2/6] Add and expose some testsupport APIs Date: Fri, 20 Mar 2015 12:59:11 +0000 Message-ID: <86C3224E41A7434B904EC364302132D80E4785D9@SHSMSX101.ccr.corp.intel.com> References: <86C3224E41A7434B904EC364302132D80E478552@SHSMSX101.ccr.corp.intel.com> <1426854029.21742.169.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1426854029.21742.169.camel@citrix.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "wei.liu2@citrix.com" , "Hu, Robert" , "Ian.Jackson@eu.citrix.com" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org > -----Original Message----- > From: Ian Campbell [mailto:ian.campbell@citrix.com] > Sent: Friday, March 20, 2015 8:20 PM > To: Pang, LongtaoX > Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com; wei.liu2@citrix.com; > 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@citrix.com] > > > Sent: Friday, March 20, 2015 12:27 AM > > > To: Pang, LongtaoX > > > Cc: xen-devel@lists.xen.org; Ian.Jackson@eu.citrix.com; > > > wei.liu2@citrix.com; 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" > > > > > > > > 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. > > > > > > > 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. > When rebooting Debian L0 or Debian L1 guest, during booting, it will take a lot of time(about 150s) to starting MTA and NTP service, and then boot into Debian OS. But, only boot into OS completely, ' osstest-confirm-booted' shell script in '/etc/init.d' will start and generate 'reboot-confirm-booted' file at '/dev/shm' directory, only if the ' reboot-confirm-booted' file exist, then the function of 'host_reboot' is called successfully. As 'host_reboot' function in TestSupport.pm, the 'poll_loop' timeout is 40s, in my osstest env, after reboot L0 or L1 and then calling 'host_reboot' function, always cause the 'poll_loop' timeout and exit test. > > > 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? > I will try it. > Ian.