Not matched image adapter type and disk adaptertype when used with VMDK driver prevents instances boot process

Bug #1365468 reported by Igor Zinovik
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Fix Released
High
Igor Zinovik
5.1.x
Won't Fix
Medium
Fuel Partner Integration Team
6.0.x
Fix Released
High
Fuel Partner Integration Team

Bug Description

We ship CirrOS images for testing basic cloud functionality for OpenStack that works with vCenter.

CirrOS image has single adapter type which is IDE, it does not
support SCSI adapters. So even if user will create volume in
Cinder (which is created as SCSI disk and there is not option
to select IDE disk type during volume creation) CirrOS would not
be able to access it. Nevertheless volume will be successfully
attached to instance.

If user wants to be sure that his instances can read/write attached
volumes he must be sure that operating system that runs inside
instance supports SCSI adapters.

For more information see:
http://docs.openstack.org/trunk/config-reference/content/vmware.html#VMware_converting_images

Tags: docs vcenter
Igor Zinovik (izinovik)
description: updated
Igor Zinovik (izinovik)
description: updated
Changed in fuel:
assignee: nobody → Igor Zinovik (izinovik)
tags: added: docs vcenter
Changed in fuel:
milestone: none → 5.1
importance: Undecided → Medium
status: New → Won't Fix
Revision history for this message
Nastya Urlapova (aurlapova) wrote :

Evgeniya, Igor, we should add this limitation in release-notes?

Revision history for this message
Evgeniya Shumakher (eshumakher) wrote :

Nastya -
Igor documented it properly in VMware section of Fuel documentation.

Igor -
please make sure that Irina included this bug into the list of known issues for 5.1.

Revision history for this message
Andrey Danin (gcon-monolake) wrote :

Possible ways to fix that:
* It seems in Juno all should work fine https://bugs.launchpad.net/cinder/+bug/1284284 So just test it with Juno.
* Rebuild CirrOS with appropriate drivers installed http://romans-it.blogspot.ru/2013/06/rebuild-cirros-tiny-cloud-image-for.html
* Change an OSTF test's behavior to attach a volume with IDE type to a shutted down VM and then start it. It should be possible because IDE volumes are allowed to attach to powered off VMs (but this approach wasn't tested).

Revision history for this message
Igor Zinovik (izinovik) wrote :

It seems that with Juno release problems does not solves by itself.

I deployed Fuel 6.0 (Juno) with vCenter and test that creates instance and attaches volume to it
does not work.

Cinder when it uses VMDK as backend for volumes work this way:
1. Create so-called shadow VM (in vCenter .vmdk file cannot exist by itself, it must be linked to VM)
Seems that Shadow VM is never started.
2. Create disk for shadow VM - .vmdk file (with SCSI controller as adapter_type) and attach it to target virtual machine.

Cirros that is shipped with Fuel does not have SCSI support, it has only IDE controller, that is why
we cannot attach volumes created by cinder with VMDK backend.

I builded CirrOS image with SCSI support and converted resulted .raw image to .vmdk. Also
I changed adapter_type (field inside .vmdk file) to 'lsilogic' during convertion process.

Attaching volumes to image with SCSI works fine (volume is created and is successfully attached), but
unforunately, CirrOS with SCSI support behaves very strange, it does not see local (ephemeral)
disk and attached volume.

Revision history for this message
Igor Zinovik (izinovik) wrote :

Seems that followin patch solves this issue (on 10.11.2014 it is not merged):
https://review.openstack.org/#/c/122251/

Revision history for this message
Igor Zinovik (izinovik) wrote :

Packages that solve this issue are uploaded to here:
https://bugs.launchpad.net/fuel/+bug/1391136

no longer affects: fuel/5.1.x
Revision history for this message
Andrey Danin (gcon-monolake) wrote :

We are now in the middle of Soft Code Freeze and a priority of this bug is Medium, so move the bug to the next release.

Revision history for this message
Andrey Danin (gcon-monolake) wrote :

VMDK CirrOS packages was rebuilt with SCSI drivers included and adapter_type=lsilogic. The packages was merged into 6.0 mirrors. So, it seems, this bug can be marked as Fixed.

no longer affects: fuel/6.1.x
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to fuel-web (master)

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

Changed in fuel:
status: Won't Fix → In Progress
Revision history for this message
Igor Gajsin (igajsin) wrote :

 There is a workaround for fuel 5.1.1. You should download packages
  http://mirror.fuel-infra.org/fwm/6.0/ubuntu/pool/main/cirros-testvmware_0.3.3-ubuntu5_amd64.deb and
  http://mirror.fuel-infra.org/fwm/6.0/centos/os/x86_64/Packages/cirros-testvm-0.3.2-3.mira1.x86_64.rpm and
  replace their on fuel master node. After deploy this command must be runned on controller: glance image-update --property vmware_adaptertype="lsiLogic" UUID-of-TestVM

Revision history for this message
Irina Povolotskaya (ipovolotskaya) wrote :

for 5.1.1, I'll add the w/a you provided.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to fuel-web (master)

Reviewed: https://review.openstack.org/137444
Committed: https://git.openstack.org/cgit/stackforge/fuel-web/commit/?id=8d920d0d7f4383fd9ed8e965f6fa2e4f647f65e5
Submitter: Jenkins
Branch: master

commit 8d920d0d7f4383fd9ed8e965f6fa2e4f647f65e5
Author: Igor Zinovik <email address hidden>
Date: Wed Nov 26 21:44:00 2014 +0300

    provide correct vmware_adaptertype for glance

    - default Cirros images was rebuilded with SCSI adapter type,
      we should pass correct value when we upload image into glance

    Change-Id: I47eb035d614e2d75f3b1af2e91ede121287dd689
    Closes-bug: #1365468

Changed in fuel:
status: In Progress → Fix Committed
Revision history for this message
Tatyana Dubyk (tdubyk) wrote :

verified on 6.0-49.iso

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

Other bug subscribers

Remote bug watches

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