There is no disk.local for VMs having ephemeral in flavor 

Bug #2032916 reported by Amit Uniyal
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Confirmed
Low
Rajesh Tailor

Bug Description

Description
===========

This is not really a functionality issue because the VM did get created, the ephemeral disk is visible in the VM and there is a disk.eph0.

But there is a code in driver checking for disk.local if ephemeral disk is added for disk_mapping,
https://github.com/openstack/nova/blob/a9b1e024eb1e8ddd286174bd576a64ff224a9221/nova/virt/libvirt/driver.py#L4794

there is no local.disk in disk_mapping or real disk inside data/instances/<instance-id>/ directory. It do not get created during resize process either.

Reason:

build_and_run_instance: compute.manager
    # block_device_mapping received here is bdm object.
    build an object having image, device/disk and network info called resources
    with resources ASK driver to spawn VM
                 # resources = block_device_info: {disk, ephemeral, image }, network_info = {}

                 get_disk_mapping from libvirt/blockinfo
#https://github.com/openstack/nova/blob/17b46bae84bef38bc27976219a244010f1e510e3/nova/virt/libvirt/blockinfo.py#L714

                driver.spawn runs _create_image
                # pass disk_maping to _create_image
                creates instance directory
                creates 2: disk.info and disk
                look for disk.local in disk_mapping
                # but its not present so disk.local hence did not get created in compute under compute node.

Steps to reproduce
==================

- openstack flavor create --ram 512 --disk 20 --ephemeral 15 --vcpus 1 102
- openstack server create --flavor 102 --network private --image cirros-0.6.2-x86_64-disk vm_3

Expected result
===============
- there should be a disk.local in directory
  data/nova/instances/<instance-id>/

or during resize

Actual result
=============
- disk.local is NOT present in instance/<instance-id> directory
- disk.eph0 is present instance/<instance-id> directory
- there is a data file ephemeral_15_40d1d2c inside instance/_base

Environment
===========
tested in branch master and stable/train

So basically for which scenarios disk.local should/will get created?

Tags: libvirt
melanie witt (melwitt)
tags: added: libvirt
Revision history for this message
melanie witt (melwitt) wrote (last edit ):

I went on an archeological dig and assuming I didn't miss something: the short answer is that disk.local is an old/original representation of an ephemeral disk defined in the flavor and is no longer used.

There are two ways to specify ephemeral disk: in the flavor or in the block device mapping(s) in the server create request. The disk.local was for the former, when ephemeral disk was specified in the flavor and not in block device mapping(s). And originally ephemeral and swap disks from the flavor did not have block device mappings created for them.

Then there was a change a long time ago:

https://review.opendev.org/c/openstack/nova/+/83516

which changed things to create block device mappings for ephemeral and swap disks specified in the flavor, probably to move toward treating all cases in a more consistent manner.

After this, AFAICT any specified ephemeral disk would end up being considered as specified from block device mappings, so the code to create disk.local isn't reached anymore. There are always BDMs for ephemeral and swap, whether they're in the flavor or not.

I think you are right that there isn't a functionality bug here. To me it seems at worst what we have is some unused code, which doesn't hurt anything aside from being tech debt. And removing the code will take some care to make sure nothing else gets broken in the process.

Based on this, I'm marking this as Confirmed with Low priority.

Changed in nova:
importance: Undecided → Low
status: New → Confirmed
Rajesh Tailor (ratailor)
Changed in nova:
assignee: nobody → Rajesh Tailor (ratailor)
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.