Cluster Migration

[liane]

Hi,

I'm running a Proxmox VE with four OpenVZ containers without any problems (OVH distro, modified to use LVM2, I must say)

I now want to go to the next stage, managing a cluster.

I followed the guide on the wiki, and here is where I'm having a few problems:

1/ for security reasons, I always change ssh access to:
- no root login
- change port
It seems that I had to revert these changes to allow the two boxes to communicate.

2/ with root login on port 22, all is right, so I've set up my master and node, then tried to migrate one test VM from the master to the node.
Live migration failed, and a search on the forum informed me that it is a known glitch.
So I tried a non-live migration, that succeeded, but with unexpected results: I coudn't access anymore the migrated VM.
Migrating back this VM to the master, I recovered access instantly.

Of course, the IP for the VM always pointed to the master, but I thought (wrongly perhaps) that the data for this IP would be tunneled to the node when the migration was done, thus giving me plenty of time to point this IP directly to the new box.

so either I misunderstood the expected behavior of the migration option, or I have something wrong in my system.

Could you please tell me what I could check if it is the latter?

 

[dietmar]

Of course, the IP for the VM always pointed to the master, but I thought (wrongly perhaps) that the data for this IP would be tunneled to the node when the migration was done,

There is no tunnel for standard ip traffic.

thus giving me plenty of time to point this IP directly to the new box.

Confused. What does 'point this IP directly to the new box' means?

 

[liane]

There is no tunnel for standard ip traffic

oh, could I make it a feature request then?

Confused. What does 'point this IP directly to the new box' means?

well, I have a pool of IP addresses, say IP1, IP2...IPn. Each one is pointed to a physical box, either the master or the node, depending on which VE the VM is hosted.
If I have a VM on the master, using IP1, and I migrate this VM to the node, once the migration is done, no data will go to this VM because the IP1 traffic is still going to the master physical box. I need to manually use the location facility to direct IP1 traffic to the node box, instead of the master.

I'm sure I missed something here, because I don't see the point of doing live migration in this case?

 

[dietmar]

I'm sure I missed something here, because I don't see the point of doing live migration in this case?

You normally do not harcode any routes - insteasd use arp (arp proxy).

 

[liane]

You normally do not harcode any routes - insteasd use arp (arp proxy).

I'm not familiar at all with arp proxy (I never heard of it actually), but a quick search leaves me suspecting it will work with bridge, not venet (the only option allowed by the hosting companies I know, OVH in my case).

Am I wrong or is there another option to allow smooth migration of VMs using venet between boxes with one NIC?

 

[dietmar]

With venet it works out of the box (just remove the static route).

 

[liane]

With venet it works out of the box (just remove the static route).

ok, I'm definitely lost here, guess I didn't explain properly.

I have 2 VEs in cluster, VEMaster and VENode.
On VEMaster, I have one VM called test.domain.com, using venet on the IP 1.2.3.4

so in VEMaster, I have:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
test.domain.com  *               255.255.255.255 UH    0      0        0 venet0

when I migrate test.domain.com to VENode, the static route properly appears in VENode, and not anymore in VEMaster, but since traffic for IP 1.2.3.4 is still directed to VEMaster, it never hits the VM test.domain.com (which is now on VENode).

If it should work right out of the box, then I probably need to fix something here (on VEMaster I suppose), but I'm at a lost knowing where and what?

 

[dietmar]

when I migrate test.domain.com to VENode, the static route properly appears in VENode, and not anymore in VEMaster,

what route are you talking about?

but since traffic for IP 1.2.3.4 is still directed to VEMaster, it never hits the VM test.domain.com (which is now on VENode).

Why is traffic still directed to VEMaster?

 

[liane]

Why is traffic still directed to VEMaster?

And how would it magically be directed to VENode?
My boxes are rented from a hosting company, and it is a manual process on the hosting panel to direct IP traffic on a specific physical machine (in this case VEMaster or VENode).

That's why I suggested in the first post some tunneling to allow the VM to work *after* the migration is done, and *before* I had a chance to direct the IP traffic to the node (and this can take from some minutes to half an hour)

 

[dietmar]

And how would it magically be directed to VENode?

ARP

My boxes are rented from a hosting company, and it is a manual process on the hosting panel to direct IP traffic on a specific physical machine (in this case VEMaster or VENode).

That's why I suggested in the first post some tunneling to allow the VM to work *after* the migration is done, and *before* I had a chance to direct the IP traffic to the node (and this can take from some minutes to half an hour)

I guess you should ask on the OVH forum how to setup a cluster correctly.

- Dietmar

 

[liane]

ARP

ok, I'll dig that

I guess you should ask on the OVH forum how to setup a cluster correctly.

hum, since it was not an OVH specific issue (this configuration will appear with any hosting company), I kind of imagined that some explanation could have been on the wiki, since I followed the cluster page carefully. You seem to suggest that I made a mistake somehow?

Anyway, I'll ask there, thanks for your time.

 

[dietmar]

You seem to suggest that I made a mistake somehow?

It was quite difficult to find out what network configuration you have, and I have really done my best to help.

Anyway, I'll ask there, thanks for your time.

Let us know when you find a solution. And feel free to create some wiki documentation about that ;-)