Take your virtual desktops with you: XenClient makes XenDesktop mobile

4,295 views

Published on

Local virtual desktops, a key component of XenDesktop FlexCast delivery technology, are the perfect solution
to the offline challenge of today’s desktop virtualisation solutions. XenClient, the innovative, type-1 client
hypervisor, makes it all happen – increased performance, security and flexibility – while allowing your users
to be mobile. In this session you’ll learn technical considerations and best practices for local virtual desktops.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,295
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
130
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • By 2014 72% of endpoints sold will be laptops. Last year for the first time the major PC OEMs sold more laptops then desktops. Laptops are being used throughout corporations by more than just road warriors.
  • XenClient extends the reach of desktop virtualization to laptop users who have a requirement to be able to work from anywhere at any time, with or without an internet connection. With the addition of XenClient, customers can now extend the benefits of desktop virtualization to the last mile of users
  • Security policies. IT often see laptops as a necessary evil. Users demand flexibility, they have to be out on the road, executives want to be able to work from anywhere. In our research with XenClient we’ve gathered a great deal of feedback that tells us that if IT didn’t have to provide laptops, they probably wouldn’t! Laptops may rarely connect to the corporate network making data hard to backup and patches difficult to distribute. Machines can be lost, stolen or infected by Malware comprimising critical corproate data.
  • XenClient is unique in that it can deliver the security and control IT is looking for while at the same time providing freedom and flexiblity to the users.
  • The first use case to talk about is when running XenClient standalone. We are seeing a lot of IT pros adopting XenClient to run multiple isolated Windows virtual machines on a single device. IT, Test, and Development staff want to run their corporate image along with a development image and multiple test environments. We see people who want to run a corporate provided environment alongside their own personal environment even when their company does not officially provide such a program. We also see XenClient being adopted in high security environments where people want to run multiple domains of security on the same device. Previously each of these scenarios would require multiple physical systems or adoption older type II technology that provides a poor user experience along with poor security and isolation.
  • When using XenClient within a larger deployment it allows extending the benefits of Desktop virtualization to highly mobile users. This so called “last mile” of users that don’t always have a network connection. They require the ability to run their virtual machines off the network. It allows IT to deploy a highly locked down corporate image that reduces the cost of managing a laptop while at the same time providing a second person environment that gives users more flexibility. And finally XenClient allows backing up the user changes on the laptop and even enabling the users to recover their environments without IT involvement.
  • When we talk about XenClient it’s really the virtualization technology. This is the same Xen virtualization technology that we have been using for 5+ years with XenServer or datacenter class server virtualization platform. One of the great benefits of the Xen virtualization technology is that is allows VM to be hardware independent so you can deploy a single image to any number of different systems. You can easily move people to new hardware and recover to any type of system that can run XenClient.
  • XenClient has a novel ServiceVM architecture that allows a small VM to provide a shared or unique service to the platform or the VMs running on top. An example is providing a virus scanner ServiceVM. In this case you don’t need to run a virus scanner in each VM so you reduce duplicated code and reduce impact to the overall system during virusscanning activities. Additionally by moving the virus scanner outside the operating system it becomes much more secure as attacks within Windows can’t touch the virus scanner enginer.
  • To prove out the architecture we actually have a serviceVM that ships with XenClient. It’s called the Citrix Receiver for XenClient. It allows you to create and manage VMs plus it will connected to the datacenter to download, secure, and backup virtual machines. Additionally it will enforce policies set on the backend locally.
  • The synchronizer for XenClient sits in the datacenter and allows centralized deliver of VM images to a large number of XenClient systems. It not only delivers a VM but can back it up as well. And it provides policy controls such as blocking USB devices or even sending a remote kill signal to disable a managed VM.
  • XenClient was designed to run in a standalone mode on a laptop. This allows IT pros to try the technology without needing to deploy the backend. The process to install XenClient is very simple. Just download an ISO from the Citrix website and burn to a CD. Then boot from that CD and install XenCLient. Remember XenClient runs on the bare metal so you will replace whatever currently exists on the system with XenClient. Then you can use a simple wizard to create Windows VMs from the Windows install CDs or DVDs.
  • XenClient is based on the award winning Xen hypervisor. If you were to see a system booting up and could view all the boot messages you would see that right after the hardware comes up and the BIOS messages pass then the Xen hypervisor would load up on the system. Xen is really small, in fact its only 60-70k lines of code. Xen’s job is to cut up the hardware resources on the system and provide them to the virtual machines on top.At this point if you kept watching you would see what looks like a Linux system booting which we call the control domain. What actually is happening is we boot a tiny privileged Linux VM that runs our agent and also hosts drivers that drive the underlying hardware. At this point you would then load up one of more user VMs running Windows.
  • XenClient is based on the award winning Xen hypervisor. If you were to see a system booting up and could view all the boot messages you would see that right after the hardware comes up and the BIOS messages pass then the Xen hypervisor would load up on the system. Xen is really small, in fact its only 60-70k lines of code. Xen’s job is to cut up the hardware resources on the system and provide them to the virtual machines on top.At this point if you kept watching you would see what looks like a Linux system booting which we call the control domain. What actually is happening is we boot a tiny privileged Linux VM that runs our agent and also hosts drivers that drive the underlying hardware. At this point you would then load up one of more user VMs running Windows.
  • XenClient has a secure application sharing capability. This allows you to display applications running in one VM inside another VM. So you could then have personal applications and business applications coming from two separate VMs on the same display. We do this in a secure manner such that you can’t copy and paste or move data between the two VMs but you get a nice user experience of running all the applications on the same display.
  • When paired with the Synchronizer for XenClient you have a powerful solution that allows extending the benefits of virtual desktops to mobile users. Just as XenClient is easy to install so is the Synchronizer for XenClient. It is delivered as a virtual appliance that runs on XenServer. So in only about 10 minutes you can be up and running. You then upload a VM from an existing XenClient system. Assign it to some users and they can then login and download the VMs to other XenClient systems.
  • The communication between the Synchronizer and XenClient was designed to securely run over the public internet. It uses a Single https port for all traffic and the client will always initiate the connection which allows a XenClient system to be behind routers, nat, proxies, and other network infrastructure.The Synchronizer provides an easy to use web administrative interface. It allows the use of a local users and groups database for lab and poc environments and for larger deployment can source user and group information from an active directory.
  • Virtual disk drives on XenClient are stored in the standard Microsoft virtual hard disk format. This enables thin provisioning of virtual disks and with the snapshot capability provided with XenClient allows capture of only the block level changes a user is making to a VM image. Data transferred from the XenClient is always compressed using client side CPU cycles. It is then left compressed on the backend to save disk space. If a transfer is interrupted it will automatically resume where it left off.
  • Citrix provides a wan acceleration system call the branch repeater. This provides fan out infrastructure for the Synchronizer. We did some testing and simulated a 12MB connection with 100ms latency and some packet loss. We did a download over this link of a Windows 7 image which took 2 hours. When the branch repeater was added that transfer time dropped to 1 hour a 50% reduction. Then the next XenClient that did a download only took 3 minutes since the local branch repeater had cached the entire image.
  • This is getting at the fact that you can do the shared desktop thing or do dedicated desktops. If you do the dedicated desktops then you would use traditional ESD tools or manual process to manage the thing. But even just moving this “business as usual” ie what they do today on physical systems onto XenClient still provides a great deal of value including the ability to run different environments, encryption of data, data movement policies, and can make recovery easier as well.
  • For a static image IT would create an image on the backend with the OS, patches, and apps. This gets delivered as a VHD file to the client. The first time the user starts up the VM it will create a small second VHD file that will store any changes the user makes on the system or changes made by an electronic software distribution tool. The second VHD file with the changes is periodically compressed and then sent to the Synchronizer for backups. Over time you would end up with a large number of these VHD change files so we automatically collasc or merge the files together to increase performance and decrease disk space used.
  • We have another image mode called dynamic image mode. This allows you to layer the VM image. So you have an OS layer, an application layer, and a user profile layer. Each is independent and can be managed separately. At runtime XenClient will automatically assemble the layers into a single virtual machine. This technology allows Synchronizer to deploy image updates and even roll-back an image to a prior version. Additionally it allows for minimal data backup as we only backup the user profile layer. The other data already exists in the datacenter.
  • Under the covers this is implemented as three different VHD chains or think of it as 3 virtual hard disks. One for each layer. The Base OS is delivered from the backend and admins can “crack open” the image on the server to make updates. Those updates are then sent as block level differences down to the client. To roll forward to a new version of the image or even roll-back just requires the user to reboot the image. The user has the freedom to customize their application layer using Citrix XenApp or AppV packages which are stored in the virtualized app disk. And finally the users data and preferences are stored in a third disk which is then backed up to the Synchronizer to allow for recovery.
  • For both image types the Synchronizer is able to backup the changes on the client. The data is always compressed which saves space and bandwidth. Users are actually able to recover their backups by themselves with a self-service facility. This saves a great deal of IT time as they don’t need to get involved for user data recovery.
  • XenClient has a number of powerful features to ensure corporate data is secured as it runs on the laptop. Any image deployed from the Synchronizer is given a limited lease. This allows the VM to run disconnected for a period of time such as 3 days. If the system does not talk to the backend after 3 days the VM will be locked. This protects VMs on laptops that are lost or stolen but not reconnected to a network. If the system is reconnected to the network a kill pill can disable the VM immediately. To protect the data on the system VMs deployed from the Synchronizer can be protected with AES-XTS data encryption and when running on a system with an Intel Core vPro i5 or i7 processor the system will use AES-NI encryption support in the CPU to accelerate encryption operations. Finally data protection policies allow restriction of data from moving off the system. You can block USB devices, access to optical drives, networking, audio hardware and more.
  • Take your virtual desktops with you: XenClient makes XenDesktop mobile

    1. 1. Take your virtual desktops with you: XenClient makes Virtual Desktops mobile<br />Craig Hinchliffe Lead Systems Engineer<br />Citrix Systems<br />
    2. 2. Overview<br />Use Cases<br />Solution Components<br />XenClient<br />Synchronizer for XenClient<br />Agenda<br />
    3. 3. 72%<br />end-points will be laptops by 2014<br />Source: Gartner Dataquest<br />
    4. 4. Citrix XenDesktopFlexCast delivery technology<br />Enterprise Laptopusers<br />Taskworkers<br />USER TYPES<br />Hosted VDI<br />Streamed<br />VHD<br />Hosted Shared<br />Local<br />VM<br />Runs locally<br />Enables disconnected use<br />5000+ users per server<br />High Security<br />125 users per server<br />Allows Personalization<br />500 users per server<br />Users Share Common Desktop<br />Client-side compute<br />Server-side compute<br />
    5. 5. IT faces challenges supporting laptop users<br />Corporate data “walks out of the office”<br />Security policies compromised due to personal use<br />Backup policies difficult to enforce<br />Long recovery times when devices fail<br />Personalization leads to support calls<br />
    6. 6. Laptop users need flexibility<br />IT needs better security & control of corporate laptops<br />
    7. 7. Use Cases<br />
    8. 8. Multiple desktops on a single device<br />Run multiple roles - each in their own secure operating system<br />System admin, test, and user<br />Test and development<br />Business and personal<br />Multiple security domains<br />Multi-system demos<br />
    9. 9. Extending XenDesktop to the last mile of users<br />Control for IT, Flexibility for Users<br />Fast deployment of new VM’s to employees or contractors<br />Self service recovery to any XenClient device<br />Secure corporate data<br />Desktop Virtualization for corporate Laptops<br />
    10. 10. Solution Components<br />
    11. 11. <ul><li>Type 1 hypervisor: High performance because it runs on bare metal
    12. 12. Built on 64-bit open source Xen technology
    13. 13. Runs multiple virtual desktops simultaneously
    14. 14. Completely secure isolation for each VM
    15. 15. Hardware independent VMs
    16. 16. Service VM Architecture for extensibility</li></ul>What is XenClient technology?<br />Local <br />VM<br />Desktop <br />Local <br />VM<br />Desktop <br />Citrix XenClient<br />X86 Hardware<br />
    17. 17. <ul><li>Service VMs add shared or unique functionality to Local VM Desktops
    18. 18. End user interaction
    19. 19. Advanced security
    20. 20. VPN connectivity
    21. 21. Network acceleration
    22. 22. Built on XenClient API set
    23. 23. Service VM SDK – coming in 2011</li></ul>XenClient Service VM Architecture<br />ServiceVM<br />Local <br />VM<br />Desktop <br />Local <br />VM<br />Desktop <br />Citrix XenClient<br />X86 Hardware<br />
    24. 24. <ul><li>First Service VM for XenClient
    25. 25. Simple wizard to create VMs locally
    26. 26. Easy switching between VMs with Switcher Bar
    27. 27. Connector for centralized synchronization of desktops
    28. 28. Self-service provisioning and recovery
    29. 29. Enforcement of local policy and kill pill</li></ul>Citrix Receiver for XenClient<br />Citrix Receiver for XenClient<br />Local <br />VM<br />Desktop <br />Local <br />VM<br />Desktop <br />Citrix XenClient<br />X86 Hardware<br />
    30. 30. Synchronizer for XenClient<br />Copy of Local VMs<br />Citrix Receiver for XenClient<br />Local <br />VM<br />Desktop <br />Local <br />VM<br />Desktop <br />Automatic<br />Synchronizer for XenClient<br />Δsync<br />Citrix XenClient<br />X86 Hardware<br /><ul><li>Centralized delivery of virtual desktops
    31. 31. Full-time backup & rapid recovery
    32. 32. Remote kill & local policy controls</li></li></ul><li>XenClient<br />
    33. 33. XenClient runs standalone<br />Run local VM desktops<br />Receiver for XenClient create VM wizard<br />Download & burn installation CD<br />Install XenClient<br />FREE!<br />Run one or multiple VM desktops simultaneously<br />Supports Windows XP, Vista & 7.<br />Compatible with selected laptops & desktops<br />Available at citrix.com<br />
    34. 34. XenClient Architecture<br /><ul><li>Thin Xen hypervisor
    35. 35. Shared with XenServer
    36. 36. Linux Control Domain
    37. 37. Device Drivers
    38. 38. Receiver for XenClient
    39. 39. User Interface</li></ul>Windows VM<br />Windows VM<br />ServiceVM<br />Control Domain<br />Xen Hypervisor<br />Audio<br />GPU<br />USB<br />x86 Hardware<br />Disk<br />Net<br />AMT<br />
    40. 40. Flexible Virtualization Architecture<br /><ul><li>Virtualize physical hardware
    41. 41. Virtualized Disk, Network, USB, Graphics and more
    42. 42. Selective pass-through
    43. 43. Graphics Processor
    44. 44. Intel AMT
    45. 45. Mix and match</li></ul>Windows VM<br />Windows VM<br />ServiceVM<br />Control Domain<br />Xen Hypervisor<br />Audio<br />GPU<br />USB<br />x86 Hardware<br />Disk<br />Net<br />AMT<br />
    46. 46. SpeedStep<br />Dynamic CPU clock scaling based on system loads <br />Virtual Battery<br />Reflects physical battery data into the virtual machines<br />Sleep<br />Suspends VM(s) and puts device into S3 state, works on lid close<br />Hibernate<br />Hibernates VM(s) and puts device into S4 state<br />Shutdown/Restart<br />Graceful operation that shuts down running VM(s)<br />Power Management<br />
    47. 47. Secure Application Sharing<br /><ul><li>Execute app in secure VM
    48. 48. Seamless display in a less secure VM
    49. 49. Great user experience with total isolation</li></ul>XenClient Hypervisor<br />
    50. 50. Synchronizer for XenClient<br />
    51. 51. End to end solution with Synchronizer<br />Download VM Synchronizer Appliance<br />Synchronize <br />Virtual Desktop<br />Existing Virtual Desktop<br />Self-Service Download via Citrix Receiver for XenClient<br />Publish to Users<br />FREE!<br />Available at citrix.com<br />Created with Citrix Receiver VM wizard<br />
    52. 52. Synchronizer for XenClient<br />Synchronizer Architecture<br />Active Directory<br />HTTPS<br />Citrix XenServer<br /><ul><li>Single port client initiated HTTPS connection
    53. 53. Web based admin interface
    54. 54. Local or AD linked authentication</li></li></ul><li>Synchronizer<br />Efficient and Robust Data Transfer<br />VHD<br />VHD<br />VHD<br /><ul><li>Virtual Disks are VHD files
    55. 55. Block level differencing using VHD
    56. 56. Compressed during upload process (client side)
    57. 57. Left compressed on the backend
    58. 58. Block level restart on interrupted downloads</li></li></ul><li>Synchronizer<br />Branch Repeater loves XenClient<br />VHD<br />VHD<br />VHD<br />Repeater<br /><ul><li>Provides fan-out infrastructure
    59. 59. 50% reduction in initial download times
    60. 60. Once cached locally next client takes minutes to download</li></li></ul><li>Supports existing desktops tools and process<br />Apps<br />Patches<br />System Image<br />(OS + Apps+ Patch)<br />XenClient<br />XenClient<br />Initial Deployment<br />Ongoing Management<br />
    61. 61. Under the Covers<br />Deployment and Backup<br />Synchronizer<br /><ul><li>VHD Files Represent Virtual Disks
    62. 62. Initial Image Delivered from backend
    63. 63. OS + Apps + Patches
    64. 64. Mixed in Single VHD Chain
    65. 65. Updates via ESD Tools
    66. 66. New changes go into a VHD snapshot
    67. 67. Backup of snapshots to the datacenter
    68. 68. Snapshots can be taken while VM is on
    69. 69. Don’t need to backup initial image
    70. 70. Background coalescing to merge older snapshots
    71. 71. VHD snapshots are compressed before sending</li></ul>Virtual Disk<br />Base<br />OS + Apps + Patches + User Data<br />Snap<br />Snap<br />
    72. 72. Deploy and manage desktops from a Single Image * <br />User Profile<br />XenClient<br />Apps<br />XenClient<br />Desktop OS<br />Initial Deployment via Image<br />Ongoing Management from Image<br /><ul><li>Manage Updates via the Image
    73. 73. Easy Rollback
    74. 74. Smart Delta Updates
    75. 75. User Settings and Data Backed Up</li></ul>* Experimental<br />Citrix Confidential - Do Not Distribute<br />
    76. 76. Under the Covers<br />Shared Image/Layered<br /><ul><li>Initial Image Delivered from backend
    77. 77. OS + Apps + Patches
    78. 78. Deliver Empty Virtualized App Disk
    79. 79. Deliver Empty User Data Disk
    80. 80. Updates of OS + Apps + Patches from backend as VHD snaps
    81. 81. Only User Data Disk and Virtualized App Disk Persisted Across Reboots
    82. 82. Snapshots for Backup of User Data Changes
    83. 83. Don’t need the base disk, updates, or virtualized Apps</li></ul>Backend<br />Base Disk<br />OS + Apps + Patches<br />Virtualized App Disk<br />User Data <br />Disk<br />Update<br />Update<br />Snap<br />Snap<br />
    84. 84. User Settings<br />User Settings<br />Backup to Datacenter<br /><ul><li> User settings and data backed up to the datacenter
    85. 85. Smart delta update with compression
    86. 86. Backups left compressed in the datacenter
    87. 87. Self-service restore to existing or new system</li></ul>Backup corporate data and user settings<br />
    88. 88. Security policy/protection in the platform <br />Centralized Security Policies<br /><ul><li>Data movement policy
    89. 89. USB, Audio, Optical, Networking
    90. 90. Lease policies for corporate images
    91. 91. Kill pill to disable VMs on stolen devices
    92. 92. Disk encryption with AES-XTS 256</li></li></ul><li>Talk to a V-Alliance partner at IP Expo today<br />

    ×