Some interesting results from the Project VRC State of VDI/SBC Survey

I can't publish all the results, but they will be available here on March 24th, 2015.

Here are two that I found rather interesting that I can publish early:

XenDesktop seems to be the incumbent VDI solution for the survey respondents.  I knew that Citrix had been around a long time, but still rather surprised that it's still trumping VMware's Horizon View.  I probably shouldn't be though as Citrix has always advertised their solution very well and feature functionality always seems to be ahead of View.  Although, seeing XenDesktop in practice on vSphere infrastructure doesn't give me the warm and fuzzy's especially leading into the next question.
How updates are installed/updated/managed responses doesn't really surprise me, but it does bother me.  Manually updating images seems so archaic and I'm quite frankly surprised that VMware hasn't made updating Parent VM's a more automated process.  Being that the respondents were also Citrix heavy, I feel this bodes poorly for their product on the automated operations front as well.

The only way I've hypothesized to update parent VM's in a somewhat automated process is to:

  1. power-up the parent VM 
  2. query SCCM for the related VM 
  3. wait for a 'success' of applicable 'some time window' updates.  
  4. Power off VM
  5. Snapshot it
  6. Delete old snapshots (based on some time window and count)
  7. WinRM call powerCLI cmdlets on View Brokers to then associate pool to new snapshot.


I think if I remember correctly, doing that last step was not possible or somewhat very difficult because the cmdlets didn't have this capability.  Something to look into again I suppose.  I also have thoughts on using WinRM in a 'cloud' fashion against View Brokers.  I'm working on an article that I'll publish later w/ my thoughts and practical application of this thought.

Comments

Post a Comment

Popular posts from this blog

NSX-T: vCenter and NSX-T Inventory out of Sync (Hosts in vSphere not showing up in NSX-T)

Image
Summary: NSX-T loses synch w/ vCenter inventory, but statuses don't appear to show an issue.  Basically, you add a host to a vCenter cluster, NSX-T bits should start to automatically installing on new host.  Assuming you've created a Transport Node Profile and associated w/ the cluster.  The problem is that NSX-T doesn't see the new host and its link to the compute manager (vCenter) looks fine. Looks fine, Y U NO WORK!? So what's going on here?  This appears to affect NSX-T 2.5 and 2.5.1.  Cause is unknown. Workaround: Restart the cm-inventory service on each NSX-T mgmt/controller node using API or CLI. Details: If you were to query the status of the cm-inventory via API or CLI, you could query all 3 manager/controller nodes and get a status of running.  Even if the primary node associated w/ the VIP, if configured, is not necessarily in charge of inventory.  So you could restart the cm-inventory service till you are blue in the face and get nowhere be
Read more

MacOS: AnyConnect VPN client was unable to successfully verify the IP forwarding table modifications.

Image
The VPN client was unable to successfully verify the IP forwarding table modification.  A VPN connection will not be established. Summary: I started running into issue utilizing Cisco AnyConnect on my Mac basically complaining about not able to overwrite IP forwarding tables.  This was on 4.6.x.  Since my VPN endpoints were not providing me w/ an updated client and w/ no access to Cisco Anyconnect downloads, my only option was to try openconnect.  It was totally worth it, here is why and how to set it up. PreReqs: Homebrew Installing OpenConnect: Launch MacOS Terminal brew install openconnect Getting VPN IP's/DNS Endpoints from AnyConnect: The information is typically located in your profile xml files located here: /opt/cisco/anyconnect/profile/somethingsomething.xml In the xml file, you are looking for "<HostAddress>typicallyaDNSName.com</HostAddress>" entry.  These are your VPN endpoints that you would need to pass to openconnect. Using
Read more

Azure VMware Solution: NSX-T Active/Active T0 Edges...but

Image
Summary: Azure VMware Solution (AVS) delivers by default w/ a pair of redundant Large NSX-T Edge VM's each running a T0 in active/active mode.  So why is my traffic only going out one Edge VM? Short answer: The default T1 that is delivered w/ AVS is an active/passive T1 where you connect your workloads to.  So while it could technically take either T0, it's always going to go out the closest T0 to the active "SR" T1.  Where do the SR's live?  You guessed it, on the Edge VM's.  As you can imagine, this can lead to a bottleneck if you try to shove all your traffic through a single Edge VM. Simple Diagram: Longer answer with Options:
Read more