Welcome to the XenServer Technical Presentation. In this presentation we’ll be covering many of the core features of XenServer, and we’ll have the option of diving a bit deeper in areas which you may be interested in.
For those of you unfamiliar with XenServer, XenServer is a bare metal hypervisor which directly competes with vSphere, Hyper-V and KVM. It is derived from the open source Xen project, and has been in active development for over six years. In this section we’ll cover the core architectural items of Xen based deployments.
Since XenServer is based on the open source Xen project, it’s important to understand how Xen itself works. Xen is a bare metal hypervisor which directly leverages virtualization features present in most CPUs from Intel and AMD since approximately 2007. These CPUs all feature VT-D or AMD-V instructions which allow virtual guests to run without needing performance robbing emulation. When Xen was first developed, the success of Vmware ESX was largely based on a series of highly optimized emulation routines. Those routines were needed to address shortcomings in the original x86 instruction set which created obstacles to running multiple general purpose “protected mode” operating systems such as Windows 2000 in parallel. With Xen, and XenServer, those obstacles were overcome through use of both the VT-D instruction set extensions and para-virtualization. Paravirtualization is a concept in which either the operating system is modified, or specific drivers are modified to become “virtualization aware”. Linux itself can optionally run as paravirtualized, while Windows requires the use of both hardware assistance and paravirtualized drivers to run at maximum potential on a hypervisor.These advances served to spur early adoption of Xen based platforms whose performance outstripped ESX in many critical applications. Eventually VMW released ESXi to leverage VT-D and paravirtualization, but it wasn’t until 2011 and vSphere 5 that ESXi became the only hypervisor for vSphere.
This is a slide that shows a blowup of the Xen virtualization engine and the virtualization stack “Domain 0” with a Windows and Linux virtual machine. The green arrows show memory and CPU access which goes through the Xen engine down to the hardware. In many cases Xen will get out of the way of the virtual machine and allow it to go right to the hardware.Xen is a thin layer of software that runs right on top of the hardware, Xen is only around 50,000 lines of code. The lines show the path of I/O traffic on the server. The storage and network I/O connect through a high performance memory bus in Xen to the Domain 0 environment. In the domain 0 these requests are sent through standard Linux device drivers to the hardware below.
Domain 0 is a Linux VM with higher priority to the hardware than the guest operating systems. Domain 0 manages the network and storage I/O of all guest VMs, and because it uses Linux device drivers, a broad range of physical devices are supported
Linux VMs include paravirtualized kernels and drivers. Storage and network resources are accessed through Domain 0, while CPU and memory are accessed through Xen to the hardwarehttp://wiki.xen.org/wiki/Mainline_Linux_Kernel_Configs
Windows VMs use paravirtualized drivers to access storage and network resources through Domain 0. XenServer is designed to utilize the virtualization capabilities of Intel VT and AMD-V enabled processors. Hardware virtualization enables high performance virtualization of the Windows kernel without using legacy emulation technology
XenServer is designed to address the virtualization needs of three critical markets.Within the Enterprise Data Center, XenServer solves the traditional server virtualization objectives of server consolidation, hardware independence while providing a high performance platform with a very straight forward management model.Since XenServer is a Citrix product, it only stands to reason that it can draw upon the vast experience Citrix has in optimizing the desktop experience and provide optimizations specific to desktop workloads.Lastly, with the emergence of mainstream cloud infrastructures, XenServer can draw upon the heritage of Amazon Web Services and Rackspace to provide a highly optimized platform for cloud deployments of any scale.
Since all these use cases depend on a solid data center platform, let’s start by exploring the features critical to successful enterprise virtualization
Successful datacenter solutions require an easy to use management solution, and XenServer is no different. For XenServer this management solution is called XenCenter. If you’re familiar with vCenter for vSphere, you’ll see a number of common themes. XenCenter is the management console for all XenServer operations, and while there is a powerful CLI and API for XenServer, the vast majority of customers perform daily management tasks from within XenCenter. These tasks include starting and stopping VM, managing the core infrastructure such as storage and networks, through to configuring advanced features such as HA, workload placement and alerting. This single pane of glass also allows administrators to directly access the consoles of the virtual machines themselves. As you would expect, there is a fairly granular set of permissions which can be applied, and I’ll cover that topic in just a little bit.
Of course any management solution which doesn’t have role based administration isn’t ready for the modern enterprise. XenServer fully supports granular access to objects and through the distributed management model ensures that access is uniformly applied across resource pools regardless of access method. In other words, the access available from within XenCenter is exactly the same access available via CLI or through API calls.
What differentiates Live Storage Migration from Live VM Migration is that with Live Storage Migration the storage used for the virtual disks is moved from one storage location while the VM itself may not change virtualization hosts. In XenServer, Live VM Migration is branded XenMotion and logically Live Storage Migration became Storage XenMotion. With Storage XenMotion, live migration occurs using a shared nothing architecture which effectively means that other than having a reliable network connection between source and destination, no other elements of the virtualization infrastructure need be common. What this means is that with Storage XenMotion you can support a large number of storage agility tasks, all from within XenCenterFor example:Upgrade a storage arrayProvide tiered storage arraysUpgrade a pool with VMs on local storageRebalance VMs between XenServer pools, or CloudStack clusters
One of the key problems facing virtualization admins is the introduction of newer servers into older resource pools. There are several ways vendors have chosen to solve this problem. They can either “downgrade” the cluster to a known level (say Pentium Pro or Core 2), disallow mixed CPU pools, or level the pool to the lowest common feature set. The core issue when selecting the correct solution is to understand how workloads actually leverage the CPU of the host. When a guest has direct access to the CPU (in other words there is no emulation shim in place), then that guest also has the ability to interrogate the CPU for its capabilities. Once those capabilities are known, the guest can optimize its execution to leverage the most advanced features it finds and thus maximize its performance. The downsize is that if the guest is migrated to a host which lacks a given CPU feature, the guest is likely to crash in a spectacular way. Vendors which define a specific processor architecture for the “base” are effectively deciding that feature set in advance and then hooking the CPU feature set instruction and returning that base set of features. The net result could be performance well below that possible with the “least capable” processor in the pool. XenServer takes a different approach and looks at the feature set capabilities of the CPU and leverages the FlexMigration instruction set within the CPU to create a feature mask. The idea is to ensure that only the specific features present in the newer processor are disabled and that the resource pool runs at its maximum potential. This model ensures that live migrations are completely safe, regardless of the processor architectures; so long as the processors come from the same vendor.
The ability to overcommit memory in a hypervisor was born at a time when the ability to overcommit a CPU far outpaced the ability to populate physical memory in a server in a cost effective manner. The end objective of overcommiting memory is to increase the quantity of VMs which a given host can run. This lead to multiple ways of extracting more memory from a virtualization host than was physically present. The four most common ways of solving this problem are commonly referred to as “transparent page sharing”, “memory ballooning”, “page swap” and “memory compression”. While each has the potential to solve part of the problem, using multiple solutions often yielded the best outcome. Transparent page sharing which seeks to share the 4k memory pages used by an operating system to store its read-only code. Memory ballooning seeks to introduce a “memory balloon” which appears to consume some of the system memory and effectively share it between multiple virtual machines. “Page swap” is nothing more than placing memory pages which haven’t been accessed recently on a disk storage system, and “memory compression” seeks to compress the memory (either swapped or in memory) with a goal of creating additional free memory from commonalities in memory between virtual machines.Since this technology has been an evolutionary attempt to solve a specific problem, it stands to reason that several of the approaches offer minimal value in todays’ environment. For example, transparent page sharing assumes that the readonly memory pages in an operating system are common across VMs, but the reality is that the combination of large memory pages and memory page randomization and tainting have rendered the benefits from transparent page sharing largely ineffective. The same holds true for page swapping whose performance overhead often far exceeds the benefit. What this means is that the only truly effective solutions today are memory ballooning and memory compression. XenServer currently implements a memory balloning solution under the feature name of “dynamic memory control”. DMC leverages a balloon driver within the XenServer tools to present the guest with a known quantity of memory at system startup, and then will modify the amount of free memory seen by the guest in the even the host experiences memory pressure. It’s important to present the operating system with a known fixed memory value at system startup as that’s when the operating system defines key parameters such as cache values.
Managing a single virtual machine at a time works perfectly fine when you’re evaluating a hypervisor, or when you’re a small shop, but eventually you’re going to want to manage applications which span a group of servers as a single item. Within XenServer, this is accomplished using a vApp. At its highest level, a vApp is a container which includes one or more VMs and their associated settings. This container is manageable using all the standard XenServer management options, and importantly can participate in HA and disaster recovery planning as well as backup export operations.
VM Protection & Recovery GoalProvide a way to automatically protect VM memory and disk against failures Snapshot TypesDisk onlyDisk and memorySnapshot frequencyHourlyDailyWeekly (multiple days)Start timeSnapshot retention configurable (1-10)Archive frequencyAfter each snapshotDailyWeekly (multiple days)Start timeArchive locationCIFSNFSCompressed export
As today's hosts get more powerful, they are often tasked with hosting increasing numbers of virtual machines. For example, only a few years ago server consolidation efforts were generating consolidation ratios of 4:1 or even 8:1, today’s faster processors coupled with greater memory densities can easily support over a 20:1 consolidation ratio without significantly overcommiting CPUs. This creates significant risk of application failure in the event of a single host failure. High availability within XenServer protects your investment in virtualization by ensuring critical resources are automatically restarted in the event of a host failure. There are multiple restart options allowing you to precisely define what critical means in your environment.
The features we’ve just covered form the basis of a basic virtualized data center. Once your data center operations reach a point where you’re operating at scale which has many admins, or multiple resource pools, some of the advanced data center automation components within XenServer will start to become valuable.
When looking at storage usage within virtualized environments, there typically is either a file based or block based model, but regardless of the model the shared storage is essentially treated as if it were nothing more than a large dumb disk. Advanced features of the storage arrays aren’t used, and storage usage might be inefficient as a result. StorageLink uses specialized adapters which are designed for a given array. These adapters take full advantage of the feature set contained within the storage array. Key advantages of StorageLink over simple block based storage repositories include: Thin-provisioning, deduplication and array based snapshot management.Note:Integrated StorageLink replaces the StorageLink Gateway technology used in previous editionsLUN-per-VDIUsing array “smarts”Does not require a (virtual) machine for running StorageLink componentsRemoves SPOFSupported AdaptersNetAppDell EqualLogicEMC VMX
When resource pools are small, and the number of VMs under management are similarly low, it’s not unreasonable for a virtualization admin to make acceptable decisions about where to place a given guest for optimal performance. Once the number of VMs reaches a critical point, typically between 20-30, placement decisions and interdependencies become so complex that humans aren’t going to place VMs in the most optimal location. This is why VMW and others have implemented resource placement services, and if you’re familiar with vSphere DRS, then XenServer Workload Balancing will look very familiar. Like DRS, WLB takes into account CPU and RAM utilization when attempting to determine where the best host to start or rebalance a VM is, but unlike DRS, WLB also includes key IO metrics such as disk reads and writes and network reads and writes in those computations. This allows WLB to ensure IO dominant applications are rarely placed on the same host, and that overall resource pool operations are optimized.In addition to performing workload placement, WLB is also directly integrated into XenServer power management to perform workload consolidation on a scheduled basis. This feature allows for the consolidation of underutilized servers onto fewer hosts during evening hours, and the evacuated hosts powered down for the duration. When the morning schedule takes effect, the powered down hosts are automatically restarted and workloads rebalanced for optimal performance.Lastly, WLB incorporates a series of health and status reports suitable for both operations and audit purposes.Schedule pool policy based on time of day needsWhen starting guests, an option to “Start on optimal server” is available, and XenServer chooses the most appropriate server based on policyUsers have the ability to over-ride policy, or specify guests or hosts that are excluded from policy (eg high-demand applications)
Planning for and supporting multi-site disaster recovery within a virtualized environment can be quite complex, but with XenServer’s integrated site recovery option, we’ve taken care of the hard parts. The key to site recovery is that we take care of the VM metadata, while your storage admins take care of the array replication piece. What this means is that every iSCSI or HBA storage solution on our HCL is supported for site recovery operations, providing that it either has built-in replication or can work with third party replication. When site recovery is enabled, the VM metadata corresponding to the VMs and/or vApps you wish to protect are written to the SR containing the disk images for the VMs. When the LUNs are replicated to the secondary site, the metadata required to reconfigure those VMs is also automatically replicated. Because we’re replicating the underlying VM disk images and associated metadata, if VMs in the secondary site are running from different LUNs Integrated Site Recovery can fully support active/active use models. Note that due to VM replication, active/active will require a minimum of two LUNs.Recovery from failure, failback and testing of failover is accomplished using a wizard within XenCenter. Each step of the wizard validates that the configuration is correct and that the system is in fact in a state of “failure”.
XenServer Web Console GoalsEnable XenServer Mgmt from a Web based console Offer VM level delegation so end users can manage their VM’sWeb SS delivers Remote ManagementITadmins have long wanted a means to mange VM’s remotely via a browser based, non-windows platformEnd User Self ServiceWSS also allows IT to delegate routine management tasks to the application/VM ownerThis satisfies the more strategic goal of helping IT to enable customer self service in the datacenterFinally WSS also provides a foundation for future innovation in the areas of web based mgmt, self service and an opencloud director layer for x-platform mgmt
Performing a snapshot of a running VM using live memory snapshot allows the full state of the VM to be captured during the snapshot, all with minimal impact to the running VM. Additionally, if the Volume Snapshot Service (VSS) is enabled within Windows VMs, any services which have registered themselves with VSS will automatically quiesce during the snapshot. Examples of services which register themselves include SQL Server.XenServer supports both parallel branches for the snapshot chains, and will automatically coalesce any chains if intermediate snapshots are deleted. Additionally, snapshots can be converted to custom templates.
Desktop virtualization is a core topic in many organizations today, and while some vendors would have you believe that a general purpose hypervisor is the correct solution for desktop workloads, the reality is that desktop workloads present a very distinct usage pattern not seen with traditional server based workloads. This is one reason why when you look at Citrix XenDesktop you see it taking advantage of specific features of XenServer which are unique to desktop virtualization. In this section, we’ll cover what the Desktop Optimized XenServer looks like and what specific benefits XenServer has when XenDesktop is used as the desktop broker.
Within desktop virtualization there are two distinct classes of users, those who are using general purpose applications and those who are using graphics intensive applications. Supporting the former is readily accomplished using the traditional emulated graphics adapters found in hypervisors, but when you need the full power of a GPU for CAD, graphic design or video processing those emulated adapters are far from sufficient. This is why XenServer implemented the GPU Pass-through feature. With GPU pass-through users requiring high performance graphics can be assigned a dedicated GPU contained within the XenServer host making GPU pass-through the highest performing option on the market.
So this use traditionalcase is shown on the left. Each blade or workstation needed a GPU installed, and Windows was installed physically.On the right we have the GPU pass-thru use case. We can install a number of GPUs in the XenServer host, and assign them to the Virtual machines.The actual savings will be determined by the number of GPUs in the server, or the capabilities of the new “multi-GPU cards” coming from vendors such as nVidia.
One of the biggest areas of concern when deploying desktop virtualization isn’t the overall license costs, but the impact of shared storage. On paper if you were considering a deployment requiring 1000 active desktops, and assumed an average of 5GB per desktop, if you happened to have space for a 5 TB LUN on an existing storage array, you might be tempted to carve out that LUN and leverage it for the desktop project. Unfortunately, were you to do so you’d quickly find that while you had the space for the storage you might not have the free IOPS to satisfy both the desktop load and whatever pre-existing users were leveraging the SAN. With XenServer, we recognized that this would be a barrier to XenDesktop adoption and implemented IntelliCache to leverage the local storage on the XenServer as a template cache for the desktop images running on that host.
The key to IntelliCache is recognizing that with desktop virtualization the number of unique templates per host is minimal. In fact, to maximize the effect of IntelliCache target the minimum number of templates to the given host. At the extreme, if the number of active VMs per template requires more than a single host, then dedicating a resource pool per template might be optimal.
Hidden as due to citrix.com website optimizations due at launch, the calculator will be offline
When desktop virtualization is the target workload, the correct hypervisor solution will be one which not only provides a high performance platform, and has features designed to lower the overall deployment costs and address critical use cases, but one which offers flexibility in VM and host configurations while still offering a cost effective VM density. Since this is a classic case of use case matters, take a look at the Cisco Validated Design for XenDesktop on UCS with XenServerhttp://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/Virtualization/ucs_xd_xenserver_ntap.pdf
As with desktop virtualization, there are unique characteristics of cloud workloads which make a general purpose hypervisor less than idea. The vast experience Citrix has with cloud operators such as Amazon, Rackspace and SoftLayer over the years has allowed us to develop features which directly address the scalability and serviceability of cloud infrastructure.
When dealing with high VM density in cloud hosting, the standard 1Gb NICs of a few years ago simply don’t provide the level of network throughput needed for most hosting providers. This lead to 10 Gb NICs becoming commonplace, but the hypervisor overhead of processing packets for a 10 Gb network artificially limited the throughput as well. This meant that even with 10 Gb cards, wire speed was hard to attain. SR-IOV is the answer to this type of problem. Through the use of specialized hardware, the physical NIC can be divided into virtual NICs at the hardware layer and these virtual NICs, commonly referred to as virtual functions, are then presented directly into the hypervisor. The core objective of this PCI standard is to minimize the hypervisor overhead in high performance networks. While SRIOV can provide significant efficiencies with 10 Gb networks, there are a few downsides to the technology today, but each of these limitations is being addressed as the technology matures.
It is through the use of SRIOV and other cloud optimizations that the NetScaler SDX platform is able to provide the level of throughput, scalability and tenant isolation that it can. The NetScaler SDX is a hardware Application Delivery Controller capable of sustained throughput over 50 Gbps, all powered by a stock Cloud Optimized XenServer 6 hypevisor.
As you would expect from Citrix, and our historical relationship with Microsoft, XenServer has a strong integration with System Center
CIMOM = Common Information Model Object ManagerXenServer uses the OpenPegasus CIMOM
XenServer is available in a variety of product editions to meet your needs with price points ranging from Free, through “Included with purchase of management framework”, to standalone paid editions.
Platinum: Integrated DREnterprise: Adds IntelliCache for improved TCO of XenDesktop installments and adds a monitoring pack for Systems Center Ops which can now be used to manage XenServerAdvanced: Adds Automated VM protection and recovery to protect VMs data in the event of an outage or failureXenServer: Improvements to capacity, networking, upgrading, and converting existing workloadsThe “Desktop Optimized XenServer” is available with the purchase of XenDesktop, and the “Cloud Optimized XenServer” is available with the purchase of CloudStack
One of the most obvious comparisons is between vSphere and XenServer. A few years ago vSphere was the clear technical leader, but today the gap has closed considerably and there are clear differences in overall strategy and market potential. Key areas which XenServer had lagged, for example with live migration or advanced network switching are either being addressed or have already been addressed. Of course there will always be features which XenServer is unlikely to implement, such as serial port aggregation, or platforms it’s unlikely to support, such as legacy Windows operating systems, but for the majority of virtualization tasks both platforms are compelling solutions.
Platinum Edition: Data protection and resiliency for enterprise-wide virtual environmentsEnterprise Edition: Automated, integrated, and production-ready offering for medium to large enterprise deploymentsAdvanced Edition: Highly available and memory optimized virtual infrastructure for improved TCO and host utilizationFree Edition: Free, enterprise-ready virtual infrastructure with management tools above & beyond alternatives .
More information on Citrix Subscription Advantage: http://www.citrix.com/lang/English/lp/lp_2317284.asp
Premier Support: http://www.citrix.com/lang/English/lp/lp_2321822.aspPremier Support Calculator: http://deliver.citrix.com/WWWB1201PREMIERSUPPORTCALCULATORINBOUND.html
The single vendor lock-in model only benefits the vendor. Choose the correct hypervisor for your workloads to ensure the best performance as well as extending your IT budget. Use POCs to measure how well each solution performs in your environment so you can truly gauge how much ROI you will get from a given implementation. Support is a valuable asset when deploying any environment and understanding each vendors model will make sure you don’t get stuck with a costly services bill later on.Understand the requirements of each project so you can assess the best tool for the job. Know what features are needed for your applications so you can spend money on costly features wisely.
Key items to note:GPU is attached to a VM at boot time, and stays attached as long as the VM is running.Mixing GPU and non-GPU workloads on a host will maximize VM densityThe number of GPUs which can be installed in a host is limited
*Require the HP Graphics Expansion Blade moduleKey items: There is a tight relationship between the host and GPU in this model, and that means a much more limited HCL. In other words, you can’t simply install a series of GPUs into a host and expect it work; it might, but it might not. There are a lot of moving parts.Current list: http://hcl.xensource.com/GPUPass-throughDeviceList.aspx
Pretty much read this slide. It’s important stuff
Key items:If you haven’t told the host to use local storage for intellicache, it won’t
Key items: Same idea when adding a host to desktop studio
Key items:As you would expect, we did some testing and found that IntelliCache made a differenceThese next three slides go together, and it’s important to pay attention to the vertical scale
Key items:While the best results were achieved with SSDs, this really is a spindle story so if you have a server which can host a number of high performance rotational disks, then you do get a significant benefit from IntelliCache. Live migrating a VM which is backed by IntelliCache can be done, but it does require additional configuration. By default since the disk is local, live migration won’t work.
Just read it
While not required for many private clouds, the concept of resource costing, billing and chargeback are core to determining the success of your cloud initiative. Eventually someone is going to be looking for usage stats, or better still capacity planning information. That information is going to be readily available in a solution which was designed to capture deployment details from the start. One important detail to bear in mind is that no billing solution is going to be perfect. Entire products are designed around the whole concept of “billing”, and XenServer isn’t such a product. Our approach is a bit different. It recognizes that there is going to be some requirement for external data (such as costing information), and that this information simply doesn’t belong in a billing system. What we’ve done is provide the billing primitives, and easy SQL data views to access the data. From this framework, custom billing and chargeback models can be developed without encumbering the cloud provisioning system with complex billing requirements.
Key items:Prior to XenServer 6, there was a feature known as Site Recovery Manager. This feature was implemented using the StorageLink Gateway and had a very limited HCL. We removed that feature and replaced it with the Integrated Site Reocvery starting in version 6 of XenServer. This allowed us to support any iSCSI or HBA array on the HCL.
Persist following SR information in the SR:name_labelname_descriptionallocationUUIDPersist the following VDI information for all VDIs in the SR:name_labelname_descriptionUUID is_a_snapshotsnapshot_ofsnapshot_timetypevdi_typeread_onlymanagedmetadata_of_poolThe metadata is stored in a logical volume called “MGT” in each SR. Writes to this volume are O_DIRECT and block size aligned, so the metadata is always consistent.
Shows the entire flow of setup and failover.
Core terminology used in this section
Explain the problems we’re attempting to address with the new switch.Rich, flexible virtual switching for each host thatGuarantees separation & isolationParticipates in all standard switching protocol exchanges, just like a physical switchProvides full visibility into and control of the packet forwarding pathBy and for multiple VM tenantsProvides complete management of all switch features just like a hardware switchBy and for multiple managing tenantsIs inherently aware of virtualizationVM ACLs are a property of the VMMulti-tenancy<clikc>Pooled state from multiple virtual switches in a virtual infrastructure to permit the abstraction of a virtual port to be separated from a software virtual switch on a single serverBuilding block of multi-tenant virtual private data center overlayPreserve network state per-VM as VMs migrate between physical serversPermit unified management, visibility into and control of VM traffic from a single point in the infrastructurePermit multi-tenant aware management of the distributed virtual switchPermit per-flow timescale decisions to be made for control of traffic on any virtual portMulti-tenant aware & secure
Key items: Access control is exactly the same as firewall rules in a traditional switch. What’s different here is that the definition of a virtual switch becomes analagous to a stack which allows network admins to define rulesets which apply regardless of what the virtualization admin might change.
Key items:QoS with bursting
Key items: Doing port mirroring on a VM without DVS requires filtering traffic from other VMs. With DVS, a couple of clicks of a mouse and you’re done.
Key items: NetFlow is an industry standard for network monitoring, and DVS handles it out of the box. All you need to do is configure the collector address and you’re done.
Key items: Built in to the DVSC is a basic NetFlow collector and analyzer. Good for small installations, but can be disabled for larger enterprises.
Key items:DVS gives us jumbo framesDVS allows us to create private networks using management interfaces, and those private networks are secured using GRE. This means that there are no VLAN boundaries to worry abouthttp://en.wikipedia.org/wiki/Generic_Routing_Encapsulation
Key items: Restart used for most critical servicesRestart if possible used if restart desired, but application design will ensure continued operation in the event the service can’t be restarted. This option also provides additonal failure “head room”Non-agile VMs can not be guaranteed to restart
New in XenServer 5.6 - Dynamic Memory ControlMaximize investment in server hardwareSome configuration risk – VMs not guaranteed to bootCrashed VMs automatically placed on best fit serversRunning VMs could be "squeezed" to free up RAM
When dealing with resilient applications and HA, there is always the potential for creating single points of failure which the application deployment guide cautioned against. For example, if you have a SQL Server cluster made up of two nodes, if both of those nodes end up on the same host and that host fails, the resiliency of SQL Server won’t save you. Here’s how to avoid such situations in XenServer by using both HA and WLB.Define a host in WLB to not participate in optimization and rebalancing activitiesPlace one node of the SQL Server cluster on that host (node A)Place the second node of the SQL Server cluster on any other host (node B)Configure HA to protect the second node of the SQL Server cluster using “restart if possible”, but not the first nodeLet’s explore the various automatic failure modes:If the host excluded from WLB activities fails, node A fails and does not restart. Node B continues to operate with no downtimeIf a host running node B fails, node B will be restarted on any surviving host except for the host excluded by WLB. If the only host with capacity to start node B is the excluded host, then node B won’t be started, otherwise it will be restarted without breaking resiliency
Embed multiple VMs in a single management frameworkPackage is managed as an entity (e.g. backup)VM start order and delays contained in package
Says it all
Key items: When you overlay a file system on to manage VMs, there are inherent features that file system imposes, and those features might not be compatible with what a given storage array can offer. The core objective of StorageLink is to maximize the potential of a storage array without artificially imposing virtualization concepts upon it.
So without StorageLink, you end up asking the storage admins for a LUN, and that LUN ends up being a storage repository in XenServer provisioned as LVM. LVM storage repositories are block based primitives which have the virtual disks contained within them and while a VM is running, LVM effectively requires that virtual disk to be fully provisioned. Obviously as you add more an more disks, there will come a point when the LUN will be full, but the virtual disks themselves might not be fully used. The net result being that additional VM capacity requires a second storage repository which in turn requires a new LUN.
With StorageLink, StorageLink manages the array directly and provisions a LUN for each virtual disk. Since StorageLink has direct access to the array, it can provision the LUNs using key features such as thin-provisioning and thus make more efficient utilization of the array. This model is known as LUN per VDI
In addition to LUN provisioning, since StorageLink has direct access to the array, it also can levearge the array’s native APIs to perform snapshots and clones. Without StorageLink, those snapshots live within the provisioned “fat LUN” and will compete for storage space with the primary virtual disks. StorageLink effectively frees the snapshot mechanism to leverage the entire space from the array.
StorageLink uses an adapter based architecture where the XenServer host and control domain have a StorageLink Gateway Bridge into which the adapters plug. Legacy NetApp and Dell EQL adapters are still in the code, but mainly for users upgrading to XenServer 6 who are using the Legacy adapter today. New SRs created from XenCenter will use the new integrated SL adapter.iSL supports NetApp, Dell EqualLogic and EMC VNX arrays
The primary driving force behind SRIOV support is that with the advent of 10Gb ethernet, the existing PV driver model simply can’t sustain full throughput on these cards. So while 1Gb line rate is possible, dom0 saturation prevents 10Gb from attaining line rate.
Taking a bit of a step back, we see that the solution itself requires more than just SRIOV, but rahter a series of enhancements.Starting with VMDq we create separate RX and TX pairs for each VM:Device has multiple RX queuesDedicate one RX queue to a particular guestProgram device to demultiplex incoming packets to the dedicated queue using guest MAC addressPost RX descriptors pointing to guest memoryDevice places received packet directly into guest memory avoiding data copyWith direct IO (VTd) we now can map the IO directly into a guest VM and this allows for attainment of line rate on 10GbMoving past VTd, we have SRIOV which itself carves out virtual NICs from the physical NIC to form virtual functions. Each of the virtual functions can be mapped into a VM, but more importantly since each VM can itself be performing high levels of IO the line rates can be further extended. This is precisely how the NetScaler SDX can attain its high throuput using standard XenServer.
When looking at the key objectives of virtualization and hardware, you can see that direct hardware access has historically provided limited scalability due to the inability of most devices to natively share access. With SRIOV, this scalability limitation is largely overcome.
Of course, since you’re mapping a dedicated hardware resource to a VM you’ve now prevented it from participating in live migration. With XenServer 6 we’ve introduced experimental support for SolarFlare cards supporting SRIOV with live migration.By default the guest VM will use the “fast path” for network traffic, however a regular VIF backup path is available and the VM will fallback to this path during migration to a different host. If a Solarflare SR-IOV adapter is available on the target host, the guest will switch back to the “fast path” again after migration.