Showing posts with label Hyper V. Show all posts
Showing posts with label Hyper V. Show all posts

Microsoft’s Virtualization Support Story

The support story for Microsoft products running on virtualization hardware is long and complicated. Until several years ago, Microsoft offered limited support for its flagship server products, such as SQL Server, Exchange Server, and SharePoint. Microsoft even left open the option that a support problem might need to be duplicated on physical hardware if support technicians couldn’t determine the nature of the problem in a virtual environment. Adding to Microsoft’s weak support story was the fact Virtual Server 2005 R2 was its virtualization product during the early days of Microsoft Office SharePoint Server (MOSS) 2007. Virtual Server 2005 R2 wasn’t a hypervisor-based product and couldn’t virtualize 64-bit guests, which limited supported environments to those running the 32-bit versions of MOSS 2007. This greatly curtailed the performance that could be achieved, particularly for the database role, which was the most resource-intensive and could take advantage of the 64-bit architecture the most. In addition, web front ends typically required significantly more memory than a 32-bit platform.

Two significant developments changed this story. The first was Microsoft’s release of a 64-bit–capable hypervisor named Hyper-V. The second was the development of a program called the Server Virtualization Validation Program, which outlined Microsoft’s official support stance on running its products on third-party hypervisor virtualization platforms. This program, outlined in the Microsoft article “Support policy for Microsoft software running in non-Microsoft hardware virtualization software” (support.microsoft.com/kb/897615), allowed for support of Microsoft products on third-party virtualization products that were validated by Microsoft and complied with certain criteria. These two developments opened the doors for Microsoft servers running on virtual machines (VMs) and gave peace of mind to organizations that needed to deploy supported virtualized solutions.

The 2007 wave of SharePoint products—which includes Windows SharePoint Services 3.0 (WSS 3.0) and MOSS 2007—was the first to gain broad virtualization support from Microsoft. However, in production, most organizations opt to virtualize only the web role and sometimes the query role. Other roles aren’t typically implemented for various reasons. For example, the index role is often implemented only on physical hardware because of heavy processor and memory constraints and the limitation of one index server per Shared Services Provider. Microsoft’s official SharePoint 2010 support stance is that any SharePoint role or service is supported for hardware virtualization. SharePoint 2010 is positioned as a great version to virtualize because of the virtualization technology advances and reduction of disk I/O requirements for the indexing and search components. In addition, advances in hardware virtualization make it easier to virtualize I/O intensive applications such as SQL Server, allowing the SharePoint database role to be more easily virtualized. As a result, many organizations are looking at virtualizing their new SharePoint 2010 farms.

Source of Information : Windows IT Pro June 2010

Software Recommendations and Licensing Notes

It’s highly recommended that you use the latest virtualization host software from your particular vendor. For example, the latest version of Hyper-V is included with Windows Server 2008 R2. Hyper-V 2.0 has significant performance improvements over Hyper-V 1.0, such as I/O improvements for fixed-size VHDs. Hyper-V 2.0 also has new features such as Core Parking, Live Migration, TCP Offload, Jumbo Frames, and support for Second-Level Address Translation (SLAT)–enabled processors. If you’re virtualizing SharePoint on Hyper-V, you should also consider deploying the virtual host on Server Core to minimize its security footprint, OS disk overhead (2GB versus 10GB), and memory use.

If you’re managing multiple virtual host machines, centralized management software is also recommended. For example, Microsoft offers System Center Virtual Machine Manager (VMM) 2008 R2 for virtualization management. It allows for physical to virtual (P2V) server migration, server template libraries, and management of both Hyper-V and VMware hosts and guests through a single console.

Microsoft provides cost-effective virtualization licensing options for Windows Server, which lets organizations save significantly on Windows Server licenses when virtualizing servers. The three types of virtualization server licenses are:

• Windows Server Standard Edition, which allows a single physical OS environment (POSE) or a single virtual OS environment (VOSE) with each Standard Edition license. Note that a virtualization host that’s dedicated to virtualization tasks doesn’t consume a license, regardless if it’s running Windows Server (such as in the case of Hyper-V).

