Last week I blogged about the lack of View oriented bloggers or articles. This week 3 articles of the top 5 are View centric. That can't be a coincidence can it? Anyway I am in a hurry... so no time for a huge introduction. Here is the top 5:
- Ian Gibbs - Cleaning up orphaned replicas in View
If, like me, you have been through all the versions of View Composer
and the broker since its introduction, various bugs and broken
recompositions will have left you with a large amount of detritus in
your VMwareViewComposerReplicaFolder, making it hard to keep an eye on
the proper operation of the Composer, and in my case, causing a
datastore to run out of space and subsequent operations to fail. Time
for a clean up. This is decently documented here, but how do you know which ones you can delete...
- Arne Fokkema - PowerCLI: Find Resourcepool or VMs with Memory Ballooning/Swap Usage
In this post I will show you how to report Resource Pools and VMs with active Memory Ballooning with the use of the PowerCLI/Ecoshell.
- Chad Sakac - What’s what in VMware View and VDI Land...
Let’s say once again that your peak workload is 12 IOps per client, and
you have 15,000 desktops you want to virtualize. That’s a total of
180,000 IOps, which is a very, very large workload for common storage
configurations. It would hammer a large CX4, for example. You would
need to carefully scale out all the aspects of the design, and consider
it just like you would consider the system design for a MASSIVE
database. Can it be done? Of course – but there’s a reason why the
“what’s the single ESX host maximum IOPs” test at the vSphere 4 launch
(365,000 IOPs) was backended by 3 CX4-960s with 30 solid-state disks.
That’s a whackload of IO.
- Ruben Spruijt / Herco van Brug - Understanding how storage design has a big impact on your VDI!
It should be obvious by now that calculating the amount of storage
needed in order to properly host VDI is not to be taken lightly. The
main bottleneck at the moment is the IOPS. The read/write ratio of the
IOPS that we see in practice in most of the reference cases demonstrate
figures of 40/60 percent, sometimes even as skewed as 10/90 percent.
The fact is that they all demonstrate more writes than reads. And
because writes are more costly than reads - on any storage system - the
number of disks required increases accordingly, depending on the exact
usage of the users and the application.
- Vittorio Viarengo - Virtualize Production Databases first
So, how does a database run faster in a virtual environment? Well, most of these databases were running on relatively old and under-utilized machines. By upgrading them to a new modern server running VMware, these customers could allocate more resources to each database instance therefore achieving better performance. Moreover, thanks to VMware HA and FT, they could provide their internal customers with better business continuity without deploying more complex clustering solutions from the database vendors.