You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Rajani Karuturi (JIRA)" <ji...@apache.org> on 2015/10/09 07:02:26 UTC
[jira] [Commented] (CLOUDSTACK-8933) SSVm and CPVM do not survice a
reboot from API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14949895#comment-14949895 ]
Rajani Karuturi commented on CLOUDSTACK-8933:
---------------------------------------------
I debugged a little and found that virtio serial port (/dev/vport0p1) which was written from the patchviasocket.pl is empty on reboot
cloud-early-config doesnt handle this and waits infinitely for it (L 120-130)
I checked the history. patchviasocket.pl was never called on reboot. It was always doing dumpxml and creating a vm from it.
I dont know how this was surviving reboots before.
The only change I see is the way we create the xml has changed from dm.getXMLDesc(0); to dm.getXMLDesc(1); (LibvirtComutingResource.java:2638)
If I diff the xmls, I dont see any change except for password being added in the new one..
Any ideas on how to save the state of /dev/vport0p1 driver to the dumpxml? or how it was working before?
> SSVm and CPVM do not survice 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
>
>
> 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)