Thank you.  I tired to move the VM into the cluster before setting up EVC on it, but it was not working. I can deploy a vCenter VM into the cluster, but when I setup the cluster in the newly deploy vCenter its host will not be in the cluster at the start, so I would be back at the beginning, I think.  If feel like this is a bit like the chicken and the egg.

Federico

You're going to have to post more specific information, error messages, screenshots, whatever.

I was using 15.0.  When I started it told me the upgrade was available for "free".
So I upgraded, not realizing that it would mean I was left without VMWare.
The "upgrade" first uninstalled the existing, working version, and then attempted to install the new version.

After some time, the installation failed, reporting that it could not install the USB inf file.

The installation process then proceeded to rollback, leaving me with no VMWare.

So, I tried to get technical support (that's where you have to pay for the "free" upgrade)

They told me I could either pay for a support ticket to try to get a product that I paid for to install so that I could use it again or I could try to get support here.

I was also told that even if I were to pay for a support ticket, that I would have to be available during business hours in my timezone (when I was at work), that they would not be able to get to me today, that they could not guarantee that it could be fixed on the call (or subsequent calls), and that the charge was not refundable (even if the problem was not solved).

Looking at the messages here, I see that others have had the same problem, but all of those problems are marked as "Not answered".

I wasn't at all surprised that there was no answer.  What incentive does VMWare have to post an answer to a question on a free forum when they can charge users for one (and potentially not fix the problem after said charge)

I know it's a long shot; I'm posting this topic again, in this message, in case someone has an answer to this problem.

Failing that, I'll have to take a day off work, phone support, and gamble that some engineer fix the problem caused by their own installer.

This is what I get when I try to migrate the vCenter appliance:

The target host does not support the virtual machine's current hardware requirements.

Use a cluster with Enhanced vMotion Compatibility (EVC) enabled to create a uniform set of CPU features across the cluster, or use per-VM EVC for a consistent set of CPU features for a virtual machine and allow the virtual machine to be moved to a host capable of supporting that set of CPU features. See KB article 1003212 for cluster EVC information.

CPUID faulting is not supported.

com.vmware.vim.vmfeature.cpuid.ibpb

com.vmware.vim.vmfeature.cpuid.ibrs

RDTSCP is unsupported.

1 GB pages are not supported (PDPE1GB).

3DNow! PREFETCH and PREFETCHW are unsupported.

XSAVE YMM State is unsupported.

XSAVE SSE State is unsupported.

com.vmware.vim.vmfeature.cpuid.ssbd

com.vmware.vim.vmfeature.cpuid.fcmd

com.vmware.vim.vmfeature.cpuid.stibp

com.vmware.vim.vmfeature.cpuid.mdclear

Fast string operations (Enhanced REP MOVSB/STOSB) are unsupported.

Supervisor Mode Execution Protection (SMEP) is unsupported.

Instructions to read and write FS and GS base registers at any privilege level are unsupported.

RDRAND is unsupported.

Half-precision conversion instructions (F16C) are unsupported.

Advanced Vector Extensions (AVX) are unsupported.

XSAVE is unsupported.

AES instructions (AES-NI) are unsupported or disabled in the BIOS. See KB 1034926.

POPCNT is unsupported.

MOVBE is unsupported.

SSE4.2 is unsupported.

SSE4.1 is unsupported.

PCID is unsupported.

FMA3 is unsupported.

Carryless multiply (PCLMULQDQ) is unsupported or disabled in the BIOS. See KB 1034926. 

  hostname

  The vMotion interface is not configured (or is misconfigured) on the "Source" host 'hostname'. 

  hostname

  A general system error occurred:

The IP address family of source vMotion nic (IPv6) does not match the destination (IPv4). If you proceed with the operation, there is a high likelihood of operation failure. 

  hostname

Apparently the HW version 15 was not added in 11.5.
You'll have to use the ExtensionData, see for example Re: HW Version Report

Can you show what you have or describe in detail? What you've posted suggest you have EVC enabled and that you have a host without vMotion enabled.

Vmware 6.7 U3 - 6.7.0.40000  - 14367737

Esxi 6.7 U3 - 14320388

Vsan On-Disk format version – 10.0

4 nod vsan cluster with 2x10Gbits optical fiber nics.

HCIBench 2.2.1

I’m receiving error messages Lost access to volume during Vsan tests with HCIBench.

HCIBench settings was Easy Run and VDBENCH.

Now starts the interesting part.

This error messages Lost access to volume are experienced on the SECOND test vdb-8vmdk-100ws-4k-100rdpct-100randompct-4threads exactly 16 seconds after the start of the test and ONLY when the test phase include Virtual Disk Preparation ZERO. If you do not delete the guest VMs and just Reuse them, then no errors at all.

Now because the error Lost access to volume also contain due to connectivity issues and I have not find any other error in the logs, which to explain the connectivity issues, nor congestions,  I have started and logged time stamped vmkpings from all esxi hosts to all vsan vmkernel adapters and I have not find any packet lost on the vsan interfaces in the vmkping logs starting 1 minute before the errors and during the hole error period.

This Lost access to volume errors are reported only once per VM but for all running VMs (also includes other VMs different from the HCIBench guest VMs) at that moment in that cluster during the hole test cycle run. The whole error period (the Lost and the Recovered) is different every time but usually is shorter like from 1 to 3 seconds and only once I have seen the time to be 8 seconds for that period. It looks like you hit them all together (the running VMs) in the same time with something. I have not found any indication for problems inside the running VMs during this Lost access to volume period.

It took me a while to see this errors as pattern and to narrow this strange problem how to be reproduced every time on my test cluster. For me this is some wired vsan bug.

I have tried to stress my test cluster with other ways that HCIBench but the problem Lost access to volume is experienced only with HCIBench test.

Try like this

Hi,

Few things to check

1) storage is shared across clusters from and too?

