Virtualization Education Environment

Transcription

1 Virtualization Education Environment Project Plan Project Team: 15 Client: Dr. Daniels Advisor: Dr. Daniels Tasewell Fox Robert Goetz Jacob Phillips Submitted 3/1/2011

2 Table of Contents A. Executive Summary I. System Requirements 1. Problem Statement 2. Conceptual System 2.a) Concept Sketch 2.a-1: Fully Virtualized 2.a-2: Virtual Lab Virtualization Only 2.b) System Block Diagram 3. Functional Requirements 3.a) System Access 3.b) Open Source Technology 3.c) Creation/Configuration 3.d) Benchmarking 3.e) Hardware/Software Requirements 4. Non-functional Requirements 4.a) Hardware Access 4.b) Compatibility 4.c) Performance and Reliability 4.d) Security 4.e) Virtual Machines 5. Operating Environment and Constraints 5.a) Operating Hardware/Software 5.b) Nested Virtualization II. Project Management 1. Work breakdown and statement of work 1.a) Virtualization Education Environment statement of work 2. Project Schedule (Gantt Chart) 3. Resource Requirements (Budget) 4. Potential Risks and Mitigation 4.a) Delay of development hardware 4.b) Opensource possibilities and abilities 4.c) CSG Hardware 4.d) Unacceptable Performance III. Conclusion 1. End-product description and deliverables 1.a) Virtual Lab Implementation 1.b) Labs 1.c) Benchmarking Suite

3 2. References 3. Project Team Contact Information 3.a) Project Leader: Tasewell Fox 3.b) Web Master: Robert Goetz 3.c) Communications Officer: Jacob Phillips

4 A. Executive Summary The product is a virtualization lab environment (VLE) with a laboratory procedure for testing various systems related to virtualization. This project is needed because there is currently no lab for Cpr E 342 and the class cannot be taught to students until this is remedied. The proposed solution is to develop a VLE that can coexist either beside or on top of the current lab setup for Cpr E 308/489. This virtual lab environment will provide a virtual lab space for students to work as well as give them root access, something they would not have available to them in normal lab situations. At its core this project is a system integration, content development and deployment problem. At the conclusion of this project, there will be a complete VLE, benchmarking suite and a set of lab procedures to execute for the cpre 342 labs. The VLE will be provided to the Computer Service Group(CSG) to consider implementing throughout the lab.

5 I. System Requirements 1. Problem Statement A virtualization class has been created, but it is missing a lab portion. A series of labs must be developed, based around the existing lab infrastructure using nested virtualization. The labs require students to edit and create their own virtual machines. Some level of security must be present so an incorrectly configured virtual machine does not crash the session.

6 2. Conceptual System 2.a) Concept Sketch 2.a-1: Fully Virtualized In this system the operating system on the lab machines would be replaced with a type one hypervisor. This would allow the current lab configuration (308/489) to be moved to a virtual machine alongside the new virtual lab (Virt Lab). Inside the virtual lab would be a type two hypervisor which would provide access to the level two virtual machines.

7 2.a-2: Virtual Lab Virtualization Only In this system a type two hypervisor is used inside the current lab configuration (308/489). This allows the virtual lab (Virt Lab) to be virtualized inside the 308/489 configuration without modification.

8 2.b) System Block Diagram

9 3. Functional Requirements 3.a) System Access For this project system access must be restricted. Students will only be allowed root access on the Virt Lab virtual machine. Students will not be allowed root access on either the type one hypervisor or the 308/489 system. 3.b) Open Source Technology The second level of virtualization must be open source technology. 3.c) Creation/Configuration Students can create and configure multiple level 2 virtual machines, inside of the Virt Lab virtual machine. 3.d) Benchmarking Students must be able to run multi-level benchmarks. The benchmarks should include programs and techniques for the following: CPU\Memory Performance CPU Arithmetic Memory Access, Latency, and Bandwidth Disk Performance Read/Write speeds Data throughput Network Performance Network Status (can it reach outside the virtual environment) Network Latency Network Bandwidth [OPTIONAL]: If time allows, a unified system will be put in place that allows the benchmarks to be run from a single executable. This executable will have a graphical user interface, support for batch processing, and systems to view the results of a benchmark run. 3.e) Hardware/Software Requirements The system must run on Red Hat Enterprise Linux. The system must run on a PC using the Intel x86_64 architecture.

10 4. Non-functional Requirements 4.a) Hardware Access Since this hardware is owned by Iowa State and used as the primary laboratory for the Cpr E 308 and 489 courses, we will not have physical access to the machines. Any changes to the system must be pre-approved by CSG. 4.b) Compatibility The system must be compatible with the current CprE 308 / CprE 489 lab setup. Compatibility in this case means that both systems can coexist without interfering with the operation of the other. 4.c) Performance and Reliability Since this is a machine that will be used for education it is paramount that the system is stable and performance is acceptable. Performance shall be judged based upon the base hardware s performance vs. the virtual environment by using predetermined benchmarks. The parameters for acceptable performance are: For a system running a single level 1 virtual machine, that level 1 virtual machine shall not perform any less then 50% worse then the base hardware. A system running a single level 1 virtual machine and a single level 2 virtual machine, that level 2 virtual machine shall not perform any less then 70% worse then the base hardware. Stability shall be judged by these parameters: The VLE shall add no instabilities to the Cpr E 308/489 systems. A student that properly follows all instructions shall be able to complete the entire lab course without the system failing. 4.d) Security The VLE shall add no major security flaws to the current lab system. This requirement will be determined by CSG. 4.e) Virtual Machines The system must allow multiple nested (virtual machines inside virtual machines) virtual machines.

