|Skip Navigation Links|
|Exit Print View|
|Oracle VM Server for SPARC 3.0 Administration Guide Oracle VM Server for SPARC|
Virtual disk multipathing enables you to configure a virtual disk on a guest domain to access its back-end storage by more than one path. The paths lead through different service domains that provide access to the same back-end storage, such as a disk LUN. This feature enables a virtual disk in a guest domain to remain accessible even if one of the service domains goes down. For example, you might set up a virtual disk multipathing configuration to access a file on a network file system (NFS) server. Or, you can use this configuration to access a LUN from shared storage that is connected to more than one service domain. So, when the guest domain accesses the virtual disk, the virtual disk driver goes through one of the service domains to access the back-end storage. If the virtual disk driver cannot connect to the service domain, the virtual disk attempts to reach the back-end storage through a different service domain.
Note - Starting with the Oracle VM Server for SPARC 2.0 release, the virtual disk multipathing feature can detect when the service domain cannot access the back-end storage. In such an instance, the virtual disk driver attempts to access the back-end storage by another path.
To enable virtual disk multipathing, you must export a virtual disk back end from each service domain and add the virtual disk to the same multipathing group (mpgroup). The mpgroup is identified by a name and is configured when you export the virtual disk back end.
The following figure shows a virtual disk multipathing configuration, which is used as an example in the procedure How to Configure Virtual Disk Multipathing. In this example, a multipathing group named foo is used to create a virtual disk, whose back end is accessible from two service domains: primary and alternate.
Figure 7-2 Configuring Virtual Disk Multipathing
With virtual disk multipathing, the path that is used to access the back end automatically changes if the back end becomes inaccessible by means of the currently active path. This path change occurs independently of the value of the virtual disk timeout property.
The virtual disk timeout property specifies the amount of time after which an I/O fails when no service domain is available to process the I/O. This timeout applies to all virtual disks, even those that use virtual disk multipathing.
As a consequence, setting a virtual disk timeout when virtual disk multipathing is configured can prevent multipathing from working correctly. This is especially the case with a small timeout value. So, it is best not to set a virtual disk timeout for virtual disks that are part of a multipathing group.
For more information, see Virtual Disk Timeout.
# ldm add-vdsdev mpgroup=foo backend-path1 volume@primary-vds0
where backend-path1 is the path to the virtual disk back end from the primary domain.
# ldm add-vdsdev mpgroup=foo backend-path2 volume@alternate-vds0
where backend-path2 is the path to the virtual disk back end from the alternate domain.
Note - backend-path1 and backend-path2 are paths to the same virtual disk back end, but from two different domains (primary and alternate). These paths might be the same or 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.
# ldm add-vdisk disk-name volume@primary-vds0 ldom
Note - Although the virtual disk back end 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 back end through any of the service domains.
After you configure the virtual disk with multipathing and start the guest domain, the virtual disk accesses its back end through the service domain it has been associated with (the primary domain in this example). If this service domain becomes unavailable, the virtual disk attempts to access its back end through another service domain that is part of the same multipathing group.
Caution - When defining a multipathing group (mpgroup), ensure that the virtual disk back ends that are part of the same mpgroup are effectively the same virtual disk back end. If you add different back ends into the same mpgroup, you might see some unexpected behavior, and you can potentially lose or corrupt data stored on the back ends.