Outline for Getting Started
This TOC should be changed -please indicate what needs changing in a different color or with an arrow. Please put your name in the line that has the change so we can track it. Thanks!
1. Document Conventions
1.1. Typographic Conventions 1.2. Pull-quote Conventions 1.3. Notes and Warnings
2. We Need Feedback!
1.1. Who should read this guide? 1.2. Virtualization in Fedora Linux --> grundblom: This should be a more general statement, no technical products mentioned here, but directed to chapter 3 for more information. 1.3. Virtualization resources
2. General Overview of Virtualization
2.1. What is Virtualization? 2.2. What are the costs of Virtualization 2.3. Performance factors of Virtualization 2.4. Flexibility options of Virtualization 2.5. Disaster Recovery options and scenarios of Virtualization 2.6. Security options and benefits of Virtualization 2.7. Differences and commonalities of Virtualization for servers and individuals
3. Introduction to Fedora virtualization products
3.1. KVM --> grundblom:Lets just call this KVM 3.2. libvirt and tools --> grundblom: Removed the "libvert tools" and shortened it 3.3. Boxes 3.4 Containers --> grundblom: I would like to mention something on how to use docker containers, or containers in general, but not a lot of detail here since there should be other guides, or more detailed resources eslewhere
4. Introduction to Boxes --> kirsti only a separate chapter for boxes, not for the other products? --> grundblom: I agree we should have sections for each product we mentioned in 4 I volunteer to write a section on how to make a vm in kvm.
4.1. Features of Boxes 4.2. How do I create a virtual machine in Boxes? 4.3. How do I connect to other computers in Boxes? 4.4. How do I change the settings of a machine in boxes? 4.5. How do I delete a box? 4.6. Boxes Tips and Tricks 4.7. Advanced Commands in Boxes
5. Creating and Managing Guests with Virt-Manager --> smccann work toward common topic titles w/ Boxer chapter - should be covering same information
5.1. System Requirements 5.2. Installing Virtualization package groups 5.3. Network Support 5.4. Creating guests with virt-manager
A. Advanced Virtualization Concepts --> kirsti would this be a place to make a pointer to containers?
A.1. Virtualized hardware devices
A.1.1. Virtualized and emulated devices A.1.2. Para-virtualized devices A.1.3. Physical host devices A.1.4. CPU models A 1.5. Storage --> grundblom: Took storage pools and added them here since its more of a definition/concept then in the detailed part of libvir</spam> A 1.5.1. Storage pools A 1.5.2. Storage volumes
A.2. guestfish A.3. Other useful tools --> kirsti is it an idea to add a few dos and do nots, as in what would make good use cases for virtualization, and what not?
B. Revision History
Changes to Content
Here you can list specific changes you would like to see made. In each instance please include some information that will help us find the location of the issue
|Chapter/Section||Link/URL||Change Needed||Who is requesting the Change||Approved||BZ Link|
|Ch 1||http://docs.fedoraproject.org/en-US/Fedora/22/html/Virtualization_Getting_Started_Guide/chap-Virtualization_Getting_Started-Introduction.html||"The Fedora Virtualization Getting Started Guide introduces the basics of virtualization and assists with the navigation of other virtualization documentation and products that Fedora provides. This guide also explains the advantages of virtualization and dispels some common myths that exist regarding virtualization." leave out the second part (going with leaving out the misconceptions). First sentence could read "The Fedora Virtualization Getting Started Guide introduces the basics, and advantages of virtualization; and assists with the navigation of other virtualization documentation, and products that Fedora provides." (adding Oxford comma).||Kirsti|
|ch2.1||http://docs.fedoraproject.org/en-US/Fedora/22/html/Virtualization_Getting_Started_Guide/chap-Virtualization_Getting_Started-What_Is_It.html||Missing link in the note to Fedora Virtualization Deployment and Administration Guide||Kirsti|
|ch2.2||http://docs.fedoraproject.org/en-US/Fedora/22/html/Virtualization_Getting_Started_Guide/sec-migration.html||under live migration is a reference to fedora 19."In Fedora 19, shared storage is not necessary for storing guest images to be migrated." Does this still apply to fed 22?||Kirsti|
|ch 3||http://docs.fedoraproject.org/en-US/Fedora/22/html/Virtualization_Getting_Started_Guide/chap-Virtualization_Getting_Started-Advantages.html||when we decide to go without the misconceptions, we need to rephrase the first two paragraphs, willing to make the attempt. The chapter as a whole, with all the explanations would make a poor business case, I would not be able to use it to convince a manager to go Virtual||Kirsti|
|ch3.3||http://docs.fedoraproject.org/en-US/Fedora/22/html/Virtualization_Getting_Started_Guide/ch03s03.html||This chapter takes it from a misconception point of view. Searching the web I cannot come up easily with a good description, but is there a place in the admin manual where this subject is better explained? Could we work with something like: "While virtualization can speed processing up, it doesn't just magically make things better. Without the right architecture and tuning, virtualization will not deliver performance benefits." and then add a link to how to implement virtualization?||Kirsti|
|ch3.4||http://docs.fedoraproject.org/en-US/Fedora/22/html/Virtualization_Getting_Started_Guide/ch03s04.html||Is this all we can say about flexibility? nothing about expanding or decreasing the number of machines in your network, easy test environment set-up without using up massive amounts of resources, easy to install when using images...||Kirsti|
Random thoughts and things I have been looking into. Is this going anywhere usefull? Still reading up on a lot of things...
Proposal CH2 what I have now (WIP):
2. General Overview of Virtualization 2.1. What is Virtualization? /* keeping it as is /* general suggestion: go for short clear titles (like it was before)
Virtualization is a broad computing term used for running software, usually multiple operating systems, concurrently and in isolation from other programs on a single system. Most existing implementations of virtualization use a hypervisor, a software layer or subsystem that controls hardware and provides guest operating systems with access to underlying hardware. The hypervisor allows multiple operating systems, called guests, to run on the same physical system by offering virtualized hardware to the guest operating system. There are several methods for virtualizing operating systems.
/*do we add an FAQ here? suggestions for questions? Virtualization methods
Full virtualization Full virtualization uses the hardware features of the processor to provide guests with total abstraction of the underlying physical system. This creates a new virtual system, called a virtual machine, that allows guest operating systems to run without modifications. The guest operating system and any applications on the guest virtual machine are unaware of their virtualized environment and run normally. Hardware-assisted virtualization is the technique used for full virtualization with KVM (Kernel-based Virtual Machine) in Fedora. Para-virtualization Para-virtualization employs a collection of software and data structures that are presented to the virtualized guest, requiring software modifications in the guest to use the para-virtualized environment. Para-virtualization can encompass the entire kernel, as is the case for Xen para-virtualized guests, or drivers that virtualize I/O devices. Software virtualization (or emulation) Software virtualization uses slower binary translation and other emulation techniques to run unmodified operating systems.
Note For more information and detailed instructions on guest installation, refer to the Fedora Virtualization Deployment and Administration Guide. /*add link when possible
2.2. Virtualization costs Before you consider to virtualize your environment it is important to perform a Return on Investment (ROI) analysis to determine the best use of virtualization in your environment. Consider the following benefits:
Smaller footprint Using virtualization negates much of the need for multiple physical platforms. Consolidating servers onto fewer machines means less physical space is required. This equates to less power being drawn for machine operation and cooling, resulting in reduced energy costs. This means more efficient energy resource management for your data centre.
Less maintenance Provided adequate planning is performed before migrating physical systems to virtualized ones, less time is spent maintaining them. This means less money being spent on various resources.
Extended life for installed software Older versions of software may not run on newer, bare metal machines directly. However, by running the older software virtually on a larger, faster system, the life of the software may be extended while taking advantage of the performance from the newer system.
2.3. Performance Modern servers are delivered with multiple CPU as a standard. This has significantly changed the possibilities with VMs. Depending on what you would like to use your VM for, and how many CPUs are available, you can now set up a VM with multiple CPUs. As discussed in the chapter about use cases for setting up a VM, all of these uses will have their own system requirements.
2.4. Flexibility Virtualization provides greater flexibility for managing systems. Virtual machines can be copied or moved to test software updates and validate configuration changes, without impacting other systems. Because each of the virtualized systems are completely separate to each other, one system's downtime will not affect any others. With separate virtualized systems you can use any hardware available, and install the OS needed for the function. There is no verndor lock-in.
Since less space is needed in a data centre to put up the production environment, it is easier to create extra space for development and testing environments. Both are easily set up and discarded. Having a more felixible environment, makes it easier to provide secure redundancy planning; and with easy access to a test machine, more stable systems can be built up.
With the fast changing market, a virtual configuration will provide a flexible, stable environment, with which a business can quickly adapt, to stay on top of the competition.
2.5. Disaster Recovery Disaster recovery has become part of the business plan. In case of IT, besides having a stable an efficient production environment, a place where this environment can be moved to is desired. To make sure the business loses as little time as possible to set up this shadow environment, virtualization might prove to be the best choice.
Even when the production environment is still on hardware, disaster recovery is quicker and easier when the systems are virtualized. On a physical system, if something serious goes wrong, a complete re-install of the operating system is usually required, resulting in hours of recovery time. However, when a clone or snapshot of the system is stored as a backup, this can be used a fast and reliable set-up of a virtual machine. A virtual machine is not depended on specific hardware, this makes any server suitable to recover your machines on.
In the case of using a clone, you will only have the set up of the machine available. The longest delay would then be in restoring guest data. When using a snapshot, the data as was when last made will be available immediately.
General thoughts on how users could read documentation. Realizing this might come close to the personas that are being defined.
- As an advisor or manager with no technical background, I would probably only read the chapter Virtualization 101. Because here I can find the basis for a business case, to which company specific calculations and graphs can be added.
(decision makers love graphs!)
- As a technical project manager I will go over all of the documentation, and might ask some specialists (about the security aspect for example)for further details. This is a good starting point to base a project plan on, in which a business case is included, but also the planning; what do we use it for? what is needed in hardware & software resources? what are the risks (and how do we solve this)? what does the architecture look like? how much time do I need? and how many people, with which skills? Looking at the guide as it is, I think all of that is covered.
- As a sysadmin I might start with the Chapter on How to install a Virtual machine. Now here we have some of the personas already defined.
Each would look for their own use-case; server, network, application, desktop. By adding a short list of these cases, with normal hardware spec, and possible links to where these cases are explained; and a short explanation of why only a simple set-up is explained in this chapter (I read this as a desktop setup, going with the choices for the use of one core and the amount of memory), this is a good stand alone chapter, very hands on.