vmadm update on nics with update rule on command line seems to be broken

[MerlinDMC]

[root@1c-6f-65-cf-04-88 ~]# vmadm list -o uuid,nics.0.ip
UUID                                  NICS.0.IP
061fd2f7-e54e-490a-b60f-830537e550ae  192.168.1.231
[root@1c-6f-65-cf-04-88 ~]# vmadm update 061fd2f7-e54e-490a-b60f-830537e550ae nics.0.ip=192.168.1.234
Successfully updated 061fd2f7-e54e-490a-b60f-830537e550ae
[root@1c-6f-65-cf-04-88 ~]# vmadm list -o uuid,nics.0.ip
UUID                                  NICS.0.IP
061fd2f7-e54e-490a-b60f-830537e550ae  192.168.1.231

The output of "Successfully updated" without changing anything seems to be wrong.

It should either be possible to update nics this way or the command should produce a Failure message

Also after rebooting the zone the ip does not get changed.
The output of vmadm get 061fd2f7-e54e-490a-b60f-830537e550ae displays the unchanged data as well.

[joshwilsdon]

This is actually already on my list of things to do. I've added a reference in our internal ticket (OS-1208) to this ticket so that they can both be closed when this is resolved.

[dyu]

I experienced this 2 days ago. Had to delete the zone.

[joshwilsdon]

dyu, can you explain why you had to delete the zone? Did the syntax described in the man page not work for you?

[kreutter]

Is there a workaround? Seems still to be broken in joyent_20120906T221231Z, I can't change the nics either. So I guess the reason for @joshwilsdon to delete the zone was to recreate it with a correct nics.

[MerlinDMC]

The "workaround" is to use the update_nics json as described in the manpage.

from the manpage:

 Example 10: Change the IP of the NIC with MAC b2:1e:ba:a5:6e:71 for the VM
             with the UUID 54f1cc77-68f1-42ab-acac-5c4f64f5d6e0.

     vmadm update 54f1cc77-68f1-42ab-acac-5c4f64f5d6e0 <<EOF
     {
       "update_nics": [
         {
           "mac": "b2:1e:ba:a5:6e:71",
           "ip": "10.2.121.72"
         }
       ]
     }
     EOF

[kreutter]

Thanks, Daniel! Sorry for not reading the man page carefully... because I had to delete netmask and gateway (switched to dhcp) I had to use "remove_nics" first and then "add_nics" instead of update. Could use "gateway": [] with "update_nics" to remove the gateway but this didn't work with "netmask". Anyways, thanks again for the swift reply.

[vtoc]

There is more inconsistent behaviour on vmadm update:

works

echo '{ "quota": "10" }' | vmadm update 243a8f2c-8e49-4dcb-9b79-d77c002dfaac
vmadm update 243a8f2c-8e49-4dcb-9b79-d77c002dfaac quota=12
echo '{ "resolvers": ["8.8.8.8", "8.8.4.4"] }' | vmadm update 243a8f2c-8e49-4dcb-9b79-d77c002dfaac
vmadm update 243a8f2c-8e49-4dcb-9b79-d77c002dfaac max_swap=1024

repots success but doesn't update anything

echo '{ "tmpfs": "1024" }' | vmadm update 243a8f2c-8e49-4dcb-9b79-d77c002dfaac
vmadm update 243a8f2c-8e49-4dcb-9b79-d77c002dfaac tmpfs=1024

core dumps on update

vmadm update 243a8f2c-8e49-4dcb-9b79-d77c002dfaac resolvers='["8.8.8.8", "8.8.4.4"]'
vmadm update 243a8f2c-8e49-4dcb-9b79-d77c002dfaac resolvers="8.8.8.8,8.8.4.4"

