[root@00-25-90-21-aa-c8 ~]# echo '{"brand":"kvm", "autoboot":true}' | vmadm create
Successfully created 39b7b2f0-bf22-47f5-963a-c3f21b15e7e4
[root@00-25-90-21-aa-c8 ~]# echo 'info attr name=vm-autoboot' | zonecfg -z 39b7b2f0-bf22-47f5-963a-c3f21b15e7e4 -f -
On line 1:
attr:
        name: vm-autoboot
        type: string
        value: true

Compare the above to here, where I don't set autoboot: true:

[root@00-25-90-21-aa-c8 ~]# echo '{"brand":"kvm", "autoboot":false}' | vmadm create
Successfully created 696ce4de-7e1f-4818-907c-d25199bc1597
[root@00-25-90-21-aa-c8 ~]# echo 'info attr name=vm-autoboot' | zonecfg -z 696ce4de-7e1f-4818-907c-d25199bc1597 -f -
On line 1:
No such attr resource.

The affect of this is the following error message printed on console and in logs when you start the VM without the vm-autoboot attribute:
startVM(): Failed to select attr name=vm-autoboot; set value=true; end for 696ce4de-7e1f-4818-907c-d25199bc1597

I just want to make sure this isn't something you guys already have fixed, before I start looking for a fix.

- SmartOS Live Image v0.147+ build: 20111213T065935Z
[root@00-0c-29-0d-7b-cb ~]# ping google.com
ping: unknown host google.com
[root@00-0c-29-0d-7b-cb ~]# host google.com
google.com has address 74.125.230.242
google.com has address 74.125.230.241
google.com has address 74.125.230.240
google.com has address 74.125.230.244
google.com has address 74.125.230.243
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
[root@00-0c-29-0d-7b-cb ~]#

If I add the hostnames to /etc/hosts it works.

[root@00-0c-29-0d-7b-cb ~]# echo 74.125.230.242 google.com>>/etc/hosts
[root@00-0c-29-0d-7b-cb ~]# ping google.com
google.com is alive
[root@00-0c-29-0d-7b-cb ~]#

It's hard to download some isos for tests if you have to enter each host to /etc/hosts ;)

When building ISC Bind on SmartOS, it breaks as it wants /usr/ccs/bin/nm, which is in /usr/bin now but not symlinked from /usr/ccs/bin - in fact /usr/ccs/bin is very empty on SmartOS:

# ls -l /usr/ccs/bin
total 3
drwxr-xr-x 2 root bin   3 Sep  6 19:29 amd64
lrwxrwxrwx 1 root root 12 Sep 12 19:30 ld -> ../../bin/ld
lrwxrwxrwx 1 root root 12 Sep 12 19:30 m4 -> ../../bin/m4
lrwxrwxrwx 1 root root 16 Sep 12 19:30 regcmp -> ../../bin/regcmp

Given these just symlink back to ../../bin equivalents, you could do what alanc reports has been done on S11 and symlink /usr/ccs/bin to /usr/bin.

The output from "ps ux" and "ps aux" needs a column separator to prevent the "SZ" and "RSS" columns from bleeding together like this:

USER       PID %CPU %MEM   SZ  RSS TT       S    START  TIME COMMAND
nobody   20334  0.0  0.14314825996 ?        S   Feb 29  0:00 /opt/apache22/bin/httpd -f /opt/napp/etc/httpd.conf -k start
nobody   20335  0.0  0.14356426144 ?        S   Feb 29  0:00 /opt/apache22/bin/httpd -f /opt/napp/etc/httpd.conf -k start
nobody   20336  0.0  0.14483227564 ?        S   Feb 29  0:00 /opt/apache22/bin/httpd -f /opt/napp/etc/httpd.conf -k start
nobody   20337  0.0  0.14480427456 ?        S   Feb 29  0:00 /opt/apache22/bin/httpd -f /opt/napp/etc/httpd.conf -k start

With joyent_20120405T204624Z I occasionally see:

# dsadm avail | head
UUID                                 OS      PUBLISHED  URN                    
b2845b76-80c5-11e1-9d72-5b4ca4191e12 smartos 2012-04-07 sdc:sdc:smartosplus64:3.2.0
c36a3d28-80c2-11e1-9ec6-df5bd8b43f76 smartos 2012-04-07 sdc:sdc:smartosplus:3.2.0
ce610cc2-80ac-11e1-8626-d788d6268d5b smartos 2012-04-07 sdc:sdc:smartos64:1.6.2
a93fda38-80aa-11e1-b8c1-8b1f33cd9007 smartos 2012-04-07 sdc:sdc:smartos:1.6.2  
e4cd7b9e-4330-11e1-81cf-3bb50a972bda linux   2012-04-04 sdc:jpc:centos-6:1.0.1 
f4c23828-7981-11e1-912f-8b6d67c68076 smartos 2012-03-29 sdc:sdc:smartos64:1.6.1
2b4466d8-7981-11e1-9be2-3b0d0e114740 smartos 2012-03-29 sdc:sdc:smartos:1.6.1  
d239389c-7535-11e1-b60a-6f75edc139df smartos 2012-03-23 sdc:sdc:mongodb:1.2.4  
98f38e14-6f83-11e1-bc32-2b9d0a8b6759 smartos 2012-03-16 sdc:sdc:mongodb:1.1.1  

events.js:48
        throw arguments[1]; // Unhandled 'error' event
                       ^
Error: write EPIPE
    at errnoException (net.js:646:11)
    at Object.afterWrite [as oncomplete] (net.js:480:18)

Happens perhaps 1 out of 3 attempts, running in VirtualBox connected via SSH.

I have taken the example "joyent" brand zone from the comments in /usr/sbin/create-machine. When I run it I get the following error:

  fs.js:221
  return binding.open(path, stringToFlags(flags), mode);
                 ^
Error: EBADF, Bad file number '/zones/57d46f5e-e749-493d-8824-1458e6fa78da/root/etc/hostname.net0'
    at Object.openSync (fs.js:221:18)
    at Object.writeFileSync (fs.js:483:15)
    at writeZoneconfig (/usr/sbin/create-machine:731:16)
    at /usr/sbin/create-machine:1408:21
    at /usr/sbin/create-machine:588:13

