The upgrade from 20151112T052215Z to 20151126T062747Z did not resolve the problem, unfortunately.
The next thing I tried was creating a new etherstub for a NAT subnet ( https://wiki.smartos.org/display/DOC/NAT+using+Etherstubs), just to rule out the possibility that it was the admin nic_tag that was causing problems. [root@00-25-90-b5-25-a8 /opt/json/test]# ls -la total 11 drwxr-xr-x 2 root root 5 Nov 29 17:15 . drwxr-xr-x 3 root root 8 Nov 29 16:47 .. -rw-r--r-- 1 root root 316 Nov 29 16:59 cl.json -rw-r--r-- 1 root root 580 Nov 29 16:46 fw.json -rw-r--r-- 1 root root 392 Nov 29 17:15 lx.json The fw.json file is for the firewall described in the "NAT using Etherstubs" tutorial. The cl.json file is for the client described in the "NAT using Etherstubs" tutorial. After verifying that the cl zone was able to reach the internet using the steps in the wiki article, I deleted this vm, and tried to replicate the same using an lx zone. The lx.json file is for the lx zone. It has the same network configuration as cl.json. Unfortunately, vmadm still fails to create it. It fails in the same unexplained way as with all of my previous attempts. The JSON file used to create the network's NAT/firewall zone. It works: [root@00-25-90-b5-25-a8 /opt/json/test]# cat fw.json { "alias": "fw", "hostname": "fw", "brand": "joyent", "max_physical_memory": 256, "dataset_uuid": "885b69c8-6e99-11e5-9be4-836f345753ed", "default_gateway": "199.15.249.249", "nics": [ { "nic_tag": "admin", "ip": "199.15.249.251", "netmask": "255.255.255.248", "allow_ip_spoofing": "1", "gateway": "199.15.249.249", "primary": "1" }, { "nic_tag": "stub0", "ip": "10.200.197.1", "netmask": "255.255.255.0", "allow_ip_spoofing": "1", "gateway": "10.200.197.1" } ] } The JSON file used to create the network's client zone. It works: [root@00-25-90-b5-25-a8 /opt/json/test]# cat cl.json { "alias": "cl", "hostname": "cl", "brand": "joyent", "max_physical_memory": 256, "dataset_uuid": "9250f5a8-6e9c-11e5-9cdb-67fab8707bfd", "nics": [ { "nic_tag": "stub0", "ip": "10.200.197.2", "netmask": "255.255.255.0", "gateway": "10.200.197.1" } ] } The JSON file used to create the network's lx zone. NIC information here is the same as with the previous zone. For a reason unknown to me, this does not work: [root@00-25-90-b5-25-a8 /opt/json/test]# cat lx.json { "alias": "lx", "hostname": "lx", "brand": "lx", "kernel_version": "3.13.0", "max_physical_memory": 2048, "image_uuid": "1adf7176-8679-11e5-9ff7-3beedf8060b9", "nics": [ { "nic_tag": "stub0", "ip": "10.200.197.2", "netmask": "255.255.255.0", "gateway": "10.200.197.1" } ] } You might notice that the lx zone's configuration doesn't have a resolvers's key, as it did in my previous attempts. While it hasn't been shown here, I've also tried this using a resolver's key that's value was ["8.8.4.4","8.8.8.8"]. Same results. As with the last example, when vmadm create returns this: timed out waiting for /var/svc/provisioning to move for 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 Cody Mello's dtrace command returns this: CPU ID FUNCTION:NAME 2 22364 exit:entry zoneadmd exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 2 22364 exit:entry zoneadmd exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 2 22364 exit:entry zoneadmd exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 2 22364 exit:entry zoneadmd exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 2 22364 exit:entry zoneadmd exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 2 22364 exit:entry zoneadmd exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 2 22364 exit:entry zoneadmd exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 2 22364 exit:entry zoneadmd exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 2 22364 exit:entry zoneadmd exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 4 8155 exec_common:exec-success lxinit execed in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 7 8155 exec_common:exec-success ipmgmtd execed in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 7 22364 exit:entry ipmgmtd exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 6 22364 exit:entry metadata exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 5 8155 exec_common:exec-success routeinfo execed in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 5 22364 exit:entry routeinfo exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 0 8155 exec_common:exec-success systemd execed in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 7 8155 exec_common:exec-success ksh93 execed in a49a4419-a133-45a3-94a9-ab5c21952b2a 7 8155 exec_common:exec-success ksh93 execed in a49a4419-a133-45a3-94a9-ab5c21952b2a 7 8155 exec_common:exec-success logadm execed in a49a4419-a133-45a3-94a9-ab5c21952b2a 7 22364 exit:entry logadm exited with 0 in a49a4419-a133-45a3-94a9-ab5c21952b2a 0 22364 exit:entry ipmgmtd exited with 9 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 5 22364 exit:entry systemd exited with 9 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 4 22364 exit:entry zsched exited with 0 in 7212f63c-4fd3-4e1d-a03f-e2095d7c0de1 Indicates an issue with ipmgmtd around the same time the init program is run - in this lx image's case, that init program is systemd. On Fri, Nov 27, 2015 at 2:36 PM, Evan Rowley <[email protected]> wrote: > I have trouble understanding what the root cause of the problem is. Just > to ensure that the network information was valid, I created a standard > smartos zone using the same network parameters, and vmadm was able to > create it successfully. It's odd that the network configuration that worked > with a standard zone would not work with the lx zone. Anyways, I hope that > the Nov 26th update will solve the issue. > > [root@00-25-90-b5-25-a8 ~]# cat /opt/json/zonetest.json > { > "brand": "joyent", > "image_uuid": "842e6fa6-6e9b-11e5-8402-1b490459e334", > "alias": "zonetest1", > "hostname": "zonetest1", > "max_physical_memory": 512, > "quota": 20, > "resolvers": ["8.8.4.4", "8.8.8.8"], > "nics": [ > { > "nic_tag": "admin", > "ip": "<zone ip>", > "netmask": "<zone netmask>", > "gateway": "<zone gateway>" > } > ] > } > > On Fri, Nov 27, 2015 at 12:02 PM, Evan Rowley <[email protected]> > wrote: > >> Thanks guys for your help on Thanksgiving night! >> >> William Ratcliffe - >> The 20151112T052215Z release that you upgraded to is what I'm already >> running. I see now, however, that a new release was released on >> Thanksgiving: 20151126T062747Z. Later tonight I'll connect to my management >> VPN and start the upgrade. >> >> Cody Mello - >> Thanks for the cool dtrace command! This is the first time that I've ever >> run anything like that. Definitley cool technology. Here is what I got: >> >> By the time the vmadm create command returned with this: >> >> [root@00-25-90-b5-25-a8 /opt/json]# vmadm create -f lxtest.json >> timed out waiting for /var/svc/provisioning to move for >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> >> The dtrace command had printed all of this: >> >> [root@00-25-90-b5-25-a8 /opt/json]# dtrace -n 'proc:::exec-success >> /zonename != "global"/ { printf("%s execed in %s", execname, zonename); }' >> -n 'fbt:genunix:exit:entry /zonename != "global"/ { printf("%s exited with >> %d in %s", execname, args[1], zonename); }' >> dtrace: description 'proc:::exec-success ' matched 1 probe >> dtrace: description 'fbt:genunix:exit:entry ' matched 1 probe >> CPU ID FUNCTION:NAME >> 3 22192 exit:entry zoneadmd exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 3 22192 exit:entry zoneadmd exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 3 22192 exit:entry zoneadmd exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 3 22192 exit:entry zoneadmd exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 3 22192 exit:entry zoneadmd exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 3 22192 exit:entry zoneadmd exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 3 22192 exit:entry zoneadmd exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 3 22192 exit:entry zoneadmd exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 3 22192 exit:entry zoneadmd exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 3 7982 exec_common:exec-success lxinit execed in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 5 7982 exec_common:exec-success ipmgmtd execed in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 5 22192 exit:entry ipmgmtd exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 6 22192 exit:entry metadata exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 4 7982 exec_common:exec-success routeinfo execed in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 4 22192 exit:entry routeinfo exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 3 7982 exec_common:exec-success init execed in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 4 22192 exit:entry ipmgmtd exited with 9 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 6 22192 exit:entry init exited with 9 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> 1 22192 exit:entry zsched exited with 0 in >> 3007419e-a40e-4083-a26d-b19aebd0a9a8 >> >> In the zone, there appears to be issues affecting the second time ipmgmtd >> runs, after it gets called by init. If I can locate it, then perhaps I can >> determine the problem after inspecting how ipmgmtd is being run. >> >> >> >> >> >> >> >> >> >> On Fri, Nov 27, 2015 at 3:36 AM, William Ratcliffe <[email protected]> >> wrote: >> >>> Evan, >>> >>> I had exactly the same problem with the same image this week. What >>> version of smartos are you running? >>> >>> I was running a version of smartos from Jan2015; I updated to >>> joyent_20151112T052215Z and it worked straight away >>> on reboot. >>> >>> My json looked like this >>> >>> { >>> "brand": "lx", >>> "image_uuid": "52be84d0-6b06-11e5-a4c0-9f0c52fa368a", >>> "alias": "ubuntu-1404-lxzone", >>> "kernel_version": "3.13.0", >>> "hostname": "ubunut-1404-lx-zone", >>> "max_physical_memory": 4096, >>> "quota": 40, >>> "resolvers": ["8.8.8.8", "208.67.220.220"], >>> "nics": [ >>> { >>> "nic_tag": "admin", >>> "ip": "192.168.1.83", >>> "netmask": "255.255.255.0", >>> "gateway": "192.168.1.1" >>> } >>> ] >>> } >>> >>> Regards >>> Will >>> >>> On 26/11/2015 21:16, Evan Rowley wrote: >>> >>> Hello, >>> >>> vmadm is hanging when creating LX zone using the lxtest JSON shown on >>> the Getting Started steps of the wiki, last edited Oct 08, 2015. >>> >>> Link: >>> https://wiki.smartos.org/display/DOC/LX+Branded+Zones >>> >>> >>> I successfully ran: >>> >>> # imgadm import 52be84d0-6b06-11e5-a4c0-9f0c52fa368a >>> >>> Created the following JSON file, lxtest.json, with appropriate values >>> for <ip>, <netmask>, and <gw>. >>> >>> { >>> "alias": "lxtest", >>> "brand": "lx", >>> "kernel_version": "3.13.0", >>> "max_physical_memory": 2048, >>> "image_uuid": "52be84d0-6b06-11e5-a4c0-9f0c52fa368a", >>> "resolvers": ["8.8.8.8","8.8.4.4"], >>> "nics": [ >>> { >>> "nic_tag": "admin", >>> "ip": "<ip>", >>> "netmask": <netmask>", >>> "gateway": "<gw>", >>> "primary": true >>> } >>> ] >>> } >>> >>> Proceeded to create the zone via: >>> >>> # vmadm create -f lxtest.json >>> >>> After a while, this is what was output to the terminal: >>> >>> timed out waiting for /var/svc/provisioning to move for >>> 3168e569-3687-4367-abba-1a35094e3d33 >>> >>> >>> I can see that the vmadm command has failed: >>> >>> # vmadm list >>> UUID TYPE RAM STATE >>> ALIAS >>> 3168e569-3687-4367-abba-1a35094e3d33 LX 2048 failed >>> lxtest >>> >>> >>> I'm running release version 20151112T052215Z. >>> >>> >>> -- >>> - EJR >>> >>> >>> *smartos-discuss* | Archives >>> <https://www.listbox.com/member/archive/184463/=now> >>> <https://www.listbox.com/member/archive/rss/184463/24484565-d47e1b4e> | >>> Modify >>> <https://www.listbox.com/member/?&;> >>> Your Subscription <http://www.listbox.com> >>> >> >> >> >> -- >> - EJR >> > > > > -- > - EJR > -- - EJR ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