UNCAUGHT EXCEPTION: c0e6f985 
EXCEPTION MESSAGE: Object ["8.8.8.8", "8.8.4.4"] has no method 'join'
FROM:
buildZonecfgUpdate (/usr/vm/node_modules/VM.js:6519:61)

 fe725e65 _lwp_kill (1, 6, 1c4, fe794000, fe794000, 8625008) + 15
 fe6c13ab raise    (6, 0, 8046e90, 843e8c8, 0, 0) + 2b
 fe69c21e abort    (8625008, 9fe8a7c5, 8046f88, 831766b, 8625008, 860f8a0) + 10e
 0843a2f7 ???????? (8625008, 860f8a0, 7, 860f8a0)
 0831766b v8::internal::Isolate::DoThrow(v8::internal::Object*, v8::internal::MessageLocation*) (8625008, 9fe6f6d9, 0, a270d7f5) + 35f
 083178a8 v8::internal::Isolate::Throw(v8::internal::Object*, v8::internal::MessageLocation*) (8625008, 9fe6f6d9, 0, 8046fe8, 2, 80470cc) + 14
 082fc45e v8::internal::IC::TypeError(char const*, v8::internal::Handle, v8::internal::Handle) (80470cc, 8453e8c, 8047120, 804711c) + 5a
 0830250b v8::internal::CallICBase::LoadFunction(v8::internal::InlineCacheState, int, v8::internal::Handle, v8::internal::Handle) (80470cc, 0, 0, 8047120, 804711c, 9fe1906d) + 15b
 083028a1 v8::internal::CallIC_Miss(v8::internal::Arguments, v8::internal::Isolate*) (2, 8047120, 8625008, 9d80a2c1, 8047100, 8047130) + 111
 9d80a336 ???????? (a270d7f5, 9fe1906d, 9d814ce1, c, 9fe6afa1, 8047164)
 9d814d40 ???????? (a271378d, 9fe1906d, fe434f05, fe434f05, 93033dd1, 9fe6afc5)
 92570da9 ???????? (9fe1d775, 9fe19011, 9fe47961, 93033dd1, 83fe6e05, 93008091)
 925a5a5c ???????? (9fe6af61, 93033dd1, 9fe234f9, 9fe23a5d, 9fe6af45, 80471c8)
 92529658 ???????? (9fe6af21, 9fe234f9, 93033dd1, 9fe23a5d, 9fe23e29, 9fe6af01)
 92524446 ???????? (9fe6aedd, 9fe23d91, 93033dd1, 9fe23e29, 9fe23e9d, 9fe6aec1)
 92522de7 ???????? (93033dd1, 9fe23e9d, 9fe69469, 9fe6944d, 804721c, 92524310)
 92522cd5 ???????? (93008091, 93033dd1, 9fe69469, 9fe694ad, 9fe6948d, 8047240)
 92524310 ???????? (93008091, 93008091, 93033dd1, 9fe6ae7d, 93008091, 9fe694ed)
 9252955b ???????? (93008091, 93033dd1, 9fe694ed, 9fe6952d, 9fe69511, 8047278)
 925a56ae ???????? (93008091, 93033dd1, 0, 9fe6952d, 10, 8047290)
 9d80db41 ???????? (93033dd1, 9fe6952d, 9fe697a9, 9fe69551, 80472b4, 9d8245a5)
 9255e927 ???????? (93008081, 93033dd1, 2, 2, 9d824441, c)
 9d8245a5 ???????? (9fe69e59, 93008081, 9fe697a9, 9fe69e59, 9fe69e11, 9fe69df5)
 9d85bcbd ???????? (9fe69e4d, 2, 9fe69e11, 10, 804730c, 9d821bb2)
 9d80db41 ???????? (93008081, 9fe69e4d, 9fe69e11, 9d821b21, c, 0)
 9d821bb2 ???????? (0, 0, 9d812aa1, 0, 0, 0)
 9d812b4a ???????? (9d85bc80, 9fe69e11, 9fe69e4d, 1, 80475e8, a27145d5)
 082a079f v8::internal::Invoke(bool, v8::internal::Handle, v8::internal::Handle, int, v8::internal::Handle*, bool*) (804746c, 0, 868f134, 86a25e8, 1, 80475e8) + e3
 082a1a34 v8::internal::Execution::Call(v8::internal::Handle, v8::internal::Handle, int, v8::internal::Handle*, bool*, bool) (804746c, 868f134, 86a25e8, 1, 80475e8, 804747f) + 5c
 0825d5d9 v8::Function::Call(v8::Handle, int, v8::Handle*) (80474cc, 868f134, 86a25e8, 1, 80475e8, 86a25e8) + d5
 08205528 node::MakeCallback(v8::Handle, v8::Handle, int, v8::Handle*) (804754c, 86a25e8, 868f134, 1, 80475e8, 86a25e8) + 84
 082056fc node::MakeCallback(v8::Handle, v8::Handle, int, v8::Handle*) (80475cc, 86a25e8, 86a1ec8, 1, 80475e8, 2) + 4c
 0820da2b node::After(uv_fs_s*) (8688b80, 0, 8047758, fe71af98) + f3
 0824bda3 uv__fs_after (8637c50, 0, 8047678, 0, 86110d8, 0) + 5b
 0824418a eio_finish (8637c50, 8047788, 8047708, 863e21c) + ca
 08245333 eio_poll (8610c40, 804773f, 0, 8610c40) + db
 0825291d uv_eio_want_poll_notifier_cb (8610c94, 0, 400, 8610ea0) + 31
 0824299d uv__async_io (8610c40, 8610d44, 1, ffffff80, f270bddf, 4b3) + a1
 0824682d ev_invoke_pending (8610ea0, 8f5c28f6, 4012f5c2, 868f144, 8625008, 868f12c) + 4d
 08243206 uv__run  (8610c40, 86a1c88, 8047c08, 86a1cb8) + 8a
 08243439 uv_run   (8610c40, 6, 8047c64, 86a1ca8, fe71a84d, 8047c64) + 15
 08206664 node::Start(int, char**) (6, 8047c64, 8047cd0, 8047c2c) + 174
 0821599f main     (81ff634, feffb0a4, 8047c58, 819cddf, 6, 8047c64) + 1b
 0819cddf _start   (6, 8047d40, 8047d53, 8047d71, 8047d81, 8047d88) + 83

