[ 
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" <notificati...@github.com>
    Sent: ‎21-‎10-‎15 13:22
    To: "apache/cloudstack" <cloudst...@noreply.github.com>
    Cc: "Rajani Karuturi" <rajanikarut...@gmail.com>
    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)

Reply via email to