Is it possible to have multiple Iscsi paths to KVM Storage Pool supporting Live Migration?

Latest response

Hi, I am configuring a Red Hat Server that will be used as a Hypervisor for Red Hat guests.

I need to be able to use Live Migration as well.

Storage for guests are shared through iscsi and here we come to the problem. I seem to only be able to use a single path with iscsi when creating a Storage Pool and relying on a single nic between target and initiator is not an option (single point of failure).

From what i have read Bonding does not seem like an option either for iscsi.

Multipathed iscsi with device-mapper-multipath solve the issue with single path but i can't find any information if it is supported for Live Migration. Is there a way to have iscsi through multiple paths and two switches providing redundancy for the Storage Pool and guest systems while supporting Live Migration?

Thank you for your help.

Regards, Johan.

Responses

Hi Johan

Multipathed iSCSI (over two switches) and Live Migration work just fine out of the box. Are you looking for anything more specific?

Hi,

Thank you.

I was unsure if DM Multipath configuration worked for Live Migration since the iscsi targets are connected to the Hypervisor server and the multipath device is used for Storage Pool.

I was under the impression that i needed to use iscsi targets directly attached to a storage pool through virt-manager for example.

In my case i have 2-4 different nic on the target depending on server and login to them separately on the Initiator (Hypervisor).

Is it recommended to use different subnets for each path?

I then use DM multipath with alias to create a Storagel Pool for virtual guests.

Is there anything important regarding the configuration of the second server that will be used as target of Live Migration?

Thank you for the help,

http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/chap-Virtualization-KVM_live_migration.html should help you with more. It does mention that "Shared storage must mount at the same location on source and destination systems. The mounted directory name must be identical."

Regarding different subnets, yes, they should ideally be different. If they were to be the same, then the interface which comes up later will become the default route for the network traffic to traverse, and the other interface will never be used. If you do need to keep the subnets the same, you can delete the routing entries which are created by default and add [host] routes specific to the interface devices targeting the destination IP Address (iSSI Target) rather than the whole subnet.