Troubleshooting Performance Issues in a Citrix Virtualized Environment

Troubleshooting Performance Issues in a Citrix Virtualized Environment
Welcome to our session “Troubleshooting Performance Issues in a Citrix Virtualized Environment”. My name is Dan Lazar and I am a lead escalation engineer for the XenServer support team. I will be presenting with Kappa Ramlal, a senior maintenance engineer for the XenDesktop support team. This session is intended to provide an overview of XenServer performance characteristics, as well as some tools and methods for identifying and troubleshooting XenServer performance problems. Please hold your questions for the end, or feel free to meet with me and Kappa after the presentation. Kapil Ramlal Sr. Software Maintenance Engineer Daniel Lazar Lead Escalation Engineer

Citrix Confidential - Do Not Distribute
Agenda XenServer Performance Overview Troubleshooting XenServer Performance Windows Application Architecture Primer Troubleshooting Virtual Machine Performance Citrix Performance VM Demo Q & A Here is an overview of what we’ll be covering. [Read slide] Citrix Confidential - Do Not Distribute

XenServer Performance Overview
Let’s begin. XenServer Performance Overview

XenServer is designed to do one thing… Performance is a function of “VM density” Citrix XenServer All hypervisors have VM density limitations XenServer is designed to do one thing [Reveal] Consolidate machine workloads. Therefore, when we talk about performance with XenServer, we are usually talking about ‘VM density’, or how many virtual machines can we run on a single XenServer host at the same time before we expose bottlenecks affecting VM runtime? It is important to remember that every hypervisor has limitations when it comes to VM density and as a XenServer administrator you need to understand and be aware of these limitations in order to properly plan, implement, support (and troubleshoot) a XenServer environment with realistic expectations about what can be achieved with the product. …Consolidate machine workloads Citrix Confidential - Do Not Distribute

How do we determine optimal VM density for a host? XenServer Hardware Infrastructure, such as network and storage Workload and sizing demands of the virtual machines Native XenServer characteristics So, how can we determine optimal VM density for a XenServer host? Almost as much art as science… Some variables constantly changing… [Read hardware] – host hardware limitations will affect VM density [Read infrastructure] – external components like the network and storage will also impact VM performance [Read] – Clearly the type of applications running and the number of users connecting to VMs will affect performance [Read] – And then there are native characteristics within the hypervisor itself which will also affect VM density First, let’s discuss how XenServer manages virtual machine workloads. Citrix Confidential - Do Not Distribute

Host Machine (Hardware)
Dom0 DomU DomU Toolstack App App App App Guest OS Guest OS netback netfront netfront Native Driver Looking at this diagram, we can see we have a physical machine capable of running XenServer. [Show Xen layer] -Add the Xen hypervisor when we install XenServer on the machine. -Runs on top of CentOS Linux -Augmented with processes and services to allow it to host virtual machines. [Reveal Next] Uses the concept of a ‘control domain’, or Dom0 Is itself a virtual machine that is “privileged” and brokers resources to virtual machines. Automatically starts when the XenServer machine boots. Has direct access to the host hardware using native Linux drivers installed with XenServer. - DomUs, or “unprivileged” guest domains are the user-created virtual machines that request resources from Dom0. - Gets created when we start a new virtual machine and runs alongside Dom0. To allow the guest VM to access hardware resources, Dom0 has a netback interface that communicates to a netfront interface within the guest OS. As we spin up VMs, additional DomUs get created and connect their netfront interfaces to Dom0 netback allowing them access to hardware resources. Finally, we have the xen toolstack, or XenAPI The group of services and processes that provide a means for managing Dom0 and making it aware of other XenServer objects such as storage repositories and network configurations. Looking at this diagram you can probably begin to see where we might develop some bottlenecks in virtual machine performance. Hardware can present some of these as it might not have enough memory or CPU resources to sustain all of the DomUs. Control domain—if it runs out of resources you can begin to imagine how that might affect the performance of the DomUs. We will talk more about this in a bit. Virtual machines themselves. Kappa is going to go into more detail about troubleshooting issues within the guest VMs later in the session. Xen Hypervisor Host Machine (Hardware)

External Factors Network Storage VM Workload and Sizing There are also external factors that will affect virtual machine performance. Network Just like bare metal, network can cause issues. Storage Can cause performance issues if connection lost to SR. iSCSI storage could actually be network-related. VMs The environment inside the guest OS needs to be tuned and optimized, as well. In the next section we will talk in more detail about troubleshooting internal and external components that affect performance. Citrix Confidential - Do Not Distribute