• Windows Server Enterprise Edition, which allows for up to four VOSEs to be run at any one time on the host. Note that only running VMs are counted, so if a VM is shut down, it doesn’t count against the four concurrent VOSEs permitted by the Enterprise Edition license.

• Windows Server Datacenter Edition, which is a per-processor license for the virtual host (e.g., a dual quad-core server would require two licenses) that grants you the right to run an unlimited number of VMs on the host.

These licensing options apply not only to Hyper-V but also to any hypervisor that’s part of the Server Virtualization Validation Program. For organizations with a significant investment in virtualization infrastructure, buying the appropriate number of Datacenter Edition licenses to cover all the virtual hosts is the most cost effective.

Source of Information : Windows IT Pro June 2010

SAN Features

Today SANs come with features that can really help your enterprise manage your data and your virtual machines.



iSCSI
iSCSI is a type of SAN that uses industry technologies such as Ethernet and Ethernet NICs for transport and an interface. So far iSCSI has proven to be a great lower-cost solution to the Fibre Channel SAN solutions that are available. If, for instance, you are building your virtualization environment on servers that are worth U.S. $4,000 and you want to connect them to your Fibre Channel SAN, you will have to purchase Fibre Channel adapter cards that are compatible with your SAN. Each one of the Fibre Channel cards you implement into your server can range from $1,000 to $2,000 each. That can really start to be an additional cost if you are building out one or more 16-node clusters.

Now we’re sure some of you reading this are saying, “Well yeah, but I’ve already implemented my Fibre Channel architecture. Now you want me to implement another infrastructure just for this?”

Well, no, that’s not the case. What we’re saying is that if you don’t already have an infrastructure in place, iSCSI would be a great technology for you to research. One other consideration you will want to keep in mind when you are determining whether initiator comes into play. The iSCSI initiator can, like the target, be software or hardware. Most implementations that we are seeing today are running free software iSCSI initiators that come with most operating systems. Depending on the servers that you are buying, you can also buy hardware iSCSI initiators. If you find that a software initiator isn’t giving you the performance that you need, you can purchase hardware initiator cards that also have TCP/IP offload engines to help speed up the traffic.



Direct Attached Storage
Direct attached storage (DAS) is a storage array that is directly connected, rather than connected via a storage network. The DAS is generally used for one or more enclosures that hold multiple disks in a RAID configuration.

DAS, as the name suggests, is directly connected to a machine, and is not directly accessible to other devices. For an individual computer user, the hard drive is the most common form of DAS. In an enterprise, providing storage that can be shared by multiple computers tends to be more efficient and easier to manage.

The main protocols used in DAS are ATA, SATA, SCSI, SAS, and Fibre Channel. A typical DAS system is made of one or more enclosures holding storage devices such as hard disk drives, and one or more controllers. The interface with the server or the workstation is made through a host bus adapter.



NAS
Network attached storage (NAS) is a hardware device that contains multiple disks in a
RAID configuration that purely provides a file system for data storage and tools to manage that data and access. An NAS device is very similar to a traditional file server, but the operating system has been stripped down and optimized for file serving to a heterogeneous environment. To serve files to both UNIX/Linux and Microsoft Windows, most NAS devices support NFS and the SMB/CIFS protocols.

NAS is set up with its own network address. By removing storage access and its management from the server, both application programming and files can be served faster, because they are not competing for the same processor resources. NAS is connected to the LAN and assigned an IP address. File requests are mapped by the main server to the NAS server.

NAS can be a step toward and included as part of a more sophisticated SAN. NAS software can usually handle a number of network protocols, including Microsoft’s Internetwork Packet Exchange and NetBEUI and Novell’s Netware configuration.

Source of Information : Microsoft Virtualization with Hyper V

RAID Levels

A technology called RAID minimizes the loss of data due to drive failures. RAID was created by a group of scientists at University of California at Berkeley in 1987. When they designed the first RAID systems, RAID stood for Redundant Array of Inexpensive Disks. “Inexpensive” was later changed to “Independent,” but both terms are used interchangeably. The idea is that using two or more drives simultaneously can be faster and more failsafe than using a single, larger drive. Using two drives in parallel (one is a copy of the other) is much safer than a single drive. RAID technology offers both solutions at varying levels of coverage. No single RAID level is superior to any other. The RAID level you implement will depend on your needs and budget.


