That’s right! Native, pure, unadulterated Kitkat on the Dell Venue 8, today! When I saw the update was 350MB, it could only mean one thing. :-) I must admit that 4.4.2 coming this soon is a huge surprise, especially considering Cyanogenmod doesn’t even have a stable KK build for my Galaxy S3 yet. If you’re in the market for a solid 8” Android tablet with zero bloat or extra (ugly) skins, the Dell Venue 8 can’t be beat at $180. Yeah I work for Dell, but trust me this thing is awesome. All the reasons we normally root our Samsung phones and tablets don’t exist here (getting rid of bloat/ ugly skins)… it’s native Android!! I don’t have root and frankly don’t care at all…

Before:
After:


My only complaint at this point is the navigation buttons still being in the middle. I would much prefer these were together on the far left side.

Rumors on the future of Google Voice (gVoice) have been abound for well over a year now, with most indications pointing to an eventual consolidation with the G+ Hangouts app, that could be announced at Google I/O soon. As of yesterday 5/15/14, the long awaited closing of the gVoice API (XMPP) to 3rd parties has happened or soon will in the next few days. snrb Labs, creators of Android VOIP stalwart app GrooVe IP, has been warning about this shift for a long time and as of yesterday no longer supports gVoice users. GrooVe IP formerly integrated with the gVoice service via XMPP allowing users to make outbound voice calls over cellular data plans or wifi service using gVoice phone numbers, thus conserving cellular minutes. This is appealing for obvious reasons and delivers on the core value proposition of VOIP. There is also the slightly more complicated SIP client method that requires a bit more setup and has more moving parts on the backend. Any XMPP integration is now dead there too, however.

gVoice has had a good run

Despite the ability to make free calls over VOIP via 3rd-party app integration, gVoice in its current state has a host of other useful features, albeit mostly for inbound calls.

• Cellular voicemail integration/ replacement – in my phone, instead of using Verizon for vmail service, gVoice captures the messages which are then (somewhat poorly) transcripted to text and emailed to me along with a flash audio file. I can play any message from my phone via the voice app, via email or /voice site on any PC. No dialing into a legacy central voicemail service to get messages.

• Multi-ring – gVoice allows users to specify multiple end points to route incoming calls. I could have my cell, my wife’s cell and the house phone all ring when anyone calls my gVoice number.

• Call screening/ blocking – gVoice provides a great buffer and allows you to obfuscate your “real” phone number. Any caller that comes in via my gVoice number must first announce themselves, then I have the option to accept the call, send them straight to vmail, or listen to them live while they leave a message and pick up during if I choose. Just like old-school answering machine screening. You can also permanently block any caller that comes in via the service through a few creative means (not in service message).

• SMS consolidation – gVoice supports in/outbound text messaging too which comes with the same benefits as voice calls in that they show up on your phone and in email. With gmail integration, you can simply reply to a gVoice text message from email and the recipient will get the text message on their device.
• Caller Rules – Another great feature of gVoice allows users to specify calling rules based on the caller profile. If they’re in your contacts list you could: ring all phones, use a personal greeting and don’t screen. If anonymous: ring only mobile, use a generic greeting and screen. Lots of options and customizable possibilities here.

This is the end

Is the end near for gVoice? I certainly hope not, as outbound VOIP calling was far from one of the most useful features I enjoy. Google is an advertising company, first and foremost, and people forget that. Yes they are extremely profitable and lead some of the best innovation of the day, but you have to consider why Google invests in the technology it does. gVoice came out before Google’s speech-to-text initiative, which clearly benefitted from the work done and data collected in gVoice. It was possibly why gVoice was created in the first place! Google invests in technologies to bolster its core search business or related offerings. Once that pipeline runs dry it might kill the initiative or integrate it into something else. gVoice fed the core search business helping to bring voice to that space, which is now a core feature in Android fed Google searches (“Ok, Google”). gVoice has served its purpose for Google. The lack of development effort or improvement to gVoice is pretty glaring at this point. The last update to the Android app was almost 8 months ago and google.com/voice hasn’t changed in a very long time.

Google is still betting big on Google+ and the more it can do to attract and retain users in that ecosphere the better. I use Hangouts on my Android devices but I’m still one of the early Google adopter hold-outs who still does not have a G+ profile. I’ll hold out as long as I can but Google is trying very hard to close the loop and slowly force everyone into G+. At some point, if you want to be social at all in any capacity in the Google universe, you will have to have a G+ profile. Why? Laser focused and relevant advertising based on a wide spectrum view of all of your data. Period. The data Google amasses on its users is extremely valuable to advertisers.

