Thanks for the explanation, which really clarified a lot. I did as you suggested and changed the code in a local development WS and then rebuilt the RPMs using the following steps:
* Updated code in a local git repository. * Ran the " mvn clean install -P systemvm ". * Ran the "./package.sh -d centos7" to create the new RPM's * Copied the new RPMs to a local repository we have to control updates. * Stopped the cloudstack-management, cloudstack-usage and cloudstack-agent services * Reinstalled the "cloudstack-common" on all management and hosts using the "yum reinstall cloudstack-common". * Reinstalled the "cloudstack-agent" on the hosts only using "yum reinstall cloudstack-agent" * Started the agents on all hosts. * Started management services. * Stopped and then started a test VR but get the following error: Resource [Host:31] is unreachable: Host 31: Unable to start instance due to Unable to start VM[DomainRouter|r-1187-VM] due to error in finalizeStart, not retrying I also restored the system vm template on secondary storage from a backup I made before starting any changes. I tried 2 different VRs and I get this same message with a different Host:xx value. I reverted back to the original code by repeating the above process using the original RPMs. The VR start normally but I still have the original password reset issue. Ether I am missing something with the upgrade to a new VM system template process or I guess the code change could have caused this problem. I did test the code change by using a live VR and manually make the change. All worked well then but I can't test the stop/restart process cause it reverts back to the original scripts. Did I miss a step or do something incorrectly with the new system VM update? Thanks. ---------------------------------------------- Richard Klein <rkl...@rsitex.com> RSI 5426 Guadalupe, Suite 100 Austin TX 78751 > -----Original Message----- > From: Remi Bergsma [mailto:rberg...@schubergphilis.com] > Sent: Saturday, April 09, 2016 9:48 AM > To: users@cloudstack.apache.org > Subject: Re: Cloudstack 4.7 password reset issue. > > Hi, > > It’s best to make a change in the source of CloudStack, then send it as a Pull > Request to get it included. > > When you run: `mvn clean install -P systemvm` a new systemvm.iso is > generated. > > However, the management server will check the systemvm.iso’s signature, so > I’m not sure if replacing works without also copying it to the management > server and restart it (so it generates a new signature). > > Another trick is to alter the scripts on live routers with Ansible. > > Regards, > Remi > > > > > On 09/04/16 03:42, "Simon Weller" <swel...@ena.com> wrote: > > > > >Richard, > > > >The system vms are bootstrapped with an iso that is mounted and all the > scripts are installed from there. The reason for this is to reduce the number > of > times you have to completely redeploy routers (we used to have to do it for > every release). > >My guess is the file you need to change is within that iso. > >The iso is part of the cloudstack-common package that is installed onto all > >the > hosts (along with the cloudstack-agent). > >Take a look in /usr/share/cloudstack-common/vms. There should be an iso > >in there called systemvm.iso > > > >You'll probably need to mount the iso make your changes to the filesystem, > rebuild the iso with mkisofs, copy that new iso to all of your hosts and then > stop > and start your VR. > > > >Hope this helps. > > > >- Si > > > > > > > > > >________________________________________ > >From: Richard Klein (RSI) <rkl...@rsitex.com> > >Sent: Friday, April 8, 2016 7:15 PM > >To: users@cloudstack.apache.org > >Subject: RE: Cloudstack 4.7 password reset issue. > > > >I found the password reset issue and it ended up being a Python script on the > VR. I ended up modifying the "/opt/cloud/bin/configure.py" to resolve the > issue. Basically there is a "/etc/cloud/vmpassword.json" file that is updated > with the IP/password pair when the GUI password change is performed. During > the power on process the VM configuration info is sent to the router which > reads the vmpassword.json file and sends the password changes to the > password server cache file. When the client retrieved the password it was > cleared from the password cache file but not the vmpassword.json file. So > every time a VM started the last password reset was sent to the password > server again. > > > >The question I have now is how do I get the system VM template updated with > the change? Since we are using CS v4.7 we used the system template for v4.6 > per the installation instructions for CentOS7 and KVM. I performed the > following steps to use a new system VM template: > > > >* I copied the system vm template QCOW2 file from secondary storage to a > work server and made a backup of it. > >* On the work server I mounted the QCOW2 template file using "guestmount" > tools and made the code changes to the template. > >* I then copied this modified template file to a web server and registered > >the > template in cloudstack with all checkboxes off except for "routing". > >* Then we set the cloudstack global value of "router.template.kvm" to the > name of the new template. > >* The management services were restarted. > >* I picked a test VR, powered it off, destroyed it then let the system > >recreate > it. > >* When I look at the code I changed on the new VR it does not appear. > > > >I even doubled checked the database and the vm_instance table for the test > VR showed the new template ID. I must be missing something or I don't really > understand how the system templates are created. Any help/suggestions would > be appreciated. > > > > > > > >Richard Klein <rkl...@rsitex.com> > >RSI > >5426 Guadalupe, Suite 100 > >Austin TX 78751 > > > > > > > >> -----Original Message----- > >> From: Richard Klein (RSI) > >> Sent: Tuesday, April 05, 2016 2:32 PM > >> To: users@cloudstack.apache.org > >> Subject: RE: Cloudstack 4.7 password reset issue. > >> > >> The snippets for before and after the reboot via console look the > >> same so I pasted the 2nd set of message instead of the first. Sorry > >> about that. I did discover that the > >> /var/lib/dhclient/dhclient.leases existed but was empty. I've run > >> across an issue with CentOS 7 where the lease file is missing so I > >> wrote a "cloud-dhcp-check" service that makes sure it exists but now > >> I need to validate its content. That being said, I have insured that the > dhclient_leases was valid and replicated the problem. > >> > >> The cloud-set-guest-xxxx scripts are from the master branch GitHub > >> repository for apaches/cloudstack using the > >> "https://github.com/apache/cloudstack/blob/master/setup/bindir/cloud- > >> set- > >> guest-password.in" and the > >> "https://github.com/apache/cloudstack/blob/master/setup/bindir/cloud- > >> set- > >> guest-sshkey.in" links. > >> > >> I have attached the entire log from the VR but have some snippets > >> below along with the VM client logs and the issue still occurs after > >> fixing the > dhcp lease file. > >> I did not perform any password resets via the GUI during this process. > >> > >
