vm state --state reboot --shutdown --wait-port 22 isn't waiting

[bby-bishopclark]

Versions:

• Version of knife-vsphere: 2.1.1
• Version of chef: 13.8.5 (chefdk-2.5.3-1.el7)

Platform Details

• Version of vSphere: 6.5.0.13000
• Version of ESXi: 6.5.0, 7526125

Scenario:

Rolling reboots. It was requested that a series of Linux hosts reboot; really, just for superstition. The command below - with its funny code<<<data format but names changed - was used.

Note the --wait-port bit.

(cd ~/chef-repo/knife/prod/; \
 for HH in $(cat); do \
  knife vsphere vm snapshot $HH --create $(date +%Y%m%d) --quiesce --dump-memory --wait \
  && echo cd ${HOME}/chef-repo/knife/prod/';' knife vsphere vm snapshot $HH --remove $(date +%Y%m%d) | at now + 48 hours \
  && knife vsphere vm state $HH --state reboot --shutdown --wait-port 22 ; \
  echo $HH DONE; \
 done \
) <<<'host1 host2 host3' | ts

job 12 at Fri Jun 29 15:51:00 2018
Jun 27 15:51:55 Reboot virtual machine host1
Jun 27 15:51:55 Waiting for port 22...done
Jun 27 15:51:55 host1 DONE

job 13 at Fri Jun 29 15:54:00 2018
Jun 27 15:54:06 Reboot virtual machine host2 
Jun 27 15:54:06 Waiting for port 22...done
Jun 27 15:54:07 host2 DONE

job 14 at Fri Jun 29 15:56:00 2018
Jun 27 15:56:24 Reboot virtual machine host3
Jun 27 15:56:24 Waiting for port 22...done
Jun 27 15:56:24 host3 DONE

Hosts all performed the same way, immediately continuing on while the host booted, without waiting for it.

I didn't run with -VV but I'd like to know whether I had a usable syntax at the time. It looked right to me, and if it's right I can schedule another with -VV for science.

Expected Result:

As mentioned, I was hoping it would wait until the host had soft-bounced and then waited for the port to be lit. (should I have --state off -g and then --state on --wait-port 22 instead?)

Actual Result:

As the ts(timestamp) shows, the 'wait-port' passed immediately as soon as the reboot started, suggesting it didn't wait for the boot cycle before starting to check; but I may have the command invocation wrong. In each case, control passed to the next instruction while the current host was still in the boot process (the one time I was glad snapshots took so long!) .

[swalberg]

Hi and thanks for the detailed report. I think you’re right — the reboot operation doesn’t wait for completion like the other tasks do. No need for new output as I don’t see that it would improve things, and I’ll bet I can repro in my own environment. I’m on vacation for a few more days and am limited to my phone. Your off then on + wait workaround looks like it’ll do what you expect and I will investigate why the reboot doesn’t work as expected when I return. Sorry it’s causing you grief. Please let me know if the workaround helps.

…

On Jun 30, 2018, at 19:29, bby-bishopclark ***@***.***> wrote: Versions: Version of knife-vsphere: 2.1.1 Version of chef: 13.8.5 (chefdk-2.5.3-1.el7) Platform Details Version of vSphere: 6.5.0.13000 Version of ESXi: 6.5.0, 7526125 Scenario: Rolling reboots. It was requested that a series of Linux hosts reboot; really, just for superstition. The command below - with its funny code<<<data format but names changed - was used. Note the --wait-port bit. (cd ~/chef-repo/knife/prod/; \ for HH in $(cat); do \ knife vsphere vm snapshot $HH --create $(date +%Y%m%d) --quiesce --dump-memory --wait \ && echo cd ${HOME}/chef-repo/knife/prod/';' knife vsphere vm snapshot $HH --remove $(date +%Y%m%d) | at now + 48 hours \ && knife vsphere vm state $HH --state reboot --shutdown --wait-port 22 ; \ echo $HH DONE; \ done \ ) <<<'host1 host2 host3' | ts job 12 at Fri Jun 29 15:51:00 2018 Jun 27 15:51:55 Reboot virtual machine host1 Jun 27 15:51:55 Waiting for port 22...done Jun 27 15:51:55 host1 DONE job 13 at Fri Jun 29 15:54:00 2018 Jun 27 15:54:06 Reboot virtual machine host2 Jun 27 15:54:06 Waiting for port 22...done Jun 27 15:54:07 host2 DONE job 14 at Fri Jun 29 15:56:00 2018 Jun 27 15:56:24 Reboot virtual machine host3 Jun 27 15:56:24 Waiting for port 22...done Jun 27 15:56:24 host3 DONE Hosts all performed the same way, immediately continuing on while the host booted, without waiting for it. I didn't run with -VV but I'd like to know whether I had a usable syntax at the time. It looked right to me, and if it's right I can schedule another with -VV for science. Expected Result: As mentioned, I was hoping it would wait until the host had soft-bounced and then waited for the port to be lit. (should I have --state off -g and then --state on --wait-port 22 instead?) Actual Result: As the ts(timestamp) shows, the 'wait-port' passed immediately as soon as the reboot started, suggesting it didn't wait for the boot cycle before starting to check; but I may have the command invocation wrong. In each case, control passed to the next instruction while the current host was still in the boot process (the one time I was glad snapshots took so long!) . — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[bby-bishopclark]

Yay! No big rush while I have a working workaround.

Thanks!