devopsy.kinsta.cloud

Tag: hypervisor

  • VMware Backup Guide for Hyper-V Admins

    VMware Backup Guide for Hyper-V Admins

    At first glance, the Hyper-V and VMware virtual environments may seem similar, but upon closer inspection, a number of important differences between these two virtualization platforms become apparent. Initially, performing administration for VMware vSphere could present some challenges for administrators who are familiar with Hyper-V. There are several reasons a business might be switching from Hyper-V to VMware. The company could be deploying a multi-hypervisor environment – e.g., using Hyper-V for Windows-based virtual machines (VMs) while introducing VMware vSphere for VMs running Linux, Free BSD, Solaris, etc. This blog post is intended to help Hyper-V administrators understand the differences and similarities between these two major virtualization platforms, making the transition to VMware easier.

    Comparing Hypervisor Design

    The Hyper-V Role for Servers and Workstations

    Hyper-V users can set up the Hyper-V role not only on the Windows Server operating system (OS) but also on desktop versions of Windows, such as Windows 7, 8 or 10. The installation is similar for both server and desktop solutions. Hyper-V is classified as a type 1 hypervisor, meaning that it is run directly on hardware. There is also a lighter-weight alternative to installing the Hyper-V role on Windows Server: Microsoft Hyper-V Server. Hyper-V Server is a standalone product that is installed on bare metal.

    VMware Workstation for Workstations and VMware ESXi for Servers

    VMware provides VMware Workstation for installation on desktops with Windows and Linux-based operating systems. VMware Workstation is a type 2 hypervisor. A type 2 hypervisor is installed on the underlying OS. As you can see, both Hyper-V and VMware support installation on users’ PCs. If you want to install a type 1 hypervisor on bare metal, you should use VMware ESXi Server. VMs running on VMware Workstation can be migrated to ESXi Server with the VMware vCenter Converter.

    Management Tools

    vCenter as the Analog to SCVMM

    System Center Virtual Machine Manager (SCVMM) is a special universal product created by Microsoft for centralized virtualization management of Hyper-V hosts, clusters, virtual networks and storage. SCVMM is useful for the management of complex multi-site and multi-domain environments.

    Hyper-V Manager is a common tool that is available by default upon installation of the Hyper-V role. With Hyper-V Manager, you can connect to an available Hyper-V host. You can manage the host, the VMs residing on that host, the virtual devices of those VMs and VM replication. You can also create VM checkpoints, start or stop VMs and connect to VMs in order to interact with the user interface of a guest VM.

    Failover Cluster Manager is a tool for managing failover clusters and VMs within a cluster. With this tool, you can create a failover cluster. Failover Cluster Manager is not a substitute for Hyper-V Manager; you still need the latter to manage non-clustered VMs, Hyper-V hosts, virtual switches, etc.

    The equivalent of SCVMM in VMware vSphere is vCenter Server, which can perform the tasks that Failover Cluster Manager and Hyper-V Manager handle in Hyper-V environments. With vCenter Server, you can manage almost all components of vSphere – hosts, clusters, virtual networks (including standard vSwitches and distributed vSwitches), datastores, VM virtual devices, etc. vCenter is installed on a virtual machine, and the vCenter web interface can then be accessed through a browser. You can use vSphere Web Client (which comes in HTML5-based or Flash-based versions) to access vCenter via a web browser. To do so, simply enter the IP address of your vCenter server in the address bar of your browser.

    If you have a standalone ESXi host, you can similarly access that host using a browser with the vSphere client. Enter the IP address of your ESXi server in the address bar of your browser. Note that you cannot create data centers, configure distributed virtual switches or perform VM migrations when accessing a standalone ESXi host with the vSphere client.

    Below, you can see vCenter v.6.5 accessed via browser with vSphere Web Client. If you want to access the VM’s user interface, click Launch Web Console.

    A new tab is opened and you can interact with the guest OS.

     Another way to access the user interface of a VM is using VMware Workstation. For connection to a VM running on the ESXi host from VMware Workstation, click File > Connect to Server.

    Input the IP address of vCenter or ESXi Server, as well as the user name and password required to access that server. Click Connect.

    In the left pane of the VMware Workstation interface, you can see a list of VMs residing on the ESXi host to which you are connected. If you connected to vCenter, you would see the objects such as Datacenters, ESXi hosts and VMs that are managed by vCenter Server.

    PowerShell Vs. PowerCLI

    With the Hyper-V platform, the alternative to using a GUI for management of the virtual environment is using PowerShell. PowerShell is command-line shell that is available on Windows-based systems, allowing users to manage system components. PowerShell provides automation using combinations of cmdlets and scripts.

    In VMware vSphere, you should use PowerCLI as the alternative to a GUI. PowerCLI is a scripting tool built on PowerShell. It extends PowerShell and includes a set of more than 600 cmdlets. You can automate installation and configuration of any features, virtual machines, system patching, etc.

    Clusters

    VMware HA and DRS Clusters Vs. Hyper-V Failover Cluster With PRO

    The Hyper-V virtual environment offers failover cluster functionality. A failover cluster provides automatic failover of VMs from failed hosts to healthy hosts within a cluster. Upon host failure, VMs from the failed host are restarted on other Hyper-V hosts in the cluster. The Performance and Resource Optimization (PRO) feature collects data about resource usage in the virtual environment and generates PRO tips, recommending migration or reconfiguration of VMs for more rational usage of hardware resources. Since Windows Server 2012, PRO was replaced with Dynamic Optimization.

    There are two types of clusters commonly used in VMware vSphere – High Availability (HA) clusters and Distributed Resource Scheduler (DRS) clusters. The HA cluster provides high availability of VMs and carries out automatic VM failover in case of host failure within a cluster. The VMs that were running on the failed ESXi host are restarted on healthy ESXi hosts. The DRS cluster is used for load balancing. vCenter server monitors the usage of hardware resources such as CPU and memory for VMs and ESXi hosts within a cluster. If, after calculations and analysis of these metrics, the DRS decides that some of VMs can migrate from one ESXi host to another (e.g., from an overloaded host to a host with free resources that is almost idle) for more rational resource usage, then migration recommendations are generated. These recommendations can be applied manually or automatically depending on your DRS configuration.

    Power Optimization Vs. Distributed Power Management

    Power Optimization is a feature of Dynamic Optimization in Hyper-V. Power Optimization allows the migration of VMs from Hyper-V hosts with low workloads to other hosts that have enough resources within a cluster. The unused hosts are then powered off in order to save energy. The powered-off hosts are powered back on as soon as their hardware resources are needed for the cluster.

    Distributed Power Management (DPM) is a component of the DRS cluster in the VMware vSphere virtual environment. Similarly to Dynamic Optimization, the DPM executes VM migration from less loaded ESXi hosts to ESXi hosts that have sufficient resources to run the migrated VMs. The freed-up ESXi hosts are powered off (put into a standby state) to save power. When load is increased and the cluster needs more hardware resources again, those ESXi hosts are powered back on.

    Fault Tolerance in VMware HA Clusters

    VMware also provides a useful feature for HA clusters: Fault tolerance. If you use an HA cluster, in the event of ESXi host failure, there is a period of VM downtime between the VM’s failure and the VM being loaded on another healthy host. Using the fault tolerance feature in the HA cluster helps avoid any downtime. This is because a second VM (ghost replica), which is an exact copy of the VM protected with fault tolerance, is already running on another ESXi host within the cluster. The ghost replica is in an inactive state (its network connections and output are disabled) until the primary VM fails. When the host on which the primary VM was running fails, the ghost replica becomes active in an instant, and the network connections of the replica become enabled. Switching to the ghost replica is smooth; you would only notice a slightly higher latency for one packet if you were to ping the IP address of the protected virtual machine. There is no data loss or service interruption if you are using fault tolerance.

    Migration

    Live Migration Vs. vMotion

    There are two types of VM migration for Hyper-V: Live migration and quick migration. Quick migration puts the VM into a saved state, which is similar to hibernation. The VM’s memory is saved to the disk where the other VM files are located. There is a small period of VM downtime once the VM is put into a saved state until it is registered on the new host. Live migration is used for VM migration between Hyper-V hosts (including failover clustering) without losing service availability. The migration procedure consists of different stages. The most important stage of live migration is the iterative transfer of VM memory pages.

    The analog of Hyper-V Live Migration in VMware vSphere is vMotion. With vMotion, running VMs can be migrated from one ESXi host to another without interrupting the VMs and services that are running on the hosts. When the VM migration process from a source ESXi host to a destination host is initiated, the following operations are performed.

    First, compatibility is checked to ensure that the VM can be run on the target host. Hardware resources are reserved on the target ESXi host and the VM process is started. A VM memory checkpoint is created; all further VM memory changes are written to a special area. The data stored in memory before creating a checkpoint is copied to the target VM. The source VM is running and some memory pages are changed (these pages are called dirty pages). They are written to change buffers, which are copied to the target VM and integrated into the memory of the target VM. The process of copying dirty pages is repeated over and over (an iterative process) until there are no memory changes in the source VM’s memory compared to the destination VM’s memory. vMotion then stops the CPU of the source VM, copies the last change buffer, and integrates the memory changes stored in that buffer to the virtual RAM of the target VM. Disk access is discontinued on the source ESXi host and is started on the target ESXi host. vMotion sends a reverse ARP (Address Resolution Protocol) to the physical switch for the purposes of updating the MAC and IP address mappings. The source VM is then shut down and the VM process is deleted on the source ESXi host.

    Storage Migration Vs. Storage vMotion

    Hyper-V Storage Migration can move VM configuration files, checkpoint files, virtual hard disks and mounted ISO files to a new location. Storage migration can be used when the VM must continue running on the same Hyper-V host but must migrate to another storage location. If the VM must be run on another host and placed on another storage location, then live or quick migration must be used along with storage migration.

    Storage vMotion is the vSphere analog of Hyper-V’s Storage Migration. Storage vMotion can perform live migration of VM components such as VM virtual disks (VMDK files) and VM configuration files to another storage (e.g., ESXi local datastore, shared SAN datastore, etc.). First, the VM metadata (including configuration, swap and log files) stored in the VM’s home directory is copied, then the virtual disks are copied.

    Changed block tracking is used to track the changes after the first replication of the source VM’s virtual disk. While the source VM is running, the disk changes are copied in several iterations to the target virtual disk until there are no differences between the source and target virtual disks.

    The virtual disks can be transformed from thick-provisioned disks to thin-provisioned disks or vice versa. During migration with Storage vMotion, the ESXi host on which the VM is running does not change. Storage vMotion is used together with vMotion when the VM must change hosts and datastores at once.

    Storage

    Cluster Shared Volumes (CSV) Vs. VMFS Cluster File System

    Cluster shared volumes are developed to provide simultaneous access to the same disk by multiple Hyper-V hosts in a cluster for reading and writing data. Disk volumes with NTFS or ReFS file systems must be used for CSV.

    VMFS is a virtual machine file system that is optimized for virtual machines and is suitable for clusters in vSphere. A VMFS can be shared by multiple ESXi hosts in a cluster for reading and writing data. This high-performance file system holds files with metadata and has specific locking mechanisms to prevent data corruption caused by writing metadata by multiple hosts concurrently.

    SMB 3.0 Vs. NFS

    SMB 3.0 is a network-sharing protocol developed by Microsoft that can be used for accessing file-level shared storage by Hyper-V hosts in Hyper-V environments as well as Windows environments in general.

    Network File System (NFS) is a sharing protocol developed by Sun Microsystems that provides access to files in file-level shared storage. NFS can be used by different vendors, by different operating systems, and in networks that have different architectures. NFS can be used by ESXi hosts in vSphere for accessing VM files located on shared storage.

    VHDX Vs. VMDK (VM virtual disks)

    VHDX (VHD) is a file format of Hyper-V VM virtual disks. Gen1 VMs can use either VHD or VHDX virtual disk files. Gen2 VMs can use only the VHDX virtual disk file format.

    VMDK is an open file format of VMware VM virtual disks developed by VMware.

    Dynamic Disks vs. Thin-Provisioned Disks

    Dynamic disks are dynamically expanding virtual disks for Hyper-V VMs. The main purpose of using dynamic disks is to save storage space. When Dynamic Disk is created, not all provisioned space is occupied by the virtual disk file. Initially, the virtual disk is a small file. It grows as data is written to the disk.

    Thin-provisioned disks in the VMware virtual environment are similar to Hyper-V’s Dynamic disks. A thin-provisioned disk has a minimal size upon creation and grows as needed as data is written to the virtual disk.

    Checkpoints Vs. Snapshots

    A Hyper-V checkpoint is used to save the state of a virtual machine at a given point in time. You can create a checkpoint, work with a VM, and then revert the VM back to the state it was in when the checkpoint was created.

    The VMware snapshot is the analog to the Hyper-V checkpoint; it, too, is used to save the current state of a VM. You can take a snapshot at any time, e.g., before updating software configuration, updating installations, testing new software, etc. A snapshot can be taken even while a virtual machine is running. The snapshot captures the following VM data: Virtual disk states, virtual memory content, and VM settings. The following files are created and stored in the VM directory when a snapshot is taken: .vmdk, -delta.vmdk, .vmsn, and .vmsd.

    Pass-Through Disks Vs. Raw Device Mapping

    A pass-through disk is a physical disk that is mounted to a VM and used instead of (VHD/VHDX) virtual disks in Hyper-V environments.

    Raw device mapping (RDM) is an alternative to the use of virtual disks for accessing the VM disks in vSphere. Depending on your settings, you can let virtual machines access the physical storage device directly when RDM is used. RDM can be used in virtual compatibility mode or physical compatibility mode.

    Virtual compatibility mode provides full virtualization of the mapped device; snapshots can be used.

    In physical compatibility mode, the guest OS can access the hardware directly; minimal SCSIvirtualization is provided. If a VM snapshot were taken, the RDM disk would not be included in that snapshot.

    For example:

    Suppose DiskName.vmdk is a disk heading file.

    DiskName-rdmp.vmdk is the mapping file (as evidenced by the -rdmp suffix).

    A mapping file resembles a symbolic link to a mapped device.

    RCT Vs. CBT

    Resilient Change Tracking (RCT) makes it possible to copy only those data blocks that have changed since the last backup when an incremental backup of Hyper-V VMs is performed. RCT technology was released with Windows Server 2016. Files with .RCT and .MRT extensions are created when RCT is enabled.

    Changed Block Tracking (CBT) is the vSphere analog of RCT for Hyper-V, helping perform incremental backups. CBT allows backup software to track the blocks that were changed since the last backup and copy only the changed blocks. Files with .CTK extensions are created for each VMDK virtual disk and snapshot file. Block changes are tracked on the virtualization layer. The VMware vSphere API for Data Protection allows third-party software to access the CBT feature for the purposes of performing backups and replications more efficiently. Changed Block Tracking was introduced by VMware in 2009 with ESX 4.0.

    Storage Spaces Vs. vSAN

    Windows Storage Spaces is a technology that abstracts storage from physical disks, used for storage virtualization and provisioning. With Storage Spaces, you can create cost-effective, scalable, highly-available software-defined storage for Hyper-V virtual environments by using servers with HDD devices.

    VMware vSAN (Virtual Storage Area Network) is the equivalent of Windows Storage Spaces. vSAN provides a distributed concept of data storage that is integrated with vSphere at the cluster level and abstracted from hardware disks. ESXi hosts managed with vCenter must be used to deploy vSAN. This approach allows disks of ESXi hosts to be used for vSAN storage while ESXi hosts are used to run VMs. SSDs can be used for caching data, while HDDs are used to store data. Disk groups are aggregated into pools that are accessible for the entire cluster. The data can be mirrored on one or more hosts, which ensures protection against failure. This is defined by the number of failures setting. Using vSAN, you can achieve reliable and scalable enterprise-grade storage.

    Dynamic Memory Vs. Virtual Memory Overcommit

    Dynamic memory allows a VM to use the amount of memory that it currently needs, rather than all virtual memory provisioned for that VM. The hardware RAM on Hyper-V servers can be used more rationally with this feature.

    VMware Virtual Memory Overcommit is the equivalent feature in VMware. Both features use dynamic memory allocation methods, but the methods differ somewhat. With VMware, you can allocate more memory than the ESXi host has for VMs, thereby increasing the density of VMs on the host. The idea is to optimize physical memory consumption – thus, more VMs can run on the ESXi host, but there is no guarantee that all the memory provisioned for it can be provided to a particular VM at a given point in time. Using Memory Overcommit presumes that a memory can be rearranged between the VMs depending on demands. 25% of unused memory is reserved on an ESXi host in case the memory requirements of its VM suddenly increases.

    Hyper-V Integration Services Vs. VMware Tools

    Hyper-V “Integration Services” is a set of tools and drivers for providing proper functionality of child VMs and time synchronization. When Integration Services are installed, the standard drivers for mouse, keyboard, disk controllers, and network controllers are replaced by drivers included as part of the Integration Services suite for better performance and user experience.

    VMware Tools is a collection of drivers, modules, and utilities that is the VMware equivalent of Hyper-V Integration Services. VMware Tools offers advanced functionality to improve performance, user interaction with guest VMs, and integration. When VMware Tools is installed, you can shut down the guest OS directly from menu in the vSphere client or VMware Workstation. Video resolution and graphics performance are increased. Other useful features like Drag & Drop, shared folders, time synchronization, copying/pasting between VMs and hosts, and grabbing/releasing of the mouse cursor also become available. VMware Tools is usually provided as an ISO image or Operating System Specific Package (OSP).

    Migration from Microsoft Hyper-V to the VMware vSphere Platform

    Transitioning from Hyper-V to vSphere can be useful if the vSphere virtualization platform better meets your company’s needs. First, you should prepare the hardware and software. Check VMware’s hardware compatibility list to ensure that your hardware is officially supported. Install ESXi servers, vCenter, and other software that you need. Download and install VMware vCenter Converter. Run VMware vCenter Converter and click Convert Machine.

    Select Hyper-V Server as a source type. Select the IP address or server name of your Hyper-V Server. In this walkthrough, vCenter Converter is installed on the Hyper-V Server and localhost is input as the server name.

    Next, input the username and password of an account that has sufficient permissions to perform the operation. The Windows Administrator account is used in this example. Click Next.

    Select the virtual machine to be converted. Click Next.

    Select VMware Infrastructure virtual machine as the destination type. Type the IP address of your vCenter Server or ESXi host, then enter the username and password. Click Next.

     

    Select the folder and the name that should be applied to the destination VM after conversion. Click Next.

    Select a destination location, including the ESXi host and datastore. Click Next.

    Configure the options for the destination VM. You can see how to change the type of virtual disk provisioning in the screenshot provided below. Click Edit in the Data to copy section.

    In the dropdown list, select the disk provisioning type (thick or thin). Click Next.

    Check the summary and, if you are satisfied, click Finish.

    Wait until the conversion task is complete.

    Once the VM conversion is finished, you can open vCenter with vSphere Web client in your browser and find the converted VM. In this walkthrough, the VM name is Server2016-01. As you can see on the preview screenshot, the VM is successfully running. Click Launch Web console to access the user interface of the VM. You can now tune the virtual machine and install VMware Tools.

    You now know how to migrate from Hyper-V to VMware vSphere.

    Conclusion

    Knowing the differences and similarities between features of VMware and Hyper-V environments makes migration from one platform to another easier and is particularly useful for administrators of a multi-hypervisor environment. Understanding the architecture as well as the working principles of both virtualization platforms, along with their feature sets, helps administrators work comfortably and effectively when they are tasked with maintaining the less-familiar platform. There is one important rule that applies to both VMware and Hyper-V environments: The VMs must be backed up regularly. Robust VM backup can protect your business-critical data against natural disasters, technological failures, human errors and virus attacks.

  • Broadcom Acquires VMware to Expand Software Portfolio

    Broadcom Acquires VMware to Expand Software Portfolio

    Broadcom today pulled the trigger on an acquisition of VMware for $61 billion in cash and stock that could dramatically expand its software portfolio.

    Tom Krause, president of the Broadcom Software Group, told investors that the Broadcom infrastructure software group will become part of VMware once the deal closes. The deal, however, includes a 40-day “go shop” option for VMware to court another suitor who might be willing to acquire VMware at a higher price.

    Should the deal close, Broadcom is committed to melding its portfolio of DevOps, AIOps and security offerings with the VMware portfolio, said Krause. Broadcom acquired CA Technologies in 2018 and the enterprise division of Symantec in 2019.

    Krause said Broadcom plans to invest in the core VMware vSphere, vSAN and vRealize management software platforms that drive the most revenue for VMware today. Broadcom is also committed to increasing VMware earnings from $4.7 billion to $8.5 billion within the next three years. The primary driver of that growth will be savings generated by eliminating duplicate functions in the combined company and a forecasted increase in the volume of workload running on VMware platforms, said Krause. There are currently 300,000 vSphere customers that are increasing the number of workloads they are deploying both in the cloud and in on-premises IT environments, he noted.

    Broadcom is also committed to shifting as many customers as possible away from perpetual software licenses to subscriptions that generate more consistent recurring revenues, added Krause. VMware today reported revenue for the first quarter of fiscal 2023 was $3.09 billion, an increase of 3% from the first quarter of fiscal 2022. Subscription and software-as-a-service applications accounted for 29% of total revenue for the quarter. Subscription and SaaS revenue for the first quarter was $899 million, an increase of 21% year-over-year.

    Dan Kirsch, principal analyst and managing director for Techstrong Research, an arm of the parent company of devopsy.kinsta.cloud, said given the size of the deal, many existing VMware customers are naturally going to be nervous. The primary concern will be the degree to which Broadcom might attempt to increase licensing fees to meet its financial goals, he noted.

    The acquisition of VMware comes at a time when the number of workloads being deployed in the cloud is far outpacing the rate at which workloads are being deployed in on-premises IT environments. The bulk of those workloads run on non-VMware-based hypervisors. However, many of the workloads that run on VMware today in a data center are being shifted to the cloud. VMware has also invested in building a Tanzu platform for building and deploying cloud-native applications on Kubernetes clusters.

    Broadcom is committed to investing in research and development across the combined software portfolio, said Krause.

    It remains to be seen how much of the VMware employee base will remain with the combined company. It’s not uncommon for there to be a ‘brain drain’ in the wake of a major merger, noted Kirsch.

    Whether or not the deal closes, a lot of IT teams will, at the very least, be reviewing their VMware software portfolio in the weeks ahead as the new Broadcom-VMware entity evolves. In fact, it’s likely that the acquisition of VMware will set off a wave of mergers and acquisitions during what appears to be an economic downturn. That means regular reviews of vendor relationships will soon be the order of the day for a wide range of IT organizations.

  • Newly Independent VMware to Focus on Multi-Cloud

    Newly Independent VMware to Focus on Multi-Cloud

    As an independent company once again, VMware will focus its efforts on providing management planes that span multiple cloud computing environments after officially spinning out of Dell Technologies.

    Ray O’Farrell, executive vice president for the cloud-native apps business unit at VMware, said the company now has a unique opportunity to work closely with providers of cloud services, builders of on-premises IT infrastructure and providers of telecommunications services.

    The terms of the spin-off included an $11.5 billion special cash dividend that resulted in a $27.40 per share dividend payment to all VMware stockholders. VMware claims the simplified financial structure that arises from the deal will provide it with additional operational and financial flexibility.

    Going forward, much of the development work will focus on providing management planes that not only span multiple clouds but also address specific cross-platform requirements such as security. It’s not likely there will ever be one single uber control plane for all of IT, noted O’Farrell. Rather, IT teams should expect VMware to deliver a series of well-integrated control planes to automate specific tasks in a way that breaks down IT silos, he said.

    VMware, however, under terms of its existing alliance, will also continue to work closely with Dell to create server environments that are optimized for VMware hypervisor platforms, O’Farrell said.

    Key to the strategy is a portfolio of observability tools that VMware plans to continue to expand, noted O’Farrell. VMware will also address the requirements of both traditional monolithic applications running on virtual machines as well as cloud-native applications running on distributions of Kubernetes, such as VMware Tanzu, that may be deployed on top of a hypervisor or on a bare-metal server, he added.

    Given the complex state of IT environments today, it’s all but inevitable something will go wrong, said O’Farrell. The challenge and the opportunity for VMware is to provide IT teams with the observability tools required to discover as many issues as possible before they adversely impact the business, he added. Once those issues are discovered, IT teams should be able to automate the remediation process using the rest of the portfolio of VMware management frameworks, he noted.

    Those management frameworks will also provide the foundation for unifying traditional approaches to IT service management (ITSM) with DevOps best practices that are now being used more widely, especially to manage cloud-native applications, said O’Farrell.

    When it comes to on-premises IT environments, VMware continues to dominate. Its hypervisor is, by far, the most widely used on servers in local data centers. VMware has spent much of the last two years expanding its reach into multiple clouds to enable IT organizations to standardize on a series of management frameworks. The goal is to reduce the total cost of IT by reducing reliance on what would otherwise be a hodgepodge of isolated management frameworks. The challenge VMware regularly encounters is the IT teams that manage cloud computing environments are not always the same ones that are managing on-premises IT environments. As such, many IT teams that have deployed cloud applications tend to embrace the management frameworks provided by their cloud services provider.

    VMware, however, is betting that as more organizations look to reduce the total cost of IT, the economic pressure to converge IT management using its frameworks will be simply too great to ignore.

  • Windows Sandbox and Hypervisor-Based Isolation

    Windows Sandbox and Hypervisor-Based Isolation

    Completely securing the endpoint is hard. Securing it without sacrificing user productivity is even harder. Think of a modern laptop running a Windows 10 OS, for example. The OS consists of millions of potentially vulnerable lines of code. It has many legacy components written with old security standards in mind. The kernel is probably executing several third-party drivers that might also be vulnerable. Finally, there are dozens of daily-use applications. Some are provided, managed and patched by the enterprise, while others are installed on demand by users; the latter are not always from legitimate sources, making it harder to track and assess security. Timely detection and prevention of threats is a cat-and-mouse game, where a single win for the attackers is game over for the user.

    Consider, too, the rate at which organizations are moving to the cloud. For those using the endpoint purely as a browser, web isolation products can significantly enhance security by isolating browser access to risky websites and, sometimes, to risky email attachments, too. Using ChromeOS, an operating system built for the cloud with security in mind, can provide additional security benefits.

    But using only a browser is not yet practical for most organizations. Many legacy line-of-business applications are still being used daily. Workers install video conferencing applications to meet with business partners. Developers install and update software for their daily work. Almost every popular, modern cloud application (Slack, Teams, Office, etc.) comes with a full desktop client that offers superior features. For organizations looking to adopt these tools, web isolation solves only part of the problem.

    VDI or Desktop-as-a-Service (DaaS) solutions allow companies to shift corporate application workloads to the data center or the cloud. By limiting endpoint operations to that of a thin client, and only connecting them to this infrastructure, the list of potential attack vectors narrows and becomes very secure.

    But using VDI/DaaS for the entire organization becomes very expensive if massive numbers of users need remote access simultaneously. Further, the user experience and latency are far from ideal, and offline work is impossible. In terms of security, while the endpoint is now more secure, the threat still exists – it just moves to the data center or the cloud, where, in essence, a fat Windows desktop is running. With DaaS, security might be even more challenging when multiple users share the same virtual OS; a single threat can potentially compromise multiple user sessions at once.

    Hypervisor-Based Isolation

    The world trusts modern hypervisors to securely run servers, containers and other workloads in the cloud. Sometimes, multiple hypervisors run side-by-side on the same physical server, though they’re completely separated and isolated from each other. Unlike modern OS kernels, hypervisors are designed to perform a very specific task. Their code base is usually very small, well-reviewed and thoroughly tested, making it very hard to exploit. Empirically, it’s very rare to see a hypervisor-related vulnerability discovered or published.

    Is it possible to secure the endpoint with hypervisor-grade isolation? Imagine a “productivity environment” where workers can browse any website; open any email attachment or install and execute software, all without endangering the corporate environment or the organization’s crown jewels. Even better, malware or attackers who compromise this environment are trapped inside by strong, hypervisor-based isolation boundaries.

    Windows Sandbox

    Microsoft has been investing a lot in virtualization-based security (VBS) in recent years. Hypervisor-based isolation is a key element, whether it’s used to isolate LSA secrets with Credential Guard or to isolate critical Device Guard code. With the release of Windows 1903, Microsoft has introduced Windows Sandbox, describing it as a “lightweight desktop environment tailored for safely running applications in isolation.” Windows Sandbox enables users to spin up, almost immediately, a second, isolated instance of Windows with a click of a button.

    Windows Sandbox is based on the new “Krypton VM Containers” – Hyper-V-backed lightweight containers. The lightness is reflected in:

    • Reduced disk space: The container reuses the host’s binaries, reducing its disk footprint and making it easier to manage. This also means it remains as patched and secure as the host.
    • Optimized memory and CPU usage: The host’s kernel is aware of the container, and manages it as yet another application. That means improved CPU and memory allocation based on actual demand and usage.
    • Paravirtualized GPU: By enabling GPU acceleration inside the container, the CPU has less work to do.

    Unlike web isolation products, Windows Sandbox can isolate almost any application. With the Krypton optimizations, it’s fast and doesn’t place too many demands on hardware (any three-year-old laptop should suffice), making it dramatically more affordable than VDI. The virtualization layer is barely noticeable, making the performance superior to VDI/DaaS.

    The Missing Pieces

    Can Windows Sandbox enable organizations to provide an isolated “productivity environment” while further hardening and securing the host OS? In theory, it could, but in practice, unfortunately, it lacks certain capabilities necessary for enterprise environments:

    • Manageability: It’s hard to deploy and impossible to manage (policies, applications) Windows Sandbox with MDM systems such as Microsoft Intune.
    • Usability: Windows Sandbox is non-persistent. Applications installed by users or administrators are going to be wiped on reboot. User settings, cookies, and browsing history will not be saved.
    • OS integration: While users can install risky software inside the container rather than on the host, they are not forced to do so.
    • Security: While fully isolated in terms of code execution, Windows Sandbox doesn’t provide network isolation. Malware can access and attack other devices accessible by the host, even if behind a Network Access Control (NAC).
    • Software Compatibility: Some applications fail to run or to be installed inside Windows Sandbox.

    Hypervisor-based isolation has clear benefits over traditional security methods. By avoiding the cat-and-mouse game, and moving to “mitigation by isolation”, organizations can increase security and productivity, and reduce costs. Once some of the aforementioned gaps are filled, hypervisor-based isolation could become the future of endpoint security.

  • Harmonizing Real-Time on Edge Platforms

    Harmonizing Real-Time on Edge Platforms

    Edge computing platforms sit at the boundary between the real-time world and the digital enterprise. Uninterrupted, uncorrupted data from the edge is a must if analytics in the cloud drive reliable business decisions. What’s the best approach: using Linux, an RTOS (real-time operating system), a hypervisor or something else for edge platforms?  Let’s talk about harmonizing real-time on edge platforms and introduce a new foundation project in the Linux Foundation’s LF Edge family.

    Real-Time and Deterministic

    Real-time only means events are captured, tagged and processed as they unfold in the real world. That cadence can be seconds, milliseconds or microseconds depending on how many events and how often they occur and how tasks and algorithms stay in control. Three operating system characteristics determine how well real-time execution keeps pace: prioritization, interrupt response time and context switch time.

    Prioritization ensures that tasks receive resources when needed. Tasks at a lower priority should pre-empt when a higher priority task requests service. A task refusing to yield to pre-emption can throw off the prioritization scheme, causing missed deadlines.

    Interrupt response time measures the latency from the time an event requests service via a hardware interrupt to when the handler task executes. Real-time hardware platforms often place high-priority events on hardware interrupts for fastest pre-emption.

    Context switch time is softer scheduling at work. It measures the time for a change in processing control from one execution entity to another, swapping out resources including registers, cache and memory as needed.

    Deterministic means there are no surprises in behavior. The faster real-time events happen, and the harder a system works, the more likely non-determinism surfaces. One venture into virtual memory paging or a burst of networking activity can show up at an inopportune time, even though under most conditions real-time performance is adequate.

    ‘Hard’ vs. ‘Soft’ Real-Time

    That’s why most people think of real-time as “hard” with a fast, deterministic operating system. RTOS platforms optimize the kernel and only build things in around it that are necessary, providing rigorous and sometimes mathematically proven scheduling for many tasks.

    “Soft” real-time is more forgiving. On a fast processor, interrupt response time is tiny compared to the execution window. A system that isn’t deterministic can, if there is enough margin in context switch time, keep up with real-time events on a slower scale. Linux, while not deterministic, can handle some real-time needs through minimizing packages and tuning the kernel for better prioritization.

    Linux also benefits from lighter context switching. Originally, execution entities in Linux were resource-heavy processes. Now, threads can handle tasks with far less switching overhead. POSIX threads standardized the approach with portability between Linux and RTOS environments.

    How fast are threads? According to a recent synthetic thread benchmark by Eli Bendersky, switching on server-class platforms with enough memory, cache and storage can be in the range of 2 microseconds with 10,000 threads under ideal conditions. Eli pointed out his test environment has more RAM than many edge hardware platforms provide, but most edge applications won’t need that many threads, either.

    So, the line for soft real-time has moved down into new territory, making the trade-off between hard and soft a bit blurrier.

    Hypervisors and Orchestration

    If your DevOps team commits to an RTOS, you may give up some familiar functionality and have a learning curve to deal with, but you get assured hard real-time performance. If you go with Linux, you get the tools and coding practices you’re used to, but soft real-time performance can be an issue as code piles up.

    The leaders in RTOS platforms with enterprise networking noticed this, too. Recently they’ve turned to hypervisors in a bare-metal approach. A hypervisor can capture the benefits of environments working together, so teams are not forced into an either/or operating system choice. This is especially important if the edge application requires some form of certification, such as in medical, industrial or defense applications. Certified code can be compartmentalized on an RTOS, while Linux runs alongside.

    Linux providers are turning more toward orchestration layers and containers. It’s an application focus speeding up deployment, with more scalability and less hardware dependence. It also brings the edge into the enterprise faster with the same application deployment strategy anywhere. More code means more determinism risk.

    Convergence is a faint hope on this landscape with competing objectives, but a new approach offers a path for software reuse and rapid deployment.

    Harmonizing the Edge

    The Linux Foundation is active across the spectrum of IoT development, from the Zephyr open source RTOS to various embedded Linux projects. One of the newest projects in the LF Edge initiative is a foundation targeting a blend of deployment models in a consistent, open approach.

    Project EVE (short for Edge Virtualization Engine) supports containers, clusters, virtual machines and unikernels simultaneously. It’s a slim bare-metal runtime offering hardware root of trust, device resource management and software update and patch functions. EVE can host any combination of apps in virtual machines or containers, including running an RTOS with its application in a virtual machine. It can even assign CPU and GPU cores to specific applications for enhanced determinism.

    On the EVE road map is support for the ACRN hypervisor (another LF Edge project) and shrinking the EVE runtime for smaller embedded-class edge platforms. These efforts are essential where real-time requirements become harder and a hypervisor plus an RTOS makes sense. For softer real-time environments, EVE is adding support for Kubernetes K3S, Docker Compose, VPNs for public clouds and mesh networking for data flow between edge platforms.

    While the project is still young, EVE holds great promise for DevOps teams working the edge. We’d look forward to seeing some benchmarking on a real-time scale; it likely handles soft real-time needs as well as Linux today. By harmonizing a range of diverse approaches into one foundation, EVE is creating a space for real-time on edge platforms no matter which development perspective teams come from.

  • Xen Project Team Updates Open Source Hypervisor Project

    Xen Project Team Updates Open Source Hypervisor Project

    The team behind the open source Xen hypervisor announced today provided an update to the project that adds better nested performance, more robust live patching capabilities, improved security and support for Linux subdomains that make it possible to execute code within a specialized domain.

    In addition, Xen Project Hypervisor 4.14 adds the ability to run Xen as a guest under Hyper-V, the hypervisor Microsoft employs on the Azure cloud.

    George Dunlap, Xen Project Advisory Board Chair, said that latter capability will make it easier to create centrally managed hybrid cloud computing environments that span lightweight instances of Xen at the network edge and instances of Xen running in the Microsoft Azure Cloud. Xen is a core component of the Edge Virtualization Engine (EVE) being developed by LF Edge, which, like the Xen Project, is being developed under the auspices of The Linux Foundation.

    Dunlap also noted IT teams can employ Xen Project Hypervisor to run containers on top of virtual machines, which makes it possible to centrally manage the deployment of containerized applications from the edge to the cloud.

    Xen Project Hypervisor 4.14 also extends Raspberry Pi 4 support for devices with 4GB and 8GB of RAM, in addition to supporting the next-generation AMD EPYC processor, codenamed Milan.

    Finally, Xen Project Hypervisor 4.14 adds support for faster introspection of malware; the ability to live-patch security fixes in a way that ensures they are implemented in the right order; and control flow tools to combat Return-Oriented Programming (ROP) attacks.

    Dunlap noted the Xen team continues to work on Secret-free Xen, which prevents memory from being mapped as part of a side-channel attack.

    Golang bindings are also been expanded to make it easier to develop code on top of Xen using the Go programming language, and add the ability to migrate virtual machines with no drivers or broken drivers.

    While there is no shortage of options when it comes to virtual machines, Dunlap said the more they are viewed as a commodity the more likely organizations will opt to rely on an open source project, as many organizations are deciding there isn’t enough differentiated value to warrant paying for a commercial license.

    It’s too early to say how much organizations will continue to rely on virtual machines. Many IT teams do so now to provide a layer of isolation that is often deemed critical for security. Other IT teams are starting to rely more on containers deployed on bare-metal servers or a lighter-weight instance of a virtual machine that serves only to isolate workloads.

    Regardless of the path forward, the more platforms that run a common layer of virtual infrastructure, the easier it is to manage a hybrid IT environment. The real challenge is being able to enforce that level of IT discipline in an era where developers often spin up virtual machines wherever they find them.

  • Xen Project Advances Hypervisor Project

    Xen Project Advances Hypervisor Project

    The Xen Project announced this week that the latest version of the open source hypervisor can now take advantage of core scheduling, an experimental technology that enables Xen to group multiple processors together to create a single virtual central processor unit (CPU).

    Lars Kurth, chairperson for the Xen Project advisory board, said this capability also represents an important first step toward developing a more secure form of hyperthreading. Since earlier this year, many IT organizations have turned off hyperthreading because of cybersecurity concerns. However, such decisions have resulted in significant performance penalties for many applications.

    In addition to adding support for core scheduling, version 4.13 of Xen Project Hypervisor adds support for live patching and late uCode loading that makes it possible to install updates at runtime without having to reboot the hypervisor.
    The latest version of Xen also adds support for additional processors, including AMD 2nd Generation EPYC, Hygon Dhyana 18h, Raspberry Pi4 and Intel AVX512-based platforms.

    Finally, version 4.13 of Xen adds support for OP-TEE, which enables all guests to concurrently run trusted Applications on TrustZone, firmware created by ARM to isolate processors on the same system, and improvements to Dom0less, which makes it possible to partition processors running in parallel.

    The Xen Project Group also announced it has created a Functional Safety Working Group, which is committed to making the Xen hypervisor compatible with ASIL-B requirements, a set of compliance requirements defined by the automotive industry. That effort represents a significant challenge because it requires code and development processes to comply with key tenets of ISO 26262, a set of standards for embedding electronics into any road vehicle.

    The Xen Group is also working on developing a secret-free hypervisor, which Kurth said will play a critical role in thwarting side-channel cybersecurity attacks. Cybercriminals can employ side-channel attacks to break encryption algorithms by measuring and analyzing the physical attributes such as the amount of radiation being generated by a processor.

    Kurth said version 4.13 represents a major milestone in the ongoing development of Xen. In the future, Xen will also be able to take advantage of the Rust-vmm project being led by Intel that will make it possible for a processor to run multiple types of hypervisors in a modular fashion.  In addition to providing a more agile way of isolating virtual machines, Rust-vmm will reduce the amount of time required to spin up a virtual machine. Specifically, Intel is trying to make it easier for a processor to be able to run different classes of hypervisors that are optimized for legacy monolithic applications and cloud-native applications based on containers that require a much lighter-weight hypervisor.

    It’s not clear to what degree advances in technologies such as core scheduling will influence the selection of hypervisors and virtual machines. However, from a DevOps perspective, it’s clear core capabilities being added to the next generation of hypervisors will not only improve application performance, but they should also significantly advance best DevSecOps practices.

    — Mike Vizard

  • Ravello Systems Powers DevOps with Extreme Continuous Integration on Clones of Production Applications in the Cloud

    Ravello adds new Apache Maven plug-in and announces availability of Ruby and Python bindings for integration with build automation tools.

     

    PALO ALTO, Calif. – February 12, 2014 – Ravello Systems, the industry’s first Cloud Application Hypervisor provider, today announced it has added new plug-ins and RESTful APIs to provision entire multi-virtual machine environments, along with networking and storage, in the cloud. Ravello has added a new Apache Maven plug-in, and programming language bindings for Ruby and Python, with support for Continuous Integration (CI) systems including Jenkins, Bamboo, and Teamcity. With one API call, developers can instantly provision a complete clone of their existing on-premise production application and deploy it in the public cloud.

    Ravello enables CI on production replicas in the cloud

    To achieve successful agile development and test processes, enterprises are quickly adopting DevOps principles, and using CI is a key practice. The goal with CI is to get as reliable feedback as quickly as possible, resulting in higher quality software delivered faster. However, most DevOps practitioners encounter constraints when implementing CI due to (1) difficulties in automating the infrastructure, making it problematic to provision clones of multi-tier production applications, and (2) capacity restraints in the datacenter, making it impossible to deploy these clones for every code commit. Automating CI processes can be very painful, time-consuming and fraught with configuration nightmares.

    With Apache Maven, the vastly popular build automation tool, developers are able to manage a project’s build, deployment, testing, reporting and documentation from a central repository. Recognizing the value of Maven as a build automation tool, the Ravello Maven plug-in is designed to help integrate Maven-based projects with Ravello Systems’ rich APIs. This integration makes it easier to automatically configure the build, testing and deployment processes, resulting in smoother operations.

    Ravello’s Software-as-a-Service (SaaS) offering allows enterprises to spin up clones of their existing multi-tier enterprise applications in the public cloud – without any changes to the virtual machines (VMs), networking or storage. With the addition of a new Maven plug-in and the availability of Ruby and Python bindings for integration with other build automation tools, Ravello now enables extreme CI on production clones in the cloud. Now developers and test engineers can use Ravello’s APIs to:

    • Provision the entire environment;
    • Start and stop applications as needed;
    • Automatically execute the tests and either shut down to release resources once the test has passed, or save the state if an issue needs to be debugged;
    • Easily integrate with CI servers such as Jenkins, Bamboo or Teamcity.

    All this can be done right from the integrated development environment (IDE). Now each code commit can be tested on a clone of production in the cloud for instant and accurate feedback.

    “The public cloud with its infinite capacity is very promising for continuous integration, but it’s an inherently different environment than what you have on premise,” said Gil Hoffer, VP of R&D, Ravello Systems. “Your application might have multiple subnets, multiple network cards per server and specific storage requirements. With Ravello we abstract away the differences between the private and public clouds, and have built-in automation for provisioning and deploying those multi-tier applications in the cloud.”

    Supporting Resources

    Follow Ravello Systems on the Web at:

    About Ravello Systems
    Founded in 2011, Ravello Systems delivers a software-as-a-service that enables developers, devops and IT to use the unlimited resources of the public cloud to develop and test their on-premise applications. Powered by the industry’s first Cloud Application Hypervisor, Ravello enables enterprises to encapsulate their multi-tier applications and run them anywhere – on-premise or in any cloud – without making any changes whatsoever, and thereby implement a true hybrid cloud. Ravello Systems is backed by top tier VCs including Sequoia Capital, Norwest Venture Partners and Bessemer Venture Partners. For more information, visit www.ravellosystems.com.