Re: [Xen-devel] [OSSTEST PATCH 0/4] Introduction of the patches.
Please use clear subject line in the future. Currently it's not very descriptive. Something like Introduction of netsted HVM test case is better. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 0/4] Introduction of the patches.
We updated these patchs(version_3) again about adding Nested test job into OSSTest. Nested virtualization is the function of running a hypervisor inside a virtual machine. The hypervisor that runs on the real hardware is called a level 0 or L0; The hypervisor that runs as a guest inside L0 is called level 1 or L1; A guest that running inside the L1 hypervisor is called a level 2 or L2. For running nested test job, we should run build-amd64 job and build-amd64-hvm job first. During the testing, it will install L1 guest VM inside L0, the L1 guest should build xen and HVM Dom0 kernel and then boot into xen kernel. Next, begin to install L2 guest VM inside L1. After that, make sure ping L2 is successfully longtao.pang (4): Add nested testcase of preparing and installing L1 guest VM Build XEN and HVM Dom0 kernel for L1 guest VM Add nested testcase of installing L2 guest VM Insert nested test job name and runvars Osstest/Debian.pm | 27 +--- Osstest/TestSupport.pm | 31 +++-- make-flight| 19 ++ mfi-common |8 +++ sg-run-job |8 +++ ts-debian-hvm-install | 34 +++--- ts-debian-install | 166 +--- ts-xen-install | 149 +++ 8 files changed, 343 insertions(+), 99 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 0/4] Introduction of the patches.
On Mon, 2014-12-01 at 05:27 +, Hu, Robert wrote: But I'm not convinced that these patches take the right approach to achieving that. There seems to be a great deal of duplication of code. I think we should have a conversation about what moving parts are necessary for nested HVM testing. Agree with you we shall reuse existing ts-* if possible. Actually I had thought of this approach but later I defeated myself because I thought ts-* shall compromise itself as a whole test case and better not to touch them. Now I see that ts- is more like components to constitute a test case (my current understanding is your job == test cases). Have you seen the README at the top-level of osstest.git? It starts with a terminology section, which includes defining what a job is: a sequence of test steps, which could also be called a test case. The ts-* prefix stands for test step BTW. There is certainly scope for improving the docs though so please do ask if anything is unclear and we can improve the docs. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 0/4] Introduction of the patches.
-Original Message- From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] Sent: Friday, November 28, 2014 8:26 PM To: Pang, LongtaoX Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com; Hu, Robert; Zheng, Di Subject: Re: [OSSTEST PATCH 0/4] Introduction of the patches. longtao.pang writes ([OSSTEST PATCH 0/4] Introduction of the patches.): We updated these patchs about adding Nested test job into OSSTest. Thanks for your contribution. Having some testing of nested HVM would be good. Hi Ian, thanks for your support and glad getting your attention on this. We're new to osstest, and didn't find much documentation on its framework. So might violate some design and/or convention of it. We will modify as we get more conception of it. But I'm not convinced that these patches take the right approach to achieving that. There seems to be a great deal of duplication of code. I think we should have a conversation about what moving parts are necessary for nested HVM testing. Agree with you we shall reuse existing ts-* if possible. Actually I had thought of this approach but later I defeated myself because I thought ts-* shall compromise itself as a whole test case and better not to touch them. Now I see that ts- is more like components to constitute a test case (my current understanding is your job == test cases). If we had some documentation illustrating the your hierarchy of design, we should have less misunderstanding. I would guess that you could reuse ts-debian-hvm-install for the initial install of the L1 guest, and then ts-xen-install to install Xen on it. Finally, you could run some other ts-* scripts to install your L2 guests. I think you would probably find that there are only some small changes needed to make those existing scripts flexible enough. OK, we're going to do this, try to use ts-debian-hvm-install to fulfill the step of L1 dom0; use ts-xen-install to fulfil next step of constructing the normal guest to a L1 Xen environment. We will probably changes some of ts-debian-hvm-install and ts-xen-install to fulfill our test case. e.g., we may use some different configuration for L1, we will parameterize some configurations which now is hard-coded. And I don't understand why you need to rebuild anything. Surely the already-built hypervisor and tools ought to work just as well in the L1 guest ? We'll refine these parts to re-use existing things as much as possible. Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 0/4] Introduction of the patches.
longtao.pang writes ([OSSTEST PATCH 0/4] Introduction of the patches.): We updated these patchs about adding Nested test job into OSSTest. Thanks for your contribution. Having some testing of nested HVM would be good. But I'm not convinced that these patches take the right approach to achieving that. There seems to be a great deal of duplication of code. I think we should have a conversation about what moving parts are necessary for nested HVM testing. I would guess that you could reuse ts-debian-hvm-install for the initial install of the L1 guest, and then ts-xen-install to install Xen on it. Finally, you could run some other ts-* scripts to install your L2 guests. I think you would probably find that there are only some small changes needed to make those existing scripts flexible enough. And I don't understand why you need to rebuild anything. Surely the already-built hypervisor and tools ought to work just as well in the L1 guest ? Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 0/4] Introduction of the patches.
We updated these patchs about adding Nested test job into OSSTest. Nested virtualization is the function of running a hypervisor inside a virtual machine. The hypervisor that runs on the real hardware is called a level 0 or L0; The hypervisor that runs as a guest inside L0 is called level 1 or L1; A guest that running inside the L1 hypervisor is called a level 2 or L2. For running nested test job, we should run build-amd64 job and build-amd64-hvm job first. During the testing, it will install L1 guest VM inside L0, the L1 guest should build xen and HVM Dom0 kernel and then boot into xen kernel. Next, begin to install L2 guest VM inside L1. After that, make sure ping L2 is successfully root (4): Add nested testcase of preparing and installing L1 guest Building XEN and HVM Dom0 kernel for L1 guest VM Add nested test case of installing L2 guest VM Insert nested test job name and runvars into standalone database Osstest/Debian.pm | 25 ++- Osstest/TestSupport.pm| 31 +++- make-flight | 19 ++ mfi-common|8 + sg-run-job|8 + ts-debian-install | 166 + ts-nested-L1-debian-install-part1 | 202 ts-nested-L1-debian-install-part2 | 364 + 8 files changed, 773 insertions(+), 50 deletions(-) create mode 100755 ts-nested-L1-debian-install-part1 create mode 100755 ts-nested-L1-debian-install-part2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
