[Openstack] UNSUBSCRIBE
Peter Vizard
peter.vizard at free.fr
Mon Nov 17 12:32:49 UTC 2014
Thanks.
On 17/11/2014 13:00, openstack-request at lists.openstack.org wrote:
> Send Openstack mailing list submissions to
> openstack at 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-request at lists.openstack.org
>
> You can reach the person managing the list at
> openstack-owner at 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.negalur at 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.negalur at accenture.com>
> To: <openstack at lists.openstack.org>
> Subject: [Openstack] Ceilometer Api error in Juno
> Message-ID:
> <21cdf970ae844cbc9da5d212b6586d59 at 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 at 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 <harm at weites.com>
> To: openstack at lists.openstack.org
> Subject: [Openstack] Proper way of adding ARM image to Glance
> Message-ID: <5468F452.9070703 at 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 <themadengin33r at gmail.com>
> To: "openstack at lists.openstack.org" <openstack at lists.openstack.org>
> Subject: [Openstack] EMC VNX with QCOW2 disk images in cinder
> Message-ID:
> <CAN8oO4D5k2qu5DSxRCBAP7rW99Q69J2-15B2XU8C2W8JzZoYZQ at 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 <anne at openstack.org>
> To: Harm Weites <harm at weites.com>
> Cc: "openstack at lists.openstack.org" <openstack at lists.openstack.org>
> Subject: Re: [Openstack] Proper way of adding ARM image to Glance
> Message-ID:
> <CAD0KtVG0d62z2tnkeY-4eEu80z0EgLiELQyLXEV=13HtGXUhjA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Sun, Nov 16, 2014 at 1:00 PM, Harm Weites <harm at 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 at 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 <harm at weites.com>
> To: Anne Gentle <anne at openstack.org>
> Cc: "openstack at lists.openstack.org" <openstack at lists.openstack.org>
> Subject: Re: [Openstack] Proper way of adding ARM image to Glance
> Message-ID: <5468FEAA.1090601 at 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 <harm at weites.com
>> <mailto:harm at 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 at lists.openstack.org
>> <mailto:openstack at 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 <mn at mnabozny.pl>
> To: openstack at lists.openstack.org
> Subject: [Openstack] Problems with neutron networks
> Message-ID: <54690697.6090209 at 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 <thingee at gmail.com>
> To: openstack-dev at lists.openstack.org, openstack at lists.openstack.org
> Subject: [Openstack] [cinder] Anyone Using the Open Solaris ZFS
> Driver?
> Message-ID: <20141117034559.GB28778 at 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
>
More information about the Openstack
mailing list