Tag Archives: pvs

Virtual Desktops in the Classroom


I got a great question into the Ask the Architect email bag that I thought it would be great to share and potentially create a good discussion. Let’s say you are in a classroom setting where students are only in the class for 4 weeks and then after those 4 weeks, you need to reset all desktops back to a base image. Before desktop virtualization, you could use Ghost or other tools. But could we use desktop virtualization for this? Does it make sense?

As this environment is already using the local, physical desktops, I’m assuming the desktops have adequate resources, so let’s continue to use them by using the Streamed VHD FlexCast model. For those unfamiliar with Streamed VHD, I’ve provided a very rough drawing

Because the desktops have enough resources, we want to use those for computing power, thus reducing the need to buy a lot of servers in the data center. All we need is a Provisioning Services server. The classroom image (1 per classroom or 1 for all classrooms) will be streamed across the network to each physical desktop.

The unique thing with this use case is that students need to be able to modify the desktops and then when the 4 weeks class ends, those modifications are thrown away. With Provisioning Services, you simply use the Differential Disks, which will store the changes (write cache or delta disk) on the Provisioning Services server. So the PVS server will be holding the differential disks for all of the classroom desktops.

When the 4 week class is over, you simply remove the differencing disks and the desktops reset to the base state, ready for a new class. Pretty slick.

What do you need to make this work?

  1. One or two PVS servers (for redundancy) with enough storage to hold the disk image and the differential disks. You will want these disks to be fast as well to reduce latency
  2. At least 100Mbps switched to each endpoint
  3. Endpoints that are similar in hardware configuration (the more identical they are, the easier this will be)
  4. Network boot capabilities on the desktops and configured within the environment (DHCP, PXE, TFTP)

Note: If you want to see how to configure the difference disk or to see it in action, take a look at this CitrixTV Video.

Daniel – Lead Architect
XD Design Handbook

Advertisements

Streamed VHD


I was recently asked a question about how we can still utilize endpoint hardware computing power when doing desktop virtualization. If doing a hosted VM-based virtual desktop, you can do the client-side rendering of flash and other multimedia activities, but there is another option that most people forget about… Streamed VHD. You simply turn that endpoint into a virtual desktop. Did you know you could do this? Honestly, I was happy when I got this question. Too many people forget about the Streamed VHD option and it solves so many of the Hosted VM-Based challenges like IOPS, storage, server costs, server footprint, scalability, etc. I think we should be talking about this option more as I think it is a great alternative for a large number of users.

But let’s get to the details. XenDesktop includes a feature called Provisioning Services. Most people think of this to deliver a desktop image to virtual machines, or even a XenApp image to a virtual machine. But guess what? You can also stream to bare metal hardware (desktop or server hardware). And that hardware doesn’t have to be locked up in the data center. It can be sitting under your desk. All we need is a network. That means you effectively turn your endpoint into a virtual desktop. BTW, this is what is known as Streamed VHD; at least that is what it is called within Citrix’s FlexCast model.

So let’s say you decided to go with Streamed VHD instead of the hosted VM-based desktop model (VDI), what do you need to think about?

  • Desktop Image: One of the beauties about using Provisioning Services to stream to a VM is that each VM is identical from a hardware perspective. The hardware differences are hidden due because of the hypervisor. However, when streaming to a physical endpoint, this is not the case. Your desktop image must contain all of the drivers for the endpoint.     This doesn’t seem like a big deal until you start looking at little nuances across 500 different physical endpoints, especially if there were not purchased at the same time. This doesn’t’ necessarily mean you have to now have 500 images. There is a thing called common image, which allows you to use one image and deliver it to multiple hardware types (assuming the chipset is the same). Honestly, I would only do common image to similar hardware profiles, as it will make things much easier. If you try to create one image for all of your Intel-based desktops, you will have an image with hundreds or thousands of different audio, video, network, etc drivers. Can become quite difficult to manage.
  • Network Connectivity: Streamed VHD requires a network connection. In fact, it requires a fairly fast network connection. How fast? 100 Mbps switched at least. Remember, to boot up Windows 7, you will need to send roughly 200MB across the wire. If you have a slow network link, that 200 MB will take longer, thus adding a perceived slowness to the solution. The faster your network, the more responsive the desktop will seem.
  • Network Stability: Even if you have a fast network, if it isn’t stable, you will notice. Streamed VHD is Just In Time, meaning that Provisioning Services only sends what the endpoint needs at that instant. If you are dropping packets, you will have slowness as the data is retransmitted.
  • Write Cache: The write cache should be stored on the endpoints physical drives. That way we reduce the impact on the network and improve performance.
  • User Data: Just like with Hosted VM-Based pooled desktops, a streamed VHD is often done in a read-only fashion where any changes are deleted upon reboot. That means you need good profile/data practices. User’s application settings should be stored on a network drive. All user data should be stored on a network drive.

