OpenStack Compute (nova)

rescue a boot from image server and I can not login

Bug #2018719 reported by Shuai Qian
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
New
Undecided
Unassigned

Bug Description

Description
===========
I'm going to test the feature that rescuing a server booted from *image*.
I created a server as usual and I can login and do anything.

when I rescued it with password, and without specifing image, it's ok that changed status as RESCUE, but I can not login the server.

Steps to reproduce
==================
$ openstack server create --image <> --flavor <> --network <> test-rescue
$ nova set-password test-rescue
$ virsh console <>
# Login successful

$ openstack rescue --password qweasd test-rescue
$ virsh console <>
# Login incorrect

Expected result
===============
I can use password set in rescue cmd to login the server in rescue status.

Actual result
=============
I can not use old or new password to login the server

Environment
===========
1. Exact version of OpenStack you are running.
   My openstack version is *T*.

2. Which hypervisor did you use?
   My hypervisor is KVM+Qemu+Libvirt

2. Which storage type did you use?
   CephRBD

3. Which networking type did you use?
   Neutron+OpenVSwitch

Logs & Configs
==============
I get the disk xml config, and I found the index of .rescue disk is 3, it should had been 1, right?

$ virsh dumpxml instance-xxxxx
...
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='network' device='disk'>
      <driver name='qemu' type='raw' cache='writeback' discard='unmap'/>
      <auth username='nova'>
        <secret type='ceph' uuid='80b323ff-ffb0-4544-bfa2-c08dd6bab309'/>
      </auth>
      <source protocol='rbd' name='vms/a179448d-17a2-4e29-afa4-886d0e5752d8_disk.rescue' index='3'>
        <host name='172.16.140.102' port='6789'/>
        <host name='172.16.140.101' port='6789'/>
        <host name='172.16.140.172' port='6789'/>
      </source>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
    <disk type='network' device='disk'>
      <driver name='qemu' type='raw' cache='writeback' discard='unmap'/>
      <auth username='nova'>
        <secret type='ceph' uuid='80b323ff-ffb0-4544-bfa2-c08dd6bab309'/>
      </auth>
      <source protocol='rbd' name='vms/a179448d-17a2-4e29-afa4-886d0e5752d8_disk' index='2'>
        <host name='172.16.140.102' port='6789'/>
        <host name='172.16.140.101' port='6789'/>
        <host name='172.16.140.172' port='6789'/>
      </source>
      <target dev='vdb' bus='virtio'/>
      <alias name='virtio-disk1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
    <disk type='network' device='cdrom'>
      <driver name='qemu' type='raw' cache='writeback' discard='unmap'/>
      <auth username='nova'>
        <secret type='ceph' uuid='80b323ff-ffb0-4544-bfa2-c08dd6bab309'/>
      </auth>
      <source protocol='rbd' name='vms/a179448d-17a2-4e29-afa4-886d0e5752d8_disk.config.rescue' index='1'>
        <host name='172.16.140.102' port='6789'/>
        <host name='172.16.140.101' port='6789'/>
        <host name='172.16.140.172' port='6789'/>
      </source>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <alias name='ide0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
...

Revision history for this message
Amit Uniyal (auniyal) wrote :

$ openstack server rescue --password qweasd test-rescue

- You have volume attached to this server as you have mentioned the storage ceph, also

            `<disk type='network' device='disk'>`
  https://docs.openstack.org/nova/latest/user/rescue.html#stable-device-instance-rescue

- Which image are you using and so what username?

Thanks for the detailed bug report, please answer above as well and set status back to "New".

Changed in nova:
status: New → Incomplete
Revision history for this message
melanie witt (melwitt) wrote (last edit ):

I think this behavior might not be a bug based on my read of the code. There's two separate ways that admin password can be specified to a server:

* the adminPass request parameter for server create/rebuild/rescue/evacuate

* the changePassword server action

When you did 'nova set-password', you called server actions API with changePassword.

The admin password handling for create/rebuild/rescue/evacuate is however different from the changePassword action. These methods of setting the password make use of file injection to set the password [1]:

https://docs.openstack.org/nova/latest/admin/admin-password-injection.html

and by default, file injection is disabled in nova configuration. In addition to that, file injection is only allowed for servers not using config drives.

At a minimum, you would have to set [2]:

[libvirt]
inject_password=true

and based on [1] you will also have to set [libvirt]inject_partition [3] to something other than the default of -2.

If all of those conditions are met and the guest operating system supports it [4], you should be able to use 'openstack rescue --password'.

[1] https://github.com/openstack/nova/blob/b6f4c57/nova/virt/libvirt/driver.py#L4862-L4865
[2] https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.inject_password
[3] https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.inject_partition
[4] https://docs.openstack.org/nova/latest/admin/configuration/api.html

Revision history for this message
Shuai Qian (iauhsnaiq) wrote :

Hello, I really thanks for your response.

I did some test about rescuing of bfv server before, and I found that setting password via the cmd parameter --password didn't work (openstack rescue --password ...),

Then I read the api doc and code about rescuing, understanding that nova uses adminPass to set password in the process of rescuing, which is same as the adminPass in creating server.

So I tried to create a server to varify if adminPass works in the creating, it turns out that it also doesn't work and I can't login with the adminPass generated randomly.

here are my related configs of nova-compute:
```
[DEFAULT]
force_config_drive = false

[libvirt]
inject_password = true
inject_partition = -1
```

the image I used:
https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1503.raw.xz

command I execuated：
```
openstack server create --image centos7 --boot-from-volume 10 --flavor test --network test --no-config-drive test
```
I can get adminPass from result of `openstack server show test`

I try to login and failed.

I also don't think this basic simple behavior is a bug,
but I just can't figure it out why it doesn't work.

Changed in nova:
status: Incomplete → New
Revision history for this message
Shuai Qian (iauhsnaiq) wrote :

I found the reason, adminPass is passed via file injection.
but file injection for bfv is *not* allowed.

FYI:
https://github.com/openstack/nova/blob/b6f4c57/nova/virt/libvirt/driver.py#L4862-L4865
https://github.com/openstack/nova/blob/b6f4c57/nova/virt/libvirt/driver.py#L4924-L4926

Now, when you'd like to rescue a bfv server, the value of param `--password` would be passed into `adminPass`, then it wouldn't work because of the limit.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.