Relocation RHEV-M environment to a new subnet

Latest response

The problem. We have a small rhev environment running a self-hosted engine. Also in this cluster is our Satellite server. I have four hosts; two are the primary cluster in the lab (self-hosted & satellite, plus a couple VMs), and another two host cluster in our computer room.

Up until the other day, all were on 172.19.180, and all was good. Then the networking in the lab was changed to 172.19.67, and the computer room stayed at .180. It's a very long story as to why we ended up in this mess, but just need to figure out how to get my lab cluster running on .67.

I have connected the two hosts (still at .180) to a stand alone switch to see if the cluster would come up. The self-hosted engine does come up, but it's far from happy. I can get into it's GUI.

I do have the backup of the engine, as well as backups of all of the hosts & VMs.

Does anyone have any suggestions on how to proceed?

Thanks, Greg

Responses

How did you setup the networking? Do you use VM and management networks like mentioned in https://access.redhat.com/solutions/1158073?

Each host (two of them) have a dual port 1gb network card. The ports are set up a bond.

The management network was set to 172.19.180. All traffic, including the VMs was going through this connection. It's not a lot of traffic.

This is "learning how to use" RHEV environment. We have almost exclusively HP-UX.

All our hosts have two physical network interfaces combined in a bond.

According the best practice (https://access.redhat.com/solutions/1158073) we configured separate vlans on top of the bonds.

One vlan ovirtmngt for all RHEV related traffic (hosted engine <=> hypervisors). The hypervisors are also accessible for administrators via this interface. An additional storage vlan is configured for an NFS backend containing many templates and VM's. Finally we have two VM networks on which 2 separate sets of VM's live.

Moving a VM from one VM-network to the other VM-network only requires stopping the VM, editing the properties of the VM and then a restart.

In your case I would configure the vlans for the hypervisors, then add these networks to the hosted engine and finally assign them to your VM's.