11 5. Operating Environment and Constraints 5.a) Operating Hardware/Software The operating environment is Red Hat Enterprise Linux on Intel_x86_64 with virtualization. We intend to boot the stuents/lab in a virtual machine, and then let the students create and edit the VM from within this sandbox. 5.b) Nested Virtualization No open source VM's have out of the box support for it Cascading memory access Context switching 5.c) Constraints Everything must conform to the Computer Service Group s standards and system in order to be approved. All software should be open source. It must run on Intel x86_64

12 6. Security, Safety, Intellectual Property, and Technology Considerations 6.a) Security Considerations Giving student the ability to recompile a kernel introduces some major security holes, even if it is in a vm. Student may have root access on the vm, thus introducing a whole set of ways they can introduce instabilities. Students will have full network access, as in 489. So the network must be secure Various unforeseen security issues that probably exist. 6.b) Safety Our software runs no critical systems. If, in the worst case, the network were to be compromised nobody would be physically injured. 6.c) Intellectual Property All software will be open source. (xen on kvm, xen on vbox) So, the intellectual property depends on the liscence. GPL is viral, so the whole project has to be gpl if even one piece of software is, I think. That means that IP belongs to the software developers, and we only own the labs. The setup of kvm on xen or whatever shouldn t be our IP. 6.d) Technology Considerations Many technologies and approaches can be used to analyze the usability and feasibility of our design of the virtualization lab. Tools are available to asses the performance of a nested virtualization system, but these can only be used after an initial design has been implemented. Testing is thus an important consideration, as we have many designs in consideration. Some of our methods may be considered new or innovative. Nesting a virtual machine appears to be a relatively new idea, or at least preliminary research yields few results on the subject. VMWare has only recently put forth a release capable of newsted virtualization.

13 II. Project Management 1. Work breakdown and statement of work 1.a) Virtualization Education Environment statement of work Task 1 - Problem Definition, Project Goals Subtask 1.a) - Determine requirements Subtask 1.b) - Formulate initial research ideas Subtask 1.c) - Identify potential early risks Task 2 - Research / Technological Considerations Subtask 2.a) - Determine feasibility of Project given current technology Subtask 2.b) - Examine viability of existing technologies for nested virtualization Subtask 2.c) - Examine viability of existing technologies for benchmark suite Subtask 2.d) - Determine possible solutions Subtask 2.e) - Select software candidates Task 3 - Virtualized Lab Environment Design Subtask 3.a) - Choose implementation Subtask 3.b) - Design the Virtualization Lab Environment Subtask 3.c) - Implement nested virtualization prototype Subtask 3.d) - Implement Virtualization Lab Environment prototype Subtask 3.e) - Present Virtualization Lab Environment prototype to client, and CSG Task 4 - Benchmark Suite subtask 4.a) - Choose suitable benchmark utilities Subtask 4.b) - Bundle benchmark utilities into a single suite

14 Subtask 4.c) - Design benchmark suite graphical interface [optional] Task 5 - Lab Procedure Design Subtask 5.a) - Write lab procedures Subtask 5.b) - Go to client for lab verification Subtask 5.c) - Implement Lab Procedures Task 6 - Virtualization Testing Subtask 6.a) - Test initial virtualization software candidates Subtask 6.b) - Test nested virtualization prototype Subtask 6.c) - Test Virtualization Lab Environment prototype Subtask 6.d) - Test Lab procedures using Virtualized Lab Environment Task 7 - Project Reporting Subtask 7.a) - Project powerpoint presentation Subtask 7.b) - Project Plan Subtask 7.c) - Design Document Subtask 7.d) - Weekly Reporting

15 2. Project Schedule (Gantt Chart)

16 3. Resource Requirements (Budget) Item With Labor Without Labor Hardware 2 Test Machines $800 Subtotal $800 Labor at $20 / hour Fox, Tasewell $3000 Goetz, Robert $2960 Phillips, Jacob $2920 Subtotal $8880 Total $9680 $800

17 4. Potential Risks and Mitigation 4.a) Delay of development hardware There is a serious risk that we will have to wait quite some time for hardware to begin test implementation. This risk can be partially mitigated by doing what testing we can on machines without hardware virtualization and using Robert Goetz s laptop whenever possible because it supports hardware virtualization. 4.b) Opensource possibilities and abilities There are a plethora of opensource virtualization sofware available which can make choosing the correct combination a potential risk. This can be mitigated by researching each choice thoroughly before making any design decisions. There is also the potential risk that this project will be impossible to implement with opensource technology. The only mitigation to this is to test as much software as possible to find a successful combination. If no combination is found go to the client and revise requirements. 4.c) CSG Hardware The hardware that this will be deployed on is owned and administered by CSG. Any changes we hope to make to those systems must first be authorized by CSG administrators. The only way to avoid this risk is to establish early lines of communication with CSG admins so they can advise us on potential problems early in the development cycle. 4.d) Unacceptable Performance Even with a successful implementation performance may be to poor to use. There is very little we can do to mitigate this risk. Good choices of software and implementations can help though.

18 III. Conclusion 1. End-product description and deliverables 1.a) Virtual Lab Implementation An implementation of the virtual lab setup that satisfies all functional and nonfunctional requirements of the project. This virtual lab implementation will be working on one test machine and ready to be implemented lab wide pending approval. 1.b) Labs A set of lab procedures for students that demonstrate various principles of virtualization outlined by the Cpr E 342 curriculum. 1.c) Benchmarking Suite A suite of programs that provide methods to benchmark all of the requirements set down in the functional requirement found in Section I, 3.d. 2. References Project Team Contact Information 3.a) Project Leader: Tasewell Fox Phone: (515) tjfox@iastate.edu 3.b) Web Master: Robert Goetz Phone: (630) rdgoetz@iastate.edu 3.c) Communications Officer: Jacob Phillips

19 Phone: (319)