On 10/23/2014 06:12 AM, Shanil S wrote:
> Hi Juan,
>
> The following details i got from the vm after executing the reset password
>
> [root@compute4 ~]# cp
> /var/run/vdsm/payload/22f57477-5d43-4795-95ec-e39ce3ba5423.757249a787c151388f6f3fa3502cf299.img
> /tmp/my.img
> [root@compute4 ~]# mount -o loop,ro /tmp/my.img /mnt
> [root@compute4 ~]# find /mnt
> /mnt
> /mnt/openstack
> /mnt/openstack/latest
> /mnt/openstack/latest/meta_data.json
> /mnt/openstack/latest/user_data
> [root@compute4 ~]# cat /mnt/openstack/latest/user_data
> #cloud-config
> ssh_pwauth: true
> disable_root: 0
> output:
>   all: '>> /var/log/cloud-init-output.log'
> password: shanil
> chpasswd:
>   expire: false
> runcmd:
> - 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo
> ''datasource_list:
>   ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg'
> [root@compute4 ~]#
>
> The xml which i used for the reset password is
>
> <action>
>             <vm>
>                 <os>
>                     <boot dev='cdrom'/>
>                 </os>
>                 <initialization>
>          <cloud_init>
>         <users>
>          <user>
>            <user_name>root</user_name>
>            <password><![CDATA[shanil]]></password>
>          </user>
>            </users>
>         </cloud_init>
>        </initialization>
>             </vm>
>         </action>
>
> it seems the password is showing in the configuration ( you can see the
> above log ) but i am unable to login with this new password. Could you
> please have a look at ?
>
>

Ok, there is a difference in what we generated in 3.4 and what we are
generating in 3.5. Basically where aren't generating now the line that
contains the user name. It should have been as follows:

  #cloud-config
  ssh_pwauth: true
  disable_root: 0
  output:
    all: '>> /var/log/cloud-init-output.log'
  user: root  <-- This is the line that is missing
  password: shanil
  ...

I think that this is a bug, and that we should restore the previous
behavior, as described in this new bug:

  https://bugzilla.redhat.com/1156155

Without that "user: root" line what happens is that cloud-init changes
the password of its default user, as configured in
"/etc/cloud/cloud.cfg". The default for Fedora is "fedora" and for
CentOS and RHEL is "cloud-user". To workaround the issue you can edit
the "/etc/cloud/cloud.cfg" file of the VM and change the default user name:

  system_info:
  distro: rhel
  default_user:
    name: root  <-- Change this from "fedora" or "cloud-init" to root

>
> On Wed, Oct 22, 2014 at 7:51 PM, Juan Hernandez <jhernand@redhat.com

> <mailto:jhernand@redhat.com>> wrote:
>
>     On 10/22/2014 07:31 AM, Shanil S wrote:
>     > Hi,
>     >
>     > Currently i have updated the ovirt version to 3.5 and after that the
>     > reset password using api is not working but there isn't any errors
>     > returned. The following xml is i used for the reset password and
>     it was
>     > working with the previous version
>     >
>     > <action>
>     >             <vm>
>     >                 <os>
>     >                     <boot dev='cdrom'/>
>     >                 </os>
>     >                 <initialization>
>     >          <cloud_init>
>     >         <users>
>     >          <user>
>     >            <user_name>root</user_name>
>     >            <password>$newpass</password>
>     >          </user>
>     >            </users>
>     >         </cloud_init>
>     >        </initialization>
>     >             </vm>
>     >         </action>
>     >
>     > Could you please have a look at the above xml ? Is there anything
>     > modified in the new version ?
>     >
>     > The reset password is working fine from the ovirt admin panel and the
>     > issue is only when we use the ovirt api to reset the password.
>     >
>
>     That didn't change, your XML should work. I tested it in my environment
>     and it works as expected. The only thing that I can imagine failing is
>     the password containing values that break the XML syntax. Try to
>     surround the value with a CDATA section:
>
>       <password><![CDATA[yourpassword]]></password>
>
>     This is good practice, even if it isn't the cause of your problem.
>
>     As usual the first step to debug this is to check if the cloud-init
>     floppy has been generated correctly. Start the VM, go the host where it
>     is running, locate the qemu process and the location of the floppy img:
>
>       # ps -ef | grep -- '-drive file=/var/run/vdsm/payload/.*\.img'
>
>     Make a copy of that file, mount and inspect it:
>
>       # cp /var/run/vdsm/payload/...img /tmp/f.img
>       # mount -o loop,ro /tmp/f.img /mnt
>       # find /mnt
>       # cat /mnt/openstack/latest/user_data
>       # umount /mnt
>

--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.