eucalyptus ignores VNET_INTERFACE setting when creating volumes

Bug #539051 reported by ptashek
4
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Eucalyptus
Won't Fix
Undecided
Unassigned
eucalyptus (Ubuntu)
Fix Released
Wishlist
Dustin Kirkland 

Bug Description

Package versions this relates to: eucalyptus (cloud, cc, common, gl, walrus, java-common, sc) --> 1.6.2-0ubuntu13

I have a small trial cloud setup as follows:

HOST_A is the cloud controller, walrus and storage controller and also acts as cluster controller for CLUSTER_A
HOST_B is the cluster controller for CLUSTER_B
Two other hosts are NCs for CLUSTER_A and CLUSTER_B respectively

I can run and access instances in either cluster, so the entire infrastructure seems to be configured fine.

The only problem I have is with the SC on HOST_A as it seems to ignore the "VNET_INTERFACE" setting in /etc/eucalyptus/eucalyptus.conf when creating volumes.

In HOST_A's config the VNET_INTERFACE is set to "br0", however when I issue "euca-create-volume -s 1 -z ZONE_A" the volume is created and presented on "eth0" instead of "br0":

root@host_a:~# ps -ef | fgrep vblade
root 6983 6161 0 12:30 ? 00:00:00 /usr/sbin/vblade 0 2 eth0 /dev/vg-SaiRdw../lv-k3pJyQ..

So far I have tried the following steps:

- de-registered the SC
- stopped and disabled all eucalyptus services
- apt-get purged the eucalyptus-sc package
- rebooted
- installed the eucalyptus-sc package
- verified VNET_INTERFACE value
- enabled all eucalyptus services
- started eucalyptus with CLEAN=1

The behaviour still persists, so I guess there is either something I have missed or there is a bug in one of the eucalyptus packages. Attached are my (anonymized a bit) cloud-debug.log and eucalyptus.conf.

Revision history for this message
ptashek (ptashek) wrote :
Revision history for this message
ptashek (ptashek) wrote :
Revision history for this message
ptashek (ptashek) wrote :

I was able to reproduce this bug on the latest 10.04 packages --> eucalyptus (all of them) @ 1.6.2-0ubuntu14 and vblade @ 20-1ubuntu1. This host has not been running as an SC ever before, so this can be treated as a clean install I guess.

shrini (shrini)
affects: ubuntu → eucalyptus (Ubuntu)
Revision history for this message
Neil Soman (neilsoman) wrote :

The way to set the network interface for the Storage Controller in Eucalyptus 1.6.x is through the admin web interface (cluster configuration). VNET_INTERFACE is no longer honored by the Storage Controller, intentionally. This allows the user to have a CC and SC on the same machine and to control the interface setting independently for the two components.

Changed in eucalyptus:
status: New → Won't Fix
Revision history for this message
Neil Soman (neilsoman) wrote :

Also, note that if you are upgrading from 1.5.2 to 1.6, the VNET_INTERFACE setting will be respected/brought over by the upgrade process, after which the way to change the value is through the admin interface.

Revision history for this message
Mathias Gug (mathiaz) wrote :

This should probably be documented in the eucalyptus.conf man page.

Changed in eucalyptus (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
Changed in eucalyptus (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Dustin Kirkland (kirkland)
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eucalyptus - 1.6.2-0ubuntu25

---------------
eucalyptus (1.6.2-0ubuntu25) lucid; urgency=low

  * tools/eucalyptus.conf.5: add a caveat about VNET_*INTERFACE
    and storage controller, LP: #539051
  * tools/euca_conf.in: ensure that we exit 0 if no errors
  * debian/eucalyptus-udeb.postinst: don't retrieve preseed if
    skip-find = true
 -- Dustin Kirkland <email address hidden> Thu, 25 Mar 2010 18:10:17 -0700

Changed in eucalyptus (Ubuntu):
status: Fix Committed → Fix Released
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.