This appears to be because the full path hostname.net0 is missing. Only /zones/57d46f5e-e749-493d-8824-1458e6fa78da was created, while root/etc was not.

I have existing pools which I want to be managed by KVM guests running illumos and NexentaStor. On the older vmadmd in smartos-live 201109xx, I was able to add the physical disks by overloading the 'model' net-attr for devices.

For example, I have a

<device match="/dev/rdsk/c2t514d0">
    <net-attr name="model" value="none,id=sata-disk0"/>
</device>

Corresponding to 'qemu-extra-opts' contents "-device ahci,id=ahci0,bus=pci.0,multifunction=on -device ide-drive,drive=sata0-disk0,bus=ahci0.0".

This was converted into qemu arguments:
"-drive file=/dev/rdsk/c2t514d0,if=none,id=sata-disk0,index=1,media=disk"

The current vmadmd does this instead and causes qemu to choke:
"-drive file=/dev/rdsk/c2t514d0,if=undefined,index=1,media=disk"

startElement in VM.js assumes all device elements are disks but only uses the net-attr child attributes for devices with paths matching "/dev/._disk[0-9]+" when setting properties. It tries to use direct attributes for the device element as well but I don't think any are allowed by the zonecfg DTD. This results in "undefined" for the 'model' property for any devices not matching "/dev/._disk[0-9]+".

    } else if (where === 'zone.device') {
        // new disk device
        for (prop in attrs) {
            if (XML_PROPERTIES.disk.hasOwnProperty(prop)) {
                use = XML_PROPERTIES.disk[prop];
                disk[use] = attrs[prop];
            } else {
                VM.log('DEBUG', 'unknown disk prop: ' + prop);
            }
        }
        if (!obj.hasOwnProperty('devices')) {
            obj.devices = {};
        }
        obj.devices[disk.path] = disk;
        stack.push(disk.path);
    } else if (where.match(/zone\.device\.\/dev\/.*disk[0-9]+\.net-attr/)) {
        if (XML_PROPERTIES.disk.hasOwnProperty(attrs.name)) {
            use = XML_PROPERTIES.disk[attrs.name];
            obj.devices[stack[2]][use] = attrs.value;
        } else {
            VM.log('DEBUG', 'unknown disk prop: ' + attrs.name);
        }
    }

One alternative might be for vmadmd to ignore device elements without a 'model' net-attr, so invalid "-drive" arguments are not passed to qemu. This would also allow non-disk devices (audio, etc.) to be passed through.

This would leave "-drive" to be manually specified in the 'qemu-extra-opts' attr. A helpful addition might be to keep constructing "-drive" for devices with another net-attr, whose value is passed directly to qemu (as 'model' was previously).

This is obviously not a complete solution for external devices but would make my life a lot easier.

just because Date.getMonth() starts at 0 for January

[root@00-1c-42-5f-3e-a0 ~]# dsadm avail|head -n 3
UUID                                 OS      PUBLISHED  URN
1796eb3a-48d3-11e1-94db-3ba91709fad9 smartos 2012-00-27 sdc:sdc:riak:1.5.5
86112bde-43c4-11e1-84df-8f7fd850d78d linux   2012-00-25 sdc:sdc:centos6:0.1.1

simple patch: 7a07a1c90dea2a4853651a5f3b63d07ff7ee8109

On a fresh "prototype" configuration file:

[root@00-21-28-46-f1-04 /zones/json]# vmadm create -f base.json 

/usr/vm/node_modules/VM.js:1569
    if (p.hasOwnProperty('used_disk_indexes')) {
    ^
ReferenceError: p is not defined
    at createVolumes (/usr/vm/node_modules/VM.js:1569:5)
    at /usr/vm/node_modules/VM.js:1738:13
    at /usr/node_modules/async.js:453:21
    at /usr/node_modules/async.js:158:13
    at /usr/node_modules/async.js:118:13
    at /usr/node_modules/async.js:129:25
    at /usr/node_modules/async.js:160:17
    at /usr/node_modules/async.js:458:34
    at /usr/vm/node_modules/VM.js:1435:9
    at Object.forEach (/usr/node_modules/async.js:93:20)

The file was:

{
  "brand": "kvm",
  "vcpus": 1,
  "autoboot": false,
  "ram": 2048,
  "hostname": "base",
  "alias": "base",
  "default_gateway": "192.168.0.1",
  "resolvers" : ["192.168.0.2", "192.168.0.3"],
  "disks": [
    {
      "boot": true,
      "model": "virtio",
      "size": 40960
    }
  ],
  "nics": [
    {
      "nic_tag": "admin",
      "model": "virtio",
      "ip": "192.168.0.10",
      "netmask": "255.255.255.0",
      "gateway": "192.168.0.1",
    }
  ]
}

I can see in VM.js there is a check to make sure any "nics.*.primary" properties are set to "true", otherwise a error is given.
Is there any reason why the code doesn't allow you to set primary=false, without giving an error?

The background for this, is that we have a system to generate JSON objects for creating VMs, and instead of having to add/remove the "primary" property, depending on whether it's set or not, it would be easier to set it to true/false.

[root@14-da-e9-ed-e1-8b /]# vmadm boot eb0a6d55-42cb-4e10-9d5f-3fa9361503c5 order=cd,once=d cdrom=/boot.iso,ide
Unable to start VM eb0a6d55-42cb-4e10-9d5f-3fa9361503c5: Cannot find disk: /boot.iso

boot.iso is located at /zones/eb0a6d55-42cb-4e10-9d5f-3fa9361503c5/root/boot.iso

Seems to be broken since the last release.

A first look into the code introduced a new vmobj.zoneroot that seems to be never initialized with any value.

the content should be:

https://datasets.joyent.com/datasets

and not:

https://datasets.joyent.com/

I'm building inside a zone (smartos 1.3.18)
building inside that zone was successful with the last version

what i did:

rm -rf smartos-live
git clone git://github.com/joyent/smartos-live.git
cd smartos-live
cp sample.configure.smartos configure.smartos
./configure
gmake world

Console output:

 ~/smartos-live]# gmake world
(cd /root/smartos-live && ./tools/build_illumos)
==> Building Illumos (20120130T091819Z)
Build type   is  non-DEBUG
WARNING: invalid value for MULTI_PROTO (); setting to "no".
RELEASE      is
VERSION      is joyent_20120130T091819Z
RELEASE_DATE is January 2012

The top-level 'setup' target is available to build headers and tools.

Using /usr/bin/bash as shell.
dmake: Warning: Can't find `make.rules': No such file or directory
/root/smartos-live/projects/illumos/usr/src/tools
usage: install [options] file [dir1 ...]
*** Error code 2
The following command caused the error:
cd tools; pwd;  install
dmake: Fatal error: Command failed for target `bldtools'
Current working directory /root/smartos-live/projects/illumos/usr/src
gmake: *** [0-illumos-stamp] Error 1

something wrong on my side or is this reproducible?

Currently SmartOS does not deal correctly with terminals announcing themself as xterm-256color. A quick workaround would be to add this like to the default .bashrc for root:

if [ "${TERM}" == "xterm-256color" ]; then
    export TERM=xterm-color
fi

https://github.com/joyent/smartos-live/blob/master/src/vmadmd.js#L1428

vmadmd uses the 'default-gateway' VM property and and 'gateway' per-NIC property to try to locate the primary interface and only provide a hostname and dns_ip for it. It should just choose the first NIC if 'default-gateway' is not set, and also not rely on 'gateway' to be set.

[root@00-25-90-62-94-aa ~]# vmadm list
UUID TYPE RAM STATE ALIAS
6feb7166-1944-4310-a6d1-69bc8cbb4ea0 KVM 4096 configured jkm-win2008

[root@00-25-90-62-94-aa ~]# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zones 6.80G 1.78T 482K /zones
zones/config 49K 1.78T 49K legacy
zones/cores 31K 10.0G 31K /zones/global/cores
zones/dump 4.00G 1.78T 4.00G -
zones/iso 2.79G 1.78T 2.79G /zones/iso
zones/opt 31K 1.78T 31K legacy
zones/usbkey 128K 1.78T 128K legacy
zones/var 3.23M 1.78T 3.23M legacy

[root@00-25-90-62-94-aa ~]# vmadm destroy 6feb7166-1944-4310-a6d1-69bc8cbb4ea0
Command failed: cannot open 'zones/6feb7166-1944-4310-a6d1-69bc8cbb4ea0-disk0': dataset does not exist

Note the dataset returned by vmadm destroy compared to what is actually configured ("dataset/UUID" vs "tank/dataset/UUID")

# cat kvm.json
{
   "nics" : [
      {
         "gateway" : "10.21.200.1",
         "ip" : "10.21.200.108",
         "model" : "virtio",
         "netmask" : "255.255.255.0",
         "nic_tag" : "admin",
         "resolvers" : "10.1.1.92"
      }
   ],
   "dns_domain" : "immunet.com",       "brand" : "kvm",
   "hostname" : "testfoo",       "disks" : [
      {
         "boot" : true,
         "image_name" : "fc14_x86_64",
         "image_uuid" : "templates/fc14_x86_64",
         "model" : "virtio",             "size" : 10240
      },
      {
         "boot" : false,
         "media" : "disk",             "model" : "virtio",
         "zpool" : "tank/data",             "size" : "102400"
      }
   ],
   "default_gateway" : "10.21.200.1",
   "vcpus" : "2",
   "autoboot" : true,       "alias" : "testfoo",
   "ram" : "1024",
   "qemu_extra_opts" : "\"-no-hpet\""
}

# zfs list -t all | grep 49df3a66-0417-499c-bebb-8742d910ee18    tank/data/49df3a66-0417-499c-bebb-8742d910ee18-disk1                            44.5K  11.3T  44.5K  -
zones/49df3a66-0417-499c-bebb-8742d910ee18                                       114K  10.0G  83.5K  /zones/49df3a66-0417-499c-bebb-8742d910ee18
zones/49df3a66-0417-499c-bebb-8742d910ee18-disk0                                2.60M   226G  1.48G  -
zones/49df3a66-0417-499c-bebb-8742d910ee18/cores                                  31K  2.25G    31K  /zones/49df3a66-0417-499c-bebb-8742d910ee18/cores
zones/templates/fc14_x86_64@49df3a66-0417-499c-bebb-8742d910ee18-disk0              0      -  1.48G  -

# vmadm destroy 49df3a66-0417-499c-bebb-8742d910ee18
Command failed: cannot open 'data/49df3a66-0417-499c-bebb-8742d910ee18-disk1': dataset does not exist

# zfs list -t all | grep 49df3a66-0417-499c-bebb-8742d910ee18    tank/data/49df3a66-0417-499c-bebb-8742d910ee18-disk1                            44.5K  11.3T  44.5K  -
zones/templates/fc14_x86_64@49df3a66-0417-499c-bebb-8742d910ee18-disk0              0      -  1.48G  -

Note that this also means the config is not destroyed, so if you attempt to "vmadm create" with a zone with the same IP, you get an error and run into #38.

If vmadm destroy is parsing startvm to get all "-drive" elements, it may be misparsing ""file=/dev/zvol/rdsk/tank/data/93de230c-4c12-4236-9c3a-08b514950d92-disk1"?

When running through the initial setup smartos_prompt_config.sh, during the zfs pool creation swap is not created which is needed for certain actions (i.e. locking memory when create KVM instances).

The build thinks that node-*/build/Release/... will contain modules, my builds are producing node-*/build/default/.

Perhaps I screwed something up?

Following the readme I'm crawling slowly toward a first time build, but came across this problem.

I'm building on an Amilo Pa1510 2GB with intel X25-M:
$ cat /etc/release
OpenIndiana Development oi_151a X86
Copyright 2010 Oracle and/or its affiliates. All rights reserved.
Use is subject to license terms.
Assembled 01 September 2011
$ isainfo -v
64-bit amd64 applications
amd_svm tscp ahf cx16 sse3 sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx
mmx cmov amd_sysc cx8 tsc fpu
32-bit i386 applications
amd_svm tscp ahf cx16 sse3 sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx
mmx cmov amd_sysc cx8 tsc fpu

the configure seems ok:
I modified only the following lines in configure.smartos:
SUNW_SPRO12_URL="file:/home/richard/Téléchargements/sunstudio12-patched-ii-2009Sep-sol-x86.tar.bz2"
SUNW_SPRO12u1_URL="file:/home/richard/Téléchargements/sunstudio12u1-patched-ii-2010Feb-sol-x86.tar.gz"

$ ./configure
==> Installing illumos build dependencies...
Aucune mise à jour n'est nécessaire pour cette image.
==> Installing illumos-extra dependencies...
Création du planpkg: 'library/libevent' correspond à plusieurs packages
sfe.openindiana.org/library/libevent
library/libevent

==> Checking for /opt/SUNWspro/bin/cc...
+--> Ensuring SUNWspro (12.1-patched) installed in /opt/SUNWspro/sunstudio12.1...
+--> Ensuring SUNWspro (12-patched) installed in /opt/SUNWspro...
==> Creating the missing symlinks...
==> Populating projects/ directories...
==> Setting up illumos-gate

Configuration complete. You should now be able to build a live image using 'gmake world && gmake live'

for info, I have the latest libevent from sfe installed:
$ pkg list -a libevent
NAME (PUBLISHER) VERSION STATE UFOXI
library/libevent 1.3.5-0.151.1 connu -----
sfe.openindiana.org/library/libevent (sfe) 2.0.12-0.151.1 installé -----

but after gmake world I get the following mail:
==== Nightly distributed build started: Sun Oct 2 16:51:37 CEST 2011 ====
==== Nightly distributed build completed: Sun Oct 2 20:26:50 CEST 2011 ====

==== Total build time ====

real 3:35:12

==== Build environment ====

/usr/bin/uname
SunOS amilo 5.11 oi_151a i86pc i386 i86pc

/opt/SUNWspro/bin/dmake
dmake: Sun Distributed Make 7.8 SunOS_i386 Patch 126504-01 2007/07/19
number of concurrent jobs = 4

32-bit compiler
/home/richard/src/joyent-smartos-live-49b86bb/projects/illumos/usr/src/tools/proto/root_i386-nd/opt/onbld/bin/i386/cw -_cc
cw version 1.29 (SHADOW MODE DISABLED)
primary: /opt/SUNWspro/bin/cc
cc: Sun C 5.9 SunOS_i386 Patch 124868-10 2009/04/30

64-bit compiler
/home/richard/src/joyent-smartos-live-49b86bb/projects/illumos/usr/src/tools/proto/root_i386-nd/opt/onbld/bin/i386/cw -_cc
cw version 1.29 (SHADOW MODE DISABLED)
primary: /opt/SUNWspro/bin/cc
cc: Sun C 5.9 SunOS_i386 Patch 124868-10 2009/04/30

/usr/java/bin/javac
java full version "1.6.0_26-b03"

/usr/ccs/bin/as
as: Sun Compiler Common 12 SunOS_i386 snv_121 08/03/2009

/usr/ccs/bin/ld
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1726

Build project: group.staff
Build taskid: 147

==== Nightly argument issues ====

Warning: the N option (do not run protocmp) is set; it probably shouldn't be

WARNING: MULTI_PROTO is ""; should be "yes" or "no".
Setting MULTI_PROTO to "no".

==== Build version ====

joyent_20111002T144916Z

==== Tools build errors ====

==== Build errors (non-DEBUG) ====

The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/Utils/Makefile' The following command caused the error: dmake: Warning: Command failed for targetSun/Solaris/Kstat/Makefile'
The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/Intrs/Makefile' The following command caused the error: dmake: Warning: Command failed for targetSun/Solaris/Project/Makefile'
The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/Task/Makefile' The following command caused the error: dmake: Warning: Command failed for targetSun/Solaris/Exacct/Makefile'
The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/Privilege/Makefile' The following command caused the error: dmake: Warning: Command failed for targetSun/Solaris/Lgrp/Makefile'
The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/BSM/Makefile' The following command caused the error: dmake: Warning: Command failed for targetSun/Solaris/PerlGcc/Makefile'
The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/Pg/Makefile' The following command caused the error: dmake: Warning: Command failed for targetSun/Solaris/Utils/Makefile'
The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/Kstat/Makefile' The following command caused the error: dmake: Warning: Command failed for targetSun/Solaris/Intrs/Makefile'
The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/Project/Makefile' The following command caused the error: dmake: Warning: Command failed for targetSun/Solaris/Task/Makefile'
The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/Exacct/Makefile' The following command caused the error: dmake: Warning: Command failed for targetSun/Solaris/Privilege/Makefile'
The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/Lgrp/Makefile' The following command caused the error: dmake: Warning: Command failed for targetSun/Solaris/BSM/Makefile'
The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/PerlGcc/Makefile' The following command caused the error: dmake: Warning: Command failed for targetSun/Solaris/Ucred/Makefile'
The following command caused the error:
dmake: Warning: Command failed for target Sun/Solaris/Pg/Makefile' dmake: Warning: Don't know how to make targetinstall'
dmake: Warning: Target install' not remade because of errors dmake: Warning: Targetinstall' not remade because of errors
The following command caused the error:
dmake: Warning: Command failed for target 5.12' dmake: Warning: Targetinstall' not remade because of errors
The following command caused the error:
dmake: Warning: Command failed for target perl' dmake: Warning: Targetinstall' not remade because of errors
The following command caused the error:
dmake: Warning: Target `install' not remade because of errors

