Export the virtual backend from the primary service domain.
# ldm add-vdsdev mpgroup=foo backend-path1 volume@primary-vds0
Where backend-path1 is the path to the virtual disk backend from the primary domain.
Export the same virtual backend from the alternate service domain.
# ldm add-vdsdev mpgroup=foo backend-path2 volume@alternate-vds0
Where backend-path2 is the path to the virtual disk backend from the alternate domain.
backend-path1 and backend-path2 are paths to the same virtual disk backend, but from two different domains (primary and alternate). These paths might be the same or might be different depending on the configuration of the primary and alternate domains. The volume name is a user choice. It might be the same or different for both commands.
Export the virtual disk to the guest domain.
# ldm add-vdisk disk-name volume@primary-vds0 ldom
Although the virtual disk backend is exported several times through different service domains, you assign only one virtual disk to the guest domain and associate it with the virtual disk backend through any of the service domains.
Once you configure the virtual disk with multipathing and start the guest domain, the virtual disk accesses its backend through the service domain it has been associated with (the primary domain in this example). If this service domain becomes unavailable, then the virtual disk tries to access its backend through a difference service domain that is part of the same multipathing group.
When defining a multipathing group (mpgroup), ensure that the virtual disk backends that are part of the same mpgroup are effectively the same virtual disk backend. If you add different virtual disks' backends into the same mpgroup, you might see some unexpected behavior, and you can potentially lose or corrupt data stored on the backends.