So, what is next?

The future of gVoice and its current features is uncertain. A voice-enabled Hangouts app seems inevitable and a logical step for Google to make. Will most of the features I currently use in gVoice disappear at some point? Probably. With XMPP access gone, apps like GrooVe IP have had to find other means to provide their services. GrooVe IP has partnered with ring.to (backed by bandwidth.com) to carry this torch forward. This will require porting your gVoice number to ring.to or generating a new number via GrooVe IP. SMS is not currently supported with the new solution which is a bummer, but GrooVe says it’s coming. The good news is that you can still make free calls using VOIP on your Android device using your gVoice number if you wish. The bad news is that all of the gVoice integration goodness is gone and it will take the 3rd parties a while to get their solutions up to par.

Peter Fine here from Dell CCC Solution Engineering, where we just finished an extensive refresh for our XenApp recommendation within the Dell Wyse Datacenter for Citrix solution architecture.  Although not called “XenApp” in XenDesktop versions 7 and 7.1 of the product, the name has returned officially for version 7.5. XenApp is still architecturally linked to XenDesktop from a management infrastructure perspective but can also be deployed as a standalone architecture from a compute perspective. The best part of all now is flexibility. Start with XenApp or start with XenDesktop then seamlessly integrate the other at a later time with no disruption to your environment. All XenApp really is now, is a Windows Server OS running the Citrix Virtual Delivery Agent (VDA). That’s it! XenDesktop on the other hand = a Windows desktop OS running the VDA.

Architecture

The logical architecture depicted below displays the relationship with the two use cases outlined in red. All of the infrastructure that controls the brokering, licensing, etc is the same between them. This simplification of architecture comes as a result of XenApp shifting from the legacy Independent Management Architecture (IMA) to XenDesktop’s Flexcast Management Architecture (FMA). It just makes sense and we are very happy to see Citrix make this move. You can read more about the individual service components of XenDesktop/ XenApp here.

Expanding the architectural view to include the physical and communication elements, XenApp fits quite nicely with XenDesktop and compliments any VDI deployment. For simplicity, I recommend using compute hosts dedicated to XenApp and XenDesktop, respectively, for simpler scaling and sizing. Below you can see the physical management and compute hosts on the far left side with each of their respective components considered within. Management will remain the same regardless of what type of compute host you ultimately deploy but there are several different deployment options. Tier 1 and tier 2 storage are comprehended the same way when XenApp is in play, which can make use of local or shared disk depending on your requirements. XenApp also integrates nicely with PVS which can be used for deployment and easy scale out scenarios.  I have another post queued up for PVS sizing in XenDesktop.

From a stack view perspective, XenApp fits seamlessly into an existing XenDesktop architecture or can be deployed into a dedicated stack. Below is a view of a Dell Wyse Datacenter stack tailored for XenApp running on either vSphere or Hyper-v using local disks for Tier 1. XenDesktop slips easily into the compute layer here with our optimized host configuration. Be mindful of the upper scale utilizing a single management stack as 10K users and above is generally considered very large for a single farm. The important point to note is that the network, mgmt and storage layers are completely interchangeable between XenDesktop and XenApp. Only the host config in the compute layer changes slightly for XenApp enabled hosts based on our optimized configuration.

Use Cases

There are a number of use cases for XenApp which ultimately relies on Windows Server’s RDSH role (terminal services). The age-old and most obvious use case is for hosted shared sessions, i.e. many users logging into and sharing the same Windows Server instance via RDP. This is useful for managing access to legacy apps, providing a remote access/ VPN alternative, or controlling access to an environment through which can only be accessed via the XenApp servers. The next step up naturally extends to application virtualization where instead of multiple users being presented with and working from a full desktop, they simply launch the applications they need to use from another device. These virtualized apps, of course, consume a full shared session on the backend even though the user only interacts with a single application. Either scenario can now be deployed easily via Delivery Groups in Citrix Studio.

XenApp also compliments full XenDesktop VDI through the use of application off-load. It is entirely viable to load every application a user might need within their desktop VM, but this comes at a performance and management cost. Every VDI user on a given compute host will have a percentage of allocated resources consumed by running these applications which all have to be kept up to date and patched unless part of the base image. Leveraging XenApp with XenDesktop provides the ability to off-load applications and their loads from the VDI sessions to the XenApp hosts. Let XenApp absorb those burdens for the applications that make sense. Now instead of running MS Office in every VM, run it from XenApp and publish it to your VDI users. Patch it in one place, shrink your gold images for XenDesktop and free up resources for other more intensive non-XenApp friendly apps you really need to run locally. Best of all, your users won’t be able to tell the difference!

