Xen users - May 2005 - suspend/resume and live migration I/O mappings

Question about suspend/resume and live migration wrt I/O mappings.

When suspending a domain and resuming it on a different host or using live
migration, what are the I/O configuration requirements of the source and target
hosts?   In particular, if using block devices in dom0 for use as domU disks,
does the destination host require an identical view of the block devices?   In
other words, suppose a SAN LUN seen on /dev/sdc in dom0 on the source host is
mapped to a domU for one of its disks, but on the destination host, the same SAN
LUN shows up on /dev/sdd in dom0, is there an ability to remap the devices for a
domU during the resume or migration?   Same issue for eth devices as the
source/destination may not have an identical number of NICs or the network
connectivity of NICs may different on the two hosts.   I suppose the same issue
even extends to file based disks in shared NFS or clustered storage - do both
source/destination hosts require the same NFS mount points?   I''m
fairly new to Xen, but I don''t see any obvious mechanisms for remapping
a domU''s I/O during resume or live migration.


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> When suspending a domain and resuming it on a different host 
> or using live migration, what are the I/O configuration 
> requirements of the source and target hosts?   In particular, 
> if using block devices in dom0 for use as domU disks, does 
> the destination host require an identical view of the block 
> devices?   In other words, suppose a SAN LUN seen on /dev/sdc 
> in dom0 on the source host is mapped to a domU for one of its 
> disks, but on the destination host, the same SAN LUN shows up 
> on /dev/sdd in dom0, is there an ability to remap the devices 
> for a domU during the resume or migration?   
You can write a script similar to the ''block-enbd'' or
''block-file'' that
handles the mapping of some higher-level name down to the local device.
> Same issue for 
> eth devices as the source/destination may not have an 
> identical number of NICs or the network connectivity of NICs 
> may different on the two hosts.  
Again, you can intercept this in ''vif-bridge'' if you have
special
requirements.
> I suppose the same issue 
> even extends to file based disks in shared NFS or clustered 
> storage - do both source/destination hosts require the same 
> NFS mount points?  
You can intercept this in the ''block-file'' script. Note than
loopback
files over NFS is a bad idea -- linux just doesn''t handle this well.

Best,
Ian

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users