==== Build warnings (non-DEBUG) ====

dmake: Warning: Command failed for target Sun/Solaris/Utils/Makefile' dmake: Warning: Command failed for targetSun/Solaris/Kstat/Makefile'
dmake: Warning: Command failed for target Sun/Solaris/Intrs/Makefile' dmake: Warning: Command failed for targetSun/Solaris/Project/Makefile'
dmake: Warning: Command failed for target Sun/Solaris/Task/Makefile' dmake: Warning: Command failed for targetSun/Solaris/Exacct/Makefile'
dmake: Warning: Command failed for target Sun/Solaris/Privilege/Makefile' dmake: Warning: Command failed for targetSun/Solaris/Lgrp/Makefile'
dmake: Warning: Command failed for target Sun/Solaris/BSM/Makefile' dmake: Warning: Command failed for targetSun/Solaris/PerlGcc/Makefile'
dmake: Warning: Command failed for target Sun/Solaris/Pg/Makefile' dmake: Warning: Command failed for targetSun/Solaris/Utils/Makefile'
dmake: Warning: Command failed for target Sun/Solaris/Kstat/Makefile' dmake: Warning: Command failed for targetSun/Solaris/Intrs/Makefile'
dmake: Warning: Command failed for target Sun/Solaris/Project/Makefile' dmake: Warning: Command failed for targetSun/Solaris/Task/Makefile'
dmake: Warning: Command failed for target Sun/Solaris/Exacct/Makefile' dmake: Warning: Command failed for targetSun/Solaris/Privilege/Makefile'
dmake: Warning: Command failed for target Sun/Solaris/Lgrp/Makefile' dmake: Warning: Command failed for targetSun/Solaris/BSM/Makefile'
dmake: Warning: Command failed for target Sun/Solaris/PerlGcc/Makefile' dmake: Warning: Command failed for targetSun/Solaris/Ucred/Makefile'
dmake: Warning: Command failed for target Sun/Solaris/Pg/Makefile' dmake: Warning: Don't know how to make targetinstall'
dmake: Warning: Target install' not remade because of errors dmake: Warning: Targetinstall' not remade because of errors
dmake: Warning: Command failed for target 5.12' dmake: Warning: Targetinstall' not remade because of errors
dmake: Warning: Command failed for target perl' dmake: Warning: Targetinstall' not remade because of errors
dmake: Warning: Target `install' not remade because of errors

==== Elapsed build time (non-DEBUG) ====

real 3:30:40.3
user 4:42:18.1
sys 53:27.8

==== cstyle/hdrchk errors ====

==== Find core files ====

A snippet from the log file:
/home/richard/src/joyent-smartos-live-49b86bb/projects/illumos/usr/src/cmd/perl/5.12/Sun/Solaris/Utils
sh: line 1: /usr/perl5/5.12/bin/perl: not found
*** Error code 127
The following command caused the error:
cd Sun/Solaris/Utils; pwd; /usr/perl5/5.12/bin/perl Makefile.PL INSTALLDIRS=perl CC='/home/richard/src/joyent-smartos-live-49b86bb/projects/illumos/usr/src/tools/proto/root_i386-nd/opt/onbld/bin/i386/cw -_cc' LD='/home/richard/src/joyent-smartos-live-49b86bb/projects/illumos/usr/src/tools/proto/root_i386-nd/opt/onbld/bin/i386/cw -_cc' 2>&1 /dev/null
dmake: Warning: Command failed for target `Sun/Solaris/Utils/Makefile'
Current working directory /home/richard/src/joyent-smartos-live-49b86bb/projects/illumos/usr/src/cmd/perl/5.12

perl 5.12 is not found by the package manager, only 5.10.
special step necessary?

updated : http://lists.illumos.org/pipermail/developer/2011-March/001644.html

manual tracing led me to clear_boot_mappings() called from release_bootstrap().

However I'm not sure whether this was caused by callout/interrupt activity, but the crash is always reproducible in that place.

file /usr/lib/64/libexpat.so.1.5.2
/usr/lib/64/libexpat.so.1.5.2: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped

D'oh.

@postwait Thanks for mentioning this.

This seems to be a bug, I have reproduced this on lastest USB Image of SmartOS and a previous image, this also occured on 2 different SmartOS nodes running different Hardware . It seems that certain graphical vnc clients for some reason result in the VNC console losing all parameters such as port settings. This is confirmed with a "vmadmin info UUID vnc" which return blank VNC ports. The VM itself is unaffected but connectivity via the console is unavailable until the VM is restarted and new VNC ports are assigned.

The way I triggered this crash is by using the following vnc client on Mac OSX Lion:

http://www.realvnc.com/products/enterprise/

I just downloaded the enterprise version in Trial mode and only installed the vnc client component and did not install the server component. The error is triggered if you connect with the gui client "realvnc viewer" it starts by loading the vnc window which remains black and non responsive. I then close the window and try to reconnect and there is no response from smartos KVM server. Running "vmadmin info UUID vnc" shows that the VM is no longer serving a PORT and its blank.

This seems to be triggered from the Client only, and running the vncviewer session from the command line works perfectly every time. run from command line as e.g "/Applications/RealVNC/VNC\ Viewer.app/Contents/MacOS/vncviewer AutoSelect=0 FullColor=1 10.1.1.201:51312 "

/usr/bin/json runs "node" from the caller's $PATH, which might not be /usr/bin/node, and is probably a newer version.

https://gist.github.com/7a4210446cc6bf666ca8

I used create-machine on a template containing:

  "disks": [
    {
      "boot": true,
      "model": "ahci",
      "size": 40960
    }

This ended up in /etc/zones/6f3c52cf-dbdf-4e67-be17-b66da6a78202.xml as:

  <device match="/dev/zvol/rdsk/zones/6f3c52cf-dbdf-4e67-be17-b66da6a78202-disk0">
    <net-attr name="index" value="0"/>
    <net-attr name="boot" value="true"/>
    <net-attr name="model" value="ahci"/>
    <net-attr name="size" value="40960"/>
  </device>

Unless I'm mistaken, net-attr attributes should only appear under the network sections.

Version is joyent_20110926T021612Z.

It appears to pull info for all zones, and then returns nothing:

# time vmadm list
UUID                                  TYPE  RAM      STATE             ALIAS 
10bc0b4a-8df4-4808-8b7c-96b19ff5dbcb  KVM   1024     running           analysis0
21e72bde-c61e-4748-90e0-8281f4e8007f  KVM   1024     running           process1
409e2214-1a40-429c-9404-039c135170c1  KVM   1024     running           analysis2
508bf6c8-f899-4924-a16f-15dd10a80211  KVM   1024     running           process2
97808650-ba5b-48fb-860d-a2624ce3afe3  KVM   1024     running           analysis1
1c8d924d-9d70-40b4-bcb2-4b3a7e318cd4  OS    2048     running           sprawlmq-int
ce3a4d67-9a61-4bb1-a520-a79131181f2c  KVM   8192     running           control1-int
a9d64ca3-a155-4e83-90a7-ea9a65179d8c  OS    16384    running           demoimport1-int
492add60-13cc-4239-a4c6-a6a561251416  OS    -        running           clouddb3
828dd430-979d-498f-abc1-a6583e90454a  OS    -        running           cleanroom
d755787d-6b1c-4027-a4a6-7c5e2a962f8f  OS    -        running           clouddb3

real    0m15.211s
user    0m3.602s
sys     0m5.896s

# time vmadm list a9d64ca3-a155-4e83-90a7-ea9a65179d8c
UUID                                  TYPE  RAM      STATE             ALIAS 

real    0m14.612s
user    0m3.738s
sys     0m5.945s

I was having issues compiling Python 2.6 with the dtrace probes enabled, with the following barfing going on:

# dtrace -o Python/phelper.o -DPHELPER -32 -I. -IInclude -I/export/home/alasdair/s10-userland/components/python/python26/Python-2.6.6/Include -IPython -I/ec/include/ncurses -D_LARGEFILE64_SOURCE -I/ec/lib/libffi-3.0.9/include   -C -G -s /export/home/alasdair/s10-userland/components/python/python26/Python-2.6.6/Python/phelper.d
./pyconfig.h: 1010: r
dtrace: failed to compile script /export/home/alasdair/s10-userland/components/python/python26/Python-2.6.6/Python/phelper.d: "/usr/include/sys/va_impl.h", line 166: invalid control directive: #error(

With richlowe's assistance we tracked this down to cpp barfing. Using cpp from Solaris 10 or OpenIndiana oi_151a fixes the issue.

Apparently smartos is using a different cpp?

If a zone is halted, vmadm boot will fail the first time it is invoked.

[root@mameshiba /etc/zones]# vmadm halt f4763d2b-d656-4e4e-a3ae-0a16900bc9c6
[root@mameshiba /etc/zones]# vmadm list -v
UUID                                  RAM      STATUS          
f4763d2b-d656-4e4e-a3ae-0a16900bc9c6  4096     off             
6f3c52cf-dbdf-4e67-be17-b66da6a78202  1024     running         
[root@mameshiba /etc/zones]# vmadm boot f4763d2b-d656-4e4e-a3ae-0a16900bc9c6
Fatal Error: "Not running boot because we're still running halt"
[root@mameshiba /etc/zones]# vmadm boot f4763d2b-d656-4e4e-a3ae-0a16900bc9c6
[root@mameshiba /etc/zones]#

The VNC information from vmadm info seems to disappear after you close your VNC session, and only rebooting the VM will bring back the ability to connect to the VNC, or see the VNC information.

To reproduce:

1. Create a VM
2. Run vmadm info <zone_id> | json vnc
3. Log into VNC
4. Close your VNC session
5. Run vmadm info <zone_id> | json vnc

The VNC information will no longer be shown.

Seems to take ~1s per zone.

# time vmadm list
UUID                                  TYPE  RAM      STATE             ALIAS
10bc0b4a-8df4-4808-8b7c-96b19ff5dbcb  KVM   1024     running           analysis0
21e72bde-c61e-4748-90e0-8281f4e8007f  KVM   1024     running           process1
409e2214-1a40-429c-9404-039c135170c1  KVM   1024     running           analysis2
508bf6c8-f899-4924-a16f-15dd10a80211  KVM   1024     running           process2
97808650-ba5b-48fb-860d-a2624ce3afe3  KVM   1024     running           analysis1
1c8d924d-9d70-40b4-bcb2-4b3a7e318cd4  OS    2048     running           sprawlmq-int
ce3a4d67-9a61-4bb1-a520-a79131181f2c  KVM   8192     running           control1-int
a9d64ca3-a155-4e83-90a7-ea9a65179d8c  OS    16384    running           demoimport1-int
492add60-13cc-4239-a4c6-a6a561251416  OS    -        running           clouddb3
828dd430-979d-498f-abc1-a6583e90454a  OS    -        running           cleanroom
d755787d-6b1c-4027-a4a6-7c5e2a962f8f  OS    -        running           clouddb3

real    0m15.211s
user    0m3.602s
sys     0m5.896s

Current vmadmd requires the 'primary' property to be set on a NIC object (or a NIC 'gateway' propertly has to match 'default-gateway') in order for the resolver and default gateway to be set for KVM guests. Using an "update_nics" JSON payload to 'vmadm update' does not appear to add this property.

[root@mameshiba /tmp]# vmadm list
UUID                                  TYPE  RAM      STATE             ALIAS
2db5ca4c-1295-4c0f-aab1-bdb8d5dadfb2  OS    256      running           -
0085b669-fade-4569-a273-937fa6f3ea39  KVM   512      stopped           winxp
6f3c52cf-dbdf-4e67-be17-b66da6a78202  KVM   1024     stopped           nexenta
f4763d2b-d656-4e4e-a3ae-0a16900bc9c6  KVM   4096     stopped           babyshiba
[root@mameshiba /tmp]# vmadm get 6f3c52cf-dbdf-4e67-be17-b66da6a78202 | json nics
[
  {
    "interface": "net0",
    "mac": "a2:ea:49:39:29:43",
    "nic_tag": "external",
    "ip": "192.168.4.208",
    "netmask": "255.255.255.0",
    "gateway": "192.168.4.254",
    "model": "rtl8139"
  }
]
[root@mameshiba /tmp]# for uuid in `vmadm list -H -o uuid`; do echo "{ \"update_nics\": [ { `vmadm get $uuid | json nics | grep mac | head -1` \"primary\": 1 } ] }"; done
{ "update_nics": [ {     "mac": "a2:e2:c4:4a:0d:07", "primary": 1 } ] }
{ "update_nics": [ {     "mac": "b2:04:f0:f9:ad:bd", "primary": 1 } ] }
{ "update_nics": [ {     "mac": "a2:ea:49:39:29:43", "primary": 1 } ] }
{ "update_nics": [ {     "mac": "a2:11:1e:dd:af:97", "primary": 1 } ] }
[root@mameshiba /tmp]# for uuid in `vmadm list -H -o uuid`; do echo "{ \"update_nics\": [ { `vmadm get $uuid | json nics | grep mac | head -1` \"primary\": 1 } ] }" | vmadm update $uuid                                                       
Successfully updated 2db5ca4c-1295-4c0f-aab1-bdb8d5dadfb2
Successfully updated 0085b669-fade-4569-a273-937fa6f3ea39
Successfully updated 6f3c52cf-dbdf-4e67-be17-b66da6a78202
Successfully updated f4763d2b-d656-4e4e-a3ae-0a16900bc9c6
[root@mameshiba /tmp]# vmadm get 6f3c52cf-dbdf-4e67-be17-b66da6a78202 | json nics
[
  {
    "interface": "net0",
    "mac": "a2:ea:49:39:29:43",
    "nic_tag": "external",
    "ip": "192.168.4.208",
    "netmask": "255.255.255.0",
    "gateway": "192.168.4.254",
    "model": "rtl8139"
  }
]

ome reason VM.js isn't picking up the hostname attr in the zonecfg xml. This means that hostnames for KVM zones can't be set by dhcp!

'hostname' shows up in zonecfg:

[root@00-25-90-56-dd-05 /tmp]# zonecfg -z 52a5cf72-0270-430f-ae69-9ffe0fa6b392 info | /opt/local/bin/grep -A 2 hostname
name: hostname
type: string
value: testing-smc01

'hostname' shows up in the xml file that VM.js parses with expat:

[root@00-25-90-56-dd-05 /tmp]# grep 'hostname' /etc/zones/52a5cf72-0270-430f-ae69-9ffe0fa6b392.xml

But doesn't seem to get parsed properly:

[root@00-25-90-56-dd-05 /tmp]# vmadm get 52a5cf72-0270-430f-ae69-9ffe0fa6b392 | grep hostname
[root@00-25-90-56-dd-05 /tmp]#

I'm pretty sure this worked at one point and I'm sure what I could have changed. Here's my vmadm create json:

{
"hostname": "testing-smc01",
"brand": "kvm",
"vcpus": 1,
"autoboot": false,
"ram": 1024,
"default-gateway": "10.0.0.1",
"resolvers" : ["10.0.0.1" ],
"disks": [
{
"boot": true,
"model": "virtio",
"image_uuid": "datasets/ubuntu_10-04",
"size": 40960
}
],
"nics": [
{
"primary": 1,
"nic_tag": "admin",
"model": "virtio",
"ip": "10.0.4.3",
"netmask": "255.255.0.0",
"gateway": "10.0.0.1"
}
]
}

Thanks!

A config file of

{
      "brand": "joyent",
      "dataset_uuid": "467ca742-4873-11e1-80ea-37290b38d2eb",
        "nics": [
        {
          "nic_tag": "admin",
          "ip": "192.168.111.31",
          "netmask": "255.255.255.0",
          "gateway": "192.168.111.1"
        }
      ]
    }

passed to vmadm create < config yields an error :

fs.js:221
  return binding.open(path, stringToFlags(flags), mode);
                 ^
Error: EBADF, Bad file number '/zones/1d0c4411-b3ed-4f09-90d4-c397ff234365/root/etc/hostname.net0'
    at Object.openSync (fs.js:221:18)
    at Object.writeFileSync (fs.js:483:15)
    at writeZoneconfig (/usr/vm/node_modules/VM.js:1800:20)
    at /usr/vm/node_modules/VM.js:2767:17
    at /usr/node_modules/async.js:453:21
    at /usr/node_modules/async.js:158:13
    at /usr/node_modules/async.js:118:13
    at /usr/node_modules/async.js:129:25
    at /usr/node_modules/async.js:160:17
    at /usr/node_modules/async.js:458:34

(SunOS 00-0c-29-fe-47-fd 5.11 joyent_20111219T225629Z i86pc i386 i86pc)

This was very helpful when wrapping create-machine. It returns a message, a status type, the UUID, and if there was an error: the message and a stacktrace.

Are there plans to reintroduce JSON output for vmadm create, either by default or as a flag?

This could either be filed as a regression or an RFE, depending on your outlook. :)

When running through the initial setup smartos_prompt_config.sh, during the zfs pool creation, if multiple disks are entered only one is used to create the zones pool.

Expected behavior is if 2 disks are entered, they are mirrored and if 3+ disks are entered, they are raidz.

Hi dear joyent team,
I'd wanted to ask you if it were possible to tag the releases you use to build the official SmartOS images - that way people who build their own/modified versions can stay in sync and not accidentally pick a newer release with bugs :).

I have a problem that manifests as follows:

# vmadm start 922a8b40-e9ea-47ff-a5d0-fecd617a6127
Successfully started 922a8b40-e9ea-47ff-a5d0-fecd617a6127

# vmadm list | grep 922a8b40-e9ea-47ff-a5d0-fecd617a6127
922a8b40-e9ea-47ff-a5d0-fecd617a6127  KVM   4096     running           -

# vmadm list | grep 922a8b40-e9ea-47ff-a5d0-fecd617a6127
922a8b40-e9ea-47ff-a5d0-fecd617a6127  KVM   4096     shutting_down     -

# vmadm list | grep 922a8b40-e9ea-47ff-a5d0-fecd617a6127
922a8b40-e9ea-47ff-a5d0-fecd617a6127  KVM   4096     stopped           -

# tail -2 /zones/922a8b40-e9ea-47ff-a5d0-fecd617a6127/root/tmp/vm.log
=== OUTPUT ===
Failed to allocate memory: Resource temporarily unavailable

Apparently this is because of the 1GB extra RAM being allocated per VM. Could that maybe be a tunable parameter?

But the actual problem I have is that this failure can be predicted and still vmadm start tells me that it was successful.

As a SmartOS user, I would find it beneficial to have dsadm support API calls to multiple sources. This will allow third parties to provide branded zones that may be hosted on SmartOS. Ideally, I would be able to list/import/destroy sources easily.

Note, this may be because I have Node 0.6.8 on this machine, instead of the stock 0.4.9, and thereby hit an error such as #46.

In this example I use vmadm destroy on a running VM, and the ZFS dataset is left behind:

[root@00-25-90-21-aa-c8 ~]# echo '{"brand":"kvm", "disks":[{"model":"virtio", "size":10240}]}' | vmadm create
Successfully created 4c359459-8887-415f-83d4-c38e21322182
[root@00-25-90-21-aa-c8 ~]# vmadm list
UUID                                  TYPE  RAM      STATE             ALIAS
4c359459-8887-415f-83d4-c38e21322182  KVM   256      running           -
[root@00-25-90-21-aa-c8 ~]# vmadm destroy 4c359459-8887-415f-83d4-c38e21322182
Successfully deleted 4c359459-8887-415f-83d4-c38e21322182
[root@00-25-90-21-aa-c8 ~]# zfs list zones/4c359459-8887-415f-83d4-c38e21322182
NAME                                         USED  AVAIL  REFER  MOUNTPOINT
zones/4c359459-8887-415f-83d4-c38e21322182    31K  10.0G    31K  /zones/4c359459-8887-415f-83d4-c38e21322182

And here the ZFS dataset is removed because the VM is stopped first:

[root@00-25-90-21-aa-c8 ~]# echo '{"brand":"kvm", "disks":[{"model":"virtio", "size":10240}]}' | vmadm create
Successfully created 6eefef94-d54f-46a1-8001-d43659f0a9b8
[root@00-25-90-21-aa-c8 ~]# vmadm stop -f 6eefef94-d54f-46a1-8001-d43659f0a9b8
Succesfully completed stop for 6eefef94-d54f-46a1-8001-d43659f0a9b8
[root@00-25-90-21-aa-c8 ~]# vmadm destroy 6eefef94-d54f-46a1-8001-d43659f0a9b8
Successfully deleted 6eefef94-d54f-46a1-8001-d43659f0a9b8
[root@00-25-90-21-aa-c8 ~]# zfs list zones/6eefef94-d54f-46a1-8001-d43659f0a9b8
cannot open 'zones/6eefef94-d54f-46a1-8001-d43659f0a9b8': dataset does not exist

Is this something you already have fixed, or should I try to debug and fix it? :)

(Looking at the output above, I can see there is a typo in the output for the stop command, do you want me to create a separate issue for that?)

The "ps" command supports the BSD style arguments "auxww" for generating a wide listing that includes more of the command line arguments. However, this option is not documented in the man page. Instead, the man page confusingly refers only to an 80 character limit.

In an attempt to compile apcusbd, we ran up against an issue linking libusb.

There is a libusb.so.1 in /usr/lib, but no libusb.so, which the configure script and linker are searching for with the -lusb flag.

Adding a symlink from libusb.so to libusb.so.1 resolves the issue:
ln -s /usr/lib/libusb.so.1 /opt/local/lib/libusb.so
crle -u -l /opt/local/lib

After that compiling with -lusb appears to function properly.

Hello,

I have setup a new machine using Zotac Z68ITX-A-E and Intel Sandy Bridge Core i5 2500T.

I tried to boot SmartOS using various USB images but the boot process stops and the machine reboots.
I tried all following images:

• smartos-20120126T231012Z.img
• smartos-20120130T201844Z-USB.img
• smartos-20120210T043623Z-USB.img

Note that those images do boot correctly on my Dell Inspiron Mini (Atom N450) ; using the same USB thumb that fails on the Z68.

After destroying this zone, the template snapshot still exists:

zones/templates/fc14_x86_64@3c034e66-a901-4b32-9e2f-e873961bb4e7-disk0

Is this a pathname issue (as "zone/template" is a dataset, not a pool), or an oversight?

In man/man, there's a symlink "man" pointing to ".". This causes infinite recursion for anything traversing the tree.

Hi,

I run Smart-OS and Gentoo Linux on the same machine. The machine has 4 1GiE interfaces. I installed SmartOS and the machine came up well. But, when i rebooted it into Linux( Machine that i use to run KVM Guests with N/W Interfaces in Bridged mode) and back to SmartOS the admin Interface now cannot be found.

Thanks

I have created a VM where I specified "boot": "order=nc" during creation. This is however not honored when the VM is started. It uses the default cd order.

Also vmadm doesn't seem to be able to read the boot attribute:

[root@00-25-90-21-aa-c8 ~]# echo 'info attr name=boot' | zonecfg -z 362ff340-6abc-4f86-a01a-7403bed08ad7 -f -
On line 1:
attr:
    name: boot
    type: string
    value: order=nc
[root@00-25-90-21-aa-c8 ~]# vmadm get 362ff340-6abc-4f86-a01a-7403bed08ad7 | json -i boot
undefined
[root@00-25-90-21-aa-c8 ~]# echo '{"boot":"order=nc"}' | vmadm update 362ff340-6abc-4f86-a01a-7403bed08ad7
Command failed: On line 1 of /tmp/zonecfg.10533.tmp:
An attr resource with the name 'boot' already exists.

Is this something you already have fixed, or should I try to debug and fix it? :)

I am not 100% certain if this is a bug or purpose:
if I create a VM with a nic tagged as external but no external net is defined VM.create neutrons an error but still creates the VM, this behavior seems wrong to me, since it can lead to accidentally creating multiple VMs.

Regards,
Heinz

"Conflict detected with another vm, please check the MAC and IP" returns 0. Should exit 1.

With release smartos-20120309T073819Z the network interface works but with smartos-20120322T181745Z it doesn't. The driver seems to be rge. Some output from prtconf -d -D:

    pci8086,3a44 (pciex8086,3a44), instance #2 (driver name: pcieb)
        pci1043,82c6 (pciex10ec,8168), instance #0 (driver name: rge)

Please help me direct this bug report to the relevant project and tell me what information you may need.