New in XenServer 5.6! In XenServer 5.6 we have introduced a new feature to assist with optimizing virtual machine density called Dynamic Memory Control. With previous versions of XenServer: Adjusting virtual memory was difficult and, You had to restart virtual machines to add or remove memory… In addition to tuning XenServer and Dom0 there are now additional options to achieve a greater virtual machine density. [Read slide] Citrix Confidential - Do Not Distribute

What is Dynamic Memory Control? With Dynamic Memory Control we can: Adjust virtual machine memory on-the-fly: Dynamically add memory Dynamically remove memory And, in many cases, no need to restart virtual machines (with some restrictions). It also allows us to start more virtual machines on a host that is already full! Citrix Confidential - Do Not Distribute

How can DMC help my virtual desktop environment? In virtual desktop environments without DMC: Memory allocation of a running virtual desktop is fixed. It is not possible to change memory without rebooting. Once the host memory is exhausted, we cannot start additional desktops. Administrators are left with a choice: Allocate larger amount of memory to each virtual desktop. This will increase virtual desktop performance, but decreases the number of users-per-host. As more users arrive, you might need more hosts. Allocate a smaller amount of memory to each virtual desktop. This will increase the number of users-per-host, but decrease virtual desktop performance. As users leave, memory is wasted. Citrix Confidential - Do Not Distribute

DMC frees you from making a fixed choice between: Host memory per virtual desktop Number-of-virtual-desktops per host Once configured, DMC can automatically manage the trade- off between these two quantities. For more information about DMC and how to try it out, visit the XenServer 5.6 Beta website: Citrix Confidential - Do Not Distribute

Troubleshooting XenServer Performance
Let’s talk a bit about how to identify and troubleshoot performance issues in XenServer Troubleshooting XenServer Performance

Domain 0 Memory Management
for Dom0 Dom0 Memory Pool Total XenServer Memory Pool (ex. 12GB) for DomU total Dom0 = memory required for n VMs 6 MB x n 352 MB 328 MB 400 MB 346 MB 752 MB 6 MB 6 MB 6 MB 6 MB + ( = Total DomU “footprint” for DomU ) for DomU Before we discuss troubleshooting performance issues in detail, let’s briefly talk about Domain 0 and how it allocates resources. Please note that the following is a guideline and that actual resource utilization will vary depending on the size and demands of the virtual machines. When a XenServer boots it reserves a fixed amount of RAM for Dom0, about 752MB. [Reveal] Dom0 takes about 400MB of that total memory for itself right off the bat, leaving around 352MB. Every time a VM start request is processed resources are reserved within Dom0 to execute that DomU—this we call the DomU “footprint”. The DomU footprint will vary in size depending on the workload demands of the VM, but an average footprint is around 6MB. As we spin up VMs the Dom0 memory pool decreases. So the total footprint of all the VMs would be approximately 6MB times n, where is n is the number of VMs. And finally, add to that the 400MB in use by Dom0 and we can define approximately how much total memory is required by Dom0 to host n virtual machines. This all works out to about 60 VMs per host, which might not seem like that many, but remember that this is just a guideline. The actual resource utilization will vary depending on VM resource demands. for DomU 752MB allows for about 60 VMs-per-host

What happens when we start more VMs than Dom0 has memory to manage? Slow VM performance, poor user experience. Slow response from XenAPI—takes longer to process tasks like starting, shutting down and migrating virtual machines. It can cause XenServer host instability resulting in unpredictable behavior and potentially crashing the XenServer host machine!! [Read point 1] [Reveal] Read slide Shortly we will discuss how to tune XenServer to allow us to avoid these potential issues. First, let’s briefly discuss how we can monitor XenServer resource consumption to give us an idea how much load a host is experiencing. Citrix Confidential - Do Not Distribute

There are two common ways to monitor performance in XenServer XenCenter Performance Tab XenServer Command Line Interface [Read point] [Reveal] The Performance tab in XenCenter, and, running scripts and commands in the XenServer Command Line Interface, or CLI. Citrix Confidential - Do Not Distribute

