vThinkBeyondVM's Accepted Solutions

are you getting this error while connecting to web client or vSphere Think client (C#client)? I am not sure you have read this blog post: Goodbye vSphere Client for Windows (C#) – Hello HTML5 - VMware vSphere Blog What's New in vSphere 6.5: vCenter Server - VMware vSphere Blog

As per official API documentation@ VMware.Vim.VirtualMachineRelocateSpec , We can just specify target datastore, hence any vSphere SDK + PowerCLI also must honor it. Can you please post your script here?

Hi Hari, Good point. DRS behavior can be changed to consider consumed memory as well. From 5.5 U2c and above, DRS does consider consumed memory as well. How much it considers is specified in below KBs. Refer: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2059868 There is one more KB linked into above KB. Please have look into that as well. As per me, alarm is bit generic, it works even without DRS. It seems, alarm is designed a way that it is not aware that host is part of DRS enabled cluster. DRS comes with enterprise license and alarm will work with basic licenses as well. are you suggesting that Alarm should be aware of the hosts those are part of DRS enabled cluster and only raise alarm as per the memory metric configured on DRS?

Both ways I have tried earlier and both worked for me and I believe it will work for you as well. Storage vMotion would be preferable. You can create a sample dummy vm (mem 10 MB, and cpu 1vCPU) and test this as well

Hi birdylarry, I have recently installed PowerCLI 6.0 R3 and I just executed "Get-Module" command and it shows all the modules we have as follows: PowerCLI C:\> Get-Module ModuleType Version    Name                                ExportedCommands ---------- -------    ----                                ---------------- Script     0.0        Initialize-VMware.VimAutomation.... Script     0.0        Initialize-VMware.VimAutomation.... Script     0.0        Initialize-VMware_VimAutomation_Cis Script     0.0        Initialize-VMware_VimAutomation_Vds Script     0.0        Initialize-VMware_VumAutomation Manifest   3.1.0.0    Microsoft.PowerShell.Management     {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Content...} Manifest   3.0.0.0    Microsoft.PowerShell.Security       {ConvertFrom-SecureString, ConvertTo-SecureString, Get-Acl, Get-Auth Manifest   3.1.0.0    Microsoft.PowerShell.Utility        {Add-Member, Add-Type, Clear-Variable, Compare-Object...} Manifest   3.0.0.0    Microsoft.WSMan.Management          {Connect-WSMan, Disable-WSManCredSSP, Disconnect-WSMan, Enable-WSMan Binary     6.0.0.0    VMware.VimAutomation.Cis.Core       {Connect-CisServer, Disconnect-CisServer, Get-CisService} Binary     6.0.0.0    VMware.VimAutomation.Cloud          {Add-CIDatastore, Connect-CIServer, Disconnect-CIServer, Get-Catalog Script     6.0.0.0    VMware.VimAutomation.Core Binary     6.0.0.0    VMware.VimAutomation.HA             Get-DrmInfo Binary     1.0.0.0    VMware.VimAutomation.License        Get-LicenseDataManager Binary     6.0.0.0    VMware.VimAutomation.PCloud         {Connect-PIServer, Disconnect-PIServer, Get-PIComputeInstance, Get-P Manifest   6.0.0.0    VMware.VimAutomation.Sdk Binary     6.0.0.0    VMware.VimAutomation.Storage        {Export-SpbmStoragePolicy, Get-NfsUser, Get-SpbmCapability, Get-Spbm Binary     6.0.0.0    VMware.VimAutomation.Vds            {Add-VDSwitchPhysicalNetworkAdapter, Add-VDSwitchVMHost, Export-VDPo Binary     1.0.0.0    VMware.VimAutomation.vROps          {Connect-OMServer, Disconnect-OMServer, Get-OMAlert, Get-OMAlertDefi Binary     6.0.0.0    VMware.VumAutomation                {Add-EntityBaseline, Copy-Patch, Get-Baseline, Get-Compliance...} See if your installation has some issues. I am running PowerCLI on Windows 7. Also, look for this : Local Operating System Support You can install VMware vSphere PowerCLI 6.0 Release 3 on the following operating systems: OS Type 64-Bit Server Windows Server 2012 R2 Windows Server 2008 R2 Service Pack 1 Workstation Windows 8.1 Windows 7 Service Pack 1 Refer: Compatibility Matrixes for vSphere PowerCLI 6.0 Release 3

1. Did you add your vCenter VM in domain and then you installed vCenter on it ? if Not, you will have to first add your domain as identity source into SSO(This can be done only through web client : use default user: administrator@vsphere.local, if its vCSA default would be "user: root/pass: vmware") & then you will have to give vCnter admin privileges to domain administrator user . 2. If Yes, please try login using webclient instead of VI client. (https://<web client IP>:9443) (If you installed all vCnter component on the same VM, then VC IP itself is web client IP, same for VCSA). Also try giving complete domain name like "VC01.com\administrator etc. (whatever is your domain). 3. If you just try "administrator", it would be local OS(The VM on which you installed VC) admin user not the domain admin user . At-least you should be able to login with this user: administrator@vsphere.local (its default SSO domain)...if its vCSA default would be "user: root/pass: vmware" Let me know if you still face the issue.

Regular patches are planned one, ESXi patch usually gets release every 3 (not strict, it changes) months(It will have bug fixes, important, critical, catastrophic, security fixes etc) . Express patch on the other hand is not planned one: It usally gets released when there is issue which is having impact on multiple customers. Also critical security fixes get into the Express patches. Checking release notes/KBs on particular patch (either regular patch or express) will help you to understand what is being fixed in the patch, based on that you can decide whether you really need to apply the patch right away or you can wait. If fixes does not impact you, then you need not to apply the patch. However, it is recommended that you apply the latest patch. Sometime you can not know when particular issue may pop up in your environment which was fixed in patch. Testing on non-production environment usually is not must (people do it just to be on safer side), they look into release notes/KBs of the particular patch and test fixed issues in the patch (those matter to them) to make sure whether fixed issues work fine or not. (some time they check whether upgrade workflow works or not ).  If it works then they go ahead and apply the patch in production. 

Yes, it can happen that VPXA is not sending stats update to VPXD. It also can happen that VPXA did not get any stats from the host itself. 1. Login to the host (SSH) which is not showing any stats: and execute below command /etc/init.d/vpxa restart (or stop and start) 2. how long you are getting these values as zero? Usually when host connects to the vCenter, it takes around 30-70 Sec to get stats displayed on VI client. 3. is your vCenter got restarted recently (right before stats are zero)? is DRS/HA also enabled on cluster? Answer to above queries will help to take this forward

Yes, that is best practice. However, I usually deploy vcenter for my testing  and almost 99% of times, I did not add vCenter VM to domain and it worked just fine for me in test environment. Later I use to add domains as identity source in order to give permissions to domain users. If it is production environment, it is always better to add it to domain.

As per me, we can do this. Plz refer:VMware KB: Sharing an RDM virtual disk between multiple virtual machines Check this as well :vSphere 5.5, RDMs and Microsoft Clustering | CormacHogan.com

It is expected. Even though 5.5 supports max VMDK size 62TB, VI client will continue to show it as 2TB as all new features from 5.5 are supported in Web client. If you check the same from web client, it will definitely show 62TB VMDK as max size. If you want to create VMDK size more than 2TB, you will have to use web client. All features upto 5.1 are fully supported on VI client.

Yes. Answer is 100% correct. If configured VM-Host affinity/anti-affinity rule is MUST, it can not be violated. Even vSphere HA honors the VM-Host must rules. Even you can not manually migrate that VM1 to other Host. Maintenance mode also can not evaluate the host. Even if there is CPU/Memory imbalance, DRS will still obey this rule. If you want this rule to be flexible, then you can configure the same as "soft/should" rule. In this case, rule will be violated whenever it is absolutely required(like MM, HA does not honor this rule, you can manually migrate that VM to other, DRS for the sake of balancing cpu/memory can violet this rule) But note that in the immediate next invocation of DRS, DRS will try its best to resolve the rule violation. To know which rules can be honored by vSphere HA :is vSphere HA aware of DRS affinity rules? | vThinkBeyondVM Let us know if you need any other clarity.

No.  vMotion across datacenter is NOT supported with latest version of vCenter ie. vCenter 5.5. Even with linked mode vCenter its not possible : When vCenter Server systems are connected in Linked Mode, you can perform the following actions: ■ Log in simultaneously to vCenter Server systems for which you have valid credentials. ■ Search the inventories of the vCenter Server systems in the group. ■ View the inventories of the vCenter Server systems in the group in a single inventory view. You cannot migrate hosts or virtual machines between vCenter Server systems connected in Linked Mode. Refer:vSphere 5.5 Documentation Center However, As per VMworld 2014 announcement. we can expect vMotion across datacenter as well as vCenters in upcoming release of vCenter. Refer:vMotion Enhancements for vSphere 6 Announced - Wahl Network

I believe there is no difference between vCenter licenses across windows & appliance.  You will get vCenter license (as whole) and now its your choice to deploy vCenter either on windows or deploy the same as appliance. Once deployed you need to apply the  license. If you go for vCenter foundation, you will get same set of features either you deploy the VC on windows or as appliance. Same applies to vCenter standard license. If you deploy on windows, you need windows license as well. Refer: Buy VMware vCenter Server: Management for Virtualization Systems | United States Let me know if you need clarification

When ESXi host where vCenter VM is placed goes down, as HA is enabled, vCenter VM will get restarted on other available host (or dedicated failover host) in the HA enabled cluster. vCenter is required to just manage & configure vSphere HA. Once configured, even if vCenter goes down, HA will work as HA agents are there on each ESXi host. Note that failed over vCenter VM will restart, hence there will be downtime till the VM gets restarted and all the vCenter server services also gets restarted. In case of HA failure, VMs on failed host do not vMotion. It gets unregistered from failed host >> VMs will be registered on available host & restarted. in case of vMotion there is no downtime but in case of HA failure there will be minimal downtime as VMs will be restarted.

Please use below VMware documentation for the same. https://pubs.vmware.com/vsphere-50/index.jsp#com.vmware.vsphere.vm_admin.doc_50/GUID-D18E6A2F-03FB-48AC-A2C4-EBCB9E27B9BC.html Let me know if you have any doubt.

Even though you disable VM restart priority" and "VM monitoring", until VM is in powered ON state, vSphere is going to say "VM" is protected. 1. if VM restart policy is disabled & VM monitoring is enabled: Host is up and VM is up, vSphere HA will keep in protected list.               >> when host fails, VM can not be restarted on other available host. Even If failed host comes back, still VM will not be restarted, it will be powered OFF and now vSphere HA will remove that VM from protected list.              >>When Guest OS fails, HA will restart that Guest on the same host and HA continue to keep in protected list. 2. if VM restart policy is disabled & VM monitoring is disabled: Host is up and VM is up, vSphere HA will keep in protected list.                     >> when host fails, VM can not be restarted on other available host. Even If failed host comes back, still VM will not be restarted, it will be powered OFF and now vSphere HA will remove that VM from protected list.              >>When Guest OS fails, HA can not  restart that Guest on the same host but as VM itself does not have any issue (VM is ON but you can not access Guest), HA continue to keep that VM in protected list. 3.if VM restart policy is Enabled & VM monitoring is disabled: Host is up and VM is up, vSphere HA will keep in protected list.            >> When host fails, VM will be restarted on other available host. , After restart , it will be powered ON and HA continue to keep that VM in protected list              >>When Guest OS fails, HA can not  restart that Guest on the same host but as VM itself does not have any issue (VM is ON but you can not access Guest), HA continue to keep that VM in protected list Note that there is difference between VM failure and GOS failure. let me know if you have any doubt.