Level 0 – Striping
RAID level 0 is not fault tolerant because no information is duplicated on the disk system. However, performance is enhanced because the data is striped in 64k strips across all the drives in the array. For example, suppose you had three drives in your array. When the controller needs to write a block of data 256k in size, it writes the first 64k block to disk 1, the next 64k block to disk 2, the next 64k block to disk 3, and the last 64k block to disk 1. Additionally, the total available space is the same as the total physical space. Because the probability of failure is greater for this RAID level, it is not used widely.


Level 1 – Mirroring
RAID level 1 is called mirroring because it maintains an identical twin of the first drive. Since all data that is written to disk 1 (original disk) is also written to disk 2 (shadow disk), disk utilization is only 50 percent. There is also a slight write performance loss due to the overhead of writing to two drives. However, there is a performance gain on disk reads and there is very good fault tolerance. To eliminate the single point of failure here, you can use two controller cards, each responsible for writing to a single disk. This completely duplicates the I/O system and is called duplexing. You should use mirroring if you
• Require a high level of redundancy
• Demand high read performance
• Do not want to deal with the complexity of other RAID systems


Level 2
Level 2 RAID uses striping (like RAID 0), but it is performed at the bit level. This method of writing data to the disk requires a good deal of CPU processing and is inefficient. It is thus not adopted and there are no commercially available RAID 2 solutions.


Level 3
Level 3 RAID uses byte striping similar to level 0 but includes a drive dedicated for parity. The parity can be thought of as the sum of all the bytes contained in the stripes of the other disks. The parity disk provides true fault tolerance because if any of the other drives fail, the information on it can be calculated by subtracting the bytes in the other stripes from the parity stripe. The capacity of RAID level 3 arrays can be expressed as a percentage: n-1/n where n is the total number of drives. Since all disks are involved in every read or write (to calculate the parity stripe), RAID level 3 arrays can process only one transaction at a time. They are not suited for random access of many small data blocks. These systems are best suited for large sequential requests, but it’s pretty rare that you’ll ever see this.


Level 4
Level 4 RAID uses striping at the block level to improve efficiency. Otherwise it dedicates a drive to the parity information like level 3 RAID, and thus has the same capacity of RAID level 3 systems.


Level 5
A popular RAID configuration is level 5 RAID. Here the parity is stored in 64k blocks and placed evenly on all drives. Since the controller can process multiple writes in parallel across the array, RAID level 5 can outperform levels 3 and 4. It doesn’t perform as well as level 0 or 1, however, because of the computation used to calculate the parity information. The capacity of RAID level 5 is the same as levels 3 and 4 and should be considered when redundancy is required but you do not have the money for a mirrored solution or if you require the overall larger capacity afforded by arrays as opposed to single, mirrored drives.


Advanced Levels
RAID level 10 is a striped array that is mirrored. This configuration provides excellent fault tolerance and a performance boost. Any single drive in each array or an entire array can fail without data loss. The capacity is reduced to 1-n/2n for every n drives. RAID level 55 requires three RAID 5 arrays that are combined into one larger RAID 5 array. Just replace each drive in RAID 5 with an array of drives each with its own controller, and you have massive capacity, excellent performance, and nearly perfect redundancy. The ratio of total usable space is the same as in RAID 5 systems (1-n/n).

Source of Information : Microsoft Virtualization with Hyper V

A virtual hard drive (VHD) can be created on the parent partition’s volume with access granted to the child partition. The VHD operates as a set of blocks, stored as a regular file using the host OS file system (which is NTFS).

Within Hyper-V there are different types of VHDs, including fixed size, dynamically expanding, and “differencing” disks:

• Dynamically expanding. This type of virtual hard drive starts small but automatically expands to react to need. It will expand up to the maximum size indicated when the virtual hard drive is created. “Dynamic,” in this context, is sort of a misnomer. Dynamic implies that the size of the virtual drive changes up and down based on need. But in actuality, the hard drive will keep expanding until it reaches the maximum limit. If you remove content from the virtual hard drive, it will not shrink to meet the new, smaller capacity.

