Thanks for the answer continuum.
This indeed the case that this datastore is in single SATA disk.
Before actual change, I wanted to check in the following way - I umnouted and deleted it from current ESXi and then wanted to add it one more time on the same server - this was not successful. I was able to add it only as a new datastore so I was loosing all files on it.
So you are saying that changing it to another server is something different than deleting and adding back on the same one?
If a host is being added to an EVC enabled cluster, and it's processor meets the baseline requirements, will it need to be rebooted as part of the process?
Without enabling EVC you cant archive want you want. The reason why you see a partial vMotion is most likely where you have the VM startet on your oldesd Hosts you should able to move it to newer once, but as soon as you start the VM on your latest youare unable to move.
Now we add 2 more variables.
If you patch one of your older ones against Meltdown, Spectre, Zombiload the CPU can have now more Features as one of your latest Hosts. This is the reason why you should upgrade vCenter first because VMware have made changes on EVC Mode. There is a KB about that.
Normaly, if having different ESXi versions within a cluster is not a big deal because this is what you automaticly have when upgrading a cluster from X to Y.
Regards
Joerg
Kermit was created on Workstation or Fusion and does not use ESXi-compatible VMDKs.
Either shrink the vmdk on WS or Fusion or import it via
vmkfstools -i kermit-000001.vmdk esxi-compatible.vmdk
first.
You do not need to read the random links provided in the previous reply.
Manual Regeneration of Certificates solved the issue
https://kb.vmware.com/s/article/2070603 -> Regenerating Self-Signed SSL Certificates in VMware vCenter Server appliance 5.1 or 5.5
> then wanted to add it one more time on the same server - this was not successful.
At that time you should have followed the KB I referenced before.
When ever you re-add an already existing VMFS-volume it should either automount or you need to check wether it is detected as a snapshot.
Stay away from the "add new datastore wizard: - that guy is only good for creating new VMFS-volumes.
The only problems i have had are the one i mentioned and using the ip for the master node. Failed because i was using the load balancer IP
Here is what i see.
ocalhost ~]$ uname -r
5.1.6-300.fc30.x86_64
localhost ~]$ rpm -qa | grep kernel- | sort
kernel-5.0.9-301.fc30.x86_64
kernel-5.1.5-300.fc30.x86_64
kernel-5.1.6-300.fc30.x86_64
kernel-core-5.0.9-301.fc30.x86_64
kernel-core-5.1.5-300.fc30.x86_64
kernel-core-5.1.6-300.fc30.x86_64
kernel-devel-5.1.5-300.fc30.x86_64
kernel-devel-5.1.6-300.fc30.x86_64
kernel-headers-5.1.5-300.fc30.x86_64
kernel-modules-5.0.9-301.fc30.x86_64
kernel-modules-5.1.5-300.fc30.x86_64
kernel-modules-5.1.6-300.fc30.x86_64
kernel-modules-extra-5.0.9-301.fc30.x86_64
kernel-modules-extra-5.1.5-300.fc30.x86_64
kernel-modules-extra-5.1.6-300.fc30.x86_64
@localhost ~]$
The reason why you see a partial vMotion is most likely where you have the VM startet on your oldesd Hosts you should able to move it to newer once, but as soon as you start the VM on your latest youare unable to move.
I had suspected that in the beginning, since I was able to move vms from the host running 6.5 to the one running 6.7. However, after I cleared off the 6.5 host, I was no longer able to move vms between any hosts except for the 2 with identical CPUs running the same ESXi version
If you patch one of your older ones against Meltdown, Spectre, Zombiload the CPU can have now more Features as one of your latest Hosts. This is the reason why you should upgrade vCenter first because VMware have made changes on EVC Mode. There is a KB about that
I had read several article regarding vulnerability patches, and how the migration process would deny migrations if those patches were inconsistent between the hosts. However, I didn't think vulnerabilities were the issue, since the errors listed unsupported CPU features as the reason the migration failed.
Normaly, if having different ESXi versions within a cluster is not a big deal because this is what you automaticly have when upgrading a cluster from X to Y.
I had not thought about that, but that is good to know
To clarify my question: Why did our original configuration allow migrations, and why does our current one not (except between Hosts 1 and 2)? I understand that an EVC enabled cluster is the answer, but I'm trying to understand why it worked in the first place, and why it doesn't now.
Hello, I'm usung an external tool (Saltstack with salt-cloud commands) and checking the cloned VM the unattende xml generated by VMWARE for the sysprep commnad has the below commnads.... is there a way to add my one custom command after those? (there is another section FirstLogonCommand that also has some commands and that part we can add commands to).
In other words, does anyone have any clue where do these 4 default RunSynchronousCommand wcm:action="add" get added or generated?
Or is it something VMWare has stored in a file or DB as a defualt unattended.xml/sysprep.xml (answer file) in case the user doesn't provide it?
Thanks!
<RunSynchronous>
<RunSynchronousCommand wcm:action="add">
<Path>C:\sysprep\guestcustutil.exe cleanBootExecute</Path>
<Order>1</Order>
</RunSynchronousCommand>
<RunSynchronousCommand wcm:action="add">
<Path>C:\sysprep\guestcustutil.exe restoreMountedDevices</Path>
<Order>2</Order>
</RunSynchronousCommand>
<RunSynchronousCommand wcm:action="add">
<Path>C:\sysprep\guestcustutil.exe flagComplete</Path>
<Order>3</Order>
</RunSynchronousCommand>
<RunSynchronousCommand wcm:action="add">
<Path>C:\sysprep\guestcustutil.exe deleteContainingFolder</Path>
<Order>4</Order>
</RunSynchronousCommand>
</RunSynchronous>
Hi,
I am running vCenter upgrade pre-check command and it is getting failed. I have updated hostname and regenerate the certificates correctly. I am trying to upgrade 5.5 to 6.5 and getting below error
2019-05-17 16:40:49,772 - vCSACliInstallLogger - DEBUG - --------------------------------------------------------------------------------
2019-05-17 16:40:49,772 - vCSACliInstallLogger - ERROR - Pre-upgrade check error: 1. Title: The vCenter Server Appliance FQDN testvca does not match the configuration of the vCenter Server certificate.
vCenter Server DNS names: "testvca.testgw.testphone.net"
vCenter Server IP addresses: ""
2019-05-17 16:40:49,773 - vCSACliInstallLogger - ERROR - Pre-upgrade check error: 1. Details: The vCenter Server Appliance FQDN ndc2cnz03mspvca does not match the configuration of the vCenter Server certificate.
vCenter Server DNS names: "testvca.testgw.testphone.net"
vCenter Server IP addresses: ""
2019-05-17 16:40:49,773 - vCSACliInstallLogger - ERROR - Pre-upgrade check error: 1. Suggested Resolution: Verify that the vCenter Server certificate is valid and that it points to the vCenter Server Appliance FQDN.
2019-05-17 16:40:49,781 - vCSACliInstallLogger - DEBUG - --------------------------------------------------------------------------------
2019-05-17 16:40:49,781 - vCSACliInstallLogger - INFO - Basic requirements:
2019-05-17 16:40:49,782 - vCSACliInstallLogger - INFO - Estimated disk space required on source VM for export data: 2.77 GB
2019-05-17 16:40:49,782 - vCSACliInstallLogger - INFO - Estimated total disk space required on target VM: 3.19 GB
No, the host won't need a reboot.
However, if the EVC mode is lower than the host's CPU features, and you have powered on VM on that host, you will need to shutdown those VMs (or migrate them off from this host).
André
I get it. The VMs would be asking the hypervisor for CPU features they couldn't use.
Then just remove 11.2.0 (as I described above) and reinstall 6.5
Hi all,
First real quick: ESX 6.5 (7967591), FCoE, NetApp backend, Cisco UCSB (Flexpod configuation)... OS: Windows 2012 R2
So, the cluster is being setup to support SQL (nit installed yet)... For my disk layout, C: (OS), D: (SQL Binaries) and Shared E: (Bkup), G: (Data), L: (Logs), T: (Temp), Q: (Qrm)
Shared on one SCSI controller and "local" on another. Both Paravirtual, Physical, etc.
** I used VMWare's published Windows Clustering guide for CAB (cross across boxes)
When running validation wizard, I get
As per VMWare support:
++ As per the best practices of Cluster Virtual Machines Across Physical Hosts on VMware vSphere 6.5 , we can have only one Virtual Disk mapped (booting) rest all should be P-RDMs
And I can map through D: as an RDM (which is what I am bein told to do), but it makes no sense to me... And yes, if I drop my D: drive, the problem goes away. And yes, I can install SQL to C:...but really??? I can only have one virtual disk!
What if I wanted to leverage my SDD local datastore for TempDb... a common scenario. I couldn't?
More details:
D: was not part of the Available Storage disks or any cluster resource
D: shows up as a Local Disk
Tried changing SCSI to LSI SAS... still no....
Note: NetApp on the backend;
SO........... Anyone ever heard of a restriction on the Virtual Disk count. I can't find any documentation and vmware support just says it's common practice????
The VM's configuration (.vmx) file, and the vmware.log file show diffetent virtual disks!?
The vmware.log contains:
scsi0:0.fileName = "EVE-2019.vmdk"
scsi0:1.fileName = "\\Rdn_nas01\NFS_3_NC\EVE-2019\EVE-2019-0.vmdk"
The .vmx file however shows the same virtual disk file twice, which is likely causing the error.
scsi0:0.fileName = "EVE-2019.vmdk"
scsi0:1.fileName = "EVE-2019.vmdk"
Either fix the configuration, so that each virtual disk points to its own .vmdk file, or remove the "scsi0:1" lines from the .vmx file.
André
Hi I'm trying to install the feature update from Microsoft to Windows 10 May 2019 update(1903). Post installing updates when system gets restart to finish the update it will get stuck at boot. I see only windows logo, and not even the spinning wheel. I'm using VMWare profession version 11.1. Can somebody help ?
Hi, I noticed you are using a non-default name for VMmark3.properties. Could you try reverting your file VMmark3.tile0.weathervane-auction.properties back to the default name VMmark3.properties (and following the instructions in the User's Guide to support that under "Starting a VMmark Run Through The GUI"). Also please comment out the line DS3DB/DS3DBsize = 100.
Also, could you please zip the results file from your most recent run and attach it to this thread.
Thank you,
Rebecca
Hey tantis14, If HCX is still stretching your network (ie you retained your IP address and Default Gateway), all of your VM traffic is being routed through your on-prem environment. This means that once it hits on-prem, it's unable to route back to AWS. At this point, You'd need to unstretch the network or move your VM to a new subnet that is not stretched.