** Branch linked: lp:~kiall/nova/fix-snapshot-id
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/962615
Title:
Unable to list volumes after building from snapshot
To manage
** Also affects: nova (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/939122
Title:
floating ips do not display in 'nova list'
I should probably have mentioned, nova checks these roles in a case
sensitive manor.
Using the wrong case means the roles simply will not work..
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to keystone in Ubuntu.
Public bug reported:
The recently merged packaging dbconfig uses Admin rather than admin
during role creation.
See: https://bugs.launchpad.net/devstack/+bug/919373 and
https://review.openstack.org/3229
** Affects: keystone (Ubuntu)
Importance: Undecided
Status: New
--
You
This is a nova bug all right, supplies the incorrect device name in the
ec2 metadata.
Nova supplies the following:
'block-device-mapping': {'ami': 'vda',
'root': '/dev/vda',
'swap': '/dev/vdc'},
When it should supply this:
I should mention, I believe the fix is for nova to ask for the device to
be attached at /dev/vdb when there is no ephemeral disk.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
** Also affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/912066
Title:
/etc/fstab contains incorrect device for swap
Libvirt XML: http://paste.ubuntu.com/807484/
Instance metadata: http://paste.ubuntu.com/807485/
$ ls /dev/vd*
/dev/vda /dev/vda1 /dev/vdb
$ cat /etc/fstab
# /etc/fstab: static file system information.
# file system mount point type
options dump
$ sudo blkid /dev/vdb
/dev/vdb: UUID=3447f2ad-9c81-4b95-ab3d-d5ff7aacbfa6 TYPE=swap
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/912066
Title:
/etc/fstab contains incorrect
Public bug reported:
On OpenStack using a flavor with no ephemeral storage, but with swap
space, cloud-init creates an invalid /etc/fstab
Given this favor (Note: Storage: 0GB and Swap: 2048MB):
p1.small: Memory: 3072MB, VCPUS: 4, Storage: 0GB, FlavorID: 15, Swap:
2048MB, RXTX Quota: 0GB, RXTX
Also, This is on the Oneiric cloud-image.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/912066
Title:
/etc/fstab contains incorrect device for swap partition when no
Okay - I've managed to get about 24 hours without a panic! (With the
stock oneiric packages ie 3.0 kernel etc)
To fix this issue, I purged all OpenStack components, Wiped the
OpenStack database and re-installed.
I say fix because obviously the Oops should never have occurred at
all, regardless
** Also affects: kvm
Importance: Undecided
Status: New
** Also affects: kvm (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to kvm in Ubuntu.
Just tested with the mainline 3.0.6-030006-generic kernel, still
panicking...
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0.6-oneiric/linux-
image-3.0.6-030006-generic_3.0.6-030006.201110050043_amd64.deb
and ...
Just tested with the mainline 3.1.0-0301rc9-generic kernel, this kernel
after
Damn - 3.1.0-0301rc9-generic lasted *much* longer, but eventually ended
with another Oops...
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to kvm in Ubuntu.
https://bugs.launchpad.net/bugs/870168
Title:
Kernel Oops - Oneiric
++ We're building our own packages for IPv6 Support...
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to keepalived in Ubuntu.
https://bugs.launchpad.net/bugs/697601
Title:
Keepalived version bump to 1.2.1
--
Ubuntu-server-bugs
Its actually simpler than that :)
L1032 of net/vnetwork.c is
fprintf(fp, subnet %s netmask %s {\n option subnet-mask %s;\n option
broadc .
change it to ..
fprintf(fp, subnet %s netmask %s {\n option domain-name
\eucalyptus.internal\;\n option subnet-mask %s;\n option broadc ...
and
Also re (I'm using the CLC private IP, because when using the public
IP, the returning packets are from the local address, and dns doesn't
like it.) ..
Thats a mix of two issues i think ..
Lets say your instance FQDN is euca-172-19-1-2.eucalyptus.internal /
Aha - I didn't noticed it was /etc/dhcp3/dhclient.conf you were editing,
rather than /etc/resolv.conf
Re the change to net/vnetwork.c .. The only config option that would
require that line to change (when DNS is delegated correctly) is when
DISABLE_DNS=Y it should use the original version .. No
I believe this is the same issue as
https://bugs.launchpad.net/eucalyptus/+bug/676167
I've been told that issue is fixed in the nightly builds..
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
I should have also mentioned - the Ghost instance (i-307905AD) was a
real instance that had been terminated, possibly before it had left the
pending state.
--
Ghost instance using a slot + elastic IP
https://bugs.launchpad.net/bugs/676832
You received this bug notification because you are a
Public bug reported:
Assuming the username kiall and security group app the XML responses
differ between DescribeInstances and RunInstances. Attached are the full
XML responses.
Describe Instances Response shows:
groupSet
item
groupIdapp/groupId
/item
** Attachment added: DescribeInstancesResponse
https://bugs.launchpad.net/bugs/676721/+attachment/1736591/+files/DescribeInstancesResponse.txt
--
Security Group names differ between DescribeInstancesResponse and
RunInstancesResponse API calls
https://bugs.launchpad.net/bugs/676721
You
** Attachment added: RunInstancesResponse
https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/676721/+attachment/1736596/+files/RunInstancesResponse.txt
** Also affects: eucalyptus
Importance: Undecided
Status: New
--
Security Group names differ between
Public bug reported:
Attaching a volume to a pending instance claims success (via
euca2ools, and the API) but never attaches to the instance. This may be
a KVM only issue.
As its pretty easy to reproduce, I haven't attached much in the way of
detail - let me know if you need any specific info.
** Description changed:
Attaching a volume to a pending instance claims success (via
euca2ools, and the API) but never attaches to the instance. This may be
a KVM only issue.
As its pretty easy to reproduce, I haven't attached much in the way of
detail - let me know if you need any
AVAILABILITYZONE|- m1.xlarge / 4 15360 5
AVAILABILITYZONE|- c1.xlarge / 8 15361 5
ki...@wk08-lmst:~/Desktop/CloudConfig$ euca-describe-instances
RESERVATION r-371406C3 kiall phostr-app
INSTANCEi-456F080E emi-077E15DD
** Attachment added: NC axis2c.log
https://bugs.launchpad.net/bugs/676832/+attachment/1736917/+files/axis2c.log
--
Ghost instance using a slot + elastic IP
https://bugs.launchpad.net/bugs/676832
You received this bug notification because you are a member of Ubuntu
Server Team, which is
** Attachment added: NC euca_test_nc.log
https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/676832/+attachment/1736927/+files/euca_test_nc.log
--
Ghost instance using a slot + elastic IP
https://bugs.launchpad.net/bugs/676832
You received this bug notification because you are a
** Attachment added: NC httpd-nc_error_log
https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/676832/+attachment/1736936/+files/httpd-nc_error_log
--
Ghost instance using a slot + elastic IP
https://bugs.launchpad.net/bugs/676832
You received this bug notification because you are a
** Attachment added: NC nc.log
https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/676832/+attachment/1736937/+files/nc.log
** Also affects: eucalyptus
Importance: Undecided
Status: New
--
Ghost instance using a slot + elastic IP
https://bugs.launchpad.net/bugs/676832
You
`service eucalyptus-(nc|walrus|sc|cloud|cc) restart` each had no
effect...
`service eucalyptus restart` free'd the IP..
--
Ghost instance using a slot + elastic IP
https://bugs.launchpad.net/bugs/676832
You received this bug notification because you are a member of Ubuntu
Server Team, which is
** Description changed:
+
+ Impact statement: This bug causes several issues warranting a fix in
maverick/lucid
+
+ A) Prevents correct communication between instances (eg icmp-reply from priv
IP when pub IP was ping'd)
+ B) Blocks communication to the local instance via its public ip
+
Public bug reported:
Ubuntu 10.10 / eucalyptus-2.0+bzr1241-0ubuntu4 / amd64
After setting USE_VIRTIO_DISK=1 (the default actually..) in
/etc/eucalyptus/eucalyptus.conf and performing a clean restart virtio is
not used while attaching an EBS volume.
I discovered this due to a related bug
** Patch added: My *dirty* patch that intentionally breaks correct behavior in
order to verify the wrong branch of the if/else was being executed
https://bugs.launchpad.net/bugs/673445/+attachment/1728847/+files/euca.diff
--
USE_VIRTIO_DISK config option ignored for EBS volumes
And .. As always with filing a bug. I just noticed a mistake on my part!
L436 of node/handlers_kvm.c forces the use of a non-virtio mount thanks
to me specifying a sdX device name rather than vdX .. I'll dig around
for the close button!
--
USE_VIRTIO_DISK config option ignored for EBS volumes
Yes - 100% sure.
I've since discovered that using /dev/vdX works without a reboot, while
/dev/sdX does not work until after a reboot!
vdX triggers the use of virtio, while sdX uses the standard method ..
whatever that is! I stopped digging once i got it working with vdX :)
--
dynamic block
@Wolfgang: Yes - Specifying, for example, /dev/vda triggers the use of
virtio over the standard - and works exactly as you would expect EBS
volumes to :)
There *is* still a bug preventing /dev/sdX from working .. but I've sank
too much time into finding it at the moment, I'll probably dig in
@Wolfgang I believe this is still an issue in maverick/10.10 aswell. I
can attach a volume with UEC (10.10 metal and 10.10 instance).
If you issue a `shutdown -r now` within the instance, the volume will be
attached after the reboot... just spent about 8 hours getting that far!
--
dynamic block
39 matches
Mail list logo
