Transcript for:
Virtualization and Hypervisors

to be able to take advantage of virtualization you need something that is going to manage the process of keeping all of these different systems running this is the virtual machine manager often referred to as the hypervisor the hypervisor is the software that manages this entire interaction between the virtual world and the physical system it's running on hypervisors can run on almost any system but many modern hypervisors can take advantage of CPUs that have specifically been built with virtualization in mind and once this hypervisor is running it can allocate CPU cycles memory networking information and keep all of that separated between all of the different virtual machines to understand more about how all of these different operating systems interact with the hypervisor I've created this block diagram that starts at the very bottom with the hardware this is the physical system that the hypervisor is running on on top of that hardware is the hypervisor and above the hypervisor are all of the different virtual machines you'll notice that each virtual machine has its own guest operating system and applications running within that OS since each one of these virtual machines has its own guest operating system installed and running there is a significant amount of overhead that takes place every time you start a new VM this means you'll need enough CPU cycles enough memory enough drive space for all of these VMs to operate simultaneously on the same physical piece of hardware this type of hypervisor that sits right on top of the hardware is known as a type one hypervisor you might also hear this referred to as a bare metal hypervisor that's because there's no operating system down at the lowest level the hypervisor effectively is the primary operating system that is running on top of this hardware examples of a type one hypervisor would be VMware's ESXi or Microsoft's HyperV if you're running a hypervisor on your own desktop then you're running a type 2 hypervisor or a hosted hypervisor this means you would have the hardware that you're currently using for your computer you have the normal operating system that you're using you might be running Windows as the primary operating system on your computer i'm running Mac OS 10 on my computer and that operating system is where you would use all of your native applications on top of that operating system we would then run some hypervisor software on your system you might be running VMware Workstation Oracle Virtual Box or Parallels Desktop to be able to provide that hypervisor running on top of your current operating system at that point the type 1 hypervisor VMs and the type two hypervisor VMs are exactly the same the only difference is how you're running those VMs with type one it's running on bare metal and on type two it's running on a hosted operating system we mentioned earlier that some CPUs have been specifically constructed to work in a virtualized environment if you're running an Intel processor with this support they refer to this as virtualization technology or VT if you're running an AMD processor the same type of functionality is called AMDV the hypervisor is allocating memory to each of these virtual machines and it's using parts of your physical memory inside of your system so you have to make sure that you have enough RAM in your computer to be able to support all of these different virtual machines running simultaneously and of course each of those virtual machines contains a complete installed operating system the applications that run in that operating system and the data that you store in those applications that means you'll need enough drive space to be able to support a fully built operating system and all of the necessary applications in each one of those VMs and from the networking perspective you have complete control over how that virtual machine is able to interact with other devices in the outside world most of the hypervisors that you run on your local computer the clientside virtual machine managers have their own virtual networks that are configured internally to your system this means the hypervisor will be in control of determining whether that VM can only communicate to itself or if it can communicate outside of that VM to other devices some hypervisors will configure a shared network address this means that the hypervisor has its own IP subnet that's different than any other network that you're currently using and when devices on that network need to communicate out to the physical network it performs a network address translation to be able to communicate outside the scope of that hypervisor you can also configure a virtual machine to look and act as if it's any other device that's on your local network we refer to this as a bridge network address there's no network address translation and all of your virtual machines have the same IP subnet and act as if they are on your same local network and if this is a highly secure virtual machine that should not be communicating to any other devices you can configure your hypervisor with a private address so that virtual machine can only communicate with itself and any other devices that you decide security is always a concern when you're running so many different operating systems on one physical device fortunately there have not been any significant security breaches relating to hypervisors but this is something that hypervisor manufacturers and developers are always aware of one type of security vulnerability that is top of mind for these hypervisor developers is a VM escape this is when malware might find itself onto one virtual machine and use a flaw in the hypervisor to be able to communicate to other virtual machines that are supported by that same hypervisor this would obviously be a significant issue if someone was able to do this this would allow malware that would normally be isolated on one single virtual machine to be able to reach out and control or access data that might be on a different virtual machine this would obviously be a significant security concern and thankfully we've not seen any significant breaches that are related to a VM escape of course each of these virtual machines is its own self-contained operating system and we have to be sure that we configure the security for that virtual machine as if it was a standalone workstation or standalone server this means we would use traditional security controls on those devices we would configure a firewall we would install the appropriate anti-malware software and configure the operating system to be hardened just like any other OS one technique that some attackers like to use is to publish a virtual machine on the internet for anyone to be able to download and use but of course these malware authors are embedding their malware inside of that VM and when you start running that virtual machine on your own environment you're running an operating system that is already infected with the malware this is why it's always a good idea to build your own virtual machine so you know exactly what software is running in those devices and if you are downloading a virtual machine from the internet make sure that you are completely aware of the information that is contained on that VM and that you're taking the appropriate security mechanisms to keep that VM and all of your data safe well if we can run a separate operating system in a window on our desktop why can't we virtualize the entire desktop that is a technology known as virtual desktop infrastructure or VDI this means that your desktop would run as a virtual machine on a separate device commonly across the network or in the cloud and the only thing that you would really need on your desk is a keyboard a mouse and some type of display sometimes you may hear this referred to as desktop as a service or DAS this means you don't need a significant CPU a lot of memory or even a lot of storage on your local computer all of the work is done on the virtualized client that's running on that virtual system obviously we are sending information to update the screen that is running on our local device so we obviously need some type of network communication but these days we tend to have significant bandwidths available to us which allow us to run technologies such as virtual desktop infrastructure once you're running the virtual desktop it looks acts and interacts with you exactly like a normal OS from the user's perspective they're running an operating system that's running on their local device even though they're really running this OS as a virtualized system across the cloud we mentioned earlier that virtual machines need their own operating system installed on each individual VM and that adds some significant overhead to the entire virtualization process but what if you could remove that operating system component and only virtualize the applications that's the idea behind application containerization where you have separate containers that are built for every application that you'd like to run on that operating system just like a virtual machine each one of these apps is self-contained it has no idea that other application containers happen to be running on that same physical system and none of those containers are able to interact with each other unless you configure that in the containerization software and since there is no operating system the entire container image is much smaller than the traditional virtual machine this makes this very lightweight you're able to transfer them very quickly from one place to the other and they're very portable which means you can move them from one physical device to another without making any changes to the application container so here's a sidebyside view of a traditional virtualized application configuration and a containerized application configuration you can see in the virtualized applications that each one of the VMs has their own guest operating system but the containerized applications have a single host operating system this certainly simplifies the process of managing the operating system since there's only one OS that you'll need to patch update and maintain on top of the host operating system you would run containerization software one of the most popular is Docker and then on top of Docker you would have the individual Docker containerized applications one significant difference in containerized applications is they're relying on that host operating system which generally means that each one of these applications must be configured to run on that host OS you generally would not be able to run a Windows container a Linux container and a Mac OS container all on the same version of Docker of course if you were running VMs you could have different guest operating systems on each of those but of course your trade-off is the overhead that you have with a virtualized application