2) network/vlan is accessible over two clusters?

3) EVC will not work if you got different hardware in two clusters , you enabled evc with intel etc/? what we have in other cluster host?

This all pre-requites is to live migrate VM

4) What is the error you see when you say migration is failing? can you paste full error.

Try tail -f /var/log/vpxd.log  while you initiate migration to see cause of failure.

Regards

Hi,

I have requirement to migrate VMs off from one cluster to another in same VC. However , i need to share plan how many ESXI i would need to make sure i am able to accomodate all VMs in new cluster.

I Checked in vROPS it is giving option how much space i would need if i have to move VM etc.

How and where can i check capacity needed to move VMs off one cluster to another. Is there anyway i can do it from VROPS?

Ok, let's see if this does the trick?

When you say "Currently claims to be using approx 80gb", where are you seeing that figure?

In particular, what do you see in the guest Finder's Get Info for its hard drive? Is that figure also about 80 GB , or is it showing a more reasonable number around 11 GB?

Depending on the answer to that question, there are two possible routes to tracking down the problem.

(a) If the guest Finder's Get Info shows about 80 GB of used space, then the problem is likely to be files in a location that your user account doesn't have permission to access, so OmniDiskSweeper isn't counting them. You'll need another method to search with admin privileges (which I can detail once I know this is the case).

(b) If the guest Finder's Get Info shows about 11 GB used space, then double check using the following command in Terminal:

df -h

The df command shows disk free and used space. The -h option displays the results in human-readable form, e.g. KiB/MiB/GiB rather than number of blocks, but note that it uses base-2 units, whereas Finder uses base-10, thus df should show numbers that are about 2% higher than Finder for KB, 4% higher for MB, 7% higher for GB.

Finder deliberately hides some things from its reported used space, in particular Time Machine's Local Snapshots (which should only exist if Time Machine is enabled in the VM). They are supposed to be deleted automatically by the system as free space gets low. df will show the actual used/free space, so Local Snapshots count toward its used space.

If df also shows about 11 GB used then the explanation is probably something to do with the structure of the VMDK and VMware's ability to shrink it.

I have two hosts, a ProLiant DL380 Gen9, Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz, outside the Cluster.  This host contains the vCenter appliance.  The cluster has VMWare EVC enabled.  In the cluster there is already another host, a ProLiant DL380 Gen9,Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz .  Ideally, I would move the vCenter appliance VM to the host already in the cluster, but when I attempt to migrate I get a validation error with above message.  I don't see how to enable EVC in the host outside the cluster.  I also don't see how to enable Per-VM EVC on the vCenter appliance.  I could enable Per-VM EVC on the vCenter appliance and migrate it to the cluster, it would fix my problem, but I don't see how.

Thank you

Federico

Currently running vSphere 6.0 with plans to go to 6.7 shortly but is it possible to configure LDAP to connect to more than 2 domain controllers for authentication? We recently had an issue where the two domain controllers went down which just happen to be the ones vCenter uses for LDAP connectivity. It seems you can only put a primary & secondary server

In the 6.7 vcenter server appliance, they only give you the option to "join AD". Which to me, means it'll use any available DC to authenticate, so long as DNS is setup. Granted, you should take my opinion with a grain of salt, because I can't even get AD working in 6.7 right now. Some screenshots of 6.7 VCSA to backup my theory.

