Virtualization by Davis: “Technotes: How to Run the NetScaler Shell Commands from a Remote Computer” plus 6 more |
- Technotes: How to Run the NetScaler Shell Commands from a Remote Computer
- RDS Client via Citrix PVS - AppV 5 Shared Content Store - Approach/Guidance?
- Technotes: XenServer Technical FAQ
- VMware terminology quiz: Do you speak virtualization?
- The networking platform that runs the cloud, now available on the cloud
- Red Hat releases its PaaS Offering OpenShift Enterprise
- Remote control software with app-v
| Technotes: How to Run the NetScaler Shell Commands from a Remote Computer Posted: 28 Nov 2012 03:35 AM PST
   | |||||||
| RDS Client via Citrix PVS - AppV 5 Shared Content Store - Approach/Guidance? Posted: 28 Nov 2012 09:06 PM PST No experience with any past versions of AppV here, but hopefully these questions aren't answered elsewhere and my terminology isn't too far off. Looking for a little help / thoughts on how to efficiently integrate this Shared Content Store under AppV 5 with a Citrix PVS environment. Overall goal is a pool of servers spooled up by PVS for general pupose applications that are fed by App-V. Keep number of PVS images small, give flexibility to update/change App-V sequences as needed. Here's my challenge and I'm curious if it is me, app limitation, or incorrect approach. One important disclaimer is I'd be looking to execute all products via XenApp. Powershell script or I could hardcode to the EXE pointer in %ProgramData%\App-V - at this point either choice would work (probably would go Powershell just so there is some error logic capability and whatnot if pointers aren't cached) I was hoping to set this up so we can build general PVS server pools, but I'm trying to determine the best way to do this with the pointers for each app getting brought into %programdata%\app-v by default. It appears as a result my only choice would be to: a. Execute a pre-cache script on PVS that could scan the entire file share and add the packages via powershell. i.e. Get-ChildItem fileserver\share -recurse -force -include *.appv | Add-AppvClientPackage. The downfall with this is it takes time - for example one product with 15k pointers still adds up to 60mb or so - it takes around 15 seconds for this one app to get added locally (to be clear - this is just pointers). It doesn't seem this will scale very well into a content share with some size. b. Now probably the obvious solution would be to keep the %programdata%\app-v persistent on the PVS'd servers, and I'm not sure if it's a bug but it doesn't look like Add-AppvClientPackage takes any less time if the product is already there. It doesn't commit any file writes if the pointers already exists, but time savings in neglible. It still takes around 10 seconds...guessing it's doing some type of file check. Once again given the neglible time savings, seems like this won't scale into a large number of packages on the content store. c. Another less desirable option could be to add the products (pointers) on the fly to the cache, but not too wild about this because I don't want to add the overhead to the product launch. It's easy enough to run Add-AppvClientPackage and then kick the product off via a powershell script that XenApp executes, but in terms of a product with say 15,000 pointers and my above examples that's around 15 seconds of overhead while we wait for the pointers to exist so we can execute. ...... So am I looking at this way off? Currently I've got a share built on my Publisher VM and the XenApp Hosts are also VMs on the same ESXi cluster. All VMDK's are sitting on the same array via fibre. So I suppose here's my questions: 1. Should I be considering a different design? I guess the ultimate question is what is going to be the best design to create the pointers in %programdata%\app-v as quick as possible? One 65mb sequence taking 15 seconds isn't a big deal, but when you start talking 100s or even 1000s not sure how I feel about that. Looking for ideas to speed this up. 2. Is there some way that one could change the location of %programdata%\app-v to a location shared by the entire pool of PVS'd XenApp hosts? Thought process is if they are all sharing the same pointers each VM won't have to individually recreate/rebuild all the time. i.e. attach say a G: drive and have app-v redirected to place the pointers here? This might be a stupid question...sorry if so. Anyway I'm sure there might be other items I'm missing. If my ideas are dumb, hopefully the requirement of trying to buildout the pointers into cache in a flexible environment as quickly as possible strikes some other ideas. Thanks!
 This posting includes an audio/video/photo media file: Download Now | |||||||
| Technotes: XenServer Technical FAQ Posted: 28 Nov 2012 02:15 AM PST
 | |||||||
| VMware terminology quiz: Do you speak virtualization? Posted: 28 Nov 2012 11:25 AM PST Thought you left vocab quizzes back in the classroom? See if you've grasped the VMware and virtualization lingo by taking our definitions quiz.       
 | |||||||
| The networking platform that runs the cloud, now available on the cloud Posted: 28 Nov 2012 07:55 AM PST It's kinda funny how things go full circle. today, at AWS re: Invent, we launched NetScaler on AWS. Literally. As in, from the AWS Marketplace, you can launch a NetScaler AMI or a CloudBridge AMI into your AWS cloud environment. NetScaler got its start in the cloud, before we were even calling it the cloud. That is, NetScaler's first deployments were in the data centers…
 | |||||||
| Red Hat releases its PaaS Offering OpenShift Enterprise Posted: 27 Nov 2012 03:08 PM PST
Red Hat today released OpenShift Enterprise, a Platform as a Service (PaaS) for on-premise use, or within private,public or hybrid clouds. As long as Red Hat Enterprise Linux instances can be configured and accessed, OpenShift Enterprise PaaS can be deployed. OpenShift Enterprise is built on top of Red Hat technologies, including Red Hat Enterprise Linux (RHEL), JBoss Enterprise Application Platform and OpenShift Origin, the basis for Red Hat's existing online OpenShift PaaS service that has been available in a free beta since May 2011. CONTINUE READING ON CLOUDCOMPUTING.INFO… Labels: Red Hat, Release        
 | |||||||
| Remote control software with app-v Posted: 23 Mar 2010 07:35 AM PDT we are currently trailing app-v with all the programs we are virtualising working normaly untill we connect the client the virtualised program is running on to a remote management program e.g. "netSupport" or "Crosstec" where the performance of certain programs like "corel draw" grinds to a halt
 This posting includes an audio/video/photo media file: Download Now |
| You are subscribed to email updates from Virtualization by Davis To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google Inc., 20 West Kinzie, Chicago IL USA 60610 | |
No hay comentarios:
Publicar un comentario