The issue I have in my environment is that one app, Bloomberg Terminal, is overwhelming all other apps, no matter how many resources we give to that full VM. Especially one internal app which needs a very fast response time - window popup time - which it gets considerably slow when Bloomberg Terminal is launched. Tried to work with CPU priority settings, but I didn't notice major improvements. I've also tried deploying Published Applications and offload the BB app on a different VM, but BB terminal app becomes very laggy once logged in into it. The actual workaround is to run VM inside VM, so I offloaded Bloomberg terminal onto another full VM and connecting to that via Horizon Client from the main VM.
Space saving is not a target for us because we are using Flash arrays with deduplication inbuilt. So I'm looking for a solution to offload some applications from the main VM onto another ones and using different CPU and memory resource, to not affect the main internal apps. Would AppVolumes help with that?
Or I might have a wrong mindset here and there could be different solutions I could look at?
App Volumes would not help with this. The applications delivered through app volumes are using the CPU/RAM resources of the VM where it is attached to.
I am however interested in how you could solve your problem in an elegant way.
you may be able to do a windows 10 pool that does app publishing just for bloomberg and another pool for normal use, that way bloomberg gets its own vm basically and then everything else is done in another one. Just check there licensing I know you can't do rdsh I think without something I think from them.
I've briefly tried that and I initially thought that I hit the jackpot, everything looks fine until the user logs in to Bloomberg app and lots of windows and charts are being launched. From that moment everything is laggy and bearable to be used. I guess that would work better with other less resource (processes) intensive apps. Or I may need to find the right best practices in order to improve that.
I'll probably give another shot to that, if no other ideas.
To update on this.
Got it working with the Published Apps. When I briefly tested it first, it was very laggy because one the main VM I had vGPU and on the Published App VM was used the default Horizon video driver. Once I removed the vGPU from my main machine everything worked fine.
Many thanks for taking the time to reply to this.
a Quick question, if you have a published App like bloomberg, does that integrate well with Excel etc. ? Are you running Excel also as published Apps (in die same Published App as Bloomberg) or are you running that on the host VM?
Thanks in advance and best regards,
I have BB slightly under control in my instant clones by way of: my GPU hosts have a better CPU than my non-GPU hosts. So I give the BB users (the important ones with multiple BB screens) 4 CPU and 24GB of memory, and the GPU helps on the graphics side. I'm pretty strict with CPU/memory, and I know I should consider giving them a full desktop with more CPU but I'm holding off on that.
If your users are not active in BB, their support can help you set screen refresh to a much lower setting, so the updates are not instant and it would reflect better on your CPU.
thank you for your answer!
we use 8 vCPUs and 32GB of RAM with 1GB vGPU (Tesla T4) cards. We only have little Bloomberg Users but they use heavily their PCs. Ram and disk (Flash Array) is not a problem, CPU not as well (because we are little users as the machines are big enought).
I for now do install bloomberg (and python and Office etc.) on the master and use some programs (Adobe reader etc.) with app volumes.
My question was directed if your bloomberg apps (with RDSH servers) are integrating well with Excel, as this is what our users normally do or if you have Excel also on the RDSH hosts).
That was a thing for us too and had some troubles getting that working for all users that needed. Yes, we tried to use Excel as a published app. Basically the Excel spreadsheets using the macros were automatically updating fine, but the Add-on wasn't there. so it wasn't a reliable solution. Then we ended up going for a full VM with BB and Excel, inside the main VM being fullscreen on 1 of 4 screens. That was okish, but we don't allow copy and paste in/out VMs for security reasons, so that was a downside. Also that the USB redirection didn't work for a published app inside a Horizon client session. Veeery ugly stuff that would make some of you here to throw up, but we had to test it.
We don't have a problem with the BB performance, but that BB is very greedy and is affecting one of our low latency internal up, adding some 700ms lag.
So we now have taken out the internal app into a standalone VM and RDP to it. It sounds again ugly, but there is no major downside and performance is great. will see how it goes until we investigate the real issue here.
Can you detail a bit more on:
"If your users are not active in BB, their support can help you set screen refresh to a much lower setting, so the updates are not instant and it would reflect better on your CPU."
what do you mean are not active in BB and what screen refresh setting? Can Bloomberg support help with that?
Yes, Bloomberg support told me they can reduce refresh per user so for people in non-trading department who do not require live instant ticker updates the screen will refresh slower.
It took me a few calls for this.
Regarding your issues, why not keep BB as an app volume and deploy to the users desktop based on requirement instead of in the gold image?
Thanks. Yes, I noticed BB support requires few pushes to be able to get some good tech advice. In regards to the refresh thing, it may help for some, but our main concern are the active traders.
We are using full clones, so no Golden images.
I have now installed Bloomber, Office and some others on the Master. This is not nice but at least it works.
What also works for me are writeable volumes, but this means to install it for every user. That is something we could somehow do by hand or script it. The advantage would be, that you can easily restore it (easier as a Masterimage) and that the users use their proper installation (with some aditional modules etc.).
App Volumes did not work for me, bloomberg is just not starting. I was readying about some permission problems and how to fix it with login scripts, but that is not the best solution for us. The link to the website: https://desktopsurgery.com/tag/appvolumes/ but as I said, this did not fix it for me...
Now I would like to know two things, how are you delivering bloomberg to the users and is your fingerprint-reader working with the bloomberg instllation (this is crucial for us)....
Thanks in advance and best regards
Like I said earlier, we are installing it on the main VM, every user having a full clone VM. So users have their own dedicated resources.
Fingerprint it's a tricky one. It's a long story. I'll try to make it short.
So it uses USB redirection. USB redirection breaks when you use Horizon Client version earlier than 2006, so basically all Horizon 7 versions (5.4, 5.5..), when you launch Chrome or Edge. Which breaks the BB keyboard functions.
With later versions it's working randomly. one connection works other doesn't. It's to do with the Composite interfaces of BB keyboard. VMware says that you don;t have to redirect keyboard and fingerprint when using VMware Horizon Client for Linux. I'm actually working on this now and waiting for BB to come with the exact info of what each interface code is for both BB keyboards 4 and 5. Will let you know how I go.
thanks for the explaination! I have found links with how to split the keyboard and pass it on, maybe I will try this. It has to work somehow, otherwise the users will be complicated as they do not always have their b-unit on hand...
From what I understand, you have bloomberg on the masterimage, which implies, that you need to update your master every 2-3 months just for bloomberg (apart from all the other software). Also this means, that bloomberg starts, downloads the updates after that and then applied them. This will be done with all the updates between the updates of the master. If you do not update you BB-terminal for 6 months, as far as I understand, you have to reinstall it, as it will not update itself after 6 months of no updates.
I am testing writeable volumes as an alternative, because bloomberg updates itself, but these updates do not remain on instantclones as they are delete after logout. A writeable volume also allows us to customize some things like one user uses python, can download packages for python by itself etc. As profile management we use DEM, to keep the user expirience the same with the instant-clones, as the user has a new PC every login.
Apart from having to install BB for every user once at the beginning (we can easily automate that), is there a reason why its better to have BB on the Master then on a writeable volume?
Thanks in advance
No Michael, This is the 3rd time I say :P. We are using Full Virtual machines (Full Clones). No Master Images, no Golden Images, no Instant clones, no Linked-clones, no appVolumes, no ThinApps.
We are deploying a full VM from a template in vCenter and then using SCCM to install the OS and the software needed. We manually install BB terminal (as the versions change so quick and are end of support), then BB terminal it is being updated automatically on each VM from the Internet. Think like having 100 Physical PCs.