Using XenCenter Good for ‘at a glance’ monitoring Unwieldy for refined or customized performance testing Difficult to use for historical trending Data cannot be easily exported Some types of information not gathered. XenCenter is great to use for checking performance ‘at a glance’, but it has some limitations that make it difficult to use for troubleshooting performance problems. [Read all points] To overcome these limitations we can use the XenServer CLI to collect customized performance data. We will focus on how to do this in the next few slides. Citrix Confidential - Do Not Distribute

Performance monitoring commands # top # Provides a dynamic real-time view of a running system. Tasks: 68 total, 2 running, 65 sleeping, 0 stopped, 1 zombie Cpu(s): 13.0%us, 33.6%sy, 0.0%ni, 1.0%id, 52.5%wa, 0.0%hi, 0.0%si, 0.0%st Mem: k total, k used, k free, k buffers Swap: k total, k used, k free, k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND D :00.57 qemu-dm 4679 root m 16m 5308 S :47.85 xapi 5993 root S :24.73 stunnel 1264 root S :24.00 udevd 4641 root S :01.25 xenstored 4650 root S :00.05 blktapctrl 12722 root R :00.03 top There are some commands and scripts we can run that give us an idea of how well our XenServer environment is performing, and, whether we need to tune or optimize the configuration. The first command I will discuss is ‘top’. This is a native Linux command that provides a dynamic real-time view of a running system. [Reveal Output] Let’s discuss a few interesting data points in this output… [Reveal] Note that top reports about 400MB total memory for the system—I can tell you that the machine has a lot more RAM than that, 12GB total in fact. ‘top’ is only aware of the memory allocated by Dom0 since the rest is reserved for the virtual machines and is not made visible to the Linux kernel. If you notice the amount of free memory is very small it may indicate you are running out of resources in Dom0—this value should be compared with the total number of running virtual machines on the host to provide an indication if Dom0 is near or at its VM density limit. By default top lists the processes in order of CPU percentage utilization but the sort order can be changed if needed. In this example note the top two CPU hogs in the environment are a process called qemu-dm, and one called xapi. Xapi is the service that represents the xen toolstack. If Dom0 is busy processing tasks, such as starting, shutting down and migrating virtual machines, this process will consume more CPU cycles from the host. qemu-dm represents resource utilization by the DomU. When the guest virtual machine is requesting CPU resources the system will typically report higher utilization by its respective qemu process. If you see qemu-dm spiking the CPU resources it could indicate a process inside the guest OS that is hogging CPU and troubleshooting inside the guest environment may be required. Since top only recognizes resources that are available to Dom0, and it is unaware of XenServer-specific objects we will want to issue a different command to get a picture of what is actually being consumed by the virtual machines. Citrix Confidential - Do Not Distribute

Performance monitoring commands # xentop # Displays real-time information about a Xen system and domains. xentop - 17:24:33 Xen 3.3.1 4 domains: 1 running, 3 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown Mem: k total, k used, k free CPUs: 1600MHz NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS ... Domain r no limit n/a Win2K Win2K Win2K Xentop is a command that reports top-like output but it is aware of the XenServer hypervisor and therefore returns statistics relevant to Dom0 and running DomUs. [Reveal] Note in this output, unlike with top, xentop is aware of all available system memory and reports what is in use both by Dom0 and any running virtual machines. However, xentop does not look inside Dom0 at its resource utilization so it will always report the total amount allocated, about 400MB. Using both top and xentop together can provide a picture of total resources available to Dom0 if we compare the memory free from the top output with the number of running DomUs. Citrix Confidential - Do Not Distribute

What if I need to increase my VM-density-per-host? We can tune XenServer to increase VM density. In a scalability study conducted by Citrix to determine the maximum number of Windows XP virtual desktops per host for XenServer 5.5 running XenDesktop 4 we were able to host 130 VMs per host. So, using the resource monitoring commands we have discussed, what if we determine that we have reached the VM density limit for our XenServer host? [Read slide] Citrix Confidential - Do Not Distribute

This was achieved by making two key configuration changes to a default XenServer 5.5 installation. Increased the amount of RAM assigned to Dom0 to 2.94GB from the default 752MB; increasing it enabled us to launch more desktop clients. Increased the “Xen-heap” setting to take into account the large number of VMs on this single server host. This was done by adding "xenheap_megabytes=24" to the Xen command-line in /boot/extlinux.conf which resulted in an increase from the default of 16MB to 24MB. [Read slide] Citrix Confidential - Do Not Distribute