• Fixed. This type of virtual hard drive is created at a certain size and it remains at that size. While fixed virtual hard drives are created to be a certain size, their size can be adjusted—just not automatically. To change the size of the virtual hard drive, you use the Hyper-V Manager Edit Disk action to make changes.

• Differencing. The third type of virtual hard drive is the differencing drive. In this scheme, a parent disk and a child disk are used. In this configuration, the parent disk contains a baseline hard disk image with the operating system (and maybe some applications and data). When this parent drive is configured, a differencing disk is allocated to a child. When the virtual machine to which the child virtual disk is assigned makes changes, those changes are made to the child differencing disk and the parent disk is left alone. Several child disks may be assigned to a parent disk, thus allowing multiple virtual machines to share the same parent disk. Differencing disks can also be chained together. The changes on one differencing disk can be merged to the parent disk. On the other hand, a new virtual hard disk can be created via the merger of a child and parent disk. This leaves the parent disk unaltered. When a differencing disk is created, a parent disk needs to be specified. The size of the differencing disk grows as space is needed.

In Hyper-V, you can expose a host disk to the guest without putting a volume on it by using a pass-through disk. Hyper-V allows you to bypass the host’s file system and access the disk directly. This disk is not limited to 2,040 GB and can be a physical hard drive on the host or a logical one on a SAN. Hyper-V ensures that the host and guest are not trying to use the disk at the same time by setting the drive to be in the offline state for the host. Pass-through disks have their downsides. You lose some VHD-related features, like VHD snapshots and dynamically expanding VHDs.

Source of Information : Microsoft Virtualization with Hyper V

What Should I Virtualize?

Virtualize everything! Well, maybe not everything; determining which servers to virtualize is probably one of the most time-consuming tasks you will do while planning your virtualization implementation. There are factors that range from performance and supported operating system to the hardest part of all, politics. We’re going to leave the politics to the politicians and focus only on the technical components of virtualization.

There are five major system components that will drive your choice to virtualize a server or workstation.

• Disk IO
• Memory Utilization
• Processor Utilization
• Network Utilization
• Operating System



Disk IO
Disk IO is the input and output (IO) of data to a hard disk. Disk IO is measured by the number of IO operations per second (IOPS) that can be performed. When planning a Windows Server 2008 Hyper-V environment, it will be critical to provide enough IO performance from your disk subsystem to the host server or servers to support the IO requirements for the host and each virtual machine you implement. When you are implementing a new virtual machine or converting a physical machine to a virtual machine, the virtual machine itself will use the same amount of IO as it did or would have if it were a physical server. Also, the total amount of IO isn’t just the sum of the virtual machines; it must also include the IO of the host. While doing this, keep in mind that you will someday add more virtual servers to that host.



Memory Utilization
Memory utilization is how much Random Access Memory (RAM) a system uses for the base operating system as well as for the applications that run on that system. The amount of memory a system uses can go up and down depending on the workload a server is experiencing at any given time. Knowing how much memory your guests use at load and on average will help you determine not only how much memory you will need to purchase for your host systems, but also how many virtual machines you will be able to place on that host.



Processor Utilization
Processor utilization is how much throughput your CPU is doing at any given time. Each task or process that runs on a multitasking CPU must share CPU cycles. This is important because if a task is already heavy on the CPU, there is less time for the CPU to work with other processes. With the creation of multicore processors there are more CPU cores available to do the tasks at hand. When you do the analysis of your current machines, pay close attention to the utilization and the type of processors that are in your systems. This will help determine the number of virtual machines that can fit on a host machine.



Network Utilization
Network utilization is the amount of network usage of a system. This usage is generally expressed as the amount of bandwidth being recorded over a period of time in megabits per second. The network utilization rate is the ratio of current traffic to the maximum traffic that the port can handle. If network utilization rates are high, then the network is busy. If they are low, then the network is idle. If the rate is too high, the result is low transmission speeds. However, when we talk about network utilization as it relates to virtualization, we’re talking about multiple virtual machines sharing a single network interface card (NIC). The result is a much more efficient strategy, and one that reduces the amount of network traffic.



