> I would suggest that eligibility for migration would require that the user > have an identical directory on the target system. This ensures that disk > geometries, network connections, memory size, CPUs, etc. are unchanged. > While you might be able to construct scenarios where this is not > necessarily required, managing the edge cases would be painful. There is > no need to abstract the I/O layer another level. > > And the underlying rdevs need to be the same disks, whether shared or > mirrored in some way.
I think CSE requires some (if not all) of those things anyway, so that wouldn't be a major restriction. I would still like to see the disk abstraction because it would streamline a lot of stuff in the current disk configuration management. I'd really rather CP do that stuff rather than have it inside a guest. As Rob already mentioned, having all that state info in a guest makes this hard. I think Dave Jones' comment on the point of this is well-taken, and I think his definition of : 1) VM needs the capability to migrate running guest operating systems from one LPAR or physical processor to another LPAR or physical processor, *with no loss of functionality by the guest*. 2) In order to achieve such a capability, certain guest virtual machine configuration setups might need to be done beforehand, e.g., each guest virtual machine CP definition in each system must be identical. is a good one. I would raise a concern about the idea of duplicate disks; I think you'd really need to have one copy (unless the controller is making the duplicates outboard) and pass control of it along with the other metatdata about the virtual machine when migrating to the other VM image.
