I've seen this issue exactly when running openstack in a vm. There is a line
of code in the cloud init script in the ttylinux image which checks its
processor speed and disables generating keys and starting sshd if it is too
low. If you feel comfortable mounting and hacking the image you can d
Hi,
The weird thing is that I seem to be *almost* the only person having this
problem - googling around I came across just one other person reporting exactly
this same issue.
Anyway thanks for the feedback, see some remarks below.
On Aug 26, 2011, at 4:37 PM, Scott Moser wrote:
> On Fri, 26
On Fri, 26 Aug 2011, Leo van den Bulck wrote:
> Hi,
>
> Talking about cloud-init and Ubuntu instances... I have a problem related to
> that part which I can't really reproduce reliably.
>
> When spinning up an Ubuntu "tty" image, I'm often seeing this, during the
> cloud-init/cloud-setup phase:
Hi,
Talking about cloud-init and Ubuntu instances... I have a problem related to
that part which I can't really reproduce reliably.
When spinning up an Ubuntu "tty" image, I'm often seeing this, during the
cloud-init/cloud-setup phase:
cloud-setup: cloudinit: getting ssh keys: [0=test]
stty: /
On Thu, 18 Aug 2011, 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
On Fri, 19 Aug 2011, Joshua Harlow wrote:
> Begin: Running /scripts/init-bottom ... done.
> [1.348832] EXT4-fs (sda1): re-mounted. Opts: (null)
> cloud-init start-local running: Fri, 19 Aug 2011 21:34:59 +. up 4.01
> seconds
> no instance data found in start-local
> init: cloud-init-local
On Mon, 22 Aug 2011 12:10:59 -0700
Joshua Harlow wrote:
> Here is also the libvirt.xml section that might be useful:
>
> $ more instance-0033/libvirt.xml
>
> instance-0033
> 524288
>
> linux
> /dev/xvda
>
> /home/ctoteam/nova/nova/..//in
Here is also the libvirt.xml section that might be useful:
$ more instance-0033/libvirt.xml
instance-0033
524288
linux
/dev/xvda
/home/ctoteam/nova/nova/..//instances/instance-0033/kernel
ro
Attempting to follow your notes.
I have the following ubuntu kernel.
Linux version 2.6.35-24-virtual
This is just a standard ubuntu UEC image.
With command line options.
Command line: root=/dev/xvda ro
I've got a dom0 running with the following.
menuentry 'Debian GNU/Linux, with Linux 2.6.32
Sounds good.
I'll check it out.
Would this still be needed in the libvirt template?
/usr/lib/xen-4.0/bin/pygrub
On 8/20/11 6:53 AM, "Thomas Goirand" wrote:
On 08/20/2011 05:40 AM, Joshua Harlow wrote:
> So what I've figured out is the following seems to work with xen4.
The naming of sda vs x
On 08/20/2011 05:40 AM, Joshua Harlow wrote:
> So what I’ve figured out is the following seems to work with xen4.
The naming of sda vs xvda has nothing to do with the hypervisor, and a
lot to do with your kernel.
Thomas
___
Mailing list: https://launc
On 08/20/2011 01:26 AM, Joshua Harlow wrote:
> Ok but I am going through libvirt instead of xenapi since I am just
> using a debian + xen-hypervisor package.
>
> Also going through libvirt seems to be better, since it doesn’t make
> your setup as “strongly” connected to xen.
>
> For those using t
On 08/20/2011 01:52 AM, Joshua Harlow wrote:
> For my nova/virt/libvirt.xml.template on my compute node.
>
> The following is being done.
>
> #if $type == 'xen'
> #set $disk_prefix = 'sd'
> #set $disk_bus = 'scsi'
> linux
> /dev/xvda
>
> Should that be /
So what I've figured out is the following seems to work with xen4.
$ diff nova-2011.3/nova/virt/libvirt.xml.template libvirt.xml.template
21c21
< /dev/xvda
---
> /dev/sda
46a47,49
> #if $type == 'xen'
> /usr/lib/xen-4.0/bin/pygrub
> #end if
62c65,69
<
For my nova/virt/libvirt.xml.template on my compute node.
The following is being done.
#if $type == 'xen'
#set $disk_prefix = 'sd'
#set $disk_bus = 'scsi'
linux
/dev/xvda
Should that be /dev/sda for the /root node here?
On 8/19/11 10:24 AM, "Joshua Harl
Ok but I am going through libvirt instead of xenapi since I am just using a
debian + xen-hypervisor package.
Also going through libvirt seems to be better, since it doesn't make your setup
as "strongly" connected to xen.
For those using the following in debian/ubunbu would the usage of the xena
Ya, that is what I was thinking also.
I haven't customized anything though. This is just the normal
euca-run-instances + basic openstack diablo-3.
$ euca-run-instances ami-001f -k mykey -t m1.tiny
Where ami is:
IMAGEami-001fubb/maverick-server-uec-amd64.img.manifest.xml
It looks like it was maverick, you can find a lot of good info here on xen,if
you're not using this already:
http://wiki.openstack.org/XenServerDevelopment
I believe the work around Vish is referring to is made in nova.conf:
--xenapi_remap_vbd_dev=true
Give that a go, hopefully gets you on your
There was an issue on one version of ubuntu (I think it was natty?), where xen
was using /dev/sd* instead of /dev/xd*. I remember discussion on the mailing
list or a bug about having to have a specific workaround.
On Aug 19, 2011, at 1:42 AM, Thomas Goirand wrote:
> On 08/19/2011 01:31 PM, Isa
On 08/19/2011 01:31 PM, Isaku Yamahata wrote:
> 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?
This seems wrong then, because under Xen, you should us
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
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
22 matches
Mail list logo
