Re: [Openstack] Unable to run instances , instance status is networking,
Hi Wayne, Thanks for your reply. On my slave node, if I run following command, I am able to see instances but state is ' shut off ' root@openstack3:~# virsh list --all Id Name State -- - instance-002ashut off - instance-003cshut off - instance-003eshut off - instance-0040shut off root@openstack3:~# I went ahead and started instances manually, I have got following errrors. virsh # start instance-002a *error: Failed to start domain instance-002a error: operation failed: failed to retrieve chardev info in qemu with 'info chardev'* virsh # I have checked the log files also, 2011-08-18 11:03:06.324: starting up LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name instance-003c -uuid d846d3ab-e7c4-fe41-7e6f-769e899943d7 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-003c.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc -boot c -kernel /var/lib/nova/instances/instance-003c/kernel -append root=/dev/vda console=ttyS0 -drive file=/var/lib/nova/instances/instance-003c/disk,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,fd=19,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=02:16:3e:51:69:8a,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/instance-003c/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -usb -vnc 0.0.0.0:0 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 char device redirected to /dev/pts/2 *qemu: could not load kernel '/var/lib/nova/instances/instance-003c/kernel': Inappropriate ioctl for device 2011-08-18 11:03:06.625: shutting down* Could any one can help me here. --Thanks and regards, Praveen GK. On Thu, Aug 18, 2011 at 10:03 AM, Wayne A. Walls wrote: > Greetings, Praveen! > > On your compute nodes, the only required service is nova-compute. There > has been a semi-recent update to nova-network that adds HA to the service, > and this requires nova-network to be installed on all the compute nodes as > well. As far as api and scheduler go, they are not required on every node. > > > For more information on nova-network's HA work, check out Vish's blog: > http://www.unchainyourbrain.com/openstack/13-networking-in-nova > > Cheers, > > > Wayne > > From: praveen_kumar girir > Date: Thu, 18 Aug 2011 09:28:32 +0530 > To: Dan Wendlandt > Cc: openstack > Subject: Re: [Openstack] Unable to run instances , instance status is > networking, > > Dear Dan, > I have changed my /etc/nova/nova.conf file to reflect proper fixed_ip > range, > then it start to launch. > > I have one more question, > > does the compute nodes required to have all the nova softwares to run. > because on my slave nodes initially it was only nova-compute, later > installed nova-scheduler, api, network n all. > > Started multiple instances from master node, able to create vm on slave > nodes, but the status is shutdown. No idea. > > if I am able to access these from slave nodes, it requires EC2_ACCESS_KEY. > By default it is not set, do I need to set it manually. > > Could any one please clarify my doubts. > > --Thanks and regards, > Praveen GK. > > On Wed, Aug 17, 2011 at 8:43 PM, Dan Wendlandt wrote: > >> Hi Praveen, >> >> The error you are seeing is because there is no 'network' record in the >> nova database corresponding to 'br100' (which is the default value for the >> bridge). Spawning a VM requires finding the appropriate network(s) for that >> VM in the database, and assigning the VM an IP address from the associated >> network subnet. >> >> Did you run nova-manage to create a network? If so, can you send out the >> command you ran? >> >> For example the Running Nova wiki (http://wiki.openstack.org/RunningNova) >> includes the line: >> >> sudo nova-manage network create novanetwork 10.0.0.0/8 1 64 >> >> Dan >> >> >> On Tue, Aug 16, 2011 at 9:45 PM, praveen_kumar girir >> wrote: >> >>> Dear Mandell, >>> The nova-network process is running. >>> But I am not able to see any log file under /var/log/libvert/qemu/ >>> directory. >>> When I run describe instance command , I am able to see this output. >>> root@openstack2:~# euca-describe-instances >>> RESERVATIONr-l4zr8lygbexardefault >>> INSTANCEi-000cami-2b84327cnetworkingtest >>> (bexar, openstack2)0m1.tiny2011-08-12T11:29:42Znova >>> >>> RESERVATIONr-s8zj5yjebexardefault >>> INSTANCEi-000aami-2b84327cnetworkingtest >>> (bexar, openstack2)0m1.tiny2011-08-12T11:29:33Znova >>> >>> >
[Openstack] Improving test coverage and how you can help out!
At the design summit, we agreed we'd work hard on improving our test coverage. Our friendly neighbourhood butler, Jenkins, keeps track of our test coverage: https://jenkins.openstack.org/job/nova-coverage/lastStableBuild/cobertura/ Clearly, there's lots of room for improvement. I'd like to encourage anyone who cares about testing to take a look at that page, find something, big or small, that lacks test coverage and add tests for it. No method is too small to be tested (the devil's in the details!). Good test coverage is extremely important for maintaining momentum in a project of this level of complexity, so this is a very important effort. I've started filing bugs about missing unit tests. I've only filed a few so far, some are about a few statements that are missing tests, others are about entire modules that hardly have any unit tests at all: https://bugs.launchpad.net/nova/+bugs?field.tag=unittests Feel free to add more bugs like these! It's easier to pick stuff off of a list like that than to try to take in the entire coverage report. The 100% test coverage we decided (or was it 99%? ot 95%?) at the summit is not going to happen within the next month or two, so I'd like to just see how much we can achieve before the Diablo release. I'll try to extract some useful numbers every week to see how we're doing. Who's with me? -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Improving test coverage and how you can help out!
Hi Soren, Surely this is a key aspect that can sometimes get overlooked by us developers. Thanks for bringing this up again. There have been hundreds of bugs that have been filed over the last few months and many clearly indicate that they could have been caught at the unit test level. Unit testing is not a hard task (albeit a lazy one sometimes), and there's no debating that the earlier we catch those bugs, the more we get to sleep later on!! We have some branches (libvirt, network) for unit tests that will greatly increase the coverage numbers and we are still working actively working on this (testing) front. A collective effort from the community means that the 95 or 100% numbers are achievable. Thanks! Rohit (NTT) -Original Message- From: openstack-bounces+rohit.karajgi=vertex.co...@lists.launchpad.net [mailto:openstack-bounces+rohit.karajgi=vertex.co...@lists.launchpad.net] On Behalf Of Soren Hansen Sent: Thursday, August 18, 2011 4:24 PM To: openstack@lists.launchpad.net Subject: [Openstack] Improving test coverage and how you can help out! At the design summit, we agreed we'd work hard on improving our test coverage. Our friendly neighbourhood butler, Jenkins, keeps track of our test coverage: https://jenkins.openstack.org/job/nova-coverage/lastStableBuild/cobertura/ Clearly, there's lots of room for improvement. I'd like to encourage anyone who cares about testing to take a look at that page, find something, big or small, that lacks test coverage and add tests for it. No method is too small to be tested (the devil's in the details!). Good test coverage is extremely important for maintaining momentum in a project of this level of complexity, so this is a very important effort. I've started filing bugs about missing unit tests. I've only filed a few so far, some are about a few statements that are missing tests, others are about entire modules that hardly have any unit tests at all: https://bugs.launchpad.net/nova/+bugs?field.tag=unittests Feel free to add more bugs like these! It's easier to pick stuff off of a list like that than to try to take in the entire coverage report. The 100% test coverage we decided (or was it 99%? ot 95%?) at the summit is not going to happen within the next month or two, so I'd like to just see how much we can achieve before the Diablo release. I'll try to extract some useful numbers every week to see how we're doing. Who's with me? -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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
Re: [Openstack] Improving test coverage and how you can help out!
Soren, that's an awesome utility to have. I'll certainly be using to shore up some coverage. Nice work! -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Soren Hansen [so...@linux2go.dk] Sent: Thursday, August 18, 2011 7:54 AM To: openstack@lists.launchpad.net Subject: [Openstack] Improving test coverage and how you can help out! At the design summit, we agreed we'd work hard on improving our test coverage. Our friendly neighbourhood butler, Jenkins, keeps track of our test coverage: https://jenkins.openstack.org/job/nova-coverage/lastStableBuild/cobertura/ Clearly, there's lots of room for improvement. I'd like to encourage anyone who cares about testing to take a look at that page, find something, big or small, that lacks test coverage and add tests for it. No method is too small to be tested (the devil's in the details!). Good test coverage is extremely important for maintaining momentum in a project of this level of complexity, so this is a very important effort. I've started filing bugs about missing unit tests. I've only filed a few so far, some are about a few statements that are missing tests, others are about entire modules that hardly have any unit tests at all: https://bugs.launchpad.net/nova/+bugs?field.tag=unittests Feel free to add more bugs like these! It's easier to pick stuff off of a list like that than to try to take in the entire coverage report. The 100% test coverage we decided (or was it 99%? ot 95%?) at the summit is not going to happen within the next month or two, so I'd like to just see how much we can achieve before the Diablo release. I'll try to extract some useful numbers every week to see how we're doing. Who's with me? -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Improving test coverage and how you can help out!
I am! On Thu, Aug 18, 2011 at 5:54 AM, Soren Hansen wrote: > At the design summit, we agreed we'd work hard on improving our test > coverage. Our friendly neighbourhood butler, Jenkins, keeps track of > our test coverage: > > > https://jenkins.openstack.org/job/nova-coverage/lastStableBuild/cobertura/ > > Clearly, there's lots of room for improvement. > > I'd like to encourage anyone who cares about testing to take a look at > that page, find something, big or small, that lacks test coverage and > add tests for it. No method is too small to be tested (the devil's in > the details!). Good test coverage is extremely important for > maintaining momentum in a project of this level of complexity, so this > is a very important effort. I've started filing bugs about missing > unit tests. I've only filed a few so far, some are about a few > statements that are missing tests, others are about entire modules > that hardly have any unit tests at all: > >https://bugs.launchpad.net/nova/+bugs?field.tag=unittests > > Feel free to add more bugs like these! It's easier to pick stuff off > of a list like that than to try to take in the entire coverage report. > > The 100% test coverage we decided (or was it 99%? ot 95%?) at the > summit is not going to happen within the next month or two, so I'd > like to just see how much we can achieve before the Diablo release. > I'll try to extract some useful numbers every week to see how we're > doing. > > Who's with me? > > -- > Soren Hansen| http://linux2go.dk/ > Ubuntu Developer| http://www.ubuntu.com/ > OpenStack Developer | http://www.openstack.org/ > > ___ > 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
Re: [Openstack] How to connect br100 to xen bridge
if you plan on using multiple networks, i would get into the habit of specifying the bridge with the --bridge parameter to nova-manager network create. If you rely on the flag and then create multiple networks they'll all end up connected to the same bridge. On Wed, Aug 17, 2011 at 7:17 PM, Joshua Harlow wrote: > Hi all, > > Just trying to continue with my xen+openstack integration. > > Is there a recommended way to get openstack to connect to the xen bridge. > > Apparently the xen bridge is @ xenbr0 but openstack likes to use br100. > > Is it just a simple DB update to make this happen, or can this be changed > in the nova-network config? > > Has anyone had any experience with this? > > Thanks > > ___ > 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
[Openstack] Multiple nova-api's...
Is it possible to have multiple nova-api's, nova-networks running in the same instance (connected to the same db/rabbitmq)? Say that you want to have fault tolerance, so you would have multiple instances of these, so that if one failed the whole iaas system would not. Is that something typically done? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please welcome OpenStack's new community manager, Stefano Maffulli
2011/8/17 praveen_kumar girir > I have newly joined to this community as developer and managing own private > cloud at an organization. > fantastic, welcome to the community. > Here I have suggestion, on our openstack site, we are showcasing multiple > releases of openstack projects, we should provide more informations as > release features, platform specific features, stable release, and which > release is compatible on which platform. > As we have in our kernel.org site. > Thank you very much for you ideas Praveen. I'll be collecting and evaluate suggestions during the next weeks, so keep them coming. Cheers, stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Multiple nova-api's...
Yes and maybe (we're doing it). The individual nova-api processes need to run on their own port though. nova-api --flagfile=/etc/nova/nova.conf --logfile=/var/log/nova/nova-api-.log --ec2_listen_port= nova-api --flagfile=/etc/nova/nova.conf --logfile=/var/log/nova/nova-api-.log --ec2_listen_port= you can fire up multiple nova-api processes with something like monit. Then you can load balance between them with something like haproxy. Everett On Thu, Aug 18, 2011 at 11:43 AM, Joshua Harlow wrote: > Is it possible to have multiple nova-api’s, nova-networks running in the > same instance (connected to the same db/rabbitmq)? > > Say that you want to have fault tolerance, so you would have multiple > instances of these, so that if one failed the whole iaas system would not. > > Is that something typically done? > > ___ > 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
[Openstack] AuthZ functionality in Keystone - Re: [WAS]OpenStack Identity: Keystone API Proposal
Hi Ziad, Apologies for reviving this old thread, I am changing the subject so that my email doesn't get lost in this big pile. We are working on integrating Quantum Network Service with Keystone as the AuthN/Z service provider. I believe you are aware of the prior discussion between you, Salvatore and Vish regarding Keystone's capabilities and Quantum's AuthN/Z use cases. To recap prior emails, Quantum plans to leverage Keystone for AuthN services, this is simple enough, well understood use case, for which Keystone provides good support. The point of contention has been around Quantum's AuthZ use case. Quantum's AuthZ use case: 1) A tenant named Tenant-X( or user with access to Tenant-X) requests that Network-A be created - simple enough, Keystone does AuthN and Quantum associates the particular network with a specific tenant (Tenant-X) 2) Tenant-X( or user with access to Tenant-X) requests that Nova plug a Virtual Network Interface named "instance-0001-eth0" into Network-A 2.1) Quantum needs to ensure Tenant-X( or user with access to Tenant-X) owns Network-A - Simple enough, since this network was created in Quantum, Quantum tracks which tenant owns which Quantum resources. 2.2) Quantum needs to ensure Tenant-X( or user with access to Tenant-X) owns Virtual Network Interface named "instance-0001-eth0" available in Nova - *This is where we need AuthZ help from Keystone* 2.3) Quantum needs to ensure Tenant-X( or user with access to Tenant-X) is authorized to perform the "plug_virtual_interface()" operation. To solve Quantum's AuthZ use-cases as specified in section 2.2 & 2.3, we have one possible solution using "roles", as was described by you and Vish earlier in the original Keystone API email thread. Solution: 1) For every token, that spins up a new VM, on VM and Virtual network interface creation, Nova adds a "role" to the particular tenant( or token?) with the following pattern - nova:plug_vif: 2) Quantum queries Keystone for roles associated with a particular token( tenant/user) and can then verify if the particular user has authorization over a virtual interface and if the user can perform "plug_vif" operation. My question to Keystone devs is: 1) Do you guys see the proposed solution to be compatible with Keystone Diablo API? 2) Would you recommend any other solution to Quantum's use-cases based on the Keystone API available in Diablo time-frame. 3) If we implement the above mentioned solution, then we might easily end up with 1 additional role for every virtual interface in Nova, this can easily amount 1000's of roles associated with every tenant as its not unheard of for a Virtual Machine to have 3-4 Virtual Interfaces, and now with multi-nic support, we might see that in OpenStack too. - Having, for example, 3000 roles per tenant, and having a 1000 tenants would be a reasonable estimate for a medium sized deployment. In such a scenario, will Keystone be able to scale and operate?, do we have any estimates or validation on Keystone's scale numbers? - If this doesn't work today, what are the limits of the system today? - If Quantum's AuthZ use case cannot be fulfilled with what Keystone API offers in Diablo time-frame, would you know what are the future plans around AuthZ that will help fulfill Quantum's use-cases while not imposing scalability restrictions. Thanks in advance for parsing through this long email and we will look forward to your recommendations. Regards, Somik On Thu, Jul 21, 2011 at 11:51 AM, Ziad Sawalha wrote: > Hot, Texas summer regards to all! > > Since my last note we have had much progress on Keystone. Particularly: > >- We now have Nova, Dashboard, Glance, and Keystone integration ( >https://github.com/cloudbuilders/deploy.sh >- We've done some work on Swift integration ( > > https://github.com/rackspace/keystone/blob/master/keystone/middleware/swift_auth.py >) >- LDAP an be your backend ( >https://github.com/rackspace/keystone/pull/102) >- We're incubating! Keystone is now officially an OpenStack Incubation >project. >- And many other updates, enhanced testing, stability improvements, >etc… > > In my last note I called out our latest API proposal and asked for input. > We've received much of that input – thank you - and have four new blueprints > to change the API. These are: > >1. Support Service Registration (blueprint here > > https://blueprints.launchpad.net/keystone/+spec/keystone-service-registration >). >2. Remove support for 'default' tenant. Instead, a 'Member' or >'default' role can be used to manage a default tenant (this may be >implemented in the legacy_token_auth front end (blueprint here: >https://blueprints.launchpad.net/keystone/+spec/remove-default-tenant >). >3. Support for EC2 API and non-password credentials (blueprint here: > > https://blueprints.launchpad.net/keystone/+spec/support-multiple-credentials >). >4. Support
Re: [Openstack] Multiple nova-api's...
The way suggested here would setup them as different ec2 entry points though right? (the different port part). If you have one nova-api on one machine Y with X port and then another nova-api on another machine Z with X port would that work. It would seem possible, just not sure if the code would handle that correctly (is everything really stateless...) That way if Y machine dies, action will still occur on machine Z (just whatever Y may be doing is dead - which may result in DB state & messages being incorrect?). It seems like rabbitmq has active/passive failure, has anyone looked into that? On 8/18/11 12:27 PM, "Everett Toews" wrote: Yes and maybe (we're doing it). The individual nova-api processes need to run on their own port though. nova-api --flagfile=/etc/nova/nova.conf --logfile=/var/log/nova/nova-api-.log --ec2_listen_port= nova-api --flagfile=/etc/nova/nova.conf --logfile=/var/log/nova/nova-api-.log --ec2_listen_port= you can fire up multiple nova-api processes with something like monit. Then you can load balance between them with something like haproxy. Everett On Thu, Aug 18, 2011 at 11:43 AM, Joshua Harlow wrote: Is it possible to have multiple nova-api's, nova-networks running in the same instance (connected to the same db/rabbitmq)? Say that you want to have fault tolerance, so you would have multiple instances of these, so that if one failed the whole iaas system would not. Is that something typically done? ___ 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
Re: [Openstack] AuthZ functionality in Keystone - Re: [WAS]OpenStack Identity: Keystone API Proposal
Hi Vish, That would be one very reasonable way to do it, but in that case we are fragmenting AuthZ in multiple services instead of Keystone taking care of AuthZ across all services. Depending on Keystone's roadmap and plans, we could take a 2 phased approach, where Nova doing AuthZ is a temporary solution till Keystone can do it or if Keystone is not going to have this capability, then we go down the path you are suggesting - Keystone does AuthN and we rely on Nova to authorize a tenant's access rights to a particular vif. Thanks, Somik On Thu, Aug 18, 2011 at 3:37 PM, Vishvananda Ishaya wrote: > > On Aug 18, 2011, at 2:08 PM, Somik Behera wrote: > > > 2.2) Quantum needs to ensure Tenant-X( or user with access to Tenant-X) > owns Virtual Network Interface named "instance-0001-eth0" available in Nova > - *This is where we need AuthZ help from Keystone* > > > It seems simpler to me to have a quantum call nova with something like > get_virtual_interface and pass the token. Then nova can decide if that > token has access to the vif. > > > -- Somik Behera | Nicira Networks, Inc. | so...@nicira.com | office: 650-390-6790 | cell: 512-577-6645 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] AuthZ functionality in Keystone - Re: [WAS]OpenStack Identity: Keystone API Proposal
On Aug 18, 2011, at 2:08 PM, Somik Behera wrote: > > 2.2) Quantum needs to ensure Tenant-X( or user with access to Tenant-X) > owns Virtual Network Interface named "instance-0001-eth0" available in Nova - > This is where we need AuthZ help from Keystone It seems simpler to me to have a quantum call nova with something like get_virtual_interface and pass the token. Then nova can decide if that token has access to the vif. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] AuthZ functionality in Keystone - Re: [WAS]OpenStack Identity: Keystone API Proposal
On Aug 18, 2011, at 3:45 PM, Somik Behera wrote: > Hi Vish, > > That would be one very reasonable way to do it, but in that case we are > fragmenting AuthZ in multiple services instead of Keystone taking care of > AuthZ across all services. We can't necessarily depend on keystone to keep track of all objects owned by each service. Especially for things like swift where millions of objects are involved. I therefore think the right solution is to have the services responsible for their own objects, and allow them to delegate to keystone in the cases where it makes sense. > > Depending on Keystone's roadmap and plans, we could take a 2 phased approach, > where Nova doing AuthZ is a temporary solution till Keystone can do it or if > Keystone is not going to have this capability, then we go down the path you > are suggesting - Keystone does AuthN and we rely on Nova to authorize a > tenant's access rights to a particular vif. > > Thanks, > Somik ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] AuthZ functionality in Keystone - Re: [WAS]OpenStack Identity: Keystone API Proposal
inline. Thanks, Somik On Thu, Aug 18, 2011 at 3:50 PM, Vishvananda Ishaya wrote: > > On Aug 18, 2011, at 3:45 PM, Somik Behera wrote: > > > Hi Vish, > > > > That would be one very reasonable way to do it, but in that case we are > fragmenting AuthZ in multiple services instead of Keystone taking care of > AuthZ across all services. > > We can't necessarily depend on keystone to keep track of all objects owned > by each service. Especially for things like swift where millions of objects > are involved. I therefore think the right solution is to have the services > responsible for their own objects, and allow them to delegate to keystone in > the cases where it makes sense. > > I just wasn't sure if that's what we had decided, or Keystone was going to be independently scalable system that can keep track of all object ids and their AuthZ. If we have decided to delegate AuthZ to individual services, that sounds like a perfectly reasonable way to to implement AuthZ. Along those lines, are we then planning a generic Nova API that will take a token and a resource( VM, vif or what have you) and say if the the token is authorized to access the resource( or a action on a resource) > > > > Depending on Keystone's roadmap and plans, we could take a 2 phased > approach, where Nova doing AuthZ is a temporary solution till Keystone can > do it or if Keystone is not going to have this capability, then we go down > the path you are suggesting - Keystone does AuthN and we rely on Nova to > authorize a tenant's access rights to a particular vif. > > > > Thanks, > > Somik > -- Somik Behera | Nicira Networks, Inc. | so...@nicira.com | office: 650-390-6790 | cell: 512-577-6645 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] AuthZ functionality in Keystone - Re: [WAS]OpenStack Identity: Keystone API Proposal
On Aug 18, 2011, at 5:50 PM, Vishvananda Ishaya wrote: > > On Aug 18, 2011, at 3:45 PM, Somik Behera wrote: > >> Hi Vish, >> >> That would be one very reasonable way to do it, but in that case we are >> fragmenting AuthZ in multiple services instead of Keystone taking care of >> AuthZ across all services. > > We can't necessarily depend on keystone to keep track of all objects owned by > each service. Especially for things like swift where millions of objects are > involved. I therefore think the right solution is to have the services > responsible for their own objects, and allow them to delegate to keystone in > the cases where it makes sense. (I hope I'm not getting into something here that I don't need to be in) The way this is handled in swift is a 2-phased approach. First, the auth system (keystone) can approve or deny a request up front if it already has enough in to do so. Second, the auth system provides an "authorize" method callback in the wsgi environment that swift can call at a later time in the request/response cycle. So after more information about the request is gathered (like ACLs stored on a particular object), swift calls the provided authorize method with the new info and then the final authorization determination is made. Perhaps a similar approach could be used for other services. *Oh, and as a point of (boastful) clarification, swift will be storing billions of objects, not millions. ;-) --John > >> >> Depending on Keystone's roadmap and plans, we could take a 2 phased >> approach, where Nova doing AuthZ is a temporary solution till Keystone can >> do it or if Keystone is not going to have this capability, then we go down >> the path you are suggesting - Keystone does AuthN and we rely on Nova to >> authorize a tenant's access rights to a particular vif. >> >> Thanks, >> Somik > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] AuthZ functionality in Keystone - Re: [WAS]OpenStack Identity: Keystone API Proposal
On Thu, Aug 18, 2011 at 4:09 PM, John Dickinson wrote: > > On Aug 18, 2011, at 5:50 PM, Vishvananda Ishaya wrote: > > > > > On Aug 18, 2011, at 3:45 PM, Somik Behera wrote: > > > >> Hi Vish, > >> > >> That would be one very reasonable way to do it, but in that case we are > fragmenting AuthZ in multiple services instead of Keystone taking care of > AuthZ across all services. > > > > We can't necessarily depend on keystone to keep track of all objects > owned by each service. Especially for things like swift where millions of > objects are involved. I therefore think the right solution is to have the > services responsible for their own objects, and allow them to delegate to > keystone in the cases where it makes sense. > > (I hope I'm not getting into something here that I don't need to be in) > > The way this is handled in swift is a 2-phased approach. First, the auth > system (keystone) can approve or deny a request up front if it already has > enough in to do so. Second, the auth system provides an "authorize" method > callback in the wsgi environment that swift can call at a later time in the > request/response cycle. So after more information about the request is > gathered (like ACLs stored on a particular object), swift calls the provided > authorize method with the new info and then the final authorization > determination is made. > > This approach sounds very similar to what Vish proposed, here instead of gathering "ACLs stored on a particular object", Quantum will check with Nova if the particular tenant has access to a specified VIF and then callback into Keystone for final authorization determination. Based on both of your suggestions, I feel that asking Nova if a particular VIF is owned by a particular tenant and then invoking a Keystone callback for the final authorization decision seems to be the way to go at this point. > Perhaps a similar approach could be used for other services. > > *Oh, and as a point of (boastful) clarification, swift will be storing > billions of objects, not millions. ;-) > > --John > > > > >> > >> Depending on Keystone's roadmap and plans, we could take a 2 phased > approach, where Nova doing AuthZ is a temporary solution till Keystone can > do it or if Keystone is not going to have this capability, then we go down > the path you are suggesting - Keystone does AuthN and we rely on Nova to > authorize a tenant's access rights to a particular vif. > >> > >> Thanks, > >> Somik > > > > ___ > > Mailing list: https://launchpad.net/~openstack > > Post to : openstack@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > -- Somik Behera | Nicira Networks, Inc. | so...@nicira.com | office: 650-390-6790 | cell: 512-577-6645 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] nova cloud controller and compute issues Diablo v3
I recently deployed a couple of test servers for Nova; I'm using Diablo v3
(http://wiki.openstack.org/NovaInstall/RHEL6Notes-Diablo-3) on RHEL v6; here
are my current issues:
On the Cloud Controller node I can launch instances and I'm able to ping
them but they don't come up cleanly because they're unable to connect to the
169.254.169.254 host via HTTP for metadata
cloud-setup: checking
http://169.254.169.254/2009-04-04/meta-data/instance-id
wget: can't connect to remote host (169.254.169.254): Connection timed out
cloud-setup: failed 1/30: up 1.38. request failed
I've tried various IPTables settings but still no go.
On the compute only node (1st one of hopefully many); I have larger issues:
I haven't figured out how to successfully change the bridge interface for
br100; my network uses eth0 for the monitoring/admin NW and I can't change
that. I was able to change it OK for the cloud controller via the settings
for the network.
Also, when instances try to run on the compute node I receive the errors
below; also I see that the kernel files out in the instances sub-directories
are 0 byte files:
./instance-000b:
total 4124
-rw-r--r-- 1 root root 0 Aug 17 23:28 ramdisk
-rw-r--r-- 1 nova nobody1704 Aug 17 23:28 libvirt.xml
-rw-r--r-- 1 root root 0 Aug 17 23:28 kernel
-rw-r--r-- 1 root root 6291456 Aug 17 23:28 disk
drwxr-xr-x 2 nova nobody4096 Aug 17 23:28 .
-rw-r- 1 root root 0 Aug 17 23:29 console.logdrwxr-xr-x 7 nova
nobody4096 Aug 18 18:12 ..
2011-08-18 18:10:46,058 nova: called setup_basic_filtering in nwfilter
2011-08-18 18:10:46,059 nova: ensuring static filters
2011-08-18 18:10:46,194 nova.virt.libvirt_conn: instance instance-001c:
Creating image
2011-08-18 18:10:46,292 nova.virt.libvirt_conn: instance instance-001c:
injecting key into image 3
2011-08-18 18:11:00,652 nova.compute.disk: list index out of range
(nova.compute.disk): TRACE: Traceback (most recent call last):
(nova.compute.disk): TRACE: File
"/usr/lib/python2.6/site-packages/nova/virt/disk.py", line 82, in
inject_data
(nova.compute.disk): TRACE: device = devices[0]
(nova.compute.disk): TRACE: IndexError: list index out of range
(nova.compute.disk): TRACE:
2011-08-18 18:11:00,750 nova.virt.libvirt_conn: instance instance-001c:
ignoring error injecting data into image 3 (list index out of range)
2011-08-18 18:11:01,541 nova.exception: Uncaught exception
(nova.exception): TRACE: Traceback (most recent call last):
(nova.exception): TRACE: File
"/usr/lib/python2.6/site-packages/nova/exception.py", line 97, in wrapped
(nova.exception): TRACE: return f(*args, **kw)
(nova.exception): TRACE: File
"/usr/lib/python2.6/site-packages/nova/virt/libvirt/connection.py", line
582, in spawn
(nova.exception): TRACE: domain = self._create_new_domain(xml)
(nova.exception): TRACE: File
"/usr/lib/python2.6/site-packages/nova/virt/libvirt/connection.py", line
1048, in _create_new_domain
(nova.exception): TRACE: domain.createWithFlags(launch_flags)
(nova.exception): TRACE: File
"/usr/lib64/python2.6/site-packages/libvirt.py", line 337, in
createWithFlags
(nova.exception): TRACE: if ret == -1: raise libvirtError
('virDomainCreateWithFlags() failed', dom=self)
(nova.exception): TRACE: libvirtError: internal error Process exited while
reading console log output: char device redirected to /dev/pts/0
(nova.exception): TRACE: qemu: could not load kernel
'/var/lib/nova/instances/instance-001c/kernel': Inappropriate ioctl for
device
(nova.exception): TRACE:
(nova.exception): TRACE:
2011-08-18 18:11:01,542 nova.compute.manager: Instance '28' failed to spawn.
Is virtualization enabled in the BIOS? Details: internal error Process
exited while reading console log output: char device redirected to
/dev/pts/0
qemu: could not load kernel
'/var/lib/nova/instances/instance-001c/kernel': Inappropriate ioctl for
device
(nova.compute.manager): TRACE: Traceback (most recent call last):
(nova.compute.manager): TRACE: File
"/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 355, in
_run_instance
(nova.compute.manager): TRACE: self.driver.spawn(instance, network_info,
bd_mapping)
(nova.compute.manager): TRACE: File
"/usr/lib/python2.6/site-packages/nova/exception.py", line 124, in wrapped
(nova.compute.manager): TRACE: raise Error(str(e))
(nova.compute.manager): TRACE: Error: internal error Process exited while
reading console log output: char device redirected to /dev/pts/0
(nova.compute.manager): TRACE: qemu: could not load kernel
'/var/lib/nova/instances/instance-001c/kernel': Inappropriate ioctl for
device
(nova.compute.manager): TRACE:
(nova.compute.manager): TRACE:
Any help would be greatly appreciated; next step is digging into the source
but I want to make sure I'm setting the environment up correctly 1st.
-Steve
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Re: [Openstack] High availability in openstack?
On 08/16/2011 04:50 PM, Joshua Harlow wrote: Are there any good documentations on making openstack fault tolerant or exactly how it will handle failures? Like say the mq server dies, can another mq server take over. Similar with the database (mysql replication?) Seems like having that kind of information for corporate users would be nice, at least a recommended “guide”. -Josh ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Josh I have a very bare bones start of a doc on making parts of Nova HA. The problem is this document is no where near ready for release as I am probably the only person who can understand it. I will try to point you in the right direction on things I have done that work pretty well. Rabbitmq http://www.rabbitmq.com/pacemaker.html Right now in the version of Nova the team I am working with nothing is marked 'persistent'. Right now in this use case if a node fails rabbitmq moves over and all the managers reconnect with no issues but all in flight messages are lost. Maybe someone here can clarify on the direction of this. I we are using Ubuntu 10.04 and the version of Rabbitmq in that release does not have the pacemaker scripts, I just pulled the current package from rabbitmq.com apt repo after that the pacemaker setup worked perfect. MySQL For MySQL I just did a simple setup using DRDB to replicate /var/lib/mysql and setup corosync/pacemaker to manage all the MySQL resources between two nodes. Again with this situation in failover I had no issues with clients reconnecting to the vip. I hope this points you in the right direction, I know its not exactly what you wanted. Maybe next week I can clean up my documentation and send it out to the list. Edward Konetzko ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] High availability in openstack?
Thanks, It was along the lines of what I was thinking. If messages are made persistent, which I hope is planned, or made a configuration option what would be the effects of them not being made persistent. Right now if a message is lost, it seems the DB/other nodes are left in a bad state, is there any plan to have a "reaper" python object that will reap this bad data/instances On 8/18/11 4:54 PM, "Edward "koko" Konetzko" wrote: On 08/16/2011 04:50 PM, Joshua Harlow wrote: > Are there any good documentations on making openstack fault tolerant or > exactly how it will handle failures? > > Like say the mq server dies, can another mq server take over. Similar > with the database (mysql replication?) > > Seems like having that kind of information for corporate users would be > nice, at least a recommended "guide". > > -Josh > > > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp Josh I have a very bare bones start of a doc on making parts of Nova HA. The problem is this document is no where near ready for release as I am probably the only person who can understand it. I will try to point you in the right direction on things I have done that work pretty well. Rabbitmq http://www.rabbitmq.com/pacemaker.html Right now in the version of Nova the team I am working with nothing is marked 'persistent'. Right now in this use case if a node fails rabbitmq moves over and all the managers reconnect with no issues but all in flight messages are lost. Maybe someone here can clarify on the direction of this. I we are using Ubuntu 10.04 and the version of Rabbitmq in that release does not have the pacemaker scripts, I just pulled the current package from rabbitmq.com apt repo after that the pacemaker setup worked perfect. MySQL For MySQL I just did a simple setup using DRDB to replicate /var/lib/mysql and setup corosync/pacemaker to manage all the MySQL resources between two nodes. Again with this situation in failover I had no issues with clients reconnecting to the vip. I hope this points you in the right direction, I know its not exactly what you wanted. Maybe next week I can clean up my documentation and send it out to the list. Edward Konetzko ___ 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
[Openstack] Ubuntu run instance error + xen
Hi all, On xen + openstack diaboli-3 when running an instance with the generic ubuntu UEC images from http://wiki.openstack.org/RunningNova#Registering_the_image I am seeing the following: [0.210681] VFS: Cannot open root device "xvda" or unknown-block(0,0) [0.210691] Please append a correct "root=" boot option; here are the available partitions: [0.210708] ca008192 sda driver: vbd [0.210720] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) This is on debian 6 (x86-64), is this a location that exists for others? Here is the xml that was used to create this instance. It looks pretty standard. Any xen users out there encountered this? instance-002b a1655436-d1c6-3e2c-bf57-a9c487f21e27 524288 524288 1 linux /home/ctoteam/nova/nova/..//instances/instance-002b/kernel root=/dev/xvda ro destroy restart destroy /usr/lib/xen-4.0/bin/qemu-dm ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] AuthZ functionality in Keystone - Re: [WAS]OpenStack Identity: Keystone API Proposal
Agreed. My suggestion (in a direct email to Jan) was:
1. A tenant (Tenant-X) has resources in Nova (VM1)
GET nova/Tenant-X/servers/VM1returns {name: VM1, interface:
instance-0001-eth0 }
2. A user (john) creates a network in Quantum (or in Nova? Or in Quantum
through Nova?)
POST nova/Tenant-X/networks returns {name: Network-A}
Or
POST quantum/Tenant-X/networks returns {name: Network-A}
Here, Quantum should store the network under the tenant (although you
may
choose to track that in some other way).
3. Per your use case below:
2.1 OK
2.2 This would need a call to Nova. Only Nova knows whether
instance-0001-eth0 belongs to Tenant-X
GET
nova/tenants/Tenant-X/servers/VM1/interfaces/instance-0001-eth0
returns 200
2.3 Who creates the role "plug_virtual_interface"? It sounds like this
should be a role created by Quantum (therefore
"quantum:plug_virtual_interface") and the user should have that role on
that tenant
GET or HEAD
keystone/tenants/Tenant-X/users/john/roles/quantum:plug_virtual_interface
returns 200
I would not advocate creating a role for each resource. Such fine-grained
authz should probably live in the service (and not in Keystone at least
not today)
Z
On 8/18/11 5:50 PM, "Vishvananda Ishaya" wrote:
>
>On Aug 18, 2011, at 3:45 PM, Somik Behera wrote:
>
>> Hi Vish,
>>
>> That would be one very reasonable way to do it, but in that case we are
>>fragmenting AuthZ in multiple services instead of Keystone taking care
>>of AuthZ across all services.
>
>We can't necessarily depend on keystone to keep track of all objects
>owned by each service. Especially for things like swift where millions
>of objects are involved. I therefore think the right solution is to have
>the services responsible for their own objects, and allow them to
>delegate to keystone in the cases where it makes sense.
>
>>
>> Depending on Keystone's roadmap and plans, we could take a 2 phased
>>approach, where Nova doing AuthZ is a temporary solution till Keystone
>>can do it or if Keystone is not going to have this capability, then we
>>go down the path you are suggesting - Keystone does AuthN and we rely on
>>Nova to authorize a tenant's access rights to a particular vif.
>>
>> Thanks,
>> Somik
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova cloud controller and compute issues Diablo v3
Any reason for trying out over RHEL having so many good distros out there ?
:P
Injection issues are pretty common under RH, but first off all, you have
metadata fetching issues, AND do you have a VT capable processor on the
compute node ?, first you need to check that, and enable on the advanced
options of the BIOS, then you have to
In the COMPUTEs node you need to add this RULE :
iptables -t nat -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80
-j DNAT --to-destination YOURCONTROLLERIP:8773
You dont need to add a rule on the controller node . To change the br100 you
have to change it on the database
Regards
:
On Thu, Aug 18, 2011 at 8:32 PM, Steve Eastham wrote:
> I recently deployed a couple of test servers for Nova; I'm using Diablo
> v3 (http://wiki.openstack.org/NovaInstall/RHEL6Notes-Diablo-3) on RHEL
> v6; here are my current issues:
>
> On the Cloud Controller node I can launch instances and I'm able to ping
> them but they don't come up cleanly because they're unable to connect to the
> 169.254.169.254 host via HTTP for metadata
>
> cloud-setup: checking
> http://169.254.169.254/2009-04-04/meta-data/instance-id
> wget: can't connect to remote host (169.254.169.254): Connection timed out
> cloud-setup: failed 1/30: up 1.38. request failed
>
> I've tried various IPTables settings but still no go.
>
> On the compute only node (1st one of hopefully many); I have larger issues:
>
> I haven't figured out how to successfully change the bridge interface for
> br100; my network uses eth0 for the monitoring/admin NW and I can't change
> that. I was able to change it OK for the cloud controller via the settings
> for the network.
> Also, when instances try to run on the compute node I receive the errors
> below; also I see that the kernel files out in the instances sub-directories
> are 0 byte files:
>
> ./instance-000b:
> total 4124
> -rw-r--r-- 1 root root 0 Aug 17 23:28 ramdisk
> -rw-r--r-- 1 nova nobody1704 Aug 17 23:28 libvirt.xml
> -rw-r--r-- 1 root root 0 Aug 17 23:28 kernel
> -rw-r--r-- 1 root root 6291456 Aug 17 23:28 disk
> drwxr-xr-x 2 nova nobody4096 Aug 17 23:28 .
> -rw-r- 1 root root 0 Aug 17 23:29 console.logdrwxr-xr-x 7 nova
> nobody4096 Aug 18 18:12 ..
>
> 2011-08-18 18:10:46,058 nova: called setup_basic_filtering in nwfilter
> 2011-08-18 18:10:46,059 nova: ensuring static filters
> 2011-08-18 18:10:46,194 nova.virt.libvirt_conn: instance instance-001c:
> Creating image
> 2011-08-18 18:10:46,292 nova.virt.libvirt_conn: instance instance-001c:
> injecting key into image 3
> 2011-08-18 18:11:00,652 nova.compute.disk: list index out of range
> (nova.compute.disk): TRACE: Traceback (most recent call last):
> (nova.compute.disk): TRACE: File
> "/usr/lib/python2.6/site-packages/nova/virt/disk.py", line 82, in
> inject_data
> (nova.compute.disk): TRACE: device = devices[0]
> (nova.compute.disk): TRACE: IndexError: list index out of range
> (nova.compute.disk): TRACE:
> 2011-08-18 18:11:00,750 nova.virt.libvirt_conn: instance instance-001c:
> ignoring error injecting data into image 3 (list index out of range)
> 2011-08-18 18:11:01,541 nova.exception: Uncaught exception
> (nova.exception): TRACE: Traceback (most recent call last):
> (nova.exception): TRACE: File
> "/usr/lib/python2.6/site-packages/nova/exception.py", line 97, in wrapped
> (nova.exception): TRACE: return f(*args, **kw)
> (nova.exception): TRACE: File
> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/connection.py", line
> 582, in spawn
> (nova.exception): TRACE: domain = self._create_new_domain(xml)
> (nova.exception): TRACE: File
> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/connection.py", line
> 1048, in _create_new_domain
> (nova.exception): TRACE: domain.createWithFlags(launch_flags)
> (nova.exception): TRACE: File
> "/usr/lib64/python2.6/site-packages/libvirt.py", line 337, in
> createWithFlags
> (nova.exception): TRACE: if ret == -1: raise libvirtError
> ('virDomainCreateWithFlags() failed', dom=self)
> (nova.exception): TRACE: libvirtError: internal error Process exited while
> reading console log output: char device redirected to /dev/pts/0
> (nova.exception): TRACE: qemu: could not load kernel
> '/var/lib/nova/instances/instance-001c/kernel': Inappropriate ioctl for
> device
> (nova.exception): TRACE:
> (nova.exception): TRACE:
> 2011-08-18 18:11:01,542 nova.compute.manager: Instance '28' failed to
> spawn. Is virtualization enabled in the BIOS? Details: internal error
> Process exited while reading console log output: char device redirected to
> /dev/pts/0
> qemu: could not load kernel
> '/var/lib/nova/instances/instance-001c/kernel': Inappropriate ioctl for
> device
> (nova.compute.manager): TRACE: Traceback (most recent call last):
> (nova.compute.manager): TRACE: File
> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 355, in
> _run_instance
> (nova.compute.manager): TRACE:
Re: [Openstack] Ubuntu run instance error + xen
It looks you specified "root=/dev/xvda", but the disk that is instantiated is /dev/sda. But I didn't see why it happened. Did you customized the template for libvirt, libvirt.xml.template? On Thu, Aug 18, 2011 at 05:54:45PM -0700, Joshua Harlow wrote: > Hi all, > > On xen + openstack diaboli-3 when running an instance with the generic ubuntu > UEC images from http://wiki.openstack.org/RunningNova#Registering_the_image > I > am seeing the following: > > [0.210681] VFS: Cannot open root device "xvda" or unknown-block(0,0) > [0.210691] Please append a correct "root=" boot option; here are the > available partitions: > [0.210708] ca008192 sda driver: vbd > [0.210720] Kernel panic - not syncing: VFS: Unable to mount root fs on > unknown-block(0,0) > > This is on debian 6 (x86-64), is this a location that exists for others? > > Here is the xml that was used to create this instance. It looks pretty > standard. Any xen users out there encountered this? > > > instance-002b > a1655436-d1c6-3e2c-bf57-a9c487f21e27 > 524288 > 524288 > 1 > > > linux > /home/ctoteam/nova/nova/..//instances/instance-002b/kernel kernel> > root=/dev/xvda ro > > > destroy > restart > destroy > > /usr/lib/xen-4.0/bin/qemu-dm > > > > > > > > > > > > > > > > > 'en-us'/> > > > > > > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp -- yamahata ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
