[
https://issues.apache.org/jira/browse/CLOUDSTACK-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14956327#comment-14956327
]
ASF GitHub Bot commented on CLOUDSTACK-8933:
--------------------------------------------
GitHub user bvbharatk opened a pull request:
https://github.com/apache/cloudstack/pull/930
CLOUDSTACK-8933 SSVm and CPVM do not survive a reboot from API
The issue is because we loop infinitely when we do not receive any cmdline
data during reboots. The current fix is to attempt one time to read the
commadline data, the data is not there we check if the cmdline is already
populated. If is already there we continue with the existing command line.
This fix will work in case of reboots, but in case of stop and start if the
cmdline changes and we do not get it on first read we will end up using the old
cmdline data instead of the new one. I am not sure if the cmd data will change
on start stop. One way to fix this will be to send some data in the cmdline on
reboot to say that we can use the existing data in the cmdline. I am not sure
if this a good way to fix it.
Please let me know if there is a better way to do this.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/bvbharatk/cloudstack CLOUDSTACK-8933
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/930.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #930
----
commit 2fd8ab0b4852e792607b8ae4431d4537e98e6fea
Author: Bharat Kumar <[email protected]>
Date: 2014-12-24T11:18:55Z
CLOUDSTACK-8933 SSVm and CPVM do not survive a reboot from API
----
> 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
> 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)