Optimization

We performed a number of tests to identify the optimal configuration for XenApp. There are a number of ways to go here: physical, virtual, or PVS streamed to physical/ virtual using a variety of caching options. There are also a number of ways in which XenApp can be optimized. Citrix wrote a very good blog article covering many of these optimization options, of which most we confirmed. The one outlier turned out to be NUMA where we really didn’t see much difference with it turned on or off. We ran through the following test scenarios using the core DWD architecture with LoginVSI light and medium workloads for both vSphere and Hyper-V:

• Virtual XenApp server optimization on both vSphere and Hyper-V to discover the right mix of vCPUs, oversubscription, RAM and total number of VMs per host
• Physical Windows 2012 R2 host running XenApp
• The performance impact and benefit of NUMA enabled to keep the RAM accessed by a CPU local to its adjacent DIMM bank.
• The performance impact of various provisioning mechanisms for VMs: MCS, PVS write cache to disk, PVS write cache to RAM
• The performance impact of an increased user idle time to simulate a less than 80+% concurrency of user activity on any given host.

To identify the best XenApp VM config we tried a number of configurations including a mix of 1.5x CPU core oversubscription, fewer very beefy VMs and many less beefy VMs. Important to note here that we based on this on the 10-core Ivy Bridge part E5-2690v2 that features hyperthreading and Turbo boost. These things matter! The highest density and best user experience came with 6 x VMs each outfitted with 5 x vCPUs and 16GB RAM.  Of the delivery methods we tried (outlined in the table below), Hyper-V netted the best results regardless of provisioning methodology. We did not get a better density between PVS caching methods but PVS cache in RAM completely removed any IOPS generated against the local disk. I’ll got more into PVS caching methods and results in another post.

Interestingly, of all the scenarios we tested, the native Server 2012 R2 + XenApp combination performed the poorest. PVS streamed to a physical host is another matter entirely, but unfortunately we did not test that scenario. We also saw no benefit from enabling NUMA. There was a time when a CPU accessing an adjacent CPU’s remote memory banks across the interconnect paths hampered performance, but given the current architecture in Ivy Bridge and its fat QPIs, this doesn’t appear to be a problem any longer.

The “Dell Light” workload below was adjusted to account for less than 80% user concurrency where we typically plan for in traditional VDI. Citrix observed that XenApp users in the real world tend to not work all at the same time. Less users working concurrently means freed resources and opportunity to run more total users on a given compute host.

The net of this study shows that the hypervisor and XenApp VM configuration matter more than the delivery mechanism. MCS and PVS ultimately netted the same performance results but PVS can be used to solve other specific problems if you have them (IOPS).

* CPU % for ESX Hosts was adjusted to account for the fact that Intel E5-2600v2 series processors with the Turbo Boost feature enabled will exceed the ESXi host CPU metrics of 100% utilization. With E5-2690v2 CPUs the rated 100% in ESXi is 60000 MHz of usage, while actual usage with Turbo has been seen to reach 67000 MHz in some cases. The Adjusted CPU % Usage is based on 100% = 66000 MHz usage and is used in all charts for ESXi to account for Turbo Boost. Windows Hyper-V metrics by comparison do not report usage in MHz, so only the reported CPU % usage is used in those cases.

** The “Dell Light” workload is a modified VSI workload to represent a significantly lighter type of user. In this case the workload was modified to produce about 50% idle time.

†Avg IOPS observed on disk is 0 because it is offloaded to RAM.

Summary of configuration recommendations:

• Enable Hyper-Threading and Turbo for oversubscribed performance gains.
• NUMA did not show to have a tremendous impact enabled or disabled.
• 1.5x CPU oversubscription per host produced excellent results. 20 physical cores x 1.5 oversubscription netting 30 logical vCPUs assigned to VMs.
• Virtual XenApp servers outperform dedicated physical hosts with no hypervisor so we recommend virtualized XenApp instances.
• Using 10-Core Ivy Bridge CPUs, we recommend running 6 x XenApp VMs per host, each VM assigned 5 x vCPUs and 16GB RAM.
• PVS cache in RAM (with HD overflow) will reduce the user IO generated to disk almost nothing but may require greater RAM densities on the compute hosts. 256GB is a safe high water mark using PVS cache in RAM based on a 21GB cache per XenApp VM.

Resources:

Dell Wyse Datacenter for Citrix – Reference Architecture

XenApp/ XenDesktop Core Concepts

Citrix Blogs – XenApp Scalability