Sarah Newman
2013-Jul-12 00:49 UTC
Changing underlying storage without shutting down guests
Hi, We''re working on a new storage architecture. In the meantime, before that architecture is ready we have to move some customers around and this will require shutting them down anyway. My goal is that we bring them back up we won''t have to take them down again to switch to the new storage architecture. The solution(?) I''ve come up is to run the domu on top of a md multipath device. The md multipath has simple failover such that all requests are directed towards only one of the md members at any time. This is the sequence I''ve tested: Pause domain sync Fail over md multipath to dummy storage Re-export primary storage using a different block layer Fail over md multipath to re-exported primary storage Unpause domain Example: mdadm --build /dev/md/bob --raid-devices=2 --level=multipath --auto=md /dev/mapper/volume-bob missing xm pause bob #bob has / on /dev/md/bob sync mdadm /dev/md/bob --add /dev/mapper/volume-move_tmp mdadm --set-faulty /dev/md/bob /dev/mapper/volume-bob mdadm --remove /dev/md/bob /dev/mapper/volume-bob tgtadm --lld iscsi --op new --mode target --tid 2 --targetname bob tgtadm --op new --mode logicalunit --tid 2 --lun 1 --backing-store /dev/mapper/volume-bob --lld iscsi tgtadm --lld iscsi --op bind --mode target --tid 2 -I ALL iscsiadm --mode discovery -t sendtargets --portal 172.16.10.156 iscsiadm --mode node --targetname bob --portal 172.16.10.156 --login mdadm /dev/md/bob --add /dev/disk/by-path/ip-172.16.10.156:3260-iscsi-bob-lun-1 mdadm --set-faulty /dev/md/bob /dev/mapper/volume-move_tmp mdadm --remove /dev/md/bob /dev/mapper/volume-move_tmp xm unpause bob It appears to work but that doesn''t prove it will always. Does anyone know if this reliable or if there''s a better method? Thanks in advance. --Sarah