Unprotect/Remove a Replica in VMware View

Posted on by
Reply

Although you can find information on the Internet about unprotecting a Replica, I do get questions about how to unprotect one once in a while. Below you will find a step by step on how to Unprotect and Remove a replica VM.

First a little bit of background information. When you provision a Pool of VM’s based on Linked Clones, a Replica VM/entity will be created in vCenter. This Replica is based on your Parent VM+Snapshot you point to when you use the “Add Pool” wizard in View Manager. This Replica is the Read-only part for your Linked Clones and in vCenter it looks like; “replica-7e710c51-4844-441a-925d-3f8df484f138” (of course the part after “replica” will be different). This Replica is crucial for your Linked Clone pool and therefor protected in vCenter so an Admin can’t delete it by accident.  Right-click on a Replica and you will see that “delete from disk” is grayed out. When you delete a Linked Clone pool, the replica(s) will be deleted as well. So first of all, the right way of deleting a replica is to delete the pool in View Manager. Personally, I always “Disable Pool” and “Disable Provisioning” for the pool in View Manager before I delete that pool. Sometimes it is necessary to manually unprotect the Replica and delete is. Below you will find the steps I take;

  • Open the vCenter Client and connect to the vCenter Server. Decide which Replica you need to unprotect.
  • In vCenter Client, go to “Home” and “Search”. Search for your Replica. What you will see is the Inventory Path of your Replica. You will need the Data Center name and Folder name later on.

 

  • Logon to your vCenter/Composer Server -> Start -> Run -> CMD
  • Navigate to the installation path of Composer. Default is;

32-bit; C:\Program Files\VMware\VMware View Composer

64-bit; C:\Program Files (X86)\VMware\VMware View Composer

  • Type; “SviConfig –operation=UnprotectEntity”. This command will show you all options/examples you have around unprotecting VM’s and Replica’s. Before this I copied/pasted a command I used before and which I saved in Notepad. That didn’t work. Apparently the command changed a bit after I upgraded to a newer version. So, for the latest command for your version, follow this step #5.

  • Follow “Example 2”, unprotecting a Replica. Just a couple of comments;

-DsnName=SVI; = the ODBC DSN name of  the Composer data base

-InventoryPath; = “/Your Data Center Name you looked up in #2/vm/The Folder you looked up in #2/replica name

  • Now your Replica is unprotected and you will be able to right click it and delete is from disk.

Virtualizing non standard, non domain PC’s with VMware View

Posted on by
1

Recently, I visited a large multinational to help setting up a VMware View PoC environment. Firstly, my contact started to explain his thoughts, wishes and use case. The use case was quite interesting and I wanted to share it with you because it is different. It does make sense though, although you wouldn’t think about it that quickly.

When we think about VDI, we most likely think about office users, needing several applications, multimedia here and there, all in a domain or several domains. In this case we are talking about virtualizing PC’s, which are controlling laboratory equipment.

In the customer’s case, officially around 2000 PC’s are running and controlling laboratory/analytical equipment. This equipment is costly and generating very valuable data. Also, these setups (connection between lab machines and PC’s are done via RS-232) have been running for multiple years in a very standalone manner. They aren’t added to the domain, not connected to the Internet and running in an isolated “Lab” network segment.

The lab PC’s need to run continuously. Downtime is very, very costly. Virtualizing them benefit higher availability. These PC’s can use vSphere HA, DRS and vMotion.  In case of unsolvable crashes, provisioning a new VM will only take minutes. Also, adding them to VMware View will allow application owners/developers to access these VM’s to update and maintain the applications, instead of visit them physically.

So, interesting use case to me, and the first step was already made; the lab equipment was IP accessible and RS-232 connections weren’t needed anymore. Then I got the question if View desktops needed to be in a domain. Hmm, good one. I quickly looked through the documentation and everywhere I looked, it stated that VM’s needed to be part of a domain. Luckily, it isn’t a hard requirement. For example, you can create VM’s in vCenter first and add them to a “Manual Pool” later. You need to use Sysprep though. Quickprep can only be used when desktops are added to the domain. Also, you need to create a local account on the VM for a specific user who gets access. Lastly, Single Sign On doesn’t work which is understandable.

This case isn’t about the lowest TCO possible. It isn’t about multimedia, bandwidth usage and lowest storage capacity. It is about high availability, making it easier and more efficient to manage and maintain these machines and more importantly, the applications. Maybe the most important feature is creating a platform for these kinds of applications, which can be used for many years. Writing off expensive lab equipment because of the controlling PC’s are difficult to replace.

Zero Clients, Host cards, Tera Chipsets and APEX card; what is what in VMware View and PCoIP land?

Posted on by
Reply

I have noticed people are mixing up/are confused about the different PCoIP hardware bits which can be used in a VMware View environment. For example, people sometimes think the Teradici APEX card is a GPU. Below I would like to give you a brief overview of what is what. I will also add links to sites where you can find more information.

Zero Clients;

