Hello again Hua, and thanks for the help!

Firstly, my (2) is identical to yours.

According to point (3) the user being used is the default "root", so adding a user to the libvirtd group (1) doesn't seem to make sense. Are you suggesting that something can't run or access something else?  If so, shouldn't there be an error message somewhere?

According to /etc/groups, "nova" is the only user of the libvirtd group.  Is this what you meant by all the chown hua:root commands?

(4)

e.g.  Here's an outline of the ownserhip of the files you suggested I chown below:

nova:nova  /var/lib/nova/instances (and contents)

root:root  /var/cache/libvirt

 

libvirt-qemu:kvm /var/cache/libvirt/*

glance:glance  /var/lib/glance (and contents)

root:root  /var/lib/libvirt (and contents, except for...)

libvirt-qemu:kvm /var/lib/libvirt/qemu

root:root /var/run/libvirt (and contents, except for sockets, which are of group libvirtd)

root:root /etc/libvirt (and contents)

/etc/sysconfig/libvirt does not exist.  (Note this is Ubuntu, not RedHat.)

root:root /usr/bin/qemu*

(5) As mentioned, my qemu is 1.0 which is greater than 0.15, no?

$ kvm --version
QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard

Thanks again!

Cheers,
Tudor.

 

On 2013-06-19 15:35, Hua BJ Zhang wrote:

Hi tudor,

      Generally speaking, I can fix qemu related issues by bellow steps in most time, you can have a try, assume using one common user named 'hua', good luck.

      1)  sudo usermod -a -G libvirtd hua

      2)  [hua@oc2048760380 nova]$ sudo grep -A 5 "^cgroup_device_acl" /etc/libvirt/qemu.conf
cgroup_device_acl = [
    "/dev/null", "/dev/full", "/dev/zero",
    "/dev/random", "/dev/urandom",
    "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
    "/dev/rtc", "/dev/hpet","/dev/net/tun",
]
     
      3) [hua@oc2048760380 nova]$ sudo grep -A 5 "hua" /etc/libvirt/qemu.conf
user = "hua"

# The group for QEMU processes run by the system instance. It can be
# specified in a similar way to user.
group = "root"

      4) sudo chown -R hua:root ~/data/nova/instances
sudo chown -R hua:root /var/cache/libvirt
sudo chown -R hua:root /var/cache/glance
sudo chown -R hua:root /var/lib/libvirt
sudo chown -R hua:root /var/run/libvirt
sudo chown -R hua:root /etc/libvirt
sudo chown -R hua:root /etc/sysconfig/libvirt*
sudo chown -R hua:root /usr/bin/qemu*

     5) upgrade the qemu version into 0.15
  sudo yum -y install http://mirror.centos.org/centos/6/os/x86_64/Packages/audiofile-0.2.6-11.1.el6.x86_64.rpm
    sudo yum -y install
http://mirror.centos.org/centos/6/os/x86_64/Packages/esound-libs-0.2.41-3.1.el6.x86_64.rpm
    sudo yum -y install
http://pkgs.repoforge.org/qemu/qemu-0.15.0-1.el6.rfx.x86_64.rpm 

      6) service libvirtd restart


Best Regards.

Zhang Hua(张华)
----------------------------------------------------
Cloud Solutions and OpenStack Development
IBM China System and Technology Lab(CSTL), Beijing
E-Mail: zhhu...@cn.ibm.com
Tel: 86-10-82452020
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
        No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193


Inactive hide details for tudor ---06/19/2013 10:50:55 AM---  Hi Zhang,tudor ---06/19/2013 10:50:55 AM---  Hi Zhang,

From: tudor
To: ,
Date: 06/19/2013 10:50 AM
Subject: Re: [Openstack] ip: SIOCGIFFLAGS: No such device
Sent by: "Openstack"





Hi Zhang,

Thanks.

I'm using QEMU emulator version 1.0 (qemu-kvm-1.0)

I'm also getting a warning in /var/log/libvirt/libvirtd.log when the instance starts up:

2013-06-19 02:44:45.827+0000: 2170: warning : x86Decode:1347 : Preferred CPU model SandyBridge not allowed by hypervisor; closest supported model will be used
2013-06-19 02:44:46.640+0000: 2170: warning : virCgroupMoveTask:887 : no vm cgroup in controller 3
2013-06-19 02:44:46.640+0000: 2170: warning : virCgroupMoveTask:887 : no vm cgroup in controller 4
2013-06-19 02:44:46.640+0000: 2170: warning : virCgroupMoveTask:887 : no vm cgroup in controller 6

Cheers,
Tudor.

On 2013-06-19 11:47, Hua BJ Zhang wrote:


Hi tudor,

    seems that your vm doesn't have the nic. so suggest you check the log of hypervisor.


    which type of hypervisor are you using? qemu? pls make sure upgrade the qemu version into 0.15 just from my experience.


   
 sudo yum -y install http://mirror.centos.org/centos/6/os/x86_64/Packages/audiofile-0.2.6-11.1.el6.x86_64.rpm
    sudo yum -y install
http://mirror.centos.org/centos/6/os/x86_64/Packages/esound-libs-0.2.41-3.1.el6.x86_64.rpm
    sudo yum -y install
http://pkgs.repoforge.org/qemu/qemu-0.15.0-1.el6.rfx.x86_64.rpm 

   


Best Regards.

Zhang Hua(张华)
----------------------------------------------------
Cloud Solutions and OpenStack Development
IBM China System and Technology Lab(CSTL), Beijing
E-Mail: zhhu...@cn.ibm.com
Tel: 86-10-82452020
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
       No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193



Inactive hide details for tudor ---06/19/2013 09:16:48 AM---  Hi,tudor ---06/19/2013 09:16:48 AM---  Hi,

From:
tudor
To:
,
Date:
06/19/2013 09:16 AM
Subject:
[Openstack] ip: SIOCGIFFLAGS: No such device
Sent by:
"Openstack"

 





Hi,
 

I've asked this question a few times on the IRC channel, and I have an open question on ask.openstack.org but so far noone has managed to answer it successfully.

I have installed OpenStack Grizzly on Ubuntu 12.04 LTS with Quantum and it is up to date with the Ubuntu OpenStack respository.

I have a simple problem: the network interface is not being created when an instance starts up.  Horizon seems to think that the interface is correct.  It lists:

IP Addresses
---------------
Officenet

However, in the logs of the instance I get:

ip: SIOCGIFFLAGS: No such device

...and the only interface that exists inside the instance is lo.

I don't appear to get any obvious errors in any of the quantum or nova logs.

I believe that quantum is supposed to create a tap port on the OVS bridge specified by externel_network_bridge (br-eth1), but this is not happening.  The network physical port connected via eth1 has a hardware DHCP server on it, but it doesn't appear to assigning a network device on that bridge, so the DHCP request is not being forwarded.

I have included my quantum config, l3_agent.ini, and the output of ovs-vsctl as I guess these are the most appropriate.  (Removing commented-out defaults)

Other than solving my particular problem, I'm also trying to understand the process that occurs here.   What service (nova/quantum/something else?) actually creates the port on the OVS bridge and links it to the instance's virtual network device?

Thanks for the help,
Tudor.

Quantum.conf

=========

[DEFAULT]
# Show more verbose log output (sets INFO log level output)
verbose = True

# Show debugging output in logs (sets DEBUG log level output)
debug = True

# Address to bind the API server
bind_host = 0.0.0.0

# Port the bind the API server to
bind_port = 9696

# Quantum plugin provider module

core_plugin = quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2

# Paste configuration file
api_paste_config = /etc/quantum/api-paste.ini

# The strategy to be used for auth.
# Supported values are 'keystone'(default), 'noauth'.
auth_strategy = keystone

# AMQP exchange to connect to if using RabbitMQ or QPID

control_exchange = quantum

# If passed, use a fake RabbitMQ provider
fake_rabbit = False

# IP address of the RabbitMQ installation
rabbit_host = 10.0.0.1
# Password of the RabbitMQ server
rabbit_password = password

# ============ Notification System Options =====================

# Notifications can be sent when network/subnet/port are create, updated or deleted.
# There are four methods of sending notifications, logging (via the
# log_file directive), rpc (via a message queue),
# noop (no notifications sent, the default) or list of them

# Defined in notifier api
notification_driver = quantum.openstack.common.notifier.list_notifier

# Defined in list_notifier

list_notifier_drivers = quantum.openstack.common.notifier.rabbit_notifier

[QUOTAS]

L3_agent.ini

========

[DEFAULT]

# OVS

interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver
# LinuxBridge
#interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver

# The Quantum user information for accessing the Quantum API.
auth_url =
http://10.0.0.1:35357/v2.0
auth_region = RegionOne
admin_tenant_name = service
admin_user = quantum
admin_password = password


# Use "sudo quantum-rootwrap /etc/quantum/rootwrap.conf" to use the real
# root filter facility.
# Change to "sudo" to skip the filtering and just run the comand directly
root_helper = sudo /usr/bin/quantum-rootwrap /etc/quantum/rootwrap.conf

# Allow overlapping IP (Must have kernel build with CONFIG_NET_NS=y and
# iproute2 package that supports namespaces).
# use_namespaces = True
use_namespaces = False

# If use_namespaces is set as False then the agent can only configure one router.
# This is done by setting the specific router_id.
# router_id =
router_id = e263323d-ad1d-4930-8739-ebf80cef3f96

# Each L3 agent can be associated with at most one external network. This
# value should be set to the UUID of that external network. If empty,
# the agent will enforce that only a single external networks exists and
# use that external network id
# gateway_external_net_id =
gateway_external_net_id = e1bbbcb1-e20d-48e5-ae89-823c1a485625

# Indicates that this L3 agent should also handle routers that do not have

# an external network gateway configured. This option should be True only
# for a single agent in a Quantum deployment, and may be False for all agents
# if all routers must have an external network gateway
# handle_internal_only_routers = True

# Name of bridge used for external network traffic. This should be set to
# empty value for the linux bridge
# external_network_bridge = br-ex
external_network_bridge = br-eth1

# IP address used by Nova metadata server
# metadata_ip =
metadata_ip = 10.0.0.1

# TCP Port used by Nova metadata server
# metadata_port = 8775

# The time in seconds between state poll requests
# polling_interval = 3

 

ovs-vsctl show

=========

# ovs-vsctl show
e1bbbcb1-e20d-48e5-ae89-823c1a485625
Bridge "br-eth1"
Port "phy-br-eth1"
Interface "phy-br-eth1"
Port "eth1"
Interface "eth1"
Port "br-eth1"
Interface "br-eth1"
type: internal
Bridge br-tun
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Bridge "br-eth0"
Port "phy-br-eth0"
Interface "phy-br-eth0"
Port "eth0"
Interface "eth0"
Port "br-eth0"
Interface "br-eth0"
type: internal
ovs_version: "1.4.0+build0"

 

 _______________________________________________
Mailing list:
https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe :
https://launchpad.net/~openstack
More help   :
https://help.launchpad.net/ListHelp

 


 

 _______________________________________________
Mailing list:
https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe :
https://launchpad.net/~openstack
More help   :
https://help.launchpad.net/ListHelp

 

 

 
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to