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 w
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
o
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?)
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
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
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
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'
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 m
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
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
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 tra
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 qu
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
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 woul
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, Salvator
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=
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
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 typicall
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
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/cobe
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
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 t
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 e
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
24 matches
Mail list logo