Additional Information Both the scalability study and instructions for increasing Dom0 memory limits are documented in the Citrix Knowledge Center here: - XenServer Single Server Scalability with XenDesktop - Adjusting Dom0 and Xenheap Setting in XenServer [Read slide] [Reveal] [Read tip] Disclaimer: Your results may vary! This testing was done on very high-end equipment using Citrix best practices! Citrix Confidential - Do Not Distribute

Troubleshooting commands - Storage # iostat # Reports basic I/O stats for devices and partitions # hdparm # Performs timed sequential reads # dd # Simple, common block device copy utility Three useful CLI commands for monitoring storage performance in XenServer are iostat, hdparm and dd. These commands will report on I/O throughput giving an indication of overall storage performance. In the case of iostat it will report on average disk throughput over time. In the case of hdparm and dd they will perform active benchmarking of I/O throughput via timed disk reads and writes. [Reveal] [Read tip] TIP: iSCSI storage throughput can usually be tied directly to network performance. If there is slow throughput for an iSCSI storage array, perform network diagnostics first!! Citrix Confidential - Do Not Distribute

Troubleshooting commands - Network # tcpdump # Dumps traffic on a network - detailed instructions for using tcpdump. # netstat # Display network interface statistics # ifconfig # Display and configure network interfaces XenServer also has some CLI tools that can be used to monitor and troubleshoot network performance. Tcpdump will dump all packets on a specified network interface. The output can be filtered and/or redirected to an output file and opened in a trace analysis tool, like Wireshark, for detailed analysis. Refer to CTX for detailed instructions on using tcpdump with XenServer. Netstat can be useful for verifying whether network interfaces are active and functional. It will tell you which ports are listening or have established connections, it can list the routing tables on the host and can also troubleshoot incoming and outgoing packet errors. Ifconfig can be used to validate and potentially reconfigure individual network interfaces. It will tell you if a NIC is connected or disconnected, what speed and duplex is established, basic transmit and receive statistics and a host of other information relating to the network interfaces. [Reveal] [Read tip] TIP: You can always type ‘man’ followed by a Linux command name (i.e., ‘man netstat’) to get detailed help for the command. Citrix Confidential - Do Not Distribute

Running Shell Scripts Can capture customized data sets Can be run over defined periods of time Can be formatted specifically for reporting purposes. Requires knowledge of Linux and shell scripting languages. Executing CLI commands is a great way to get real-time data for troubleshooting performance issues as they are occurring, but sometimes it is necessary to collect data over time to gain a picture of overall performance. Using shell scripts, along with the commands we have already discussed, is an effective way to get detailed, accurate and customized performance data for a running host or even an entire pool. [Read slide] (A shell script…) Citrix Confidential - Do Not Distribute

Additional Information On the Citrix Knowledge Center you can find shell script examples, procedures and best practices for how to troubleshoot all aspects of a XenServer environment. Some useful links to troubleshooting articles: [Read point 1] Now I am going to hand the presentation over to Kappa who is going to talk about how to troubleshoot performance issues from within a virtual machine. Citrix Confidential - Do Not Distribute

Windows Application Architecture Primer
Being able to effectively isolate, diagnose and resolve critical VM performance issues rely on an understanding of how Microsoft Windows and applications work. When we talk about performance, we are not typically concerned with how to configure an application or component, but instead we are more concerned about what the application or component is doing at the time of a problem. We don’t need to be programmers, nor do we need to memorize the internals of Windows, but knowing some basics about how applications interact with the Operating System helps when debugging performance problems. Let’s dive into some basic application architecture, and then we will discuss how to debug some common performance problems on Windows. Windows Application Architecture Primer

A process, in the simplest terms, is an executing program.
So, what does this mean? - Microsoft (2010) Citrix Confidential - Do Not Distribute

Application Basics An application consists of one or more processes
Each process provides the resources needed to execute a program One or more threads run in the context of the process Each process is started with a single thread, often called the primary thread, but can create additional threads An application consists of one or more processes. A process, in the simplest terms, is an executing program. One or more threads run in the context of the process. Each process provides the resources needed to execute a program. A process has a virtual address space, executable code, open handles to system objects, a security context, a unique process identifier, environment variables, a priority class, minimum and maximum working set sizes, and at least one thread of execution. Each process is started with a single thread, often called the primary thread, but can create additional threads from any of its threads. References:

Application Basics A thread is the basic unit to which the operating system allocates processor time Threads carry out the work of a process All threads of a process share its virtual address space and system resources Uses stack-based storage for handling data What is a Thread? A thread is the basic unit to which the operating system allocates processor time. A thread can execute any part of the process code, including parts currently being executed by another thread. Microsoft Windows supports preemptive multitasking, which creates the effect of simultaneous execution of multiple threads from multiple processes. On a multiprocessor computer, the system can simultaneously execute as many threads as there are processors on the computer. References:

Application Basics What is the Stack?
Thread Stack Frame 0 Frame 1 Frame 2 Frame 3 What is the Stack? It’s temporary memory used by threads It’s used to store function’s parameters and Local variables Local Variables Saved Frame pointer Return Address Function Parameters Frame Pointer

Citrix Confidential - Do Not Distribute
A closer look Let’s take a quick look using process explorer, at some of the core components of a process. We’ll also see how a process relies on its primary thread to remain alive and healthy. Citrix Confidential - Do Not Distribute

Application Basics User & Kernel Space Applications run in User Mode
The Windows operating system can be conceptually divided into 2 parts: User Space (User Mode) Kernel Space (Kernel Mode) Applications run in User Mode System drivers run in Kernel Mode (Privileged Mode) Reference: Windows® Internals, Fifth Edition

USER SPACE USER MODE KERNEL SPACE rusb2w2k.sys keyboard.sys win32k.sys
APPLICATION USER APPLICATION USER MODE USER APPLICATION USER APPLICATION USER APPLICATION KERNEL SPACE Applications typically run in user space, and system drivers run in kernel space. Each process in user space runs in its own protected memory space. Processes will not tamper with other processes memory, and if a process encounters an exception, only it will be affected, while other instances will be unaffected. Unlike in the kernel where the operating system code and drivers share the kernel memory space, if a driver encounters a problem, the entire system will be affected. rusb2w2k.sys keyboard.sys win32k.sys tcpip.sys […]

Troubleshooting Virtual Machine Performance
Now that we’ve covered some basic application architecture, let’s take a look at some troubleshooting techniques for performance related problems Troubleshooting Virtual Machine Performance

Troubleshooting Virtual Machine Performance
Common performance related issues inside the VM: High CPU Disk/registry contention High network utilization Memory

ProcessExplorer can be used for live stack-trace viewing!
High CPU Identify offending Thread (s) Identify the top function call and its module Capture user memory dump of offending process for analysis Engage respective application vendor Caused by one or more threads that “hog” the CPU’s time Typically related to threads stuck in an infinite loop, or expensive mathematical operations which can be very CPU intensive In addition, calls that require frequent access to and from the kernel also takes up quite a bit of CPU cycles – so repeated calls to get Operating System information might generate high CPU if not throttled correctly The Offenders? Any thread on the system, from any process on the system, can be guilty This means that any process on the system, from any application, can potentially cause this issue Systematically monitoring and tracking the usage can help reveal the culprit Finding the CPU hog Isolate the offending process Use the TaskManager, sort by CPU time, view the process consuming the most time Isolate offending thread inside offending process Microsoft’s ProcessExplorer utility can be used to view the threads in a process The thread consuming most CPU time usually shows at the top of the display output Note the hexadecimal (or decimal) thread identifier View the stack, and see if anything obvious stands out at the top (this would usually be the offending function call) Capture a memory dump of the offending process for detailed analysis It is typically better to capture a few dumps in succession Analyze the thread consuming most CPU time View the calling functions and inspect for loop conditions and expensive CPU operations ProcessExplorer can be used for live stack-trace viewing!

The Windows Performance Tools
Next generation performance monitoring from Microsoft Track CPU usage, application start times, boot issues etc. Identify common performance problems without a debugger Included with Windows 7 SDK Download ~Snip: Windows Performance Tools are designed for analysis of a wide range of performance problems including application start times, boot issues, deferred procedure calls and interrupt activity (DPCs and ISRs), system responsiveness issues, application resource usage, and interrupt storms. What Makes These Tools Possible? Performance Analyzer is built on top of the Event Tracing for Windows (ETW) infrastructure. ETW enables Windows and applications to efficiently generate events, which can be enabled and disabled at any time without requiring system or process restarts. ETW collects requested kernel events and saves them to one or more files referred to as "trace files" or "traces." These kernel events provide extensive details about the operation of the system. Some of the most important and useful kernel events available for capture and analysis are context switches, interrupts, deferred procedure calls, process and thread creation and destruction, disk I/Os, hard faults, processor P-State transitions, and registry operations, though there are many others. One of the great features of ETW, supported in WPT, is the support of symbol decoding, sample profiling, and capture of call stacks on kernel events. These features provide very rich and detailed views into the system operation. WPT also supports automated perf testing. Specifically, xperf is designed for scripting from the command line and can be employed in automated performance gating infrastructures (it is the core of Windows PerfGates). xperf can also dump the trace data to an ANSI text file, which allows you to write your own trace processing tools that can look for performance problems and regressions from previous tests.

