[
https://issues.apache.org/jira/browse/CLOUDSTACK-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966744#comment-14966744
]
ASF GitHub Bot commented on CLOUDSTACK-8933:
--------------------------------------------
Github user karuturi commented on the pull request:
https://github.com/apache/cloudstack/pull/959#issuecomment-149880745
Agree.
-----Original Message-----
From: "Wilder Rodrigues" <[email protected]>
Sent: 21-10-15 13:22
To: "apache/cloudstack" <[email protected]>
Cc: "Rajani Karuturi" <[email protected]>
Subject: Re: [cloudstack] CLOUDSTACK-8933 SSVm and CPVM do not survive
areboot from API (#959)
@karuturi @remibergsma
In the previous PR it was mentioned that looping 30 times would probably be
enough to get the configuration done and also get rid of the infinite loop. I
looked at the code and did not find any sleep or any sort of wait, so looping
30 times will go quite fast:
The block inside the for loop would be this one:
while read line; do
if [[ $line == cmdline:* ]]; then
cmd=${line//cmdline:/}
echo $cmd > /var/cache/cloud/cmdline
elif [[ $line == pubkey:* ]]; then
pubkey=${line//pubkey:/}
echo $pubkey > /var/cache/cloud/authorized_keys
echo $pubkey > /root/.ssh/authorized_keys
fi
done < /dev/vport0p1
# In case of reboot we do not send the boot args again.
# So, no need to wait for them, as the boot args are already set
at startup
if [ -s /var/cache/cloud/cmdline ]
then
log_it "Found a non empty cmdline file. Will now exit the
loop and proceed with configuration."
break;
fi
If my assumption is right, about the 30 times loop, I would suggest to do
it in a different way. For example:
local factor=2
local progress=1
for i in {1..5}
do
#block mentioned above
sleep ${progress}
progress=$[ progress * factor]
done
In a worst case scenario we would wait 16 seconds before then leave the for
loop.
What do you think?
Cheers,
Wilder
—
Reply to this email directly or view it on GitHub.
> SSVm and CPVM do not survive a reboot from API
> ----------------------------------------------
>
> Key: CLOUDSTACK-8933
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8933
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM
> Affects Versions: 4.6.0
> Environment: KVM Advanced / Basic zone
> Reporter: Remi Bergsma
> Assignee: Wilder Rodrigues
> Priority: Blocker
> Fix For: 4.6.0
>
> Attachments: Console screenshot.png, reboot.4.5.log, reboot.4.6.log
>
>
> These tests fail:
> - integration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm
> - integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm
> Stopping works, then CloudStack successfully deploys a new one. Rebooting
> doesn’t work as it doesn’t complete the boot sequence. Looking at the
> agent.log I noticed the systemvm doesn’t get patched so it is probably
> waiting for that to happen.
> A successful start shows this:
> 2015-10-05 21:26:12,748 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-4:null) Executing:
> /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n
> v-1-VM -p
> %template=domP%type=consoleproxy%host=192.168.22.61%port=8250%name=v-1-VM%zone=1%pod=1%guid=Proxy.1%proxy_vm=1%disable_rp_filter=true%eth2ip=192.168.23.2%eth2mask=255.255.255.0%gateway=192.168.23.1%eth0ip=169.254.1.20%eth0mask=255.255.0.0%eth1ip=192.168.22.137%eth1mask=255.255.255.0%mgmtcidr=192.168.22.0/24%localgw=192.168.22.1%internaldns1=8.8.4.4%dns1=8.8.8.8
> 2015-10-05 21:26:12,777 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-4:null) Execution is successful.
> The reboot doesn’t do this. When I hit reboot and run this command manually,
> it works:
> /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n
> v-1-VM -p
> %template=domP%type=consoleproxy%host=192.168.22.61%port=8250%name=v-1-VM%zone=1%pod=1%guid=Proxy1%proxy_vm=1%disable_rp_filter=tru%eth2ip=192.168.23.2%eth2mask=255.255.255.0%gateway=192.168.23.1%eth0ip=169.254.1.20%eth0mask=255.255.0.0%eth1ip=192.168.22.137%eth1mask=255.255.255.0%mgmtcidr=192.168.22.0/24%localgw=192.168.22.1%internaldns1=8.8.4.4%dns1=8.8.8.8
> I basically copy/pasted the patch line from the stop/start and used it when
> rebooting. Now everything works.
> We need to figure out why it doesn’t patch the system vms on reboot.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)