Guest Operating Systems
Windows Server 2008 Hyper-V has a limited number of operating systems that are supported to run on the guest virtual machines. Other operating systems might work with Hyper-V, but Microsoft is only supporting this list at this time. Check the Microsoft web site, www.microsoft.com/en/us/default.aspx, regularly to see if Microsoft has added any additional supported operating systems.

Source of Information : Microsoft Virtualization with Hyper V

Virtualization Stack Security

The security work that Microsoft did with Hyper-V didn’t stop at the hypervisor level:
All of the binaries that are included as part of the Hyper-V role have gone through the SDL process. One part of this process adds address-space-layout randomization, which, when enabled, loads critical DLLs in random pages of memory at each boot. This helps alleviate exploits that target DLLs that load in the same memory location every time.

•The worker processes that represent the virtual processor to the VM have a number of safeguards— they run in user mode, with reduced privileges, and each worker process is separate from the others.

•Each VM has its own instance of a virtual device. No two VMs can use the same virtual network adapter—when a VM is created, a new virtual network adapter is created for that VM.

•By requiring the Execute Disable/No Execute bit in the host’s processor, the chance of malicious buffer overflow attacks is reduced.

Other components, such as the VSP/VSC architecture, have additional security measures in place:

•Each VM that is powered on has a separate instance of Virtual Machine Bus (VMBus).

•VMBus is a point-to-point connection between the VSP in the parent and the VSC in the guest.

•Because the VSC doesn’t have access to the physical device, DMA (Direct Memory Access) attacks can’t take place.

Source of Information : Sybex Windows Server 2008 Hyper-V Insiders Guide to Microsofts Hypervisor

Hypervisor Security

Microsoft has done a number of things to ensure a secure hypervisor: Security Development Lifecycle The Microsoft Security Development Lifecycle (SDL) is one of the main ways that Microsoft assures quality software. In place since 2004, the SDL has improved product quality by implementing strict quality gates, process improvements, and other guidance throughout the entire software-development process. By being put in place at the earliest possible time, before a line of code has been written, the SDL helps eliminate security issues before the product ships and can affect users.

For more information, you can read the following white paper, which provides guidance on how Microsoft implemented the SDL: http://www.microsoft.com/downloads/details.aspx?FamilyID=2412c443-27f6-4aac-9883-f55ba5b01814&displaylang=en. Keep in mind that this is only a guide and that not all the steps Microsoft followed are publically available.

Separate address spaces. Both the hypervisor and the host operating system maintain separate address spaces. An address space refers to a specific location in memory. By ensuring that there are separate address spaces for both components, the host operating system can’t read or access the hypervisor address space and vice versa.

No third-party code. The hypervisor included as part of Hyper-V doesn’t include any thirdparty code. Other hypervisors include device drivers or other drivers that were submitted by third parties. By having all code in the hypervisor go through the SDL, Microsoft can ensure the stability of the hypervisor as a whole.

Guest-to-guest communication. No communication that takes place between guests over synthetic devices goes through the hypervisor. This reduces the chance of a man-in-themiddle attack in the hypervisor, where someone injects a driver at the hypervisor level that sniffs data going between two VMs.

No shared memory between guests. Each guest has its own memory space. This means the memory allocated to those VMs is exclusive and can’t be accessed from other VMs.

Inability of guests to affect hardware I/O. All I/O for synthetic devices in VMs is handled in the Virtualization Service Provider / Virtualization Service Client (VSP/VSC) model, which sits above the hypervisor layer. Also, the I/O model of the VSP/VSC architecture sends out requests on behalf of the VM—the VM itself doesn’t send I/O requests.

Hypervisor access. The host and guests are unable to write to the hypervisor; rather, they communicate with the hypervisor via the well-defined Hypercall API. This ensures that the hypervisor can’t be modified.

Source of Information : Sybex Windows Server 2008 Hyper-V Insiders Guide to Microsofts Hypervisor

The Hyper-V Security Model

