Client Machine .JPG to VM - Shrinking

[DB1213141516]

We are currently working on a POC to virtualize our company's desktops. Currently the application resides on the workstation, and we have a feature in place within the app to shrink the image size through .Net Framework APIs before uploading to save the user from, say, a 4 MB upload and instead make it a 120 KB upload.

I'm sure other companies have run into this problem before, but I'm not sure what they are doing about it. Is there anything provided with the VMWare client that would allow the user to transfer, say, a 4 MB image, and shrink the size down to say 120 KB to tranfer it across to their virtual machine? Our application cannot do it if the app is going to be running on the VM now. If not, any ideas on what other companies are doing?

[eeg3]

What happens if you run the application on the VM? Why will it not work there? Are you virtualizing your desktops with View or are you referring to application-level virtualization?

[DB1213141516]

We are virtualizing the desktop with View.

The issue isn't with shrinking the images once they reach the virtual desktop, the issue is that previously the app ran on their machine, so we were able to shrink it on their machine before running it across the wire. Now, their machine has nothing, so getting the image across to the VM to shrink it within the app will require running the entire image across the wire. What are other companies doing about this?

[AWo]

I still don't understand this.

You're going to virtualize a desktop where an application is running which shrinks the image. Where is the difference if that desktop is virtualized as long as the shrinking is done by software. The user will work with a remote desktop on the virtualized desktop....

AWo

VCP 3 & 4

\[:o]===\[o:]

=Would you like to have this posting as a ringtone on your cell phone?=

=Send "Posting" to 911 for only $999999,99!=

[DB1213141516]

Ok - so old scenario - each machine has the software that shrinks the image before saving to the database in the central office here. So, only 120 KB comes across the wire to the office to save to the DB.

New Scenario - each machine has no software, and the software resides in the central office (inside the Virtual Desktop). In order for the software to even see the image, the full 4 MB image needs to be sent across the wire to the VM.

We are dealing with some very low bandwidth offices, and the difference between 120 KB and 4 MB could be about 1 hour difference per image. In this case, once the image is here, there's really not much of a need to shrink it any more, as the Database and the VM server reside in the same LAN. However, the need to shrink is getting it from the (low bandwidth) office physical machine to the central office (VM) so that the software can see it.

[AWo]

Regardless of what yopu use, physical or virtual, you need to shrink it in the branch office before you move it to the central DB. So regardless of the decision to virtualize your desktops or not, as long as the data is created in the branch (and not on the virtualized desktops in the central office) you need to shrink it there. If the data can be created on the virtual desktops, which are running in the central location, you do not need to shrink them at all, as say do not leave the central location.

But if the line is so small, do you think it is a good idea to virtualize the branch office desktops? Maybe it is better to keep them as full desktops in the branch so you do not need additional bandwith (beside the data transfer) for the session traffic.

AWo

VCP 3 & 4

\[:o]===\[o:]

=Would you like to have this posting as a ringtone on your cell phone?=

=Send "Posting" to 911 for only $999999,99!=

[DB1213141516]

Well, that wasn't the answer I was looking for, lol.

We were actually expecting that this would typically improve our users' experience from a low-bandwidth location; aside from this single issue. We are expecting that the latency and bandwidth should almost always be good enough to display the Virtual Desktop image. If you picture this like a Remote Desktop Connection - it will display the image ok on a dial-up (or low-bandwidth DSL) connection, but any kind of large data trasfer into or out of the machine will take an extremely long time.

Our application also transfers a significant amount of data at various times. So, the experience within the app (from the VD) will improve greatly as the data transfer within the app (from the VD now running in the LAN) will now be local data transfer instead of across the wire.

I can guarantee this setup is not atypical of other companies moving to a VD strategy. They have low/high bandwidth offices, low/high latency offices, and mixes of the two. I'm just trying to figure out what others are doing to resolve this? Are they just verbally communicating to the users how to shrink .jpg images or to expect a delay for this; or run it during off-hours to avoid up to a 1 hour delay when working with a customer? Are they providing a web plugin to shrink the image locally? Is there any VMWare product that can help us here?

[eeg3]

You could put your VD infrastructure in the same location as your images that way the transfer from your image location to the virtual desktop is local. Your users would then connect in to their virtual desktops over the slow link and have the picture streamed to them with the benefits PCoIP bring.

That is, assuming you're using View (same would apply with HDX/XenDesktop, as well). Are you using just regular RDP to virtual machines?

[DB1213141516]

We can test this in our POC to see if it is feasible, but I suspect even over PCoIP the rest of the app (and things like our GPO and application distribution) will likely not perform, and we'll end up being better off with even just verbally communicating how to shrink images.

I'd like to assume the structure described in the previous posts. Is there anything else that can be done with this structure in place to reduce the amount of data going across the wire?

[AWo]

I don't know how the good or bad it would be over your line. I don't know your line speed and how much guests will run over that one. But how could that be better than the local desktop (except you use such old desktops like we do )

It's worth a try and as you said, it is a POC....

The local transfer speed between your central database and the application in the virtual desktop will be better, of course. How is the data generated in the branch and how do you get this into the virtual desktop (compressed or not...)?

AWo

VCP 3 & 4

\[:o]===\[o:]

=Would you like to have this posting as a ringtone on your cell phone?=

=Send "Posting" to 911 for only $999999,99!=

[DB1213141516]

From the app's perspective, running it on a VM where all of our app servers, DBs, IIS Servers, etc. reside is magnitudes better than running it on their personal desktops, as we can see the timings for our service calls from remote offices can take up to 10Xs longer than from here internally. There is a lot of reliance on internet/network connectivity within the application itself. So, if the connection is stable enough for them to virtually display the desktop (and the app) from their location, it should give them a much better user experience than they have today. There are obviously other applications that will run much better on their local machine, but our main internal application is definitely not one of them.

The image data is typically off of a digital camera. Our users are not the most computer-savvy users on the planet, so they have a hard time shrinking images themselves (hence the need to do it automatically in the app). Also, as part of the POC, we want to be able to work on an iPad. Ideally we will have one solution to the problem for all users, but it's seeming like that's not going to be possible.

[eeg3]

VMware View has an iPad client in the works. Wyse PocketCloud works on iPhone, iPad, iPod Touch, and Android.

____________

blog.eeg3.net | Useful VMware-related Links

If you found this or any other post helpful, please consider the use of the Helpful/Correct buttons to award points.

[AWo]

If the data comes from a camera I assume it would be coinnected to whatever PC via a USB stick. Connecting it to the virtual desktop via USB would meacn you have to transfer the whole data across you line.

If you still use local desktops as the display device for the virtual desktops, install the shrink software on the local desktop, connect the camera to that one, download the images, shrink them and either use the RDP function to connect local drives or a network share to copy the smaller files to the virtual desktop.

AWo

VCP 3 & 4

\[:o]===\[o:]

=Would you like to have this posting as a ringtone on your cell phone?=

=Send "Posting" to 911 for only $999999,99!=

[DB1213141516]

Well, I'm marking this as answered; although I think the answer was "no". It sounds like there is no way to avoid either distributing an app to each of the users' machines or transferring the entire file across the wire. I had hoped there would be an accelerator built-in to the View clients or something that would help in this scenario.