vmEck's Posts

Check with 3PAR on their recommended PSP. It could vary based on the exact array and software version. I would think, though, that if all of these datastores are on the same array the PSP should be consistent. There may be valid exceptions but I'd definitely start with looking at 3PAR's recommendations.

What version of vCenter/vSphere are you running? Do you have stretched layer 2 networking? SRM would be a great tool for orchestrating this. It'll use vSphere Replication and then orchestration the IP changes if you have different networks in Orlando. There are some other 3rd party tools like Zerto that would also help.

Take a look at the resources here that will walk you through the subordinate CA pieces. You have an additional CA you need to add to the chain of trust but that should be easy enough. Otherwise it should be a very similar walkthrough. You can watch the youtube videos or hit the link to the feature walkthroughs site. The slide deck might also be helpful. http://vmware.com/go/inf4529

From the workstation you're attempting the migration from, can you ping vcenter.localdomain? That doesn't seem to be an FQDN although using the IP address should work even if DNS is not properly configured. Can you get to https://10.0.0.3:5480 from that workstation?

You might want to review this KB - https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002511 The TL;DR version - Each disk drive for a virtual machine consists of a pair of .vmdk files. One is a text file containing descriptive data about the virtual hard disk, and the second is the actual content of that disk. For example, a virtual machine named examplevm has one disk attached to it. This disk is comprised of a examplevm.vmdk descriptor file of under 1 KB, and a 10 GB examplevm-flat.vmdk flat file which contains virtual machine content.

If you're moving the hosts and VMs then just power down the VMs, move the host networking over, login to each host's DCUI and change the IP settings. Connect it to vCenter and change the rest of the VSS networks, then change the VM networks and boot the VMs. No need to export the VMs unless I've misunderstood something.

npadmani‌ - You are partially correct. The problem with your process is that you'll end up with 2 vCenters with embedded PSCs that have 2 unique SSO domains. In 6.0 we do not have a way to merge SSO domains or move a vCenter from one SSO domain to another. So, in order to end up with 2 vCenters in the same SSO domain, first the OP needs to get the 2 vCenters to a common SSO domain prior to moving to 6.0. To do this deploy a new 5.5 external SSO instance at each site and then re-register the 2 vCenters to the new SSO instances. Remove the embedded instances once everything is verified to be working. Refer to VMware KB: Migrating embedded VMware vCenter Single Sign-On to an external VMware vCenter Single Sign-On deployment Next, upgrade the external SSO instances to 6.0 PSCs. Finally, upgrade the vCenters to 6.0.

You're correct. It depends. I would say that, in general, it would continue to be best to separate out the app and db tiers. You could create DRS rules to run those VMs on different hosts or you could set reservations to guarantee resources to one or both VMs. Combining them may be simpler from an operations and deployment perspective but I would suggest keeping them separate. There are certainly exceptions and it depends on the specifics of the application, database, and workload characteristics.

It may or may not work. I've seen it go successfully as well as fail - depends on config. The bottom line is that it is unsupported and so the OP would be taking a big risk by attempting to do this.

Backup/Restore of just the vCenter database is not enough to fully restore a vCenter. Some of the state data lives outside as part of the Inventory Service along with SSO (if using the embedded PSC). Certificates will also not be restored because they are not kept in the vCenter database. There is no way to change the hostname (PNID) of vCenter (Windows or vCSA) after deployment. A reinstallation is required.

It is a bit odd that you can't even change the case of the hostname. I wouldn't expect this. I'll see if I can get a comment from engineering on this. Otherwise, changing the Primary Network Identifier (PNID) of the vCenter Server or PSC is currently not supported and will cause the vSphere services to fail to start. If the vCenter Server or PSC has been deployed with an FQDN or IP as the PNID, you will not be able to change this configuration. VMware KB: Changing the IP address or hostname of the vCenter Server or Platform Service controller cause services t…

This is expected behavior. Changing the Primary Network Identifier (PNID) of the vCenter Server or PSC is currently not supported and will cause the vSphere services to fail to start. If the vCenter Server or PSC has been deployed with an FQDN or IP as the PNID, you will not be able to change this configuration. VMware KB: Changing the IP address or hostname of the vCenter Server or Platform Service controller cause services t…

You'll probably want to open an SR with GSS to get that coredump analyzed. Otherwise, are the source and target hosts running the same ESXi version? Is that VM using the E1000 or VMXNET3 ethernet adapter? Does it happen each time you vMotion that VM? Does it only happen on that new host or can you reproduce it on other hosts? What about if the VM is powered off?