Because the Hypervisor sits below all other components, it’s naturally the first attack target of those looking to compromise a Hyper-V host. One of the most talked-about items related to security of hypervisors (not specific to Hyper-V) is Blue Pill. The term Blue Pill harkens back to the film The Matrix—if you ingested the blue pill, you had no idea that you actually lived inside the Matrix. The Blue Pill concept was written by Joanna Rutkowska and presented at the Black Hat Security Conference in 2006; it referred to the possibility of malware being injected into a hypervisor-aware platform without the user’s knowledge. Needless to say, it caused quite a stir when people learned that a hypervisor could be subverted so easily.

Hyper-V was developed with a number of security assumptions in mind:

•The parent partition is trusted by the hypervisor, and the virtual machines (child partitions) trust the parent partition.

•None of the virtual machines (VMs) running on a host are trusted. They can be used for nefarious deeds.

•The code running in VMs must be run unmodified, must use all features of the x86 instruction set, and can execute in any ring necessary.

•The hypercall interface, which child partitions can use to access functions of the hypervisor is publically available and fully documented. A (potentially) untrusted VM can attempt to execute any of the hypercalls.

•A VM can detect that it’s running on a hypervisor.

Source of Information : Sybex Windows Server 2008 Hyper-V Insiders Guide to Microsofts Hypervisor

Microsoft Virtual PC

Microsoft Virtual PC 2007 is a desktop virtual machine solution to help you migrate legacy applications to Windows Vista. Virtual PC offers customers a cost-effective safety net to ease their migration to Microsoft Windows Vista and a tool to help accelerate the development, testing, deployment, and support of PC applications.

For example, Microsoft Virtual PC allows enterprise customers to run multiple operating systems on one PC, so employees can run critical legacy applications on an interim basis while IT professionals proceed with the migration to the end user’s workstation to the latest version of the Windows operating system.


Benefits. Virtual PC 2004 marked Microsoft’s entry into the Windows-based virtual machine arena in 2003. The product was built on virtualization technology that Microsoft acquired in February 2003 from Connectix Corp.

Virtual PC offers the benefit of rapid reconfiguration. For instance, the software can enhance the productivity of technical support, help desk, or call center employees by enabling them to easily switch among operating systems without logging in and out between calls.

Virtual PC is also designed to accelerate software testing by allowing developers to test and debug their software for multiple platforms in a timely and cost-effective manner, all on one PC, improving both software quality and time to market.


Features. Features of Microsoft Virtual PC include support for as many as four network adapters per virtual machine, all through the graphical user interface; Extensible Markup Language (XML) file-based configuration of virtual machines to ease the copying of a virtual machine to another computer; and support for up to 3.6GB of memory. More memory makes it possible to run more operating systems simultaneously and improves the performance of operating systems with larger memory requirements.

Key features carried over from the former Connectix product include:
• The virtual machine additions, that provide a high level of integration between host and guest operating systems, including integrated mouse, time synchronization, cut-and-paste, drag-and-drop, and folder sharing

• Undo Disks, which allows users to delete any changes they make to the virtual hard disk during a session

• Differencing Disks, which lets multiple users and multiple virtual machines use the same parent virtual hard disk at the same time.

Virtual PC also runs most x86 operating systems in the virtual machine environment with no need for custom drivers. This compatibility positions customers to migrate legacy applications and consolidate desktops for dramatic cost savings.



Virtual PC supports these host operating systems:
• Windows Vista (32-bit and 64-bit versions of Windows Vista Ultimate, Enterprise, Business editions, and European Business N only; but not Windows Vista Starter, Windows Vista Home Basic or Home Premium, or European Vista Home N editions)
• Windows XP Professional and Tablet PC Edition (32-bit) and Windows XP Professional x64 Edition (not Windows XP Home Edition or Windows XP Media Center Edition)
• Windows Server 2003



Virtual PC supports these guest operating systems:
• Windows Vista (all 32-bit editions)
• Windows XP (all 32-bit only)
• Windows Server 2008 (Virtual PC 2007 Service Pack1 onward)
• Windows 2000 Professional and Server
• Windows 98 Second Edition
• Windows Server 2003 Standard Edition
• Certain editions of IBM OS/2


Source of Information : Microsoft Virtualization with Hyper V

Connectix

