cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dsclose <>
Subject [GitHub] cloudstack pull request: CLOUDSTACK-9058 Password server should re...
Date Tue, 17 Nov 2015 15:47:03 GMT
Github user dsclose commented on the pull request:
    This was tested situationally. Not perfect, but we don't have the Cloudstack test-suite
setup yet. Not sure I will have time to do that now.
    The following steps were taken on a Cloudstack 4.5 router:
    1. Demonstrate default response when no password is to be issued.
        1. Open a session on a linux VM
        2. Use the arp table to get the IP address of the master virtual router (
in my case)
        3. Query the router for a password and save the result in pass.txt:
            wget -t 3 -T 20 -O pass.txt --header 'DomU_Request: send_my_password'
        4. Verify that pass.txt is empty, delete pass.txt
    2. Demonstrate correct response when there is a password to be issued.
        1. Obtain the IP address of a VM you want to issue a password for ( in my
        2. Set up the router to serve a password.
            1. Open a session on the router.
            2. Save a password for the VM with the value of “test_password”:
                1. /opt/cloud/bin/ –v –p test_password
            1. Verify that the password has been saved:
                cat /var/cache/cloud/passwords-
        3. Query the router:
            1. Open a session on the linux VM
            2. Run the same query command as above:
                wget -t 3 -T 20 -O pass.txt --header 'DomU_Request: send_my_password'
            3. pass.txt should now contain test_password
    Those same steps were followed for a Cloudstack 4.3 router (we upgraded from 4.3 to 4.5).
It was observed that the Cloudstack 4.3 router replied with "saved_password" when there was
no password to be served.
    Once we established the difference in behaviour we implemented the given fix, rebuilt
the systemvm.iso and pushed it out to our hypervisors.
    The solution was initially tested:
    1. By rebuilding a test network, repeating the steps above to verify that we got the expected
    2. By reproducing the password reset issue on a Windows guest VM running on a network
that used the Cloudstack 4.5 system VM. We then rebuilt that network and observed that the
Windows VM maintained its password.
        1. We also observed that the windows VM repeatedly queried the password server for
30 minutes.
        2. This has been seen each time a network is rebuilt so far.
    3. We restarted the cloud service on Windows Guest VMs to see if that would cause the
password to be lost. The password was maintained.
    4. We manually set the administrative password on a windows guest VM and then rebooted.
The password was maintained.
    5. We triggered a password reset on a windows guest VM, a new password was assigned and
adopted by the VM.
    6. We repeated steps 4 and 5 on a linux VM. The Linux VM behaved as expected.
    Subsequent to this, we rebuilt all of our networks with the fixed router. This rebuilt
several-hundred virtual routers. There are several-hundred Windows guests. Whereas we were
getting alerted by our clients regularly about password issues connected with reboots before
the fix, we have not seen a repeat of the behaviour since this fixed was rolled out.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message