We have four esx v4.0 hosts and a vcenter server on 2003. Been running 7 years so it’s time to retire.
The vm’s are already on a new Equalogic iSCSI array.
I know I can’t vmotion between the different hardware platforms, and vcenter server 6.0 won’t manage ESXi 4.0 anyway.
If I bring up four new 6.0 hosts and a new vcenter server, I’m thinking I can shut down a vm, remove it from the 4.0 inventory, and add it to the 6.0 cluster. Then boot it up.
Would this work?
Darron…
Creating and recomposing linked clone desktops will fail on Horizon view 6.1.x and all older releases after upgrading to vSphere 6.0 Update 1.
The Linked Clone desktop appears to be created on vCenter, but it will be deleted soon after vCenter complains about either “disposable” or “internal” vmdk files this desktop.
All older versions of Horizon View Composer prior to Horizon 6.2 require SSL v3 to communicate with ESXi hosts, however the SSL v3 has been disabled in ESX6i Update 1 hosts.
Please read this KB article for further information: Upgrading to vSphere 6 update 1 will cause Linked Clone pool creation and recompose failure with Horizon View 6.1.x and older releases (2133018)
Any updates to this information will be made in the KB article itself.
The post ALERT: Linked Clone pool creation and recompose failure appeared first on Support Insider.
I have a MacBook Pro 15″ late-2013 with a 512 GB SSD, 16 GB RAM and a Core i7 2.6 GHz CPU, running VMware Fusion 8. The host OS is OS X 10.10.5 (Yosemite) and the guest OS is Windows 10. My main use case for the VM is software development, and I have Microsoft Visual Studio 2015 installed on it, on which I use a plugin called VisualGDB (www.visualgdb.com), and there is a severe performance issue with my setup, which is severely dragging down my productivity. Here I should mention this is definitely not an issue with VisualGDB itself, and would most likely happen just the same with ordinary Visual Studio projects, it’s just that I don’t code in C# or VB to test a project in one of those languages.
Using VMware’s built in sharing facilities, I shared my home folder from the host OS to the guest OS. I keep all my software projects in my host OS’s home folder, and I access it from within Visual Studio using the shared folder.
The issue is this: performing a rebuild (Build menu -> Rebuild Solution in Visual Studio) of one of my projects over the shared folder takes 38 seconds (in another test, this took as long as 48 seconds; of which 15 seconds are spent just cleaning the project folder, which consists solely of deleting a number of files that’s not more than a hundred). Now if I copy the project folder somewhere inside the Windows C: drive and perform the same rebuild when opening the project from there, it takes less than 7 seconds. The funny thing is that copying the project from my shared folder to the Windows C: drive takes about a second or two, I can’t even time it accurately — so why should accessing the same files from within VS be so slow? This is a 5.5x difference and is making me lose something in the vicinity of one hour every day waiting for compiles to finish. Even creating a network share from within Mac OS X (System Preferences -> Sharing -> File Sharing) is much faster than this at about 12 seconds; this is my preferred solution for now, but frankly I don’t see just deleting less than a hundred .o files and reading in another hundred .c files should take an extra 6 seconds just because the file is on a shared folder (which is, of course, accessed over a loopback connection, so that no bytes are ever put on a physical wire, and the latency can probably be measured in microseconds).
Please note that, for various reasons related to my split Windows-Mac workflow, just copying the files to the C: drive instead of accessing them via the shared folder is not an acceptable solution. They must be kept in the shared folder at all times.
Are there any settings changes, or in general anything that I can do to speed up I/O operations on shared folders?
Good morning.
The name resolution from inside my guest VMs is not working.
ping on any non-internet-existing address resolves to 198.105.254.228
For instance, inside one vm, trying to ping another:
C:>ping win7dev
Pinging win7dev.local [198.105.254.228] with 32 bytes of data:
A ping from the Host works:
C:>ping win7dev
Pinging win7dev [192.168.0.28] with 32 bytes of data:
My setup: (I work from home so this is a very simple network)
Windows 8.1 Home
VMWare Workstation 11.1.2
Time Warner Cable through a Netgear AC1750 WiFi Cable Modem
Bridged networking with Physical Network Replicated
This page would seem to be useful but the resolution did not help:
The only solution VMWare Support is offering is to hard code all my VM’s IPs and setup hosts files everywhere.
After installing or upgrading to ESXi 6.0 and 6.0 Update 1, customers network connectivity is lost randomly with the error: NETDEV WATCHDOG: vmnic0: transmit timed out. This issue has been resolved.
Please proceed to KB article: ESXi 6.0 network connectivity is lost with NETDEV WATCHDOG timeouts in the vmkernel.log (2124669)
This issue is resolved in ESXi 6.0 Update 1a, available at VMware Downloads. For more information, see the VMware ESXi 6.0 Update 1a Release Notes.
Any updates to this information will be made in the KB article itself.
The post ALERT: Important information before upgrading to vSphere 6.0 Update 1 appeared first on Support Insider.