Connectix Corp. was a company that made virtualization software for Windows and Macintosh-based computers. In 2003 Microsoft acquired their virtualization technology and now uses it in their own virtualization products.

Connectix’s technology allowed customers to migrate to next-generation technology from Microsoft, while still being able to use legacy applications. Virtual PC for Mac provided integration of Windows on the Macintosh platform, enabling Mac OS customers to run Windows-based applications, access PC networks, use Windows-only Internet applications, and share files with PC-based colleagues. Virtual PC for Mac joined the Macintosh Business Unit’s mix of Mac products, such as Office v.X, Entourage X, and Internet Explorer for Mac.

Virtual PC for Windows provided Windows desktop customers with an additional tool for migrating to Windows XP or Windows 2000 Professional, supported legacy applications, and enabled a range of other uses for application development, call centers, technical support, education, and training.

Virtual Server addressed customer demand for an application migration solution based on virtualization and supported by Microsoft. In addition, it provided cost efficiencies by consolidating multiple Windows NT 4.0 servers and their applications into a single Windows Server system.

Though Connectix is now defunct, Microsoft continues to develop virtual machine solutions based on the Connectix technologies.


Source of Information : Microsoft Virtualization with Hyper V

VMware Infrastructure 3

VMware Infrastructure 3 (VI3) is a solution aimed at enterprises that are looking to consolidate full-scale production systems. It is the most scalable of the VMware platforms with new management, load-balancing, and high-availability features.

As VI3 is based on ESX Server, it is not dependent on a host operating system, and it can be used to host virtual machines running Windows, Linux, or other common operating systems.

Since VI3 is so scalable, it can run up to 128 concurrent virtual machines on multiple ESX servers, all managed from a central console. Those servers can all be configured to share a common file system—the VMware Virtual Machine Fine System (VMFS)—hosted on local disks, Network Attached Storage (NAS), or Storage Area Network (SAN) storage.

VMFS makes provisioning and management of virtual machines much simpler. It makes it possible to dynamically allocate resources and profess loads across both virtual machines and physical servers. In fact, you can move an entire virtual machine from one server to another, even while users and applications are actively using it. Additionally, once the virtual machines are installed, they can be managed remotely. VI3 employs the VMware Distributed Resource Scheduler (DRS), which automatically tunes processor, memory, and other resources.

VMware High Availability (HA) adds automatic failover if there is a hardware or software problem, and VMotion makes it possible to migrate live virtual machines from one server to another. This aids in maintenance and load balancing.


Source of Information : Microsoft Virtualization with Hyper V

Virtualization Stack Security

The security work that Microsoft did with Hyper-V didn’t stop at the hypervisor level:
All of the binaries that are included as part of the Hyper-V role have gone through the SDL process. One part of this process adds address-space-layout randomization, which, when enabled, loads critical DLLs in random pages of memory at each boot. This helps alleviate exploits that target DLLs that load in the same memory location every time.

•The worker processes that represent the virtual processor to the VM have a number of safeguards— they run in user mode, with reduced privileges, and each worker process is separate from the others.

•Each VM has its own instance of a virtual device. No two VMs can use the same virtual network adapter—when a VM is created, a new virtual network adapter is created for that VM.

•By requiring the Execute Disable/No Execute bit in the host’s processor, the chance of malicious buffer overflow attacks is reduced.

Other components, such as the VSP/VSC architecture, have additional security measures in place:

•Each VM that is powered on has a separate instance of Virtual Machine Bus (VMBus).

•VMBus is a point-to-point connection between the VSP in the parent and the VSC in the guest.

•Because the VSC doesn’t have access to the physical device, DMA (Direct Memory Access) attacks can’t take place.

Source of Information : Sybex Windows Server 2008 Hyper-V Insiders Guide to Microsofts Hypervisor

VMware ESX Server

ESX Server is a component of VMware’s VMware Infrastructure, which adds management and reliability services to its core server product.

The basic server requires some sort of storage, like an array of disk drives, for storing the virtualized kernel and support files. VMware offers a variant of this product called ESX Server ESXi Embedded. This moves all the server’s kernels into a dedicated hardware device.

