Open Stack

Ok, I finally got the command to change to the Compute box's IP address.  But I am still getting the same error when trying to attach a volume when creating a instance:

ProcessExecutionError: Unexpected error while running command.
2013-03-25 12:54:36 1817 TRACE nova.compute.manager [instance: a2be60ee-0fa0-4a54-a65a-852981da61e7] Command: sudo nova-rootwrap /etc/nova/rootwrap.conf iscsiadm -m node -T iqn.2010-10.org.openstack:volume-b143d06e-fd64-4dfc-8114-b457a2094080 -p 192.168.0.1:3260 --rescan
2013-03-25 12:54:36 1817 TRACE nova.compute.manager [instance: a2be60ee-0fa0-4a54-a65a-852981da61e7] Exit code: 255
2013-03-25 12:54:36 1817 TRACE nova.compute.manager [instance: a2be60ee-0fa0-4a54-a65a-852981da61e7] Stdout: ''
2013-03-25 12:54:36 1817 TRACE nova.compute.manager [instance: a2be60ee-0fa0-4a54-a65a-852981da61e7] Stderr: 'iscsiadm: No portal found.\n'



Steven Barnabas
Network Engineer
Front Porch, Inc.
209-288-5580
209-652-7733 mobile
www.frontporch.com<http://www.frontporch.com/>



On Mar 22, 2013, at 1:47 AM, Sylvain Bauza <sylvain.bauza at digimind.com<mailto:sylvain.bauza at digimind.com>> wrote:

I once had troubles with Cinder volumes, mainly due to the fact I forgot to mention iscsi_ip_addr in cinder.conf.
After restarting Cinder, all new volumes created were fine, but old present volumes were still pointing to the bad IP address.

I then cutted with my knife in cinder mysql database ('volumes' table) to match the right IP address for the existing volumes :
mysql> select id,provider_location from volumes where deleted=0;
mysql> update volumes set provider_location='XXX' where uuid=<volume_id>
sudo service cinder-api restart
sudo service cinder-volume restart
sudo service cinder-scheduler restart

Don't also forget to restart tgt to recreate the LUN paths if necessary.
sudo tgt-admin --show
sudo service tgt restart

Hope it can help,
-Sylvain

Le 22/03/2013 01:14, Steven Barnabas a écrit :
OK, found out my Cinder volume was not configured correctly.  Fixed that and Cinder is up and running.  Created a volume and everything is great.  When i go to create my windows instance now, I get an error.  When i check /var/nova/nova-compute.log I see this.
"ProcessExecutionError: Unexpected error while running command.\nCommand: sudo nova-rootwrap /etc/nova/rootwrap.conf iscsiadm -m node -T iqn.2010-10.org.openstack:volume-74e9c037-a681-48e2-b098-3c76bfb071f3 -p 127.0.0.1:3260 --rescan\nExit code: 255\nStdout: ''\nStderr: 'iscsiadm: No portal found.\\n'\n"]

The part that I think its messing up on is its trying to connect to 127.0.0.1.  When it should be connecting to the compute box.  Thats why it cannot find the portal.  I have checked my configs and cannot seem to find what I need to edit to make this thing connect to the compute when attaching a volume to the instance.

any ideas?

Thanks.





Steven Barnabas
Network Engineer
Front Porch, Inc.
209-288-5580
209-652-7733 mobile
www.frontporch.com<http://www.frontporch.com/>



On Mar 21, 2013, at 1:39 AM, Sylvain Bauza <sylvain.bauza at digimind.com<mailto:sylvain.bauza at digimind.com>> wrote:

Le 20/03/2013 21:11, Steven Barnabas a écrit :
Ok, I have successfully created a windows image using an ISO.   I am going to try a different VMDK image that I have to see if it works.  If not, then I will convert it to QCOW2 format using a different machine.  I don't want to mess up my Compute box by trying to upgrade Qemu.  I know I will mess something up :)



Cool to hear that. Anyway, upgrading to Qemu 1.3 on Ubuntu 12.04 was pretty straight for me and not regressive :
apt-get install zlib1g-dev libsdl1.2-dev libpcap-dev texinfo autoconf libtool build-essential
wget http://wiki.qemu-project.org/download/qemu-1.3.1.tar.bz2
tar jxvf qemu-1.3.1.tar.bz2
cd qemu-1.3.1
./configure --target-list=x86_64-linux-user,x86_64-softmmu # Depending on your platform of course
make
sudo make install

It will deploy qemu in /usr/local/bin/ while the Ubuntu qemu-1.0 package is based in /usr/bin.

So as to get it work with libvirt and nova, you have to make sure you have hvm capabilities (check with 'virsh capabilities'), and if not, this is due to the fact that libvirt is requesting /usr/bin/qemu-system.<platform>

In order to fix this, a quick "mv /usr/bin/qemu-system.<platform> /usr/bin/qemu-system.<platform>.0 && mv /usr/local/bin/qemu-system.<platform> /usr/bin' does the trick.

Hopefully, nova is following the path for qemu-img, which makes unnecessary to switch versions as above.

-Sylvain



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130325/e4c7d9e7/attachment.html>