In this new video tutorial we demonstrate how to downgrade the virtual hardware version of a VMware Fusion virtual machine.
This process would be needed if you were evaluating VMware Fusion 7.x and after the evaluation period expired you wanted to downgrade to VMware Fusion 6.
For additional information see VMware Knowledge Base article Downgrading VMware Fusion 7.x to 6.x (2082112).
There are various reasons a user might experience a blank (black) screen when using the PCoIP protocol with Horizon View and our Support Engineers get calls on this every day. These include, but are not limited to:
- Misconfiguration of connection server settings.
- vRAM shortage on the View virtual machine.
- Incorrect video driver version installed on the View virtual machine.
Note: Troubleshoot your PCoIP issues in the proper order
It is important that the steps outlined in KB article:
Troubleshooting a black screen when logging into a Horizon View virtual desktop using PCoIP (1028332) be followed in the order provided in order to quickly isolate and identify the proper resolution. They are also ordered in the most appropriate sequence to minimize data loss. The KB walks you through a serious of checks, verifying that various requirements are met and that your systems are configured properly. You will see many articles referenced as you work through each step. Do not skip steps. A slow, methodical approach works best here.
If you still see a problem after reading through the body of the KB article, there are also a number of related articles listed in the ‘See Also’ section. If you want to be notified when this article is updated there is an rss link you can subscribe to.
Many of you who read this blog also follow our social media accounts @vmwarekb, @vmwarecares, Facebook, and others. When we set out to engage with our customers online we wanted to be both proactive and reactive about it — that is, we would push out content like newly published KB articles, and we would answer customer questions. This has worked really well for us over the years and we thank all of you for helping making the ecosystem richer and a better place to work.
On the flip side, the number of channels tended to grow as new social networks came online. And grow. Eventually, what we ended up doing is confusing our customers as to which channel was for what purpose? We’re fixing that.
To stop this channel creep, over the next few weeks we will be consolidating some channels as follows:
Change: @vmwarekb is being retired. @vmwarecares will be the single voice going forward. We’re going to do this by renaming the vmwarekb account (as it has far more followers) to vmwarecares.
Action: If you currently follow vmwarekb you don’t need to do anything. You will still be subscribed to us, but the name will now be vmwarecares. If you follow vmwarecares currently you will need to re-follow us.
Change: VMware Knowledge Base is being retired and will go dormant. VMware Cares will be the single page going forward.
Action: Please ‘Like’ our VMware Cares.
By consolidating channels we hope to simplify and clarify the contact options to serve you better.
On Sept 24, 2014, a critical vulnerability in Bash (CVE-2014-6271, CVE-2014-7169) was published that may allow for remote code execution. The VMware Security Engineering, Communications, and Response group (vSECR) has been actively investigating the impact this vulnerability may have on our products.
For further information and updates on this vulnerability, refer to KB article:
VMware assessment of Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271 CVE-2014-7169, aka “Shellshock”) (2090740).
Note: For information regarding VMware customer portals and web sites, see Impact of bash code injection vulnerability on VMware Customer Portals and web sites (CVE-2014-6271 and CVE-2014-7169, aka “shellshock”) (2090817).
Next up in our series of VMware View topics, we’re going to talk about security. I spoke with a couple of our top support engineers about View security and they identified three Knowledgebase articles that solve more support requests than any others in the area of security, namely SSL certificates. They recommend customers use:
In View 5.1 and later, you configure certificates for View by importing the certificates into the Windows local computer certificate store on the View server host. By default, clients are presented with this certificate when they visit a secure page such as View Administrator. You can use the default certificate for lab environments, and one could even make the argument that it is OK for fire-walled environments, but otherwise you should replace it with your own certificate from a trusted CA (Verisign, GoDaddy, others) as soon as possible. They also told me you should use an SSL certificate from a trusted CA when setting up a Security Server for your environment when the Security Server can be used from outside your firewall (Internet) to access View desktops inside your firewall.
My engineers stressed to me the importance of following each step in these KBs one at a time when you are filling out the forms on those sites to obtain your certificate. It is easy to make a mistake and you might not receive something that will work for you.
Note: The default certificate is not signed by a commercial Certificate Authority (CA). Use of noncertified certificates can allow untrusted parties to intercept traffic by masquerading as your server.
Today we have three brand new videos which should be of particular interest to our VMware Fusion customers. These tutorials showcase some of the new features of VMware Fusion 7 Pro, and are based on the following Knowledge Base articles:
Visit these links to see the full step-by-step instructions and try out the new features yourselves!
One of the biggest call drivers within our VMware View support centers revolves around linked clone pools. Some of your users may be calling you to report that their desktop is not available. You begin to check your vCenter and View Administrator portal and discover some of the following symptoms:
- You cannot provision or recompose a linked clone desktop pool
- You see the error:
Desktop Composer Fault: Virtual Machine with Input Specification already exists
- Provisioning a linked clone desktop pool fails with the error:
Virtual machine with Input Specification already exists
- The Connection Server shows that linked clone virtual machines are stuck in a deleting state
- You cannot delete a pool from the View Administrator page
- You are unable to delete linked clone virtual machines
- When viewing a pools Inventory tab, the status of one or more virtual machines may be shown as missing
There are a number of reasons this might happen, and KB: 2015112 Manually deleting linked clones or stale virtual desktop entries from the View Composer database in VMware View Manager and Horizon View covers resolving this topic comprehensively, but let’s discuss a bit of the background around these issues.
When a linked clone pool is created or modified, several backend databases are updated with configuration data. First there is the SQL database supporting vCenter Server, next there is the View Composer database, and thirdly the ADAM database. Let’s also throw in Active Directory for good measure. With all of these pieces each playing a vital role in the environment, it becomes apparent that should things go wrong, there may be an inconsistency created between these databases. These inconsistencies can present themselves with the above symptoms.
Recently a new Fling was created to address these inconsistencies. If you’re not acquainted with Flings, they’re tools our engineers build to help you explore and manipulate your systems. However, it’s important to remember they come with a disclaimer:
“I have read and agree to the Technical Preview Agreement. I also understand that Flings are experimental and should not be run on production systems.”
If you’re just in your lab environment though, they are an excellent way to learn and understand the workings of your systems at a deeper level. Here is the Fling: ViewDbChk. For production systems we recommend following the tried and true procedures documented in KB 2015112. The KB includes embedded videos to help walk you through the steps.
Today we have a new video tutorial which shows how to upgrade from VMware Fusion 6.x to VMware Fusion 7.x.
Note: Some things to be aware of before you attempt your upgrade
- Ensure you shut down any virtual machine before performing the upgrade. If any virtual machines are in a suspended state, resume them from the suspended state and perform a shutdown operation from the guest operating system. Ensure that their status reads Powered Off.
- Upgrading VMware Fusion 6.x to 7.x does not affect the contents of your virtual machines. All virtual machines and the data contained in them are safely retained.
- Installing VMware Fusion 7.x automatically removes VMware Fusion 6.x from your Mac.
Complete upgrading steps can be found in VMware Knowledge Base article: Upgrading from VMware Fusion 6.x to 7.x (2081993).