Special Publication 800-125
`
`Guide to Security for Full
`Virtualization Technologies
`
`Recommendations of the National Institute
`of Standards and Technology
`
`
`
`Karen Scarfone
`Murugiah Souppaya
`Paul Hoffman
`
`
`
`WIZ, Inc. EXHIBIT - 1018
`WIZ, Inc. v. Orca Security LTD.
`
`

`

`
`
`
`
`NIST Special Publication 800-125
`
`
`
`Guide to Security for Full Virtualization
`Technologies
`
`Recommendations of the National
`Institute of Standards and Technology
`
`Karen Scarfone
`Murugiah Souppaya
`Paul Hoffman
`
`
`
`
`C O M P U T E R S E C U R I T Y
`
`Computer Security Division
`Information Technology Laboratory
`National Institute of Standards and Technology
`Gaithersburg, MD 20899-8930
`
`January 2011
`
`
`
`
`
`
`
`U.S. Department of Commerce
`
`
`Gary Locke, Secretary
`
`National Institute of Standards and Technology
`
`Patrick D. Gallagher, Director
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
`
`Reports on Computer Systems Technology
`
`The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology
`(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s
`measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of
`concept implementations, and technical analysis to advance the development and productive use of
`information technology. ITL’s responsibilities include the development of technical, physical,
`administrative, and management standards and guidelines for the cost-effective security and privacy of
`sensitive unclassified information in Federal computer systems. This Special Publication 800-series
`reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative
`activities with industry, government, and academic organizations.
`
`
`
`
`National Institute of Standards and Technology Special Publication 800-125
`Natl. Inst. Stand. Technol. Spec. Publ. 800-125, 35 pages (January 2010)
`
`
`
`
`
`
`
`
`
`
`
`
`Certain commercial entities, equipment, or materials may be identified in this
`
`document in order to describe an experimental procedure or concept adequately.
`
`Such identification is not intended to imply recommendation or endorsement by the
`
`National Institute of Standards and Technology, nor is it intended to imply that the
`
`entities, materials, or equipment are necessarily the best available for the purpose.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` ii
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
`
`
`Acknowledgments
`
`The authors, Karen Scarfone of G2, Inc., Murugiah Souppaya of the National Institute of Standards and
`Technology (NIST), and Paul Hoffman of the VPN Consortium, wish to thank their colleagues who
`reviewed drafts of this document and contributed to its technical content. The authors gratefully
`acknowledge and appreciate the contributions from individuals and organizations whose comments
`improved the overall quality of this publication.
`
`
`
`All names are trademarks or registered trademarks of their respective owners.
`
`Trademark Information
`
`
`
`
`
` iii
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
`Table of Contents
`
`Executive Summary ............................................................................................................ ES-1
`
`1.
`
`2.
`
`Introduction ................................................................................................................... 1-1
`1.1 Authority .................................................................................................................1-1
`1.2 Purpose and Scope ................................................................................................1-1
`1.3 Audience ................................................................................................................1-1
`1.4 Document Structure ...............................................................................................1-1
`Introduction to Full Virtualization................................................................................. 2-1
`2.1 Motivations for Full Virtualization ............................................................................2-1
`2.2 Types of Full Virtualization .....................................................................................2-2
`2.3 Virtualizing Hardware .............................................................................................2-4
`2.3.1 Virtualized Networking................................................................................ 2-4
`2.3.2 Virtualized Storage ..................................................................................... 2-5
`2.3.3 Guest OS Images ....................................................................................... 2-6
`2.4 Full Virtualization Use Cases ..................................................................................2-6
`2.4.1 Server Virtualization ................................................................................... 2-6
`2.4.2 Desktop Virtualization ................................................................................ 2-8
`3. Virtualization Security Overview .................................................................................. 3-1
`3.1 Guest OS Isolation .................................................................................................3-1
`3.2 Guest OS Monitoring ..............................................................................................3-2
`3.3
`Image and Snapshot Management .........................................................................3-2
`4. Security Recommendations for Virtualization Components ...................................... 4-1
`4.1 Hypervisor Security ................................................................................................4-1
`4.2 Guest OS Security ..................................................................................................4-3
`4.3 Virtualized Infrastructure Security ...........................................................................4-4
`4.4 Desktop Virtualization Security ...............................................................................4-5
`5. Secure Virtualization Planning and Deployment ......................................................... 5-1
`5.1
`Initiation ..................................................................................................................5-2
`5.2 Planning and Design ..............................................................................................5-2
`5.3
`Implementation .......................................................................................................5-3
`5.4 Operations and Maintenance ..................................................................................5-4
`5.5 Disposition ..............................................................................................................5-5
`
`
`List of Appendices
`
`Appendix A— Glossary ........................................................................................................ A-1
`
`Appendix B— Acronyms and Abbreviations ...................................................................... B-1
`
`
`
`
` iv
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
`Executive Summary
`
`Virtualization is the simulation of the software and/or hardware upon which other software runs. This
`simulated environment is called a virtual machine (VM). There are many forms of virtualization,
`distinguished primarily by computing architecture layer. This publication focuses on the form of
`virtualization known as full virtualization. In full virtualization, one or more OSs and the applications
`they contain are run on top of virtual hardware. Each instance of an OS and its applications runs in a
`separate VM called a guest operating system. The guest OSs on a host are managed by the hypervisor.
`which controls the flow of instructions between the guest OSs and the physical hardware, such as CPU,
`disk storage, memory, and network interface cards. The hypervisor can partition the system’s resources
`and isolate the guest OSs so that each has access to only its own resources, as well as possible access to
`shared resources such as files on the host OS. Also, each guest OS can be completely encapsulated,
`making it portable. Some hypervisors run on top of another OS, which is known as the host operating
`system.
`
`The recent increase in the use of full virtualization products and services has been driven by many
`benefits. One of the most common reasons for adopting full virtualization is operational efficiency:
`organizations can use their existing hardware (and new hardware purchases) more efficiently by putting
`more load on each computer. In general, servers using full virtualization can use more of the computer’s
`processing and memory resources than servers running a single OS instance and a single set of services. A
`second common use of full virtualization is for desktop virtualization, where a single PC is running more
`than one OS instance. Desktop virtualization can provide support for applications that only run on a
`particular OS. It allows changes to be made to an OS and subsequently revert to the original if needed,
`such as to eliminate changes that negatively affect security. Desktop virtualization also supports better
`control of OSs to ensure that they meet the organization’s security requirements.
`
`Full virtualization has some negative security implications. Virtualization adds layers of technology,
`which can increase the security management burden by necessitating additional security controls. Also,
`combining many systems onto a single physical computer can cause a larger impact if a security
`compromise occurs. Further, some virtualization systems make it easy to share information between the
`systems; this convenience can turn out to be an attack vector if it is not carefully controlled. In some
`cases, virtualized environments are quite dynamic, which makes creating and maintaining the necessary
`security boundaries more complex.
`
`This publication discusses the security concerns associated with full virtualization technologies for server
`and desktop virtualization, and provides recommendations for addressing these concerns. Most existing
`recommended security practices remain applicable in virtual environments. The practices described in this
`document build on and assume the implementation of practices described in other NIST publications.
`
`To improve the security of server and desktop full virtualization technologies, organizations should
`implement the following recommendations:
`
`Secure all elements of a full virtualization solution and maintain their security.
`
`The security of a full virtualization solution is heavily dependent on the individual security of each of its
`components, from the hypervisor and host OS (if applicable) to guest OSs, applications, and storage.
`Organizations should secure all of these elements and maintain their security based on sound security
`practices, such as keeping software up-to-date with security patches, using secure configuration baselines,
`and using host-based firewalls, antivirus software, or other appropriate mechanisms to detect and stop
`attacks. In general, organizations should have the same security controls in place for virtualized operating
`systems as they have for the same operating systems running directly on hardware. The same is true for
`
`ES-1
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
`applications running on guest OSs: if the organization has a security policy for an application, it should
`apply the same regardless of whether the application is running on an OS within a hypervisor or on an OS
`running on hardware.
`
`Restrict and protect administrator access to the virtualization solution.
`
`The security of the entire virtual infrastructure relies on the security of the virtualization management
`system that controls the hypervisor and allows the operator to start guest OSs, create new guest OS
`images, and perform other administrative actions. Because of the security implications of these actions,
`access to the virtualization management system should be restricted to authorized administrators only.
`Some virtualization products offer multiple ways to manage hypervisors, so organizations should secure
`each management interface, whether locally or remotely accessible. For remote administration, the
`confidentiality of communications should be protected, such as through use of FIPS-approved
`cryptographic algorithms and modules.
`
`Ensure that the hypervisor is properly secured.
`
`Securing a hypervisor involves actions that are standard for any type of software, such as installing
`updates as they become available. Other recommended actions that are specific to hypervisors include
`disabling unused virtual hardware; disabling unneeded hypervisor services such as clipboard- or file-
`sharing; and considering using the hypervisor’s capabilities to monitor the security of each guest OS
`running within it, as well as the security of activity occurring between guest OSs. The hypervisor itself
`also needs to be carefully monitored for signs of compromise. It is also important to provide physical
`access controls for the hardware on which the hypervisor runs. For example, hosted hypervisors are
`typically controlled by management software that can be used by anyone with access to the keyboard and
`mouse. Even bare metal hypervisors require physical security: someone who can reboot the host computer
`that the hypervisor is running on might be able to alter some of the security settings for the hypervisor.
`
`Carefully plan the security for a full virtualization solution before installing, configuring, and
`deploying it.
`
`Planning helps ensure that the virtual environment is as secure as possible and in compliance with all
`relevant organizational policies. Security should be considered from the initial planning stage at the
`beginning of the systems development life cycle to maximize security and minimize costs. It is much
`more difficult and expensive to address security after deployment and implementation.
`
`
`
`
`
`
`
`ES-2
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
`1.
`
`Introduction
`
`1.1 Authority
`
`The National Institute of Standards and Technology (NIST) developed this document in furtherance of its
`statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002,
`Public Law 107-347.
`
`NIST is responsible for developing standards and guidelines, including minimum requirements, for
`providing adequate information security for all agency operations and assets; but such standards and
`guidelines shall not apply to national security systems. This guideline is consistent with the requirements
`of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency
`Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental
`information is provided in A-130, Appendix III.
`
`This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental
`organizations on a voluntary basis and is not subject to copyright, though attribution is desired.
`
`Nothing in this document should be taken to contradict standards and guidelines made mandatory and
`binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these
`guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,
`Director of the OMB, or any other Federal official.
`
`1.2 Purpose and Scope
`
`The purpose of the guide is to discuss the security concerns associated with full virtualization
`technologies for server and desktop virtualization, and to provide recommendations for addressing these
`concerns. All forms of virtualization other than server and desktop full virtualization are outside the scope
`of this document.
`
`Most existing recommended security practices remain applicable in virtual environments. The practices
`described in this document build on and assume the implementation of practices described in other NIST
`publications.
`
`1.3 Audience
`
`The intended audience for this document is system and security administrators, security program
`managers, information system security officers, and others who have responsibilities for or are otherwise
`interested in the security of server or desktop full virtualization technologies.
`
`This document assumes that readers have some operating system, networking, and security expertise.
`Because of the constantly changing nature of full virtualization technologies, readers are encouraged to
`take advantage of other resources (including those listed in this document) for more current and detailed
`information.
`
`1.4 Document Structure
`
`The remainder of this document is organized into the following major sections:
`
` Section 2 presents an introduction to full virtualization technologies and describes server and desktop
`full virtualization.
`
` 1-1
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
` Section 3 discusses the security characteristics of full virtualization technologies.
` Section 4 provides security recommendations for virtualization components.
` Section 5 highlights security considerations of particular interest throughout the lifecycle of full
`virtualization solutions.
`The document also contains appendices with supporting material:
`
` Appendix A defines terms used in this document.
` Appendix B contains a list of acronyms and abbreviations used in this document.
`
`
` 1-2
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
`2.
`
`Introduction to Full Virtualization
`
`Virtualization is the simulation of the software and/or hardware upon which other software runs. This
`simulated environment is called a virtual machine (VM). There are many forms of virtualization,
`distinguished primarily by computing architecture layer. For example, application virtualization provides
`a virtual implementation of the application programming interface (API) that a running application
`expects to use, allowing applications developed for one platform to run on another without modifying the
`application itself. The Java Virtual Machine (JVM) is an example of application virtualization; it acts as
`an intermediary between the Java application code and the operating system (OS). Another form of
`virtualization, known as operating system virtualization, provides a virtual implementation of the OS
`interface that can be used to run applications written for the same OS as the host, with each application in
`a separate VM container.
`
`Application virtualization and operating system virtualization are outside the scope of this publication.
`This publication focuses on the form of virtualization known as full virtualization. In full virtualization,
`one or more OSs and the applications they contain are run on top of virtual hardware. Each instance of an
`OS and its applications runs in a separate VM called a guest operating system. The guest OSs on a host
`are managed by the hypervisor, also called the virtual machine monitor (VMM), which controls the flow
`of instructions between the guest OSs and the physical hardware, such as CPU, disk storage, memory, and
`network interface cards. The hypervisor can partition the system’s resources and isolate the guest OSs so
`that each has access to only its own resources, as well as possible access to shared resources such as files
`on the host OS. Also, each guest OS can be completely encapsulated, making it portable. Some
`hypervisors run on top of another OS, which is known as the host operating system.
`
`In full virtualization the hypervisor provides most of the same hardware interfaces as those provided by
`the hardware’s physical platform. This means that the OSs and applications running within full
`virtualization do not need to be modified for virtualization to work if the OSs and applications are
`compatible with the underlying hardware. An interesting twist on full virtualization is paravirtualization,
`which is a method for the hypervisor to offer interfaces to the guest OS that the guest OS can use instead
`of the normal hardware interfaces. If a guest OS can use paravirtualized interfaces, they offer significantly
`faster access for resources such as hard drives and networks. Different types of paravirtualization are
`offered by different hypervisor systems.
`
`This section provides an overview of full virtualization as a foundation for the rest of the publication. It
`also explains the two common use cases for full virtualization: server virtualization and desktop
`virtualization.
`
`2.1 Motivations for Full Virtualization
`
`The recent increase in the use of full virtualization products and services has been driven by many
`benefits. One of the most common reasons for adopting full virtualization is operational efficiency:
`organizations can use their existing hardware (and new hardware purchases) more efficiently by putting
`more load on each computer. In general, servers using full virtualization can use more of the computer’s
`processing and memory resources than servers running a single OS instance and a single set of services.
`Recent advances in CPU architectures have made full virtualization faster than it was just a few years ago,
`and similar advances are expected to continue to be made both by CPU vendors and virtualization
`software vendors. Also, CPU architecture changes have made full virtualization more secure by
`strengthening hypervisor restrictions on resources.
`
`A second common use of full virtualization is for desktop virtualization, where a single PC is running
`more than one OS instance. There are several reasons for deploying desktop virtualization. It can provide
`
` 2-1
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
`support for applications that only run on a particular OS. It allows changes to be made to an OS and
`subsequently revert to the original if needed, such as to eliminate changes that negatively affect security.
`Desktop virtualization also supports better control of OSs to ensure that they meet the organization’s
`security requirements. This control can be asserted by creating a high-assurance platform that constantly
`updates the guest OS to have the exact versions of the programs that it is authorized to have, and no other
`programs.
`
`A more recent use of desktop virtualization is to enable the use of applications that only run on an older
`version of an OS when the user’s desktop is running a newer version. In such a situation, desktop
`virtualization is useful for continuity of applications as the OSs advance faster than the applications that
`run on them. As more applications become web-based, desktop virtualization can become even more
`important: a web application that only runs on an older version of a particular browser can be run in a
`virtualized system that has the older version of that browser, while the user’s main environment is
`running the newer (usually more secure) version of the browser. For use cases such as this, many
`organizations use application virtualization instead of desktop virtualization.
`
`Full virtualization has some negative security implications. Virtualization adds layers of technology,
`which can increase the security management burden by necessitating additional security controls. Also,
`combining many systems onto a single physical computer can cause a larger impact if a security
`compromise occurs. Further, some virtualization systems make it easy to share information between the
`systems; this convenience can turn out to be an attack vector if it is not carefully controlled. In some
`cases, virtualized environments are quite dynamic, which makes creating and maintaining the necessary
`security boundaries more complex.
`
`2.2 Types of Full Virtualization
`
`There are two forms of full virtualization. Figure 2-1 compares their high-level architectures. In bare
`metal virtualization, also known as native virtualization, the hypervisor runs directly on the underlying
`hardware, without a host OS; the hypervisor can even be built into the computer’s firmware. In the other
`form of full virtualization, known as hosted virtualization, the hypervisor runs on top of the host OS; the
`host OS can be almost any common operating system such as Windows, Linux, or MacOS. Hosted
`virtualization architectures usually also have an additional layer of software (the virtualization
`application) running in the guest OS that provides utilities to control the virtualization while in the guest
`OS, such as the ability to share files with the host OS. Hosted virtualization architectures also allow users
`to run applications such as web browsers and email clients alongside the hosted virtualization application,
`unlike bare metal architectures, which can only run applications within virtualized systems.
`
` 2-2
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
`
`
`Figure 2-1. Full Virtualization Architectures
`
`
`Servers are most often virtualized on computers using bare metal virtualization. Desktops are most often
`virtualized on computers with hosted virtualization. In both bare metal and hosted virtualization, each
`guest OS appears to have its own hardware, like a regular computer. This includes:
`
` CPU
` Memory
` Storage (hard disk, and possibly floppy and CD-ROM drives)
` Storage controllers
` Ethernet controllers
` Display and sound devices
` Keyboard and mouse
`Many virtualization environments offer additional virtual hardware, such as USB controllers, parallel
`ports for printing, and serial ports. Some hypervisors allow paravirtualization of some hardware
`interfaces, most commonly the storage controller and Ethernet controllers. Some hypervisors also provide
`direct memory access (DMA) to high-speed storage controllers and Ethernet controllers, if such features
`are supported in the hardware CPU on which the hypervisor is running. DMA access from guest OSs can
`significantly increase the speed of disk and network access, although this type of acceleration prevents
`some useful virtualization features such as snapshots and moving guest OSs while they are running.
`
`Deciding between bare metal and hosted virtualization—whether or not to have a host OS—is an
`important operational and security decision. Adding a hypervisor on top of a host OS adds more
`complexity and more vulnerabilities to the host. However, a hypervisor is much simpler and smaller than
`a host OS, so it provides a smaller target. Choosing bare metal virtualization by replacing a host OS with
`a hypervisor may improve security, depending on how well-secured the hypervisor is, while adding a
`hypervisor on top of a host OS tends to increase risk. Organizations should balance security and
`functionality when deciding whether or not a host OS should be used under a server or desktop
`
` 2-3
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
`virtualization solution. They should also take into account that bare metal hypervisors run on a much
`more limited range of hardware than hosted hypervisors; for example, bare metal hypervisors often work
`on only a limited number of Ethernet controllers and graphics cards.
`
`Hardware emulation (sometimes called hardware translation) is a type of hosted virtualization. The
`primary difference is that in hardware emulation, the hypervisor provides different hardware interfaces
`from those provided by the physical hardware. Because the hypervisor in hardware emulation can
`simulate all of the hardware required by the guest OS, it can run unmodified OSs designed for platforms
`different from the host platform. For example, early versions of VirtualPC allowed users to run the
`Microsoft Windows OS on the PowerPC processor supported by the Apple MacOS platform. Similarly,
`Apple supplies the Rosetta software with its Intel Mac OS X platform, allowing programs designed for
`the PowerPC version of Mac OS X to run on the Intel Mac platform.
`
`2.3 Virtualizing Hardware
`
`For full virtualization to be effective, the virtualized hardware presented to the guest OS must resemble
`physical hardware extremely closely. In addition, virtualization systems must offer additional features for
`the virtualized hardware to help it integrate well with the physical hardware in an organization’s network.
`This section discusses virtualized networking and storage, as well as how a guest OS is encapsulated.
`
`2.3.1 Virtualized Networking
`
`Full virtualization hypervisors can provide networking capabilities, allowing the individual guest OSs to
`communicate with one another while simultaneously limiting access to the external physical network. The
`network interfaces that the guest OSs see may be virtual, physical, or both. Typical hypervisors offer
`three primary forms of network access:
`
` Network Bridging. The guest OS is given direct access to the host’s network interface cards (NIC)
`independent of the host OS.
` Network Address Translation (NAT). The guest OS is given a virtual NIC that is connected to a
`simulated NAT inside the hypervisor. As in a traditional NAT, all outbound network traffic is sent
`through the virtual NIC to the host OS for forwarding, usually to a physical NIC on the host system.
` Host Only Networking. The guest OS is given a virtual NIC that does not directly route to a physical
`NIC. In this scenario, guest OSs can be configured to communicate with one another and, potentially,
`with the host OS.
`When a number of guest OSs exist on a single host, the hypervisor can provide a virtual network for these
`guest OSs. The hypervisor may implement virtual switches, hubs, and other network devices. Using a
`hypervisor’s networking for communications between guests on a single host has the advantage of greatly
`increased speed because the packets never hit physical networking devices. Internal host-only networking
`can be done in many ways by the hypervisor. In some systems, the internal network looks like a virtual
`switch. Others use virtual LAN (VLAN) standards to allow better control of how the guest systems are
`connected. Most hypervisors also provide internal network address and port translation (NAPT) that acts
`like a virtual router with NAT.
`
`Networks that are internal to a hypervisor’s networking structure can pose an operational disadvantage,
`however. Many networks rely on tools that watch traffic as it flows across routers and switches; these
`tools cannot view traffic as it moves in a hypervisor’s network. There are some hypervisors that allow
`network monitoring, but this capability is generally not as robust as the tools that many organizations
`have come to expect for significant monitoring of physical networks. Some hypervisors provide APIs that
`
` 2-4
`
`

`

`GUIDE TO SECURITY FOR FULL VIRTUALIZATION TECHNOLOGIES
`
`allow a privileged VM to have full visibility to the network traffic. Unfortunately, these APIs may also
`provide additional ways for attackers to attempt to monitor network communications. Another concern
`with network monitoring through a hypervisor is the potential for performance degradation or denial of
`service conditions to occur for the hypervisor because of high volumes of traffic.
`
`The security implications of networks internal to a hypervisor should not be minimized. For example,
`assume that an organization has two computers, one that acts as a public-facing web server and another
`that is an internal database server. The organization also monitors the switch that connects the two
`computers, watching for traffic that would indicate an attack on the database. If both of those servers were
`moved onto a single hypervisor, and the hypervisor’s virtual network was used for communications
`between the servers for increased efficiency, the ability to monitor all the traffic between the two systems
`would be lost unless the hypervisor itself can perform this monitoring that meets the organization’s
`security policies.
`
`To get around this loss of visibility, some organizations purposely expose network traffic between
`virtualized hosts to the physical network already in place in the organization. This requires the system on
`which the hypervisor is running to have multiple network interfaces, and this may significantly slow
`network communications as compared to a virtual-only network, but the advantage is that the
`organization does not need to change its s