AIX

AIX

Connect with fellow AIX users and experts to gain knowledge, share insights, and solve problems.


#Power
 View Only
  • 1.  VIO Naming convention

    Posted Wed February 22, 2006 01:28 PM

    Originally posted by: aixylinux


    Does anyone have a set of "good" naming conventions for resouces in a VIO environment? I realize "good" is a relative term, but I'm looking for a starting point. Various APV documents suggest the use of a naming convention, but don't provide examples. They say a good naming convention for LPARs, disk VGs and LVs, etc, would make configuration and troubleshooting easier across LPARs and across frames. This is my first setup, and I'd like to avoid a false start. Any prior art or suggestions are highly appreciated.
    #AIX-Forum


  • 2.  Re: VIO Naming convention

    Posted Tue February 28, 2006 10:56 AM

    Originally posted by: SystemAdmin


    My employer just adopted the following host naming scheme, and it's working pretty well for us.

    • One-character field for stage (d for development, t for test, p for production, etc)
    • Two-character field for OS (ax for AIX, ln for Linux, etc)
    • One-to-four-character field for application or purpose
    • Optional three-character field for virtualization info (LP for LPAR, VM for VMWare, plus one character for physical server)
    • Two-digit serial number.

    So [b]paxdb2lpc01[/b] would be the first production AIX DB2 LPAR in physical server "C".

    For developers, we use aliases that omit the virtualization info. A DBA would probably refer to the first DB2 LPAR as just [b]paxdb201[/b].

    On each VIO, we've configured a rootvg which just contains the VIOS, and then a clientvg which contains logical volumes that correspond to hdisk devices on client LPARs. We try to name the logical volumes with the client LPAR's shortened alias, plus an underscore, plus a short designation of the nature of the target. The logical volume [b]paxdb201_rvg[/b] would be used for the rootvg of client LPAR paxdb201. To name a virtual SCSI target device with a logical volume for a backing device, we simply prepend a 'v' to the logical volume name. The vSCSI target backed by the aforementioned logical volume would be [b]vpaxdb201_rvg[/b].

    We also do a considerable amount of "MPIO in the client with SAN in the VIO" (which should sound famailiar to anyone who's worked out of the draft Advanced Virtualization Redbook*), and we try to name virtual SCSI target devices with SAN LUNs as backing devices similarly. [b]vpaxdb201_sd1[/b] would refer to a vSCSI target with a SAN backing device being offered to client LPAR paxdb201.

    While we're talking about conventions, I'll also mention that we follow the aforementioned Advanced Virtualization Redbook's advice on making client SCSI slot numbers match server SCSI slot numbers. We also provision virtual SCSI adapters from pairs of VIO servers, and contiguously numbered, so if paxdb201 has a vSCSI slot 211 corresponding to VIO1, slot 212 will be a vSCSI slot coming from VIO2.

    We try to offer all LV-backed vSCSI targets over one pair of vSCSI adapters and all SAN-backed vSCSI targets over a separate pair of vSCSI adapters. I'm not sure we have any really good reason to do this, but it seemed a cleaner way to operate. I suppose, if ever we needed to, it would allow us to create a whole new pair of VIO servers to handle dedicated SAN VIO.

    Also, since we knew up front we'd be making heavy use of virtualization, we decided to use relatively large slot numbers and categorize them by kind. So within any given server, slot numbers in the 100s refer to virtual Ethernet adapters, whie slots in the 200s are virtual SCSI. Again, there's no performance advantage to doing this, it just keeps things a littler tidier.

    I hope that helps, and I look forward to seeing what other folks are doing.

    Clayton

    #AIX-Forum