ZC’s are access devices used by View users to access their virtual desktops using PCoIP as the protocol. They are called ZC’s because they don’t have an OS running on them. Firmware runs on top of the Teradici chipset. The chip today is the Tera 1 chipset. The latest firmware can be downloaded from the Teradici support site.

ZC’s come in standalone devices but also as integrated monitors.

Teradici develops the chipsets and firmware. It is Teradici who adds functionality to the ZC’s and not VMware. There is a chance that VMware adds new features in a new VMware View release and that the current ZC firmware/chipsets don’t support the new features. A current example is Client Side Caching; a feature in VMware View 5.0 but doesn’t work on ZC’s. Teradici continues developing and supporting new features and will continue releasing new version of the Tera chip and firmware.

Personally, I do like ZC’s. I’m not too fond of the name “Zero Client” because there is firmware running, so not zero or nothing. Anyway… The good part is the firmware’s footprint is very small and doesn’t need much patching like a typical Operating System. Also, no hard drive which can break or local data which can leak. On top of that, a lot of Zero Client don’t use a lot of power. Teradici also offers a ZC management tool for free. You can manage your clients from 1 central place.

Host cards;

Host cards are Teradici cards you put into a PC/Workstation, which you put in a datacenter. Instead of connecting to a virtual desktop, a user connects to a physical Workstation with a Host card.  On that Workstation an OS (support for Linux, Mac and Windows) is running with applications. Companies use this solution for high-end graphical users. Inside the Workstation a professional graphics card is present. The output of that card is being send to the Host card and put on the network as a PCoIP stream to the user’s access device. The users most likely will use a Zero Client as their access device and can use VMware View as their broker (Workstation can only run Windows). The software driver for the host cards can also be found on the Teradici support website.  A white paper about Host cards and VMware View has been published as well.

APEX 2800 Server Offload Card;

When a VMware View user connects to a virtual desktop and is doing a lot of multimedia related work, like watching videos, all that encoding/rendering needs to be done in software of the ESX servers. Remember, PCoIP is a host-based protocol. Read more about PCoIP basics here.

Encoding/rendering and compressing cost ESX CPU cycles that might lead to a decrease of your consolidation ratio when a lot of multimedia is being done. In that case, to ensure the high level of consolidation, a Teradici APEX 2800 Server Offload Card can be used. This card will take over that encoding from the server CPU’s. Don’t mix this card with a Graphics card or GPU. The APEX is an encoding offload card and for sure not a GPU! It won’t add hardware 3D capabilities to your VM’s. That’s something else VMware is developing with NVIDIA. I will come back to that later.

Hopefully this overview gives you a clear view of what is what in PCoIP/Teradici land.

Does VDI Vendor Lock In Exist?

Posted on by
7

Yesterday, I read an article about a customer who had chosen for Citrix XenDesktop on VMware vSphere. By choosing Citrix, according to the customer, he wasn’t “vendor locked in”. As many people know VMware View requires VMware vSphere. The Citrix frontend can run on multiple hypervisors. I came across 1 other case where vendor lock in was used as a reason to go for a combination of products from different vendors; a customer explained to me he decided to go for vSphere in the backend and Citrix XenDesktop in the frontend. Also, for Application Virtualization he was going for a specific product. He wanted to create a flexible building block kind of environment; no vendor lock in and be able to change a building block when necessary.

Is seeing VMware View as “vendor lock in” a good driver for your decision? Does “vendor lock in” in this case exist?

VDI environments basically consist of 2 parts; the hypervisor layer (hypervisor, its features and management platform) and the VDI frontend. These 2 parts make up 1 solution. In the case of VMware VDI it is difficult to actually see them as individual products. The VMware back- and frontend integrate, almost unite and become one optimal working solution. Together, features become available which won’t be there with any other combination. Think about the 3D driver, which resides in vSphere and VMware View uses to support Windows Aero, basic 3D and OpenGL2.1/DirectX 9. More “exclusive” features will come out like this, making the combination more and more stronger. Also on other levels integration happen. On a development level, both development groups (View and vSphere) communicate, make plans, share ideas and build with having each other’s product in mind. Last but not least, support. It does benefits when the whole stack is coming from 1 vendor. It could make troubleshooting a lot easier.

You want to be able to change building blocks? Would you ever do so after the implementation of your first choice? Well, you might but probably not until after your solution’s economic value is zero and that might take 3-5 years. Nobody likes to throw away money. After the economic write-off, you have to invest again and can decide for other vendors for whatever reason. Of course there are exceptions where an issue occurs and no solution is available so that you have no choice than to change building blocks or even the complete solution. In all other cases I doubt you will change a building block because another vendor has a feature you might like, or your license price went up, as an example. Think about the technical implication, your knowledge/resources internally and again, which features would you lose when going for another building block.

The VMware solution will bring you more and exclusive features and functionality. Changing building blocks, in whichever combination you use them and from vendors will most likely not happen before the economic write-off or exceptional circumstances. In this case, to me, vendor lock in doesn’t exist. Comments are most welcome!