The Windows Performance Tools: Case Study
ISSUE: High CPU on wfica32.exe Methodology Compare a 30-second sample of activity and compare to non-working ICA, working ICA and working RDP Image taken from Microsoft Blog:

ICA test run where problem occurred Notice that on this dual processor machine – 1 processor is frequently at or very close to 100%. Looking inside the above testing to see which instructions were being executed the most during the test – was wfica32.exe. Image taken from Microsoft Blog:

Drilling into the calls of wfica32.exe, lead to the Windows function NtUserSetCursor() which results in calls to the igdkmd32.sys driver and then into the kernel – specifically the memcpy() function. Image taken from Microsoft Blog:

Memory Dump Collection
User dumps contain a snapshot of a process’ memory Kernel dumps contain a snapshot of kernel memory space A complete memory dump contains both the kernel and the entire user space Just like user and kernel space, there are user and kernel memory dumps

User Dump Collection Configure a default post-mortem debugger:
How to Set the NT Symbolic Debugger as a Default Windows Postmortem Debugger (CTX105888) How to Set WinDbg as a Default Windows Postmortem Debugger (CTX107528) Use Task Manager for manual dumps Old news, Dr.Watson is no longer available on Vista+ systems… To catch application crashes, configure a default post-mortem debugger of your choice.

System Dump Collection
To enable a complete memory dump using the registry: Set the CrashDumpEnabled value to 1 HKLM\System\CurrentControlSet\Control\CrashControl System Dump Collection Small Memory Dump Generally we avoid Kernel Memory Dump System crash Complete Memory Dump System unresponsive Great article: ~Snip: if you have a system with more than 2GB of RAM, the option for a complete memory dump is not available in the GUI drop down as you can see from this image. This behavior is described in Microsoft KB Article It is possible to enable a complete memory dump by modifying the CrashDumpEnabled value in the HKLM\System\CurrentControlSet\Control\CrashControl registry key to 1. Note that this will still not show the option for a complete memory dump in the GUI. If you need a complete memory dump for troubleshooting specific issues, then you may want to consider using the MAXMEM switch in the boot.ini file on 32-bit systems to limit the amount of RAM in use by the Operating System to 2GB or less (see Microsoft KB Article for details). This will then display the option for a complete memory dump. In addition, this will allow the dump file to be created quicker, and reduce the amount of downtime. This is ideal for troubleshooting scenarios - not for long-term usage - as you are limiting the RAM available to the system. Control Panel -> System->Advanced Tab -> Startup and Recovery

System Dump Collection
Windows 7 introduced the Dedicated Dump Drive setting Allows a pagefile to be configured on a dedicated drive for dump capture Recommended to debug VM’s streamed through PVS How to Recover Windows Kernel Level Dump Files from Provisioned Target (CTX123642) Citrix Confidential - Do Not Distribute

Demo: Citrix XenServer Performance VM
Some of you might be curious if Citrix has any specialized methods of isolating performance issues between host and VM. The Citrix Technical Support Team has developed a performance VM, codenamed “Storm VM”, that can help isolate performance issues on a XenServer host, which compares the metrics again Demo: Citrix XenServer Performance VM

That’s all folks! Q & A

TechEdge Survey, Video Postings & PPTs
The TechEdge survey will be ed out to end-user customers If you complete the survey, you will be entered to win a $250 Amazon gift card. The winner will be announced June 1st. View TechEdge videos & PPTs on the Knowledge Center by Monday, May17th

Troubleshooting Performance Issues in a Citrix Virtualized Environment

Similar presentations

Presentation on theme: "Troubleshooting Performance Issues in a Citrix Virtualized Environment"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Troubleshooting Performance Issues in a Citrix Virtualized Environment

Similar presentations

Presentation on theme: "Troubleshooting Performance Issues in a Citrix Virtualized Environment"— Presentation transcript:

Similar presentations

About project

Feedback