Did anyone get a root cause to this? I am hitting this on a physical deployment and it seems to be one issue after another with this deployment process. I could try to just ignore and continue on (which I will eventually do if I can't get past this) but it doesn't really lend itself to a validated configuration so I'd like to understand why the issue since I can get to the host with the passwords supplied and all the pre-reqs have been validated.

Thanks

This started happening on a computer update and persisted with a VM upgrade as well.

The problem is VMs would not start with the error "VMWare Workstation cannot connect to the virtual machine.  Make sure you have rights to run the program, access all directories the program uses, and access all directories for temporary files.  The VMWare Authorization Service is not running" - but the service is running.  So I tried stopping it to let the application start it.  Now, I can get one VM to start the service and then it opens properly - no other VM can be opened and once I close that VM it cannot be opened again either.  Stopping the AuthSvc once again allows one VM to start but no other and once it closes it and no other will start.

It sounds like the service cannot multi-thread like it used to.

Anyone have this problem

There is no shared storage between the servers.  They do share the network, they are in the same subnet I can ping each other with no problem.  I enabled EVC in the cluster with Intel Merom Generation mode.  I was able to migrate another VM to the cluster when is set its EVC to the same mode.  The hardware on both hosts are the same, except that one has  CPU E5-2640 while the other  E5-2660.  The migration is not attempted. I cannot get past the validation stage.

I tried to run tail -f /var/log/vpxd.log, but that file is not on the server.  The server has a vpxa.log file, which I this output while I tried the migration again:

[root@localhost:~] tail -f /var/log/vpxd.log
tail: can't open '/var/log/vpxd.log': No such file or directory
tail: no files
[root@localhost:~] ls /var/log/
Xorg.log                     hostd.log                    sdrsinjector.log             vmkdevmgr.log
auth.log                     hostdCgiServer.log           shell.log                    vmkernel.log
boot.gz                      hostprofiletrace.log         sockrelay.log                vmkeventd.log
clomd.log                    init.log                     storagerm.log                vmksummary.log
clusterAgent.log             iofilter-init.log            swapobjd.log                 vmkwarning.log
cmmdsTimeMachine.log         iofiltervpd.log              sysboot.log                  vmware
cmmdsTimeMachineDump.log     jumpstart-esxcli-stdout.log  syslog.log                   vobd.log
configRP.log                 jumpstart-native-stdout.log  tallylog                     vprobe.log
cryptoloader.log             jumpstart-stdout.log         upitd.log                    vpxa.log
ddecomd.log                  kickstart.log                usb.log                      vsandpd.log
dhclient.log                 lacp.log                     vdfsd-proxy.log              vsanmgmt.log
epd.log                      loadESX.log                  vdfsd-server.log             vsansystem.log
esxupdate.log                nfcd.log                     vitd.log                     vvold.log
fdm.log                      osfsd.log                    vlf
hbragent.log                 rabbitmqproxy.log            vlf-ts
hostd-probe.log              rhttpproxy.log               vmauthd.log
[root@localhost:~] ls /var/log/vpxa.log
/var/log/vpxa.log
[root@localhost:~] tail -f /var/log/vpxa.log
--> Args:
-->
--> Arg catalogChangeSpec:
--> (vim.vslm.CatalogChangeSpec) {
-->    datastore = 'vim.Datastore:ds:///vmfs/volumes/5dadf7f0-6ec46408-9161-f40343591578/',
-->    startVClockTime = (vim.vslm.VClockInfo) {
-->       vClockTime = 1
-->    },
-->    fullSync = false
--> }
2019-11-05T23:58:49.417Z info vpxa[2131508] [Originator@6876 sub=vpxaInvtHost opID=SWI-30e437e3] Increment master gen. no to (175): ResourcePool:VpxaInvtHostResPoolListener::ConfigChanged
2019-11-05T23:58:55.687Z info vpxa[2131147] [Originator@6876 sub=vpxLro opID=HB-host-69@175-43cb9874-28] [VpxLRO] -- BEGIN lro-830 -- vpxa -- vpxapi.VpxaService.getChanges -- 527d63c0-b43e-16da-3994-714349e73421
2019-11-05T23:58:55.687Z info vpxa[2131147] [Originator@6876 sub=vpxLro opID=HB-host-69@175-43cb9874-28] [VpxLRO] -- FINISH lro-830
2019-11-05T23:59:05.491Z info vpxa[2131194] [Originator@6876 sub=vpxLro opID=PollQuickStatsLoop-1f9ef85f-6c] [VpxLRO] -- BEGIN lro-831 -- vpxa -- vpxapi.VpxaService.fetchQuickStats -- 527d63c0-b43e-16da-3994-714349e73421
2019-11-05T23:59:05.492Z info vpxa[2131194] [Originator@6876 sub=vpxLro opID=PollQuickStatsLoop-1f9ef85f-6c] [VpxLRO] -- FINISH lro-831
2019-11-05T23:59:25.677Z info vpxa[2131137] [Originator@6876 sub=vpxLro opID=sps-Main-653660-360-bc-e3] [VpxLRO] -- BEGIN task-476 -- catalogSyncManager -- vim.vslm.host.CatalogSyncManager.queryCatalogChange -- 527d63c0-b43e-16da-3994-714349e73421
2019-11-05T23:59:25.688Z info vpxa[2131146] [Originator@6876 sub=vpxLro opID=sps-Main-653660-360-bc-e3] [VpxLRO] -- FINISH task-476
2019-11-05T23:59:25.688Z info vpxa[2131146] [Originator@6876 sub=Default opID=sps-Main-653660-360-bc-e3] [VpxLRO] -- ERROR task-476 -- catalogSyncManager -- vim.vslm.host.CatalogSyncManager.queryCatalogChange: vim.fault.NotFound:
--> Result:
--> (vim.fault.NotFound) {
-->    faultCause = (vmodl.MethodFault) null,
-->    faultMessage = <unset>
-->    msg = "The object or item referred to could not be found."
--> }
--> Args:
-->
--> Arg catalogChangeSpec:
--> (vim.vslm.CatalogChangeSpec) {
-->    datastore = 'vim.Datastore:ds:///vmfs/volumes/5da8f3ae-a87d5cc8-9d22-f40343591578/',
-->    startVClockTime = (vim.vslm.VClockInfo) {
-->       vClockTime = 1
-->    },
-->    fullSync = false
--> }
2019-11-05T23:59:26.684Z info vpxa[2131194] [Originator@6876 sub=vpxLro opID=sps-Main-653660-360-25-d4] [VpxLRO] -- BEGIN task-477 -- catalogSyncManager -- vim.vslm.host.CatalogSyncManager.queryCatalogChange -- 527d63c0-b43e-16da-3994-714349e73421
2019-11-05T23:59:26.694Z info vpxa[2131150] [Originator@6876 sub=vpxLro opID=sps-Main-653660-360-25-d4] [VpxLRO] -- FINISH task-477
2019-11-05T23:59:26.694Z info vpxa[2131150] [Originator@6876 sub=Default opID=sps-Main-653660-360-25-d4] [VpxLRO] -- ERROR task-477 -- catalogSyncManager -- vim.vslm.host.CatalogSyncManager.queryCatalogChange: vim.fault.NotFound:
--> Result:
--> (vim.fault.NotFound) {
-->    faultCause = (vmodl.MethodFault) null,
-->    faultMessage = <unset>
-->    msg = "The object or item referred to could not be found."
--> }
--> Args:
-->
--> Arg catalogChangeSpec:
--> (vim.vslm.CatalogChangeSpec) {
-->    datastore = 'vim.Datastore:ds:///vmfs/volumes/5dadf7f0-6ec46408-9161-f40343591578/',
-->    startVClockTime = (vim.vslm.VClockInfo) {
-->       vClockTime = 1
-->    },
-->    fullSync = false
--> }
2019-11-06T00:00:05.019Z info vpxa[2131376] [Originator@6876 sub=vpxLro opID=440bff5f] [VpxLRO] -- BEGIN lro-834 -- vpxa -- vpxapi.VpxaService.querySummaryStatistics -- 527d63c0-b43e-16da-3994-714349e73421
2019-11-06T00:00:05.055Z info vpxa[2131376] [Originator@6876 sub=vpxLro opID=440bff5f] [VpxLRO] -- FINISH lro-834
2019-11-06T00:00:05.491Z info vpxa[2131144] [Originator@6876 sub=vpxLro opID=PollQuickStatsLoop-1f9ef85f-df] [VpxLRO] -- BEGIN lro-835 -- vpxa -- vpxapi.VpxaService.fetchQuickStats -- 527d63c0-b43e-16da-3994-714349e73421
2019-11-06T00:00:05.491Z info vpxa[2131144] [Originator@6876 sub=vpxLro opID=PollQuickStatsLoop-1f9ef85f-df] [VpxLRO] -- FINISH lro-835

What does disk utility (not finder) show for free space inside the guest?

Make sure you disable time machine in the guest, then open terminal and do

tmutil listlocalsnapshots

It shouldn't return anything.  If it does, you'll need to use tmutil to manually delete each one in turn.  Once that's done, reboot and you should be clear.

The box was checked.  I un checked it and restarted the computer and loaded VM and it worked as it should.  Thank you for your help.

Wayne