In a previous article, I described the new capabilities in streaming app to use VHD 6.5 mounted to implement the layer cake on XenDesktop. These are great things for the image of the operating system that separates the image of the application and greatly helps administrator managing IT systems in a virtualized world XenDesktop + pool. Some comments in the previous article and similar requests from the sales and customer channels engineer wonder if the same "montage" of the execution content is possible within a XenApp world. This is an interesting question as it deserves its own post.
First let's back up and talk about why editing application images is necessary and specifically why editing is more efficient than copying data in the execution machine. Given the XenDesktop implementation is based on a virtual machine and the machine as "resets" virtual to baseline at each login, copy RadeCache data in the execution machine while running is an expensive operation which occurs at each logon. It would fill the space, but the copies would have to repeat each time the user connects to the hosted desktop.
A more efficient method declares disk writes "evil" and uses VHD Mount to place the contents of the execution of streaming in the execution machine as reoriented READS. The disk accesses RadeCache is reflected in the mounted VHD, effectively moving disk IRPS C: to the network stack. It also significantly reduces the number of disk writes that all cache operations for the streaming content will already be "current", saving the reading of the App Hub and writing on the local disk C:. There is a cost that the network read operations are likely slower than the bed SAN disk, but the bet is that the elimination of entries well worth the costs of moving to a network disk reader infrastructure based slower .
The technology exists now and comes with the 6.5 client for streaming to enable the mounting of execution of content for XenDesktop performance. Here is a graph which shows this visually.
In the comments of the previous post, Serge de Klerk request
does anyone know if the .vhd assembly would work on Win03 XenApp servers?
There is a very valid question and one that I have received from some sources. The rapid and official answer is "no, this feature is only for XenDesktop virtualized execution." The long answer is' yes, but you have to do some manual steps. " The answer is that it is possible that it works now, although we did not expect it.
As a quick introduction, why use up performance for XenApp servers. The answer is that many XenApp administrators now demanding the execution of the virtualized machine and "layer cake" to their construction XenApp servers in the same way that it is used for XenDesktop. The same need exists in both places. In version 6.5, we have decided to resolve the XenDestkop but XenApp administrators go back and saying "HEY! We need this as "In XenApp however, there is one more thing to worry about -.. There are multiple users per machine
VHD Mounts dissected
a VHD file is mounted in a subdirectory of a Windows-based computer. Here, it looks like a book, but from the perspective of the Windows machine, it is a mount point and watching a local physical disk. this disc is "valid" for backing store to load .EXE and execution.
from the perspective of the network server the VHD file is just a file. a file like any other file and file that is great and maybe a lot of reading occurring and precisely written zero, but in the end it is just a file. a user opens the file and the file is accessed.
the streaming system called HDV device driver installation to connect a disk volume to a mount point with a given VHD file located on a network location accessible UNC. In the case of Windows 7, the VHD driver is the Microsoft driver included with Windows. In the case of Windows XP, the streaming client uses Citrix who did the same. A side note is that the Citrix streaming group "liberated" the pilot of Citrix Provisioning Services so we were able to avoid writing from scratch. When can we stop supporting Windows XP?
This is how it looks in RadeCache space with the output of a DIR command.
The question is, will work with XenApp? Or is it simply a XenDesktop functionality
Okay? - About to post
Consider for a moment that when the App streaming system mounted VHD, the local machine gets a junction point which is effectively the same as a letter reader. The remote machine (network server) has access to files from the machine and more specifically, the USER.
The streaming system to mount the VHD "borrows" the user's ability to get to the network server as data in the access to the VHD.
SO, it will work on XenApp? The answer is usually "no", but here it becomes quite interesting.
Consider a XenApp server with 100 users ...
- User A logs on to the XenApp server and performs the continuous application.
- User B logs on to the XenApp server and executes the streaming application
- of Lather rinse and repeat until you get all the 100 users on the machine.
A user logs off. This is the user whose access rights were borrowed for the streaming system could ride the run streaming content from the App Hub. What happens to users B and more?
theory of the base operating system says that when user A disconnects, the privilege of access to the network server and vaporizes the VHD mount point becomes invalid.
I went to tell people "it will not work" for months now and I even think about possible solutions to this problem.
where things get unexpected
In writing this post, I make a few experiments. My experiences say it "works", while my knowledge undoubtedly strong internal operating Windows said he should not.
Using my Windows 7 64-bit laptop as a test platform, I led the "1, 2, 3" above experiment. As expected, when the user runs an application A continuously running streaming cache is present for all other users of the machine. Where I became surprised is that when the user logs A, mount the VHD points are still there! This is something I've yet "known" would not work. So confident that this will not work there has never been a test value, but sit down and test ... and the execution content is always present. Hum
Update (31-Oct-11) :. The answer seems to be that the kernel-mode driver duplicates the handle user mode by creating a kernel object that points to the same file. When the user logs off, the reference in user mode for decrements of file objects, but the core of the reference stays in place, keeping the file open in view of the execution machine. What is interesting is that I expected the network server client to force close all the user's files when the user logs off. This seems not to occur and allows the kernel driver to continue with successful access to files even when the user has left.
Going back to the question of Serge
> Does anyone know if the assembly. VHD could run on XenApp Win03 servers?
Never assume
My experience was above on Windows 7 64-bit. This implies that all my previous statements that this will not work are not true. But that is incomplete.
I was told people that will not work because of the assumptions I have about how the VHD files are installed in Windows. The reality is that it does not work the way I understood it. It seems that the VHD Windows device driver "clings" to the open file handle to the network server, and wishes to handle this after the user disconnects. In other words, the user who triggered the first VHD mounting need not always be connected to the VHD driver to keep things accessed the first user assisted the pilot to access. Interesting!
multiple endings
Like a good novel, this blog seems to have multiple endings. I had planned to end this post with using the XenApp administrator if the streaming system can not keep up the VHD alive, you can administrator. Create mount points outside the scope of the App streaming and the system will have these "directories" already present at the execution. The streaming system supports "magic" for how to mount points have been created and if they exist, it will use to run the streamed content. This is by design and planned. This means that if the administrator takes steps to create a mount point, as the mount point will be used. The VHD will be mounted continuous work content on XenApp although when we decided to build the 6.5 version, we were really only targeting XenDesktop virtualized execution.
The reality of the end is that you can either work today despite never really being intended to be. It will take a series of tests on additional platforms to show off. In the question registered on the blog earlier, Serge asked about XenApp Server 03. Note that there are many things that are different here than in test 1 hour, I have done for this blog. Server 03 uses the VHD Citrix driver, not the Microsoft. I'll assume for a moment that VHD driver is installed when the Streaming Client 6.5 is installed on top of Server 03, but even this is not a valid assumption. Second assumption is that the OS server version behaves the same as the client version. In other words, on Server 08 (32, 64), Server 08 R2 and other flavors, will mount points remain as they show themselves to do it on my Windows 7 64-bit machine? I do not know the answer. Given the surprising results already here, making assumptions is a good idea
Update (31-Oct-11) :. Variety of people have reported to me that the case offline Server 03 is also managed and Server 08 R0.
wrapping
The official answer is that Citrix has never wanted the VHD mounting feature in the 6.5 Client Flow be used on XenApp servers. We do not expect that officially it works.
The official response is less than if the VHD media persist, then it should work. And I will do my best to help you succeed ...
Anyone who wants to volunteer for the tests and report the results?
Joe North
architect application streaming product and Profile Manager
Citrix Systems
0 Komentar