Duplicate or Replicate ESXi Host or VMs

[Jessicasdd]

Our current environment has two VMware servers, They both point to the same VMs that are stored in a NAS. I can connect to either one and see the exact same information on the VMs.

How would I do that same configuration with our new server? I again purchased two servers and have ESXi 6.7 installed. I have the two VMs loaded on one of the servers. If I register either VM on either of the servers I cannot access them on the other server, so I know registering is not the solution.

So I'm not sure if I should be reading about duplication or replication. Replication didn't seem like the right information but I could be wrong and just not understanding it correctly.

Any help is greatly appreciated.

Thanks,

Jessica

[Scott Vessey]

Manage the hosts with vCenter Server, setup HA, and backup/replicate your VMs.

[Jessicasdd]

We don't have vCenter Server. We are using the web host. I'm sorry, I should have included that in the original post.

Thanks,

Jessica

[Scott Vessey]

I understood that, I was suggesting you deploy one and use it to manage your hosts and VMs.

[Jessicasdd]

Unfortunately, due to cost, it's not an option I have. :smileysad:

[Scott Vessey]

What are you actually trying to achieve regarding your VMs then?

[Jessicasdd]

Right now we have two servers that have ESXi installed. I can log into the host of either one and see the two VMs that we have on our NAS.

We purchased two new servers with ESXi installed. I have the VMs registered on one of the servers. How do I see those VMs from both servers?

I'm just trying to set up the new servers the way the old servers are set up.

Thanks,

Jessica

[Scott Vessey]

But why do you want to be able do that? What sort of administrative tasks do you want to be able to carry out?

[Jessicasdd]

Manual failover. With the VMs being stored on the NAS, if one of the server fails I can still get to my VMs with the other server.

Thanks,

Jessica

[StephenMoll]

It is possible to register a VM on more than one host, as long as you don't have vCenter running, which you don't. vCenter will remove extra registrations automatically.

When you start a VM on a host a "*.vmx.lck" file will be created by the host running the VM, which will prevent the VM from being started elsewhere. What this means that depending on why you need to start the VM on the alternative host, this file may still be there. For example if the host running the VM has failed rather than shutdown cleanly, leaving the LCK file in the VMs folder on the datastore. You would need to delete this file before the VM can be powered on. You will also be faced with a question to answer each time you swap to using the VM on a different host to the previous time. The host will question you as to whether the VM was copied or moved. In your case this will be "I moved it". Lastly the guest OS will not have shutdown cleanly and may need manual interventions to getting it back up and running again, but this will depend largely on the guest operating system and the installed applications.

To be honest though I don't see the need to pre-register a VM on multiple hosts like this. In my opinion it is inviting mistakes and problems. For example, answering the moved/copied question wrong could break licensed software on the VM, as a copied VM will get a new identity, and software keyed to the MAC address for example would stop working because the MAC address will change.

Also because in a real host failure situation you are going to have to log into the new host, and check the LCK file is deleted, you might as well only re-register the VM there and then, because this action is conducted in the same place.

I.e.

After host fails:

(1) Log into alternative host.

(2) Browse datastore to the folder of the VM you wish to power on.

(3) Look for and delete the *.vmx.lck file if it exists.

(4) Right click *.vmx file of the VM and select "Register VM".

(5) Close Datastore Browser.

(6) Locate the VM in the Navigator and "Power On"

Lot's of places where this could go wrong, and the security that vCenter brings is recommended if this is a production environment you're talking about.

[Jessicasdd]

Unfortunately, I didn't set the last scenario up. We had an outside firm handle the setup and we just ran with it. Whatever they did worked though because when the one host did fail we were always able to get to the VMs on the second host. It worked. I don't know how or why, it just did. Before it failed we were able to look at the VMs from both hosts.

I called that same firm and they are going to come in and help us out. When they are done maybe I can provide more of an explanation of what they did and how it worked. The only thing he said was that the VMs have to be on the NAS for it to work. If it is on the local drive then the other host can't see it. As long it's on the NAS it can be added to the inventory of both hosts.

I don't know and I don't understand it so, like I said, hopefully I can get a better explanation when they come in and post here what was done.

Thanks,

Jessica

[Scott Vessey]

I would still suggest you deploy vCenter Server - there’s a lot to gain including live migration and automatic failover.

[NathanosBlightc]

You don't have any special options if you don't want to setup the vCenter server for managing hosts & VMs. In the virtual environment with a shared datastore, you can only register the VM again via the *.vmx file and add it to the second ESXi host ( in this path: /vmfs/volume/[datastore]/[vm-dir]/vm-name.vmx)

Until you manage the ESXi hosts standalone there is no failover option, becasue the hosts are separate components without presence of the vCenter Server and couldn't reach each other's heartbeat and find-out the status of a failed ESXi. So you should do every action manually to add and power-on the VM on another healthy ESXi that has access to that NAS storage.

[Jessicasdd]

Amin, that's kind of how they described it. I can update this after they are done to let you know what they did, if you'd like me to.

This was his wording,"VMware replication is not what you need.  Since you are doing manual failover, the process would be to power on the backup server, then manually add the VMs to inventory and power them on.  There’s no other way to do it.  They cannot be registered to two VMware hosts at the same time."

All I know is that we have been running this way for the past 7 years but have never needed to use it.

Thanks,

Jessica

[StephenMoll]

They can be registered to two hosts at once, I tried it last week and it works, but it doesn't make sense to me to do this for other reasons as I explained before.

Other than that the advice you have been given sounds much as I explained before too.

I would add that not needing this in the last 7 years may have been lucky as I suspect that you might not have known to delete the lock file in order to bring the VM up on the spare server.

[Jessicasdd]

No, you're right, I wouldn't have known to delete any lock files to bring the VM up on the backup server. Thankfully that company does our backup so they are my backup in case something were to happen. Going forward I have learned more about our network and the setup that we weren't privy to in the past. This time I have done most of the setup and configurations in preparation for the upgrade. This was the most important thing left that I didn't understand. I am going to watch like a hawk to see what he does. Not that it matters, he usually explains to me what he is doing now that he is the boss. LOL

[StephenMoll]

I'd echo again to your bosses that vCenter would be a good idea, and with vSphere Essentials surely not something that would break the bank.

Good luck with it anyway.

[5mall5nail5]

Jessica -

I know you said vCenter is not in the budget, but there is a vSphere Essentials kit which would provide licensing for 6 sockets (so 3 2-CPU hosts), and vCenter Server essentials.

https://store.vmware.com/store?Action=cat&Env=BASE&Locale=en_US&SiteID=vmware&categoryID=66192900&src=eBIZ_StoreHome_Featured_Essentials_US

It's $576

This would give you proper multi-host configuration/monitor/etc. without the risk of having lock file or multi-registration issues.