In the VMware world, they refer to the hypervisor used as a vmkernel.

VMware notes that ESX Server runs on “bare metal.” That is, unlike other VMware products, it does not run on top of another operating system, but rather sets up its own kernel.

ESX Server sets up a Linux kernel first, and that kernel is used to load specialized virtualization components, including vmkernel. That first installed Linux kernel becomes the first running virtual machine and is called the service console.

The vmkernel has three interfaces with the user:
• Hardware Access to other hardware is accomplished using this interface.

• Guest systems This interface simulates hardware and occurs in such a way that a guest system itself can run unmodified on top of the hypervisor.

• Service console A general-purpose operating system used as the bootstrap for the VMware kernel and used as a management interface.

Each virtualized server perceives the system resources as unique to it, and not shared with others. ESX Server has some limitations that might restrict its deployment and use: The maximum amount of RAM for a guest system is 64GB; and there can only be 32 hosts in both High Availability (HA) clusters and Distributed Resource Scheduler (DRS) clusters.

Source of Information : Microsoft Virtualization with Hyper V

HISTORY OF VIRTUALIZATION

While computer technology continues to march forward with smaller, sleeker, more powerful machines, in many ways how we use computers has come full circle. Obviously the computers of today are way more powerful than the computers of the 1950s, but it turns out the way we are using them is harkening back to the early days of computing. Let’s take a look at the history of virtualization to see how it all began and look at some of the ways that the world of virtualization has evolved.



Mainframes
Anyone who has been around computers for a while will quickly recognize that the concept of running a client’s session on a server and then displaying the results on the client machine describes the way mainframes work.

While modern mainframes are certainly speedy things, they are more notable for their redundant internal engineering, ensuring a high level of redundancy, security, and backward compatibility with legacy applications. It’s not uncommon for a mainframe to run constantly for years without incident, even while upgrades and repairs are performed. Software upgrades are nondisruptive because one system can take over another’s application while it is being improved.



The Evolution of the Mainframe
Between the late 1950s and 1970s, several manufacturers built the first mainframes. The group of manufacturers was known at one point as “IBM and the Seven Dwarfs.” Those companies were: IBM, Burroughs, UNIVAC, NCR, Control Data, Honeywell, General Electric, and RCA.

IBM was the dominant leader in the field with its 700/7000 series, and later its 360, which continued to evolve into the current zSeries/z9 mainframes. In the 1960s, mainframes tended not to have an interactive interface. They accepted punch cards, paper tape, and magnetic tape, operating solely in batch mode to support office functions, like customer billing.

By the 1970s, mainframes had acquired interactive user interfaces and were used as timesharing computers, able to support thousands of users simultaneously. This was done mostly via a terminal interface. These days, most mainframes have phased out terminal access and end users are able to access the mainframe using a web user interface.

In the early 1980s, less demand and competition led to a lot of companies pulling out of the mainframe arena. Also, companies realized the benefits of client-server solutions, and as a result, mainframe sales fell while server sales boomed. By the early 1990s, it seemed that the mainframe was going the way of the dinosaur, but in the late 1990s, organizations found new uses for their existing mainframes. The growth of e-business increased the number of back-end transactions processed by the mainframe, as well as the size and throughput of databases.



Operation
Mainframes are able to host multiple operating systems, and operate not as a single computer, but as a number of virtual machines, which are called partitions in the mainframe world. In this capacity, a mainframe can replace hundreds of smaller servers. While mainframes were the first to function this way, we’re now seeing regular servers used in this way.

Mainframes are designed to handle very high-volume input and output. Since the mid-1960s, mainframe designs have incorporated subsidiary computers called channels or peripheral processors. These computers manage the IO devices, leaving the CPU open to manage high-speed memory. When compared to a PC, mainframes have thousands of times as much storage.

As bulletproof as they sound, mainframes do have disadvantages. Their primary issue is that they are centralized. This isn’t a problem when everything is housed under one roof, but as the organization becomes more geographically dispersed, it’s harder to justify the cost of a mainframe at several locations.

Source of Information : Microsoft Virtualization with Hyper V


Subscribe to Developer Techno ?
Enter your email address:

Delivered by FeedBurner