Kraft & Kennedy, Inc. provides technology and strategic consulting services to law firms, corporate legal departments and financial services firms. We can help you analyze, plan, implement and manage business and technology solutions to optimize your organization's functionality and processes.
For quite a while there has been confusion over how VMware’s Transparent Page Sharing (TPS) feature works with vSphere 4 running on Nehalem (or other modern) processors. Many people were noticing that it appeared that TPS was not actually working anymore and looked for ways to fix the problem.
In my recent post on the effects of ASLR in vSphere the comments turned into a discussion about TPS on modern processors. And there are countless posts about this issue on the VMTN forums where folks are looking for a fix. In reality nothing is broken and there is no need to fix the issue.
Continue reading…
In Q4 last year, Citrix made its NetScaler physical appliances available as a virtual appliance. Labeled as the “VPX”, the full featured virtual iteration of the appliance dropped its price point and made it more accessible to SMB customers. Citrix has now made the Access Gateway (CAG) and Branch Repeater physical appliances also available as VPXs. At this point, Citrix has made three of their ‘core’ Networking products available as VPX appliances, which are recapped below.
Citrix NetScaler VPX
Citrix Access Gateway VPX
Citrix Branch Repeater VPX
This week at Citrix Summit/Synergy, Citrix finally revealed details behind their much anticipated client (bare metal) hypervisor. To recap, for the folks who are not following, this will finally bring “offline VDI” to XenDesktop. It will also match (and potentially beat) VMware’s current offline VM checkin/check out functionality currently available in View.
When VMware released vSphere 4 last year, one of the changes they made was a completely re-written software iSCSI initiator. This was done to optimize performance which is great considering how popular iSCSI SANs have become. They also gave the ability to use Round Robin MPIO (mutlipathing) in the software initiator in addition to Fixed Path and MRU which were previously available.
I’m working on a vSphere implementation using Dell EqualLogic SANs and wanted to configure Round Robin on all of my datastores. Dell has a great whitepaper on how to set this up, but unfortunately the document fails to mention one key thing: this doesn’t change the default path selection plugin (PSP) from Fixed to Round Robin. That means that you’ll have to set the multipathing policy to Round Robin on all of your existing datastores and will have to remember to do that on all future datastores. When you’ve got multiple ESX hosts with lots of datastores this can quickly become a pain.
I’ve seen a lot of talk lately about VMware’s Transparent Page Sharing (TPS) and how it is affected by ASLR in Windows 2008/Windows 7. I wanted to see if there was any real measurable reduction in shared memory when using ASLR vs. when it was disabled. First, let’s talk about what TPS and ASLR actually are and what the acronyms mean.
Continue reading…
For years organizations have relied on tape drives and changers for backup and recovery of their critical data. Despite many predictions to the contrary, tape is still alive as we begin 2010.
When virtualization became popular it presented a challenge to those looking to continue to use their tape drives in fully virtualized environments. If you were using VMware you could use SCSI pass-through to present a tape drive or changer directly to a virtual machine but that prevented you from using any advanced features like VMotion. It also tied your tape drive and VM to a single host containing a SCSI card, making things complicated if that host were to experience a hardware failure.
For years the best practice has been to disable screensavers on virtual machines. Screensavers take memory and CPU cycles to run and that can hurt consolidation ratios, especially when there is no reason to run a screensaver on a server VM. After all, why run a screensaver on a server that doesn’t actually connect to a monitor? Seems obvious and almost unnecessary to bring up in 2009.
While working on a recent VDI project, I noticed unexpectedly high CPU utilization on a seemingly idle virtual desktop. Turns out that the desktop image we were given had the 3D Flying Objects screensaver enabled. When it kicked in after the desktop went idle it started taking a fair amount of the CPU. How much CPU it was using might surprise you. Take a look:
My last post Citrix Provisioning Services Part 1 – What Is It? served an introduction to what exactly Citrix Provisioning Services is capable of. Below I hope to open people’s eyes to using PVS for something other than VDI, as it is often thought of as a part of the XenDesktop suite. However PVS is actually independent of XD or VDI, and can be utilized in combination with XenApp to bring single-image benefits to the Terminal Services world.
Provisioning Services allows for server consistency, easier maintenance, dynamic servers, and aids in disaster recovery.
Creating a XenApp environment that is more dynamic and easier to maintain is a goal for many XenApp administrators. The addition of Provisioning Services to a XenApp implementation can go a long way to achieving those goals. By leveraging the single-image management capabilities of PVS, administrators can dramatically reduce the costs involved with deploying and maintaining their XenApp farms. While at the same time, guaranteeing consistency between and ensuring peak performance of each server in the farm. All while being capable of quickly adapting to changes in load and disaster scenarios.
One of the great features of desktop virtualization (VDI) being touted by the industry is the ability to manage and update all of your desktops from a single central master image.
Citrix’s solution to the single image process is accomplished by a product called Provisioning Services (PVS). This software is the result of their purchase of a company called Ardence back in 2007. Provisioning Services is an often misunderstood piece of software, and its great benefits and potential are not necessarily apparent to everyone.
PVS works by streaming a master (read-only) image from the server to a target server or workstation. Any subsequent writes are then sent back to the PVS server and written to a cache file. The reads and writes are sent back and forth between the PVS server and target in a constant stream over the network. The easiest way to grasp this is to imagine that the cable connecting the hard disk inside of the server to the motherboard (and thus the CPU and RAM) is replaced by a network cable running back to the PVS server. The operating system sees the PVS disk as though it were a normal hard disk, and everything is done entirely transparent to the OS. The magic happens when the server is powered up; instead of booting from a local disk it is instead set to boot to the network card (PXE, BOOTP) which talks to a service on the PVS server, which streams the assigned operating system image to the target. The target device starts up immediately, as though it was booting from a local disk.
The beauty here is that this single read-only image can be simultaneously streamed to multiple diskless targets, both physical and virtual. This central image can now be maintained in one place. This makes tasks such as installing updates or new software quick and easy. After installing an update into the master image, all machines running that image will boot up into the updated image on next restart. To put that in perspective, think of the time and effort required to push out something such as a service pack to Windows or Microsoft Office to your entire firm. Now imagine simply installing that update once and having every machine in your environment receive that update on next reboot, without any additional effort.
Look for a follow-up post discussing the benefits that Provisioning Services can bring to a XenApp implementation.
With the release of VMware vSphere 4, VMware has released a very powerful management tool called Fault Tolerance (FT). At a basic level, FT allows you to keep two virtual machines (a Primary VM and a Secondary VM) running in lockstep on two different physical ESX hosts. If one of the ESX hosts were to experience a hardware failure, the VM protected with FT would remain running on the second host without any downtime. This can greatly reduce downtime due to hardware failures and provide increased service levels for important applications.
FT is often compared to Microsoft Windows Failover Clusters, formerly Microsoft Cluster Server (MSCS), and in fact many have talked about how FT can replace Microsoft clustering altogether. Rather than jump to conclusions like this, it is important to understand the use cases for both technologies. In addition, there are several limitations to FT that need to be considered. Here are some important points to remember about FT: