[Xen-users] Changing underlying storage without shutting down guests

[Sarah Newman <srn@xxxxxxxxx>]

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

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users