tomtom901's Accepted Solutions

John, I know, that shouldn't be a problem. You can just consolidate the disks. The reason it mentions this, is that when a snapshot is made, a new delta vmdk (VM disk file) is created. All new changes from that point are saved in that new VMDK, but since you aborted the snapshot process, the VM is most likely running on a delta disk but the snapshot database does not report a successful snapshot. Let me know if it works out for you,

Is this the only VM with this issue, if not, have you checked if the scope is authorized, DHCP server itself is started? Both servers are on the same port group? Basically the same questions as the poster above me.

Sure, no problem. Make sure you see both paths though, under Configuration -> Storage Adapter -> Select your iSCSI adapter. Example like this. In this case I have 12 devices with 24 paths, so 2 paths to each device (LUN). You can also mark answers as helpful or correct if you'd like.

VMXNET3 is the paravirtualized adapter from VMware, less overhead (so more speed), and a 10 GbE connection. Only disadvantage, you need the VMware Tools installed in most to all guest OS'ses. So yes, I'd go with that, but which guest OS are you trying to virtualize?

Did you configure the Windows NFS share like this? With the below esxcli command, I could mount the share mentioned above without any issues. Note that I've set the allow root access bit under the permissions of the Advanced NFS sharing. That might resolve your issue if you have not enabled this. esxcli storage nfs add --host=192.168.1.10 --volume-name=NFS --share=ns

Basically, when the datastore is full, and a VM on it is requesting I/O, due to the fact that it is thin provisioned, it is being paused by ESXi. All VM's that are not requesting I/O can still run. When this happens, you get an error message like this: What the VM throws at you is basically a VM Message. Using vCenter, you can create an alarm that triggers when the VM has (a specific) information message. The message I used was something like this: When I then let a VM on a thin provisioned datastore, using thin provisioned disks run out of space, my custom alarm was triggered. N.B. I only saw the VM's icon in alarm state after I clicked retry on the popup. If you don't do this, the VM's icon will be in question state, but the custom alarm will still be triggered. Hope this helps, Tom

You could create a DRS rule for this (keep virtual machines together). HA and DRS can compliment eachother and in the event of a host failure, DRS will ensure both VM's stay together. You do this on the edit settings part of your cluster. See a screenshot here:

If you have already configured the scratch location (scratchconfig.configuredscratchlocation) and rebooted the host, all the syslog files will already be put on the specified datastore. Also setting the syslog.global.logdir to the datastore isn't needed.

Do your VM's use an E1000(E) NIC? If so, this might be related: Re: Reproducable PSOD on 5.1U1 and 5.5 with Windows 8.1 and Server 2012 R2 and E1000E NIC Try to keep VMXNET3 the prefered vNIC.

Yes, you need to stop the Exchange Services. But Exchange 2010 has a nice wizard for this, which can stop the database services, move the logs automatically and remount the database. It's located under Organization -> Mailbox Leave the database as is, but only change the Log Folder Path.

That would work indeed. You need to do some CLI commands to mark the device as local and SSD but I have outlined the steps in a post on my blog: http://tomverhaeg.nl/vmware-esxi/vmware-esxi-tag-a-device-as-local-and-ssd/

It's indeed referring to the ESXi host license. The web client only comes with a vCenter server. If you open up the vSphere client and connect to your ESXi host, under configuration -> Licensed features, you can edit the license key and fill in the needed one. In the screenshot, the steps are outlined.

If you've setup the vCenter correctly as NTP server (you did - you've tested it) I don't see a problem with this. Most people use either: Public NTP servers, which can work fine, when managed / firewalled Internal NTP servers Dedicated time appliances So, no, I don't see a problem here and if it works for you, it's a good practice. It's also nice to see that you think about security (by not giving your hosts direct access to a public NTP server) in production (?) environments.

Hi Gabrie, No, I meant esxcli storage core device list -d <naa ID>. I'll show you what I did. Default PSP for my VMW_SATP_ALUA plugin was VMW_PSP_MRU and I first took note of the naa ID of an existing LUN on this storage array (it's a QNAP NAS ).  I then ran esxcli storage core device list -d naa.6001405f96715a2d050bd4648db766dc, which provided me with this output. Note that the Vendor and Model both turn up here. I used this information in a custom SATP rule to let all devices with this model / vendor combination use Round Robin: ~ # esxcli storage nmp satp rule add -V QNAP -M "iSCSI Storage" -P VMW_PSP_RR -s VMW_SATP_ALUA ~ # esxcli storage core claimrule load Now, note that a new device that is created on this array gets Round Robin, just as we want it. Hope this clears things up for you.

Non compliant means that the host isn't running the same build as the ESXi image. Therefore, it isn't compatible with the host upgrade baseline. You can then remediate to perform the host upgrade. Hope this helps,