Home > Blogs > OpenStack Blog for VMware > Tag Archives: Glance

Tag Archives: Glance

How to Deal with DHCP Failure Caused by Consistent Network Device Naming (VIO)


VMW-Integrated OpenStack-Gray.jpg










While testing out the latest CentOS 7 QCOW2 cloud image, we ran into an issue where the guest operating system wasn’t able to obtain a DHCP IP address after successful boot.  After some troubleshooting, we quickly realized the NIC name was assigned based on predictive consistent network device name (CNDN). You can read more about CNDN from here.  Network script required to bring up the network interface was missing from /etc/sysconfig/network-scripts, only default ifcfg-eth0 script was present. The network interface remained in DOWN status since interface script wasn’t available.  Therefore, the Linux dhclient therefore couldn’t bind to the interface, hence the DHCP failure.

Fixing the symptom we simply edited and renamed the interface script to reflect the predictive name, then restart networking.  But since this problem will show up again when booting a new VM,  we need a permanent fix in the image template.

It turns out predictive naming was intended to be disabled in the CentOS 7 Cloud Image based on the udev role below:

Screen Shot 2017-04-14 at 2.41.06 PM



The system ignored this setting during bootup and predictive naming was enabled as a result.

There are multiple ways to workaround this:

Solution 1 – Update Default GRUB to Disable CNDN:

1). To restore the old naming convention, you can edit the /etc/default/grub file and add net.ifnames=0 and biosdevname=0 at the end of the GRUB_CMDLINE_LINUX variable:

Example:   GRUB_CMDLINE_LINUX=”rd.lvm.lv=centos/swap vconsole.keymap=us crashkernel=auto rd.lvm.lv=centos/root vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 biosdevname=0″

2) Review the new configuration by printing output to STDOUT

# grub2-mkconfig

3) Update the grub2 configuration after review:

# grub2-mkconfig -o /boot/grub2/grub.cfg


Solution 2: Enable Network Manager

1) Install Network Manager:

# yum install NetworkManager

2) Start Network Manager

# service NetworkManager start

3) Run chkconfig to ensure Network Manager starts after system reboot

# chkconfig NetworkManager on

Solution 3: Create Customer Udev Rule

We will create an udev rule to override the unintended predictive name.

1) Create a new 80-net-name-slot.rules in /etc/udev/rules.d/

# touch /etc/udev/rules.d/80-net-name-slot.rules

2). Add below line to the new 80-net-name-slot.rules:

NAME==””, ENV{ID_NET_NAME_SLOT}!=””, NAME=”eth0″

Final Implementation

All three solutions solved the problem.  Approach #1 involves updating GRUB config, so handle with care. Solution #2 is a very hands-off approach allowing Network Manager to control interface states.   Most sysadmins have a love/hate relationship with NetworkManager however. NetworkManager simplifies management of WiFI interfaces but can lead to unpredictable behavior in interface states. Most common concerns are interfaces brought up by NetworkManager when it should be down as sysadmin are not ready to turn up those NIC yet. OpenStack community had reported cloud-init timing related issues as well, although we didn’t have any problems enabling it on the Cloud Centos 7 image.  Solution #3 needs to align with overall deployment requirements in a Multi-NIC environment.

In reality,  CNDN was designed to solve NIC naming issues in a physical server environment.  It stopped being useful with virtual workloads.  Most of the cloud workloads deploy with a single NIC.  The NIC is always eth0.  Consequently, disabling CNDN makes sense, solution #1 is what we recommend.

Once CentOS VM image is in the desirable state, create a snapshot, then refer to the OpenStack documentation to upload into glance.  A shortcut to validate the new image,  instead of creating a snapshot, download and upload back into glance, it is perfectly fine to boot VM directly from a snapshot.   Please refer to VIO documentation for recommended steps.

Be sure to test this out on your VMware Integrated OpenStack setup today.  If you don’t have VIO yet, try it on our VMware Integrated OpenStack Hands-On-Lab , no installation required.

OpenStack Summit:

We will be at the OpenStack Summit in Boston. If you are attending the conference, swing by the VMware booth or attend one of our many sessions:

OpenStack and VMware – Use the Right Foundation for Containers

Digital Transformation with OpenStack for Modern Service Providers

Is Neutron challenging to you – Learn how VMware NSX is the solution for regular OpenStack Network & Security services and Kubernetes

OpenStack and OVN – What’s New with OVS 2.7 

DefCore to Interop and back again: OpenStack Programs and Certifications Explained

Senlin, an ideal bridge between NFV Orchestrator and OpenStack 

High availability and scalability management of VNF

How an Interop Capability becomes part of the OpenStack Interop Guidelines

OpenStack Interoperability Challenge and Interoperability Workgroup Updates: The Adventure Continues

Lightning Talk:

Openstack and VMware getting the best of both. 


Station 1: VMware NSX & VMware Integrated OpenStack

Station 2: NFV & VMware Integrated OpenStack


OpenStack 2.5: VMware Integrated OpenStack 2.5 is GA – What’s New?

We are very excited about this newest release of VMware Integrated OpenStack, OpenStack 2.5. This release continues to advance VIO as the easiest and fastest route to build an OpenStack cloud on top of vSphere, NSX and Virtual SAN So, what’s in this release? Continue reading to learn more about the latest features in VMware Integrated OpenStack 2.5, which is available for download now.

  1. Seamlessly Leverage Existing VM Templates
  2. Smaller Management Footprint
  3. Support for vSphere Standard Edition with NSX
  4. Troubleshooting & Monitoring Out of the Box
  5. Neutron Layer 2 Gateway Support
  6. Optimized for NFV

Continue reading

Windows Images in Your OpenStack Cloud

Linux is not the only operating system in cloud computing; your OpenStack users may want to utilize Windows images too! Today, we discuss how to create your Windows VM for OpenStack and how to import that VM with the Glance service. Continue reading

VMware Integrated OpenStack Video Series: Working with Images

The OpenStack image service (Glance) allows users to utilize pre-configured virtual machines to deploy their cloud workloads from. This is a concept that is similar to VM templates in VMware vSphere.

VMware Integrated OpenStack (VIO) natively supports VMDK, OVA, and ISO image types, and VIO versions 2.0 and later also support automated conversion of non-native types to VMDK including Qcow2, Raw, VHD, and VDI.

You can export a virtual machine from VMware vSphere, or Workstation and Fusion, to the OVA format and import it to VMware Integrated OpenStack. In addition, you can leverage a tool like Packer to automatically build an image for VMware Integrated OpenStack.

The following video provides a detailed walkthrough of using the OpenStack image service.


Stay tuned for the next installment covering the OpenStack orchestration service (Heat)! In the meantime, you can learn more on the VMware Product Walkthrough site and on the VMware Integrated OpenStack product page.

VMware Integrated OpenStack Video Series: Working with Instances

In our last installment, we discussed the simplicity of the VMware Integrated OpenStack deployment process. Today, we will discuss how VMware Integrated OpenStack users can provision virtual machines. First, we need to get familiar with some OpenStack terminology:

  • Instance – a running virtual machine in your environment. The OpenStack Nova service provides users with the ability to manage hypervisors and deploy virtual machines.
  • Image – similar in concept to a VM template. The OpenStack Glance service maintains a collection of images from which users will deploy their instances.
  • Volume – this is an additional virtual disk (VMDK) that is attached to a running instance. Volumes can be added to instances ad hoc via the OpenStack Cinder service.
  • Flavor – allocation of resources (i.e. number of vCPUs, storage, RAM).
  • Security Group – rules governing network access to your deployed instance (ex: this instance may be accessed via TCP port 22 from a certain IP range).
  • Network – the VMware vSphere port group that your instance will be attached to. Your port groups are automatically created by the OpenStack Neutron service.

OpenStack emphasizes the capability for users to manage their infrastructure programmatically through REST APIs, and this is exhibited in the multiple ways that a user can deploy an instance. The Horizon GUI provides the capability to launch instances with a point-and-click interface. The Nova CLI provides users with simple commands to deploy your instances, and these commands can be combined in shell scripts.

For users who want even more control and flexibility over instance deployment, the REST APIs can be leveraged. The important thing to note is that regardless of the interface the user selects, the REST API is utilized behind the scenes. For example, if I use the nova boot CLI command, it translates my simple inputs into an HTTP request that the Nova service will understand.

If you would like to see the API code being generated by your CLI commands, you can use the “–debug” option with CLI tools (ex: nova –debug boot…). An example HTTP Request generated by the nova boot CLI command is included below:

curl -g -i -X POST https://vio-dashboard.eng.vmware.com:8774/v2/b228bcefad9f487fb6ae4821bfb90130/servers
-H "User-Agent: python-novaclient"
-H "Content-Type: application/json"
-H "Accept: application/json"
-H "X-Auth-Token: {SHA1}c1ef2534845b985dc4c52b803e357c08daea265b"
-d '{
"server": {
"name": "apitest",
"imageRef": "0723d0ac-9a08-49f5-9160-97efe05aa6ca",
"flavorRef": "2",
"max_count": 1,
"min_count": 1,
"networks": [{"uuid": "a722cb2b-f041-40b1-ad6a-74a27d30539a"}],
"security_groups": [{"name": "default"}]

My instance name (“apitest”) may seem too generic, and it’s possible that another user may use the same name. Not to worry, instance names do not need to be unique: OpenStack identifies all resources, including instances, by unique identifiers. In the sample code above, my source image, flavor, and network are all identified by their unique identifiers. Well, what about vCenter?  In vCenter, my virtual machine’s name includes its OpenStack identifier:


VMware Integrated Openstack instance uuid in vCenter

How vCenter Displays an OpenStack Instance

As we saw in the code above, the user specifies the source image, flavor, network, and security group during instance deployment. In the background, the user’s credentials and the interactions between the various OpenStack components are authenticated by the OpenStack Identity service (Keystone). The following graphic provides an illustration of these interactions:


VMware Integrated OpenStack Component Interaction

OpenStack Component Interaction

Check out the following video to see instance deployment in action with the Horizon GUI and the Nova CLI, :


Stay tuned for next week’s blog post when we discuss working with OpenStack networks! In the meantime, you can learn more on the VMware Product Walkthrough site and on the VMware Integrated OpenStack product page.