[mattconnolly]

Updating the resolvers appears to be still broken:

[root@30-85-a9-ae-cb-00 ~]# vmadm update 16c992b5-1e27-4723-9233-7d299d07b899 '{"resolvers":["8.8.8.8","8.8.4.4"]}'
Successfully updated VM 16c992b5-1e27-4723-9233-7d299d07b899
[root@30-85-a9-ae-cb-00 ~]# vmadm get 16c992b5-1e27-4723-9233-7d299d07b899 | grep resolvers
  "resolvers": [],

Each time the zone boots, it resets the /etc/resolv.conf file to no name servers as in the above. Is there another way to update this?

[mattconnolly]

zonecfg can be used to set missing resolvers: https://gist.github.com/mattconnolly/6127693

[schmurfy]

still broken ?
If you can't / won't fix it at least remove it from the help/man page...
When you add the fact that update always tells you it was successfull even if it has no clue what you just asked it can really be annoying.

$ vmadm update <XXX> color="somewhat red"
Successfully updated VM 0a8b7b99-1b05-45d2-ba00-ab7701feb2a7

better show nothing than this in my opinion.

[sa5bke]

When updating resolvers, this one works:

echo '{"resolvers":["x.x.x.x"]}' | vmadm update uuid

Using other syntax gives success message, but does not update.

[schmurfy]

as shown by my previous comment the success message does not mean anything.

[mattconnolly]

@schmurfy can you please keep your comments constructive. As with all things open source, you are free to fix it yourself, pay someone else to fix or wait.

[schmurfy]

sorry for the last comment but this is annoying when you try to fight with a tool (sometimes for a long time) only to find out that there is an issue opened two years ago for the same or a linked problem.

removing the "Successfully updated xxx" message would take what, 5s? to someone with a development environment already in place and who knows the codebase.

This is even more annoying because I consider SmartOS to be by far the best VM Platform out there, now I know that this update message means absolutely nothing so I am fine but for others or new users they could and will believe it as I did except it might not have done a thing.

Ps: I edited my previous comment

[joshwilsdon]

The reason you see the 'Successfully updated xxx' messages is that the update did succeed (there were no errors). You just didn't specify any valid parameters to update. So just 'removing the message' here is the wrong thing to do as that would also remove it for cases where an update actually changed something as well. I realize this is less than ideal and I have it on my list of things to do eventually to make this print a warning about nonsense parameters the update payload and possibly display a list of fields that were changed. Hopefully I'll find time to do that sooner rather than later.

Note you should also be able to use the 'vmadm validate' command like:

echo '{"color": "blue"}' | vmadm validate update kvm

to validate your payload before you send it to vmadm update. Which could be help you understand why your update is not working.

In the meantime if you find a case where the man page is wrong I can fix that.

[schmurfy]

thanks for the precision, validate should definitely be helpful.