This isn’t a complete list of what to look out for when doing Streamed VHD, but it is a start. One thing should look familiar; many of the recommendations mimic those of a Hosted VM-based desktop or a hosted shared desktop model. You are able to re-use the same design principles regardless of the type of virtual desktop you decide to implement. So it isn’t like we have to learn a whole set of new design best practices, we just have to apply them to a different type of virtual desktop.

Hope this helps

Daniel – Lead Architect
XenDesktop Design Handbook

PVS or MCS – What’s Your Decision Going to Be


Note: This blog is in reference to Citrix XenDesktop 5.0 ONLY.

Note: The following link contains the  latest discussion between PVS and MCS (https://virtualfeller.com/2016/05/17/pvs-vs-mcs-part-1-resource-delivery-options/)

The decision between using Provisioning Services or Machine Creation Services is based on many things, with a few being discussed previously:

  1. Big Picture
  2. Operations
  3. Resource Requirements

Let’s say you’ve gone through these discussions and are still trying to determine what approach you should take. Personally, I like to use decision trees, like the following:

By answering these questions, you will get a better idea of what is most appropriate:

  1. Hosted VDI Desktops Only: Larger enterprise environments are often more complex, in terms of end user requirements. The complex user requirements cannot be completely met with Hosted VDI desktops, which require the organization to expand into different options. Using Provisioning Services for these architectures is recommended due to the ability to deliver images more than Hosted VDI desktops.
  2. Dedicated VDI Desktops: If there is a user requirement for dedicated desktops, there is an increased recommendation to use Machine Creation Services or to use installed images.
  3. Large Boot/Logon Storms: Boot and logon storms create massive IO activity on the storage infrastructure, requiring greater levels of IOPS. For larger deployments with a large boot/logon storm, Provisioning Services is recommended due to IOPS savings.
  4. Blade PCs: Certain users require the performance of a Blade PC, while still secure within the data center. Because Blade PCs are standalone hardware devices, Machine Creation Services cannot be used.
  5. SAN: Provisioning Services has the flexibility to work with and without a SAN infrastructure. However, Machine Creation Services becomes more challenging without a shared storage infrastructure, like a SAN. If a shared storage solution is not in scope or is too costly for the environment, Provisioning Services is a better option.
  6. Change Control Processes: Maintaining Provisioning Services desktop images requires proper processes depending on the type of update required (hotfix versus network driver update). Smaller environments will most likely not have processes in place. Maintaining a Machine Creation Services image is often seen as easier.

What did you come up with? Surprised? Or is it what you expected? If you want the full breakdown on deciding between the two options, then please refer to the recently released version of the “Planning Guide: Desktop Image Delivery” which was recently added to the XenDesktop Design Handbook.

If you are new to the handbook, then I suggest you read about it from Thomas’s blog discussing how to get the handbook for offline use.

Daniel – Lead Architect
XenDesktop Design Handbook

PVS or MCS – We Talking About IOPS Again


Deciding between PVS and MCS is a tough decision for many organizations. Although MCS is limited in that it can only do virtual machines, it does appear to be easier to setup than PVS. In fact, MCS just works while PVS requires another server and configuration of bootstrap processes like TFTP/PXE. So it sounds like we should be using MCS for everything. Right? Not so fast. We need to look at the resource requirements, beyond servers, as this might negate the benefit of easier setup/configuration.

If you’ve gone through the other two discussions so far, we focused on the Big Picture of your environment and the operational model. This time, we are focusing on resource requirements.

First, we know that using PVS will require, at least, 2 additional servers (remember I’m including fault tolerance). MCS doesn’t require any extra hardware besides the hypervisor. Now let’s look at storage requirements, and with storage I’m talking about IOPS, our favorite topic.

If you look at PVS, we do all reads from one location and do all of our writes on another location. Because of this, we can optimize the systems. We know that on the PVS server, we allocate enough RAM so the reads happen in RAM and not disk, thus greatly reducing read IOPS.

MCS is different. The reads and writes happen on the same storage. This is a big deal. Look at the graph below.

We know that during desktop startup, we have a huge amount of read IOPS, during logon, it is evenly split, and during the steady state (working), the ratio moves towards writes. Most people are concerned with the boot and logon storms. Because these are more read intensive, you would think that PVS would be the better option for large boot/logon storms as we cache the vDisk in PVS RAM. This line of thinking is correct.

Now before people say, “Hey, my SAN can cache”. You are correct. Of course there are SAN caching solutions, but these cost money. With PVS, it is just part of the Windows operating system. Because of this, we can see a MCS implementation generating more IOPS than a PVS implementation. How much more? I’ve seen as much as 1.5X more IOPS. For deployments with 50 desktops, this might not be a big deal, but what if you are talking about 20,000 desktops?

Some might be thinking about using XenServer IntelliCache to bring these more inline. This has a potential to help lower MCS IOPS requirements, but the products aren’t integrated yet, so I’ve got no data points to share.

But regardless, you need to take the resource requirements into consideration before making your PVS/MCS decision.

Daniel – Lead Architect
XenDesktop Design Handbook

Provisioning Services or Machine Creation Services… Big Picture Matters


Note: this is the first part in a multi-part discussion on PVS and MCS

Since XenDesktop 5 came out, one of the biggest questions flying around is, “Should I use Provisioning Services (PVS) or Machine Creation Services (MCS)?” Both options work and both options provide single image management, but what is the right answer?  Is it shocking that this question is the wrong question to ask?

What you should be asking is “What is my desktop virtualization solution going to look like?” Are we only doing Hosted VDI desktops? Do we need Local VMs? Are Hosted Shared Desktops in the mix? (Note: look at the Citrix FlexCast site for a description of each option). Each organization’s desktop transformation roadmap plays an important role in picking the right option. The following diagram was taken from the XenDesktop 5 Reference Architecture, which can be found in the XenDesktop Design Handbook.

One thing you should be able to see is that if you select Machine Creation Services, you can only do the Hosted VDI desktop model on a hypervisor (XenServer, Hyper-V or vSphere) in the data center ONLY. That means no Blade PCs. It means no Hosted Shared Desktops. It means no streamed VHDs. If this is your roadmap, then Machine Creation Services is still a viable option, but the decision cannot be made yet. You still need to look at a few other considerations like SAN requirements, storm impacts, imaging team expertise, etc. before you can make a proper decision, which will be discussed in future blogs.

But what if your design calls for some of these other FlexCast options? Then Provisioning Services will definitely play a major role. However, there still might be a need for a mixed imaging solution based on a few other decision factors. For example, what if you need a desktop where users have complete control of the desktop to install applications or make operating system-level changes that are not captured in profile management tools? I can still do Existing, Physical, Dedicated and Streamed desktops. However, would you use PVS for this (streamed desktops)? It does work, but you probably won’t go with this option. In my experience, using a private desktop model with Provisioning Services is not efficient. It requires complete copies of the base image, configured for private (read/write) mode. You still have to manage these images in a 1:1 fashion (or use an enterprise desktop management tool). You are essentially adding too many layers where other options might be a better fit.

Why not use an Existing, Physical or Dedicated desktop, which relies on either installed images or MCS? If I go with installed images, I need to either install them one-by-one or use cloning solutions like SysPrep. If I use MCS, unique identities are built into the solution. MCS makes the deployment easier than the Existing or Physical desktop model, but they both work. What does this all mean? If you use multiple FlexCast options with private desktops, you will end up using [PVS + (MCS or Installed)]

You don’t want to focus on which technology to use, you want to focus on the overall architecture, which will help guide your decision. But the decision is based on more than the big picture. You need to stay tuned for more on this topic as this isn’t the end yet. We still need to dive deeper into the Hosted VDI Desktop model only scenario to align our business requirements with the appropriate solution.

Daniel – Lead Architect
XenDesktop Design Handbook