host (cn40), we now get to start checking out handling and management
of SmartOS OS VMs (SOSVMs). Jumping in where we left off in part 3, we
start with the configuration for our image repository hosted on "serv1"
(our services host):
cn40 [0] /usr/bin/getent hosts serv1.admin.none
10.0.7.10 serv1.admin.none
cn40 [0] cat /var/db/imgadm/sources.list
https://datasets.joyent.com/datasets
cn40 [0] cat /var/db/imgadm/sources.list
http://serv1.admin.none/datasets/
cn40 [0]
In the above, I've checked that we can resolve the FQDN for "serv1"via 'getent'. I've also updated the 'imgadm' sources from Joyent.com
related to reflect the configuration on "serv1". (Remember, this is a
completely sandboxed environment so there is no routing to the outside
world, including to joyent.com.) In the course of my testing, I found
that the URL in "source.list" above needs to include an FQDN, so an IP
address won't work. Also, 'imgadm' seems to fail on "update" if there
isn't a trailing slash (/), thus the reason it is added in the updated
"source.list" entry. The failure of no trailing slash can be seen below:
cn40 [0] imgadm update
updating local images database...
Get http://serv1.admin.none/datasets...
undefined:1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
^
SyntaxError: Unexpected token <
at Object.parse (native)
at IncomingMessage.cacheUpdate (/usr/img/node_modules/imgadm.js:343:38)
at IncomingMessage.EventEmitter.emit (events.js:126:20)
at IncomingMessage._emitEnd (http.js:366:10)
at HTTPParser.parserOnMessageComplete [as onMessageComplete] (http.js:149:23)
at Socket.socketOnData [as ondata] (http.js:1367:20)
at TCP.onread (net.js:403:27)
cn40 [1]
With our side tangent resolved and our "source.list" file updatedappropriately, 'imgadm update' will now function and add the image
references from our image repository on "serv1" to our local image
database. While we still don't have any locally imported images
('imgadm list' reports nothing), we can see what images our repository
has available (imgadm avail):
cn40 [0] /usr/sbin/imgadm update
updating local images database...
Get http://serv1.admin.none/datasets/...
done
cn40 [0] /usr/sbin/imgadm list
cn40 [0] /usr/sbin/imgadm avail
UUID OS PUBLISHED URN
fdea06b0-3f24-11e2-ac50-0b645575ce9d smartos 2012-12-05 sdc:sdc:base64:1.8.4
84cb7edc-3f22-11e2-8a2a-3f2a7b148699 smartos 2012-12-05 sdc:sdc:base:1.8.4
aa583f78-3d83-11e2-9188-fff9b605718d smartos 2012-12-03 sdc:sdc:base64:1.8.2
ef22b182-3d7a-11e2-a7a9-af27913943e2 smartos 2012-12-03 sdc:sdc:base:1.8.2
b00acc20-14ab-11e2-85ae-4f03a066e93e smartos 2012-10-12 sdc:sdc:mongodb:1.4.0
1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc smartos 2012-10-11 sdc:sdc:nodejs:1.4.0
dc1a8b5e-043c-11e2-9d94-0f3fcb2b0c6d smartos 2012-09-21 sdc:sdc:percona:1.6.0
a0f8cf30-f2ea-11e1-8a51-5793736be67c smartos 2012-08-30 sdc:sdc:standard64:1.0.7
3390ca7c-f2e7-11e1-8818-c36e0b12e58b smartos 2012-08-30 sdc:sdc:standard:1.0.7
cn40 [0]
The images on our image repository contain compressed ZFS snapshots.Once imported, we'll see that they've been added to our local ZFS
datasets. Below, I've checked our reported file systems (FS) via 'df',
imported the images for sdc:sdc:base64:1.8.4, sdc:sdc:mongodb:1.4.0,
and sdc:sdc:nodejs:1.4.0 by their respective UUIDs (as reported by
'imgadm avail'), and listed the locally imported images now reporting via
'imgadm list':
cn40 [0] /bin/df -h | /bin/grep '/zones'
zones 16G 650K 13G 1% /zones
zones/cores 10G 31K 10G 1% /zones/global/cores
zones/config 16G 38K 13G 1% /etc/zones
cn40 [0] for i in fdea06b0-3f24-11e2-ac50-0b645575ce9d \
> b00acc20-14ab-11e2-85ae-4f03a066e93e 1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc ; do \
> /usr/sbin/imgadm import ${i} ; done
fdea06b0-3f24-11e2-ac50-0b645575ce9d doesnt exist. continuing with install
fdea06b0-3f24-11e2-ac50-0b645575ce9d successfully installed
image fdea06b0-3f24-11e2-ac50-0b645575ce9d successfully imported
b00acc20-14ab-11e2-85ae-4f03a066e93e doesnt exist. continuing with install
b00acc20-14ab-11e2-85ae-4f03a066e93e successfully installed
image b00acc20-14ab-11e2-85ae-4f03a066e93e successfully imported
1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc doesnt exist. continuing with install
1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc successfully installed
image 1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc successfully imported
cn40 [0] /usr/sbin/imgadm list
UUID OS PUBLISHED URN
b00acc20-14ab-11e2-85ae-4f03a066e93e smartos 2012-10-12 sdc:sdc:mongodb:1.4.0
1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc smartos 2012-10-11 sdc:sdc:nodejs:1.4.0
fdea06b0-3f24-11e2-ac50-0b645575ce9d smartos 2012-12-05 sdc:sdc:base64:1.8.4
cn40 [0] /bin/df -h | /bin/grep '/zones'
zones 16G 654K 11G 1% /zones
zones/cores 10G 31K 10G 1% /zones/global/cores
zones/config 16G 38K 11G 1% /etc/zones
zones/fdea06b0-3f24-11e2-ac50-0b645575ce9d 16G 372M 11G 4% /zones/fdea06b0-3f24-11e2-ac50-0b645575ce9d
zones/b00acc20-14ab-11e2-85ae-4f03a066e93e 16G 774M 11G 7% /zones/b00acc20-14ab-11e2-85ae-4f03a066e93e
zones/1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc 16G 1.0G 11G 9% /zones/1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc
cn40 [0] /usr/sbin/zfs list -r zones | /bin/grep -- '-'
zones/1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc 1.02G 10.6G 1.02G /zones/1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc
zones/b00acc20-14ab-11e2-85ae-4f03a066e93e 774M 10.6G 774M /zones/b00acc20-14ab-11e2-85ae-4f03a066e93e
zones/dump 838M 10.6G 838M -
zones/fdea06b0-3f24-11e2-ac50-0b645575ce9d 372M 10.6G 372M /zones/fdea06b0-3f24-11e2-ac50-0b645575ce9d
zones/swap 2.06G 12.7G 16K -
Following the 'imgadm' listing of imported images, our 'df' output abovenow reports the imported ZFS datasets related to each image. A 'zfs
list' further supports our 'df' output. Since these templates (images)
are really just unconfigured zones, their respective ZFS datasets will
be cloned during the creation of new SOSVMs. To further illustrate this,
we can have a look at the image manifest for an image via 'imgadm show':
cn40 [0] /usr/sbin/imgadm show 1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc
{
"name": "nodejs",
"version": "1.4.0",
"type": "zone-dataset",
"description": "Node.js Image with MongoDB",
"published_at": "2012-10-11T14:40:57.936Z",
"os": "smartos",
"files": [
{
"path": "nodejs-1.4.0.zfs.bz2",
"sha1": "d2c40995ff693994e0343a661fb2279794546748",
"size": 269634973,
"url": "http://10.0.7.10/datasets/1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc/nodejs-1.4.0.zfs.bz2"
}
],
"requirements": {
"networks": [
{
"name": "net0",
"description": "public"
}
]
},
"users": [
{
"name": "root"
},
{
"name": "admin"
},
{
"name": "mongodb"
}
],
"generate_passwords": true,
"uuid": "1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc",
"creator_uuid": "352971aa-31ba-496c-9ade-a379feaecd52",
"vendor_uuid": "352971aa-31ba-496c-9ade-a379feaecd52",
"creator_name": "sdc",
"platform_type": "smartos",
"cloud_name": "sdc",
"urn": "sdc:sdc:nodejs:1.4.0",
"created_at": "2012-10-11T14:40:57.936Z",
"updated_at": "2012-10-11T14:40:57.936Z",
"_url": "http://serv1.admin.none/datasets/"
}
Now that we have some images locally imported and at our disposal,let's create a simple OS VM using the "base64:1.8.4" image. For anyone
familiar with 'zoneadm' and 'zonecfg', you could potentially use them,
but 'vmadm' makes things a lot simpler. Below, I've created a new
SOSVM, vmnonet, passing off JSON attributes to 'vmadm' (see vmadm(1m)
for details on the properties available). Additionally a 'vmadm list'
and 'zoneadm list' both confirm our new SOSVM is now running:
cn40 [0] /usr/sbin/vmadm create <<EOF
> { "alias": "vmnonet", "brand": "joyent", "image_uuid": "fdea06b0-3f24-11e2-ac50-0b645575ce9d" }
> EOF
Successfully created c7885cb0-4489-484d-9cb9-3e048c1f0ed5
cn40 [0] /usr/sbin/vmadm list
UUID TYPE RAM STATE ALIAS
c7885cb0-4489-484d-9cb9-3e048c1f0ed5 OS 256 running vmnonet
cn40 [0] /usr/sbin/zoneadm list
global
c7885cb0-4489-484d-9cb9-3e048c1f0ed5
cn40 [0] zoneadm list -v
ID NAME STATUS PATH BRAND IP
0 global running / liveimg shared
1 c7885cb0-4489-484d-9cb9-3e048c1f0ed5 running /zones/c7885cb0-4489-484d-9cb9-3e048c1f0ed5 joyent excl
cn40 [0] /bin/df -h | /bin/grep c7885cb0-4489-484d-9cb9-3e048c1f0ed5
zones/c7885cb0-4489-484d-9cb9-3e048c1f0ed5 10G 379M 10.0G 4% /zones/c7885cb0-4489-484d-9cb9-3e048c1f0ed5
zones/cores/c7885cb0-4489-484d-9cb9-3e048c1f0ed5 10G 31K 10G 1% /zones/c7885cb0-4489-484d-9cb9-3e048c1f0ed5/cores
cn40 [0]
The 'df' output above identifies 2 ZFS datasets for our new VM. One isfor our VM's normal usage, the other, "cores", is for any core dumps.
Of note, all SOSVMs created are identified in SmartOS via UUID. While not
a required attribute, including an "alias" property during SOSVM creation
can help reduce confusion in identifying your VMs via 'vmadm' ('zoneadm'
will not show aliases). Since we didn't include any network properties to
"vmnonet", we can only log on locally, as seen below via 'zlogin':
cn40 [0] /usr/sbin/zlogin -l root c7885cb0-4489-484d-9cb9-3e048c1f0ed5
[Connected to zone 'c7885cb0-4489-484d-9cb9-3e048c1f0ed5' pts/3]
__ . .
_| |_ | .-. . . .-. :--. |-
|_ _| ;| || |(.-' | | |
|__| `--' `-' `;-| `-' ' ' `-'
/ ; SmartMachine base64 1.8.4
`-' http://wiki.joyent.com/jpc2/SmartMachine+Base
[root@c7885cb0-4489-484d-9cb9-3e048c1f0ed5 ~]# /usr/sbin/ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
[root@c7885cb0-4489-484d-9cb9-3e048c1f0ed5 ~]# exit
logout
[Connection to zone 'c7885cb0-4489-484d-9cb9-3e048c1f0ed5' pts/3 closed]
cn40 [0]
Alright, one VM down, let's create another, this time incorporatingnetworking. For our new SOSVM, "vm100", I've opted to use an input file:
cn40 [0] cat /var/tmp/vm100
{
"alias": "vm100",
"brand": "joyent",
"image_uuid": "1fc068b0-13b0-11e2-9f4e-2f3f6a96d9bc",
"dns_domain": "world.none",
"hostname": "vm100",
"resolvers": [
"10.0.8.10"
],
"nics": [
{
"nic_tag": "world",
"ip": "10.0.8.100",
"netmask": "255.255.255.0",
"gateway": "10.0.8.37",
"primary": true
}
]
}
The image we'll be using is our locally imported nodejs:1.4.0 image.Added to the above is our domain, name server(s), and configuration for
our SOSVM network interface. We've identified the global NIC to attach
to using the NIC_TAG we previously obtained from 'sysinfo -p' in part 3.
Below, we create the new VM using 'vmadm', list out our running VMs,
and using 'dladm' see that our vNIC (net0) for "vm100" is attached to our
"world" NIC (e1000g1, in the global zone):
cn40 [0] /usr/sbin/vmadm create -f /var/tmp/vm100
Successfully created 7b7f6343-2584-46a4-a077-707281108449
cn40 [0] /usr/sbin/vmadm list
UUID TYPE RAM STATE ALIAS
7b7f6343-2584-46a4-a077-707281108449 OS 256 running vm100
c7885cb0-4489-484d-9cb9-3e048c1f0ed5 OS 256 running vmnonet
cn40 [0] /usr/sbin/dladm show-link
LINK CLASS MTU STATE BRIDGE OVER
e1000g0 phys 1500 up vmwarebr --
e1000g1 phys 1500 up vmworld --
vmwarebr0 bridge 1500 up -- e1000g0
vmworld0 bridge 1500 up -- e1000g1
net0 vnic 1500 ? -- e1000g1
cn40 [0] /usr/sbin/dladm show-vnic
LINK OVER SPEED MACADDRESS MACADDRTYPE VID ZONE
net0 e1000g1 0 92:bd:41:a6:c7:74 fixed 0 7b7f6343-2584-46a4-a077-707281108449
cn40 [0]
In part 3, a piece of our configuration included importing an SMF toautomatically create a bridge to support our SOSVMs. Without that
bridge linked to our "world" NIC, our VMs wouldn't be reachable outside
of our compute node (cn40). Since the bridge "vmworld" has been set up,
we can now remotely access our VM (vm100). By default, SmartOS-created
VMs are configured to only allow ssh key-based authentication without
keyboard interaction. This means generating an ssh key via 'ssh-keygen'
with a blank passphrase on our workstation host (glados):
# on glados:
troy@glados [0] ssh-keygen -f ~/.ssh/vms-smartos
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/troy/.ssh/vms-smartos.
Your public key has been saved in /home/troy/.ssh/vms-smartos.pub.
The key fingerprint is:
a2:0d:81:d1:87:29:ee:49:1c:40:e0:20:c8:eb:f6:05 troy@glados.vbox.none
The key's randomart image is:
+--[ RSA 2048]----+
|Xo.. o |
|=.oo+ . |
| +oo.. |
| .+E . |
|.o .o . S |
| oo = . |
|. . o . |
| . |
| |
+-----------------+
troy@glados [0]
Once you've generated a key to use, add the contents of the public key(vms-smartos.pub) to the root user's "authorized_keys" file for your
new VM (vm100) on your compute node (cn40). The path in the case of
this write up is:
/zones/7b7f6343-2584-46a4-a077-707281108449/root/root/.ssh/authorized_keys
(The "7b7f6343-2584-46a4-a077-707281108449" part of the path is the UUIDof our VM.) Back on our workstation, we can log into "vm100" by passing
our private key (vms-smartos) to 'ssh':
troy@glados [0] ssh -i ~/.ssh/vms-smartos -l root vm100
The authenticity of host 'vm100 (10.0.8.100)' can't be established.
RSA key fingerprint is 13:ad:45:d0:87:e9:79:cb:08:32:2c:b5:05:c5:9c:52.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'vm100,10.0.8.100' (RSA) to the list of known hosts.
Last login: Tue Jan 29 04:42:00 2013 from 192.168.56.1
__ . .
_| |_ | .-. . . .-. :--. |-
|_ _| ;| || |(.-' | | |
|__| `--' `-' `;-| `-' ' ' `-'
/ ; SmartMachine (nodejs 1.4.0)
`-' http://wiki.joyent.com/jpc2/SmartMachine+Node.JS
[root@vm100 ~]#
Excellent, we're logged in to our networked nodejs VM. As part of acursory review of our VM, I've checked out the output of 'ifconfig',
'df', validated host resolution via 'host', reviewed "resolv.conf",
and checked our routing table via 'netstat':
[root@vm100 ~]# /usr/sbin/ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
net0: flags=40001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,L3PROTECT> mtu 1500 index 2
inet 10.0.8.100 netmask ffffff00 broadcast 10.0.8.255
ether 92:bd:41:a6:c7:74
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
[root@vm100 ~]# /bin/df -h
Filesystem size used avail capacity Mounted on
zones/7b7f6343-2584-46a4-a077-707281108449
11G 1.0G 10.0G 10% /
/dev 0K 0K 0K 0% /dev
/lib 251M 219M 32M 88% /lib
/lib/svc/manifest 11G 656K 11G 1% /lib/svc/manifest
/lib/svc/manifest/site
11G 1.0G 10.0G 10% /lib/svc/manifest/site
/sbin 251M 219M 32M 88% /sbin
/usr 376M 355M 22M 95% /usr
/usr/ccs 11G 1.0G 10.0G 10% /usr/ccs
/usr/local 11G 1.0G 10.0G 10% /usr/local
proc 0K 0K 0K 0% /proc
ctfs 0K 0K 0K 0% /system/contract
mnttab 0K 0K 0K 0% /etc/mnttab
objfs 0K 0K 0K 0% /system/object
lxproc 0K 0K 0K 0% /system/lxproc
swap 256M 49M 207M 20% /etc/svc/volatile
/usr/lib/libc/libc_hwcap2.so.1
376M 355M 22M 95% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
swap 256M 49M 207M 20% /tmp
swap 256M 49M 207M 20% /var/run
[root@vm100 ~]# /usr/sbin/host serv1.world.none
serv1.world.none has address 10.0.8.10
[root@vm100 ~]# /bin/cat /etc/resolv.conf
nameserver 10.0.8.10
[root@vm100 ~]# /usr/bin/netstat -rn
Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ---------- ---------
default 10.0.8.37 UG 3 458 net0
10.0.8.0 10.0.8.100 U 4 5 net0
127.0.0.1 127.0.0.1 UH 2 0 lo0
Routing Table: IPv6
Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------- -----
::1 ::1 UH 2 0 lo0
[root@vm100 ~]#
By default, our SOSVM is created fairly secure with only one externalsocket open, that of 'sshd' on port 22. Being curious about the open
port on 127.0.0.1 below, I turned to 'pfiles':
[root@vm100 ~]# /usr/bin/netstat -f inet -na
TCP: IPv4
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
-------------------- -------------------- ----- ------ ----- ------ -----------
127.0.0.1.27017 *.* 0 0 128000 0 LISTEN
*.22 *.* 0 0 128000 0 LISTEN
10.0.8.100.22 192.168.56.1.50078 64128 0 128872 0 ESTABLISHED
[root@vm100 ~]# /usr/bin/pfiles /proc/* | /usr/bin/egrep "^[0-9]|sockname"
5866: zsched
5933: /sbin/init
5973: /lib/svc/bin/svc.startd
5975: /lib/svc/bin/svc.configd
6020: /lib/inet/ipmgmtd
6054: /usr/lib/pfexecd
6219: /usr/sbin/nscd
sockname: AF_ROUTE
6287: mongod --fork -f /opt/local/etc/mongodb.conf --pidfilepath /var/mongod
sockname: AF_INET 127.0.0.1 port: 27017
sockname: AF_UNIX /tmp/mongodb-27017.sock
6293: /usr/sbin/cron
6295: /usr/lib/inet/inetd start
sockname: AF_UNIX /var/run/.inetd.uds
6299: /usr/sbin/rsyslogd -c5 -n
6300: /usr/lib/saf/sac -t 300
6305: /usr/lib/utmpd
6306: /usr/lib/saf/ttymon
6307: /usr/lib/saf/ttymon -g -d /dev/console -l console -T vt100 -m ldterm,t
6331: /usr/lib/ssh/sshd
sockname: AF_INET6 :: port: 22
6498: /usr/lib/ssh/sshd
sockname: AF_INET6 ::ffff:10.0.8.100 port: 22
6499: /usr/lib/ssh/sshd
sockname: AF_INET6 ::ffff:10.0.8.100 port: 22
6502: -bash
[root@vm100 ~]# exit
logout
Connection to vm100 closed.
troy@glados [0]
Awesome, port 27017 appears to have been opened by 'mongod', PID 6287.After identifying that, we exit our VM. Next I wanted to test if SmartOS
is mindful of VM state and to ensure that our "world-nic" service from
part 3 was going to operate appropriately following a reboot. With that
in mind, I stopped "vmnonet", verified it was stopped, and rebooted
"cn40":
# back to cn40:
cn40 [0] /usr/sbin/vmadm stop c7885cb0-4489-484d-9cb9-3e048c1f0ed5
Successfully completed stop for c7885cb0-4489-484d-9cb9-3e048c1f0ed5
cn40 [0] /usr/sbin/vmadm list
UUID TYPE RAM STATE ALIAS
7b7f6343-2584-46a4-a077-707281108449 OS 256 running vm100
c7885cb0-4489-484d-9cb9-3e048c1f0ed5 OS 256 stopped vmnonet
cn40 [0]cn40 [0] /usr/sbin/init 6
cn40 [0]
Connection to cn40 closed.
Following the reboot of "cn40", I've logged back in via 'ssh' and verifiedour network stack in the global zone; everything appears as it should.
Further, I've verified with 'vmadm' that "vm100" was restarted on boot
up of our compute node whereas "vmnonet" is still in a stopped state,
just as we left it:
troy@glados [0] ssh -l root cn40
Password:
Last login: Tue Jan 29 03:50:05 2013 from 192.168.56.1
- SmartOS Live Image v0.147+ build: 20130111T010112Z
[root@cn40 ~]#
# reset the prompt:
cn40 [0] /usr/sbin/ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
e1000g0: flags=1100943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,ROUTER,IPv4> mtu 1500 index 2
inet 10.0.7.40 netmask ffffff00 broadcast 10.0.7.255
ether 8:0:27:2d:59:51
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
inet6 ::1/128
cn40 [0] /usr/sbin/dladm show-link
LINK CLASS MTU STATE BRIDGE OVER
e1000g0 phys 1500 up vmwarebr --
e1000g1 phys 1500 up vmworld --
vmwarebr0 bridge 1500 up -- e1000g0
vmworld0 bridge 1500 up -- e1000g1
net0 vnic 1500 ? -- e1000g1
cn40 [0] /usr/sbin/dladm show-bridge
BRIDGE PROTECT ADDRESS PRIORITY DESROOT
vmwarebr stp 32768/8:0:27:2d:59:51 32768 32768/8:0:27:2d:59:51
vmworld stp 32768/8:0:27:91:1f:6e 32768 32768/8:0:27:91:1f:6e
cn40 [0] /usr/sbin/vmadm list
UUID TYPE RAM STATE ALIAS
7b7f6343-2584-46a4-a077-707281108449 OS 256 running vm100
c7885cb0-4489-484d-9cb9-3e048c1f0ed5 OS 256 stopped vmnonet
cn40 [0]
For a final act of verification, we can log into "vm100" via 'ssh'as seen below:
troy@glados [0] ssh -i ~/.ssh/vms-smartos -l root vm100
Last login: Tue Jan 29 04:51:07 2013 from 192.168.56.1
__ . .
_| |_ | .-. . . .-. :--. |-
|_ _| ;| || |(.-' | | |
|__| `--' `-' `;-| `-' ' ' `-'
/ ; SmartMachine (nodejs 1.4.0)
`-' http://wiki.joyent.com/jpc2/SmartMachine+Node.JS
[root@vm100 ~]# uptime
04:57am up 0:03, 1 user, load average: 0.09, 0.17, 0.08
[root@vm100 ~]#
So this was my first look at SmartOS, and to be honest, I like whatI see. Granted, while I have a lot of familiarity with Solaris, I'm
still getting accustomed to SmartOS so some of the routes I've gone may
have been unnecessary or over-kill. Anyhow, SmartOS is definitely worth
a look. (Hopefully I won't catch too much flak from the Joyent guys
and gals over my stumblings in this series of write ups.)
see also:
Intro SmartOS Setup pt 1
Intro SmartOS Setup pt 2
Intro SmartOS Setup pt 3
