On to the true purpose of this artcle, let’s get virtualizing with OpenSolaris’ rendition of Xen, SUN xVM.

OpenSolaris

I am going to assume that you already have OpenSolaris installed. At the time of this article, I was using 2009-06. The second assumption is that all the following commands are ran as root. The third assumption is that your installation of OpenSolaris has access to the Internet.

Installing xVM

In the first step we will create a new boot environment using the beadm tool. Option “-a” states to activate the new boot environment and the “-d xvm” defines the description for the boot environment. The final xvm is the name of the boot environment.

# pfexec beadm create -a -d xvm xvm

The second step will install the xVM software packages into the newly created boot environment. The first command mounts the boot environment. The second command installs the xvm-gui package which has all of the xVM dependencies associated, forcing a full install of xVM.

# pfexec beadm mount xvm /tmp/xvm-be
# pfexec pkg -R /tmp/xvm-be install xvm-gui
# pfexec beadm umount xvm

Configuring your Grub Boot Menu

The next step requires that you modify your boot menu, grub/menu.lst. In the new installation of OpenSolaris, this file will reside as /rpool/boot/grub/menu.lst. Use your favorite editor to open menu.lst:

# nano /rpool/boot/grub/menu.lst

At the bottom of the file, add the following lines:

title xvm
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/xvm
kernel$ /boot/$ISADIR/xen.gz
module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=text
module$ /platform/i86pc/$ISADIR/boot_archive

Note: if you already have a “title xvm” section, and your installation was similar to mine, you will likely find that the boot configuration I specified above will work better. However, if you would like to try the boot configuration that was automatically entered, move along with the article and test a connection to the xVM services using the Virtual Machine Manager. If it fails, replace the “title xvm” with my version above and reboot.

Save the menu.lst file and reboot your OpenSolaris server:

# reboot

Enabling xVM Services

The final step to installing the xVM hypervisor in OpenSolaris is to enable the services for xVM, this is accomplished with the following two commands:

# svcadm enable -r xvm/virtd
# svcadm enable -r xvm/domains

Jump In!

Being that I am a Windows administrator by trade, I enjoy the GUI interface. Such would be my choice in any Linux environment too. Using the Applications menu choose System Tools > Virtual Machine Manager and connect to the localhost.

As a final note, be sure to check out the documentation on OpenSolaris.org.

-Aaron Gilbert

SUN iSCSI Initiator

Obviously you need to have your network configured properly prior to working with the iSCSI initiator or targets. In this example, I was working with the iSCSI initiator and target in a lab environment, with the host (target) being 192.168.0.18 and the client (initiator) being 192.168.0.19. Secondly, you will need the iSCSI initiator software to be installed from Package Manager – easiest way is to search for iscsi and ensure all four of those packages are installed.

For this example we will use Send Targets for discovering iSCSI targets/paths:

iscsiadm add discovery-address 192.168.0.18:3260
iscsiadm modify discovery --sendtargets enable

Now that you have added the discovery address of the iSCSI target and enabled the discovery “Send Targets”, check to see if your target was discovered:

iscsiadm list target

If you saw the targets you were expecting, the next step is to create the device links between iSCSI and your system – so you can see the iSCSI LUN as a disk on your system.

devfsadm -i iscsi

Check the available disks on your system using the format command. After running the format command, hit CTRL-C to bounce back to the terminal prompt.

Using / Mounting the iSCSI LUN

Now that you have the iSCSI initiator working properly and the iSCSI targets discovered, lets actually use the new iSCSI disk with ZFS.

First we need to create the ZFS pool using the new disk. If you forgot the name of the new disk, you can learn it using the format command. If it is anything like the one on my OpenSolaris box, the name is rather large, (c0t600144F0F9A00C0000004AA9510A0001d0):

zpool create diskpool c0t600144F0F9A00C0000004AA9510A0001d0

To verify the pool was created, use:

zpool list

Now we can create a ZFS file system on top of that pool:

zfs create diskpool/test

Check your new ZFS filesystem was created:

zfs list

And now you can create files within the mount point:

root@opensolaris:/diskpool/test/#

Everything you write to that mount point will be written to the iSCSI target, as one would hope.

Good luck with your performance!

Credits

http://wikis.sun.com/display/OpenSolarisInfo/How+to+Configure+an+iSCSI+Initiator

Creating the Link Aggregate

If your configuration was similar to mine, you will already have your interfaces plumbed – which means they cannot be added to the link aggregate until they are unplumb’ed.

Checking for Plumbing

If you try to create an aggregate with plumbed interfaces, you will receive a “dladm: create operation failed: link busy” error. You can check if they have been plumbed as they will show in the list for “ifconfig -a”:

e1000g0: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 8
 inet 0.0.0.0 netmask 0
 ether 0:15:17:b8:47:a8
e1000g1: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 9
 inet 0.0.0.0 netmask 0
 ether 0:15:17:b8:47:a9
e1000g2: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 10
 inet 0.0.0.0 netmask 0
 ether 0:15:17:b8:47:aa
e1000g3: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 11
 inet 0.0.0.0 netmask 0
 ether 0:15:17:b8:47:ab

If they appear, as shown above, unplumb them using the following commands:

ifconfig e1000g0 unplumb
ifconfig e1000g1 unplumb
ifconfig e1000g2 unplumb
ifconfig e1000g3 unplumb

Create the Aggregate and Plumb It!

Using the dladm tool, you can easily create the aggregate usign the following command:

dladm create-aggr -d e1000g0 -d e1000g1 -d e1000g2 -d e1000g3 1

You’lll notice a -d with each interface and a number 1 at the end. The number 1 references the aggregate number and it must start at 1, not 0.

Next we will plumb the newly created aggregate with an IP address:

ifconfig aggr1 plumb 192.168.0.101 up

Show me the Aggregate

If you are like me, then you will want to see the aggregate configured:

dladm show-aggr

You should see an output similar to the following:

LINK            POLICY   ADDRPOLICY           LACPACTIVITY  LACPTIMER   FLAGS
aggr1           L4       auto                 off           short       -----

Modify Aggregate for LACP

To ensure that LACP is functioning as I would hope, I modified the aggregate, changing LACPACTIVITY to active instead of off. Use the following command to modify LACPACTIVITY:

dladm modify-aggr -L active -T short 1

Now run the following command to verify the settings took:

dladm show-aggr

You should now see an output similar to the following:

LINK            POLICY   ADDRPOLICY           LACPACTIVITY  LACPTIMER   FLAGS
aggr1           L4       auto                 active        short       -----

Setting Aggregate IP Configuration as Persistent

To ensure that your IP address configuration for the aggregate is persistent across reboots, modify the /etc/hostname.aggr1 file and add the desired IP address. The /etc/hostname.aggr1 should contain one line consisting of the IP address:

192.168.0.101

Switch Configuration

Obviously, you must configure the switch for LACP otherwise your aggregate will fail. Each switch is different, refer to the manual for your switch.

I’m out…

Disable GUI

To disable the GUI, type the following command in a terminal window:

pfexec svcadm disable gdm

Enable GUI

To enable the GUI, type the following command at the terminal prompt:

pfexec svcadm enable gdm

I’m out…