Send Openstack mailing list submissions to
openstack@lists.openstack.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
or, via email, send a message with subject or body 'help' to
openstack-requ...@lists.openstack.org
You can reach the person managing the list at
openstack-ow...@lists.openstack.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Openstack digest..."
Today's Topics:
1. Ceilometer Api error in Juno (m.channappa.nega...@accenture.com)
2. Proper way of adding ARM image to Glance (Harm Weites)
3. EMC VNX with QCOW2 disk images in cinder (mad Engineer)
4. Re: Proper way of adding ARM image to Glance (Anne Gentle)
5. Re: Proper way of adding ARM image to Glance (Harm Weites)
6. Problems with neutron networks (Maciej Nabo?ny)
7. [cinder] Anyone Using the Open Solaris ZFS Driver? (Mike Perez)
8. Re: Problems with neutron networks (Robert van Leeuwen)
9. Re: Problems with neutron networks (Maciej Nabo?ny)
10. why virsh list --all shows nothing? (Du Jun)
11. Re: why virsh list --all shows nothing? (Christophe Le Guern)
12. Re: why virsh list --all shows nothing? (Mark Loza)
----------------------------------------------------------------------
Message: 1
Date: Sun, 16 Nov 2014 18:01:04 +0000
From: <m.channappa.nega...@accenture.com>
To: <openstack@lists.openstack.org>
Subject: [Openstack] Ceilometer Api error in Juno
Message-ID:
<21cdf970ae844cbc9da5d212b6586...@by2pr42mb181.048d.mgd.msft.net>
Content-Type: text/plain; charset="us-ascii"
Hello Geeks,
I have installed three node openstack Juno. I was configuring ceilometer using
mongodb as back end.
I found my ceilometer-api is not starting and throwing some module error.
root@Control:/var/log/ceilometer# tail -50 ceilometer-api.log
2014-11-15 12:02:02.124 23900 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 170, in
_load_plugins
2014-11-15 12:02:02.124 23900 TRACE ceilometer
self._on_load_failure_callback(self, ep, err)
2014-11-15 12:02:02.124 23900 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/stevedore/driver.py", line 50, in
_default_on_load_failure
2014-11-15 12:02:02.124 23900 TRACE ceilometer raise err
2014-11-15 12:02:02.124 23900 TRACE ceilometer ImportError: No module named
bson.code
2014-11-15 12:02:02.124 23900 TRACE ceilometer
2014-11-16 22:22:30.649 17570 CRITICAL ceilometer [-] ImportError: No module
named bson.code
2014-11-16 22:22:30.649 17570 TRACE ceilometer Traceback (most recent call
last):
2014-11-16 22:22:30.649 17570 TRACE ceilometer File "/usr/bin/ceilometer-api", line
10, in <module>
2014-11-16 22:22:30.649 17570 TRACE ceilometer sys.exit(main())
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/ceilometer/cmd/api.py", line 23, in main
2014-11-16 22:22:30.649 17570 TRACE ceilometer srv = app.build_server()
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py", line 157, in
build_server
2014-11-16 22:22:30.649 17570 TRACE ceilometer app = load_app()
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py", line 153, in load_app
2014-11-16 22:22:30.649 17570 TRACE ceilometer return
deploy.loadapp("config:" + cfg_file)
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in
loadapp
2014-11-16 22:22:30.649 17570 TRACE ceilometer return loadobj(APP, uri,
name=name, **kw)
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in
loadobj
2014-11-16 22:22:30.649 17570 TRACE ceilometer return context.create()
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
2014-11-16 22:22:30.649 17570 TRACE ceilometer return
self.object_type.invoke(self)
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 203, in invoke
2014-11-16 22:22:30.649 17570 TRACE ceilometer app =
context.app_context.create()
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in create
2014-11-16 22:22:30.649 17570 TRACE ceilometer return
self.object_type.invoke(self)
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 146, in invoke
2014-11-16 22:22:30.649 17570 TRACE ceilometer return
fix_call(context.object, context.global_conf, **context.local_conf)
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 55, in fix_call
2014-11-16 22:22:30.649 17570 TRACE ceilometer val = callable(*args, **kw)
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py", line 181, in
app_factory
2014-11-16 22:22:30.649 17570 TRACE ceilometer return
VersionSelectorApplication()
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py", line 104, in __init__
2014-11-16 22:22:30.649 17570 TRACE ceilometer self.v2 =
setup_app(pecan_config=pc)
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py", line 68, in setup_app
2014-11-16 22:22:30.649 17570 TRACE ceilometer
storage.get_connection_from_config(cfg.CONF, 'metering'),
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/ceilometer/storage/__init__.py", line 82, in
get_connection_from_config
2014-11-16 22:22:30.649 17570 TRACE ceilometer return get_connection(url,
namespace)
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/ceilometer/storage/__init__.py", line 93, in
get_connection
2014-11-16 22:22:30.649 17570 TRACE ceilometer mgr =
driver.DriverManager(namespace, engine_name)
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/stevedore/driver.py", line 45, in __init__
2014-11-16 22:22:30.649 17570 TRACE ceilometer
verify_requirements=verify_requirements,
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/stevedore/named.py", line 55, in __init__
2014-11-16 22:22:30.649 17570 TRACE ceilometer verify_requirements)
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 170, in
_load_plugins
2014-11-16 22:22:30.649 17570 TRACE ceilometer
self._on_load_failure_callback(self, ep, err)
2014-11-16 22:22:30.649 17570 TRACE ceilometer File
"/usr/lib/python2.7/dist-packages/stevedore/driver.py", line 50, in
_default_on_load_failure
2014-11-16 22:22:30.649 17570 TRACE ceilometer raise err
2014-11-16 22:22:30.649 17570 TRACE ceilometer ImportError: No module named
bson.code
2014-11-16 22:22:30.649 17570 TRACE ceilometer
Looking for some help..
Regards,
Malleshi CN
________________________________
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise confidential information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the e-mail by you is prohibited. Where allowed by local law, electronic
communications with Accenture and its affiliates, including e-mail and instant
messaging (including content), may be scanned by our systems for the purposes
of information security and assessment of internal compliance with Accenture
policy.
______________________________________________________________________________________
www.accenture.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openstack.org/pipermail/openstack/attachments/20141116/a7ae963b/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 16 Nov 2014 20:00:34 +0100
From: Harm Weites <h...@weites.com>
To: openstack@lists.openstack.org
Subject: [Openstack] Proper way of adding ARM image to Glance
Message-ID: <5468f452.9070...@weites.com>
Content-Type: text/plain; charset=windows-1252
Hi,
My cloud recently got extended with some simple ARM hosts so now I'd
like Glance to offer ARM images next to x86_64. However, I'm unsure on
how to do just that.
I've added Cirros 0.3.3 using the following glance commands:
glance image-create --name='Cirros 0.3.3 ARM (kernel)'
--disk-format=aki --container-format=aki < cirros-0.3.3-arm-kernel
glance image-create --name='Cirros 0.3.3 ARM (ramdisk)'
--disk-format=ari --container-format=ari < cirros-0.3.3-arm-initramfs
glance image-create --name="Cirros 0.3.3 ARM" --disk-format=ami
--container-format=ami --property architecture=armv7l --property
kernel_id=\$KUUID --property ramdisk_id=\$RUUID <
cirros-0.3.3-arm-rootfs.img
But this results in an unusable image, from which I can't create a new
volume to use for boot. The image is stuck in a queued-state:
| ce98688b-35ab-4b0b-b8d0-1396631e82d9 | Cirros 0.3.0
ARM | ami | ami | |
queued |
| 1c371d20-656d-42fb-9b2d-0ee129bedf91 | Cirros 0.3.0 ARM
kernel | aki | aki | 3741276 | active |
| 2bf96321-7986-4b09-a9b5-2b8c47463b4a | Cirros 0.3.0 ARM
ramdisk | ari | ari | 2023036 | active |
Next I tried importing the ubuntu cloud image
(utopic-server-cloudimg-armhf-disk1) but booting a new instance from
that results in nothing - console.log stays empty so it presumably fails.
How should I add ARM images to Glance to make Nova happily boot new ARM
instances? Are there any specifics I need to take into account in an
ARM-scenario?
Regards,
Harm
------------------------------
Message: 3
Date: Mon, 17 Nov 2014 00:44:54 +0530
From: mad Engineer <themadengin...@gmail.com>
To: "openstack@lists.openstack.org" <openstack@lists.openstack.org>
Subject: [Openstack] EMC VNX with QCOW2 disk images in cinder
Message-ID:
<can8oo4d5k2qu5dsxrcbap7rw99q69j2-15b2xu8c2w8jzzo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Is there any way to use EMC VNX with out using vnx direct driver.I want
to use qcow2 virtual disk and benefit from its thin provisioning and
snapshot capability rather than spending more money on features which is
already there in my hypervisor :-( .Is it possible?
Experience with vmware and EMC VNX
we currently export a LUN to vmware and vmdk images are created on that and
its snapshot feature work without any extra cost for snapshot license from
EMC(which is required for making it work with cinder)
Is it possible to achieve similar with cinder + EMC VNX
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openstack.org/pipermail/openstack/attachments/20141117/d0a8ce42/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 16 Nov 2014 13:23:57 -0600
From: Anne Gentle <a...@openstack.org>
To: Harm Weites <h...@weites.com>
Cc: "openstack@lists.openstack.org" <openstack@lists.openstack.org>
Subject: Re: [Openstack] Proper way of adding ARM image to Glance
Message-ID:
<CAD0KtVG0d62z2tnkeY-4eEu80z0EgLiELQyLXEV=13htgxu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sun, Nov 16, 2014 at 1:00 PM, Harm Weites <h...@weites.com> wrote:
Hi,
My cloud recently got extended with some simple ARM hosts so now I'd
like Glance to offer ARM images next to x86_64. However, I'm unsure on
how to do just that.
I've added Cirros 0.3.3 using the following glance commands:
glance image-create --name='Cirros 0.3.3 ARM (kernel)'
--disk-format=aki --container-format=aki < cirros-0.3.3-arm-kernel
glance image-create --name='Cirros 0.3.3 ARM (ramdisk)'
--disk-format=ari --container-format=ari < cirros-0.3.3-arm-initramfs
glance image-create --name="Cirros 0.3.3 ARM" --disk-format=ami
--container-format=ami --property architecture=armv7l --property
kernel_id=\$KUUID --property ramdisk_id=\$RUUID <
cirros-0.3.3-arm-rootfs.img
But this results in an unusable image, from which I can't create a new
volume to use for boot. The image is stuck in a queued-state:
| ce98688b-35ab-4b0b-b8d0-1396631e82d9 | Cirros 0.3.0
ARM | ami | ami | |
queued |
| 1c371d20-656d-42fb-9b2d-0ee129bedf91 | Cirros 0.3.0 ARM
kernel | aki | aki | 3741276 | active |
| 2bf96321-7986-4b09-a9b5-2b8c47463b4a | Cirros 0.3.0 ARM
ramdisk | ari | ari | 2023036 | active |
Next I tried importing the ubuntu cloud image
(utopic-server-cloudimg-armhf-disk1) but booting a new instance from
that results in nothing - console.log stays empty so it presumably fails.
How should I add ARM images to Glance to make Nova happily boot new ARM
instances? Are there any specifics I need to take into account in an
ARM-scenario?
Check out
http://docs.openstack.org/cli-reference/content/chapter_cli-glance-property.html
Can you find the architecture of the underlying node?
architecture: The CPU architecture that must be supported by the
hypervisor. Run *uname -m* to get the architecture of a machine.
You may also need to find the Libvirt machine type. Valid types can be
viewed by using the virsh capabilities command (machine types are displayed
in the machine tag).
Please log a doc bug if you see anything outdated on that page.
Thanks,
Anne
Regards,
Harm
_______________________________________________
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openstack.org/pipermail/openstack/attachments/20141116/60050626/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 16 Nov 2014 20:44:42 +0100
From: Harm Weites <h...@weites.com>
To: Anne Gentle <a...@openstack.org>
Cc: "openstack@lists.openstack.org" <openstack@lists.openstack.org>
Subject: Re: [Openstack] Proper way of adding ARM image to Glance
Message-ID: <5468feaa.1090...@weites.com>
Content-Type: text/plain; charset="utf-8"
Hi,
The node is supported:
# uname -m
armv7l
As you can see I've used this value to specify a specific architecture
for my image.
Libvirt is happy as well, as it supports the machine Nova is hardcoded
to use:
<machine maxCpus='4'>vexpress-a15</machine>
-Harm
Op 16-11-14 om 20:23 schreef Anne Gentle:
On Sun, Nov 16, 2014 at 1:00 PM, Harm Weites <h...@weites.com
<mailto:h...@weites.com>> wrote:
Hi,
My cloud recently got extended with some simple ARM hosts so now I'd
like Glance to offer ARM images next to x86_64. However, I'm unsure on
how to do just that.
I've added Cirros 0.3.3 using the following glance commands:
glance image-create --name='Cirros 0.3.3 ARM (kernel)'
--disk-format=aki --container-format=aki < cirros-0.3.3-arm-kernel
glance image-create --name='Cirros 0.3.3 ARM (ramdisk)'
--disk-format=ari --container-format=ari < cirros-0.3.3-arm-initramfs
glance image-create --name="Cirros 0.3.3 ARM" --disk-format=ami
--container-format=ami --property architecture=armv7l --property
kernel_id=\$KUUID --property ramdisk_id=\$RUUID <
cirros-0.3.3-arm-rootfs.img
But this results in an unusable image, from which I can't create a new
volume to use for boot. The image is stuck in a queued-state:
| ce98688b-35ab-4b0b-b8d0-1396631e82d9 | Cirros 0.3.0
ARM | ami | ami | |
queued |
| 1c371d20-656d-42fb-9b2d-0ee129bedf91 | Cirros 0.3.0 ARM
kernel | aki | aki | 3741276 |
active |
| 2bf96321-7986-4b09-a9b5-2b8c47463b4a | Cirros 0.3.0 ARM
ramdisk | ari | ari | 2023036 |
active |
Next I tried importing the ubuntu cloud image
(utopic-server-cloudimg-armhf-disk1) but booting a new instance from
that results in nothing - console.log stays empty so it presumably
fails.
How should I add ARM images to Glance to make Nova happily boot
new ARM
instances? Are there any specifics I need to take into account in an
ARM-scenario?
Check
out
http://docs.openstack.org/cli-reference/content/chapter_cli-glance-property.html
Can you find the architecture of the underlying node?
architecture: The CPU architecture that must be supported by the
hypervisor. Run *uname -m* to get the architecture of a machine.
You may also need to find the Libvirt machine type. Valid types can be
viewed by using the virsh capabilities command (machine types are
displayed in the machine tag).
Please log a doc bug if you see anything outdated on that page.
Thanks,
Anne
Regards,
Harm
_______________________________________________
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
<mailto:openstack@lists.openstack.org>
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openstack.org/pipermail/openstack/attachments/20141116/4e6beafc/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 16 Nov 2014 21:18:31 +0100
From: Maciej Nabo?ny <m...@mnabozny.pl>
To: openstack@lists.openstack.org
Subject: [Openstack] Problems with neutron networks
Message-ID: <54690697.6090...@mnabozny.pl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi,
I have some problems with neutron network. I've configured Openstack
according to instructions (I hope :) with gre tunnels and everything
looks fine, like in my similar RDO installation. All vswitch bridges
look like are connected together, with tunnels and routers. The only
problem is, that there is no comminication between virtual machines and
routers in networks :)
I've tried to debug it with pings and tcpdump. It looks like packets are
droped between br-int and br-tun vswitches, both on compute node and
neutron. Icmp packets are visible only when I'm listening on br-int
(pings from vm or qrouter namespace in neutron). I cannot see them by
listening on br-tun. Patch-tun and patch-int are configured.
Do you have any sugestions, how to debug my problem or where it could
be? If necessary, I can attach some output and configuration
Regards,
Maciek
------------------------------
Message: 7
Date: Sun, 16 Nov 2014 19:45:59 -0800
From: Mike Perez <thin...@gmail.com>
To: openstack-...@lists.openstack.org, openstack@lists.openstack.org
Subject: [Openstack] [cinder] Anyone Using the Open Solaris ZFS
Driver?
Message-ID: <20141117034559.gb28...@gmail.com>
Content-Type: text/plain; charset=us-ascii
The Open Solaris ZFS driver [1] is currently missing a lot of the minimum
features [2] that the Cinder team requires with all drivers. As a result, it's
really broken.
I wanted to gauge who is using it, and if anyone was interested in fixing the
driver. If there is not any activity with this driver, I would like to propose
it to be deprecated for removal.
[1] -
https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/san/solaris.py
[2] -
http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features
