In yesterday’s post, we talked about the problem with input/output delay on virtualized desktops, though to be fair, we only really talked about one type of virtualized desktop solution. That is, we talked about the challenges associated with server-side desktop virtualization, where the OS runs on the server and the end-user essentially sits at the end of a dumb terminal.
There is another method, called client-side desktop virtualization where the entire OS is downloaded over the network onto the hard drive (or RAM disc) of the client computer, where input and output are localized to the client computer, which means that you don’t get any added latency to the input and output.
However, this type of setup has its own problems. First, downloading an entire OS at once is likely to create bursts of traffic and spikes of high Internet activity. Specifically, what do you think is going to happen when everybody turns on the computer and logs in at 8:30? Or logs out at 5?
This method might be more applicable for work-from-home telecommuters, who can access the “work computer” from home during work hours, and log-off to use the “family computer” at night. There you run into a last-mile problem – will broadband be sufficient to download the OS each morning, and – more importantly, considering most personal broadband is asynchronous – be able to upload the OS each evening?
Now, none of these criticisms of virtualization – either form – should in any way constitute a criticism of the technology. We hope that someday, we’ll be able to realize the full benefits of virtualized desktops without network performance degradation. But do consider the impact of virtualized desktops on your network when considering whether they’re feasible.
No comments yet.