Invalid EC2 instance type for a volume backed instance

[Feodor Tersin]

Since nova.virt.driver:LibvirtDriver.get_guest_config prepends instance root_device_name with 'dev' prefix, root_device_name may not coincide with device_name in block device mapping structure.
In this case describe instances operation reports wrong instance type: instance-store instead of ebs.

Environment: DevStack

Steps to reproduce:
1 Create volume backed instance passing vda as root device name
$ cinder create --image-id xxx 1
$ nova boot --flavor m1.nano --block-device-mapping vda=yyy:::1 inst
Note. I used cirros ami image.

2 Describe instances
$ euca-describe-instances
Look on instace type. It must be ebs, but it is instance-store in the output.

Note. If euca-describe-instance crashes on ebs instnce, apply https://review.openstack.org/#/c/95580/

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/96399

[Jay Pipes (jaypipes)]

Ooops, sorry!

[Jay Pipes (jaypipes)]

Feodor, if you want to boot from a volume, you need to leave the " --image xxx" out of the nova boot command.

[Jay Pipes (jaypipes)]

So, you would need to execute this:

nova boot --flavor m1.nano --block-device-mapping vda=xxx:::1 inst

[Feodor Tersin (ftersin)]

Wnen i boot instance with no image i get another bug: https://bugs.launchpad.net/nova/+bug/1322180

One more way to boot such instance is using block-device parameter. In this case the instance will be launched properly.
But this bug will still remain. Because it's reason is in difference between instance root_device_name and device_name in bdm. We pass 'vda' to bdm, but virt driver sets '/dev/vda/' to root_device_name.

Also when using block-device parameter we get yet another bug: https://bugs.launchpad.net/nova/+bug/1322157

So now the only way to boot properly worked instance is to use image and block-device-mapping parameters.

Also since this manner of booting is legacy, many end user scripts can use it. Moreover this manner was recommended in previous version of documentation: http://docs.openstack.org/grizzly/openstack-ops/content/attach_block_storage.html
Futhernore neigher nova cli, nor Nova API are not blocks this combination of parameters.
So the bug exists.

Another matter that this bug can be fixed differently.
For example, we can block this way of booting.
Or we can fix virt driver to path device_name in a bdm too, or not to path root_device_name in an instnace.

All methods listed above have their own advantages and disadvantages.

The method choosed by me has an advantages - it does not affect other parts of code.

[Feodor Tersin (ftersin)]

Briefly, the problem still exists if image parameter is unused

[Feodor Tersin (ftersin)]

i'v updated the bug description

[Feodor Tersin (ftersin)]

Since https://review.openstack.org/#/c/105687/ is merged, there is no chance to populate an instance with no '/dev/' prefix in root device name. So, this problem looks not actual.

But if an instance was populated early, in previous version, the problem can be reproduced. See commit message in https://review.openstack.org/#/c/112975/.
But in previous versions it was unable to work with volume backed instances through EC2 (see https://bugs.launchpad.net/nova/+bug/1323403).

So i'm not sure that this bug (and other related, but not just registered) should be fixed.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/96399
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=de58feb796d63dd4eea1fd49e66102686fcf4037
Submitter: Jenkins
Branch: master

commit de58feb796d63dd4eea1fd49e66102686fcf4037
Author: Feodor Tersin <email address hidden>
Date: Thu May 29 12:35:45 2014 +0400

    Fix EC2 instance type for a volume backed instance.

    EC2 reports 'instance-store' type for a volume backed instance
    which was booted with short root device name (no '/dev/' prefix).

    This fix make instance type detection independent of addition
    'dev' prefix to the instance root device name.

    Change-Id: I6c2be09eaa91341e401bbc128b3efc79c60e345e
    Closes-Bug: #1324400