** Changed in: eucalyptus
Assignee: (unassigned) = Daniel Nurmi (nurmi)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in Ubuntu.
https://bugs.launchpad.net/bugs/742443
Title:
cc looses database information after
This is a UEC upstart init script related issue; marking as invalid
against the eucalyptus upstream.
** Changed in: eucalyptus
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in Ubuntu.
** Changed in: euca2ools
Assignee: (unassigned) = Mitch Garnaat (mitch-garnaat)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to euca2ools in Ubuntu.
https://bugs.launchpad.net/bugs/850196
Title:
euca-describe-images crashed
** Changed in: eucalyptus
Status: Incomplete = Won't Fix
** Changed in: eucalyptus
Status: Won't Fix = Invalid
** Changed in: eucalyptus
Assignee: (unassigned) = Dmitrii Zagorodnov (dmitrii)
--
partition2disk error starting up an instance
Please see revno 1255 (latest) of Eucalyptus (lp:eucalyptus/2.0). That
branch should resolve java and C compilation issues for Natty. The C
compilation fix was twofold: re-arrange the gcc commandlines in various
Makefiles to put system library link options after local object options
(gcc *.c *.o
** Changed in: eucalyptus (Ubuntu Natty)
Assignee: (unassigned) = Daniel Nurmi (nurmi)
** Changed in: eucalyptus
Assignee: (unassigned) = Daniel Nurmi (nurmi)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus
This looks like another gcc linker option ordering issue. revno 1256 of
the eucalyptus branch contains a modified node/Makefile that should
resolve the problem (tested as a clean compile on natty):
root@ubuntu:~# ldd /usr/lib/axis2/services/EucalyptusNC/libEucalyptusNC.so
** Changed in: eucalyptus
Assignee: (unassigned) = chris grzegorczyk (chris-grze)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
https://bugs.launchpad.net/bugs/731702
Title:
euca-add-user adds a new
** Changed in: eucalyptus
Status: Incomplete = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
https://bugs.launchpad.net/bugs/470355
Title:
ec2-bundle-vol and ec2-upload-bundle result in
The part of the UEC that uses eucalyptus-ipaddr.conf is package
specific, and so we'll mark it as invalid against the upstream system.
** Changed in: eucalyptus
Status: New = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
** Changed in: eucalyptus
Status: New = Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
https://bugs.launchpad.net/bugs/476619
Title:
Networking problem in Eucalyptus when VNET_PUBLICIPS has an
It turns out that I had(ve) apparmor disabled while working on this
problem, but the new dhcpd needs a slight change to its profile in order
to work. Here is what I saw with apparmor enabled:
root@eucahost-4-243:/var/log/eucalyptus# dmesg
[ 800.347860] type=1400 audit(1300832242.358:24):
Carlos,
This is the message that was being thrown when the original problem was
cropping up; if you're still seeing this message with the patch
installed, then it (the patch) is not working properly. The server
should run even though there is no address in the config on the
10.55.55.0/24 subnet,
Carlos,
As a debugging aid, I've attached a stand-alone program that uses the
same loop as the patch for dhcpd: running it on the CC right after a
run-instances should result in output like this:
root@eucahost-4-243:~# gcc getifaddrs.c; ./a.out
INTERFACE=lo SCRUBBEDINTERFACE=lo ADDR=127.0.0.1
All,
I think I've found the problem all! So, looking at:
bzr branch lp:ubuntu/isc-dhcp
1.) the patch I've supplied is being placed at the end of the '00list' file in
debian/patches. not a problem normally i suspect, however:
2.) the patch is not present in the actual code that is being used
Public bug reported:
This report applies to Eucalyptus in Karmic
The default configuration file (/etc/eucalyptus/eucalyptus.conf) that is
installed by the UEC installer/eucalyptus-cc/eucalyptus-nc packages has
the networking mode (VNET_MODE) set to SYSTEM. In order to enable
security groups,
Public bug reported:
This applies to Eucalyptus in Karmic
the three java components (cloud controller, walrus, and storage
controller) share many common files, but the three services should be
split into three separate packages (right now, the 'eucalyptus-cloud'
package contains all three
Public bug reported:
This report applies to eucalyptus in Karmic
In order for the UEC/Eucalyptus to function right after install, the
nodes are required to have a bridge device set up to which a physical
ethernet device is attached (and, the device needs to be on the same
ethernet network on
Public bug reported:
The UEC installer asks the user for a cluster name upon installing the
front-end components, but this information is not propagated through to
the first boot, where the components are running and ready to be
registered. The manual process is currently:
one front-end:
Public bug reported:
In order for the 'Store' tab to populate with appliances, the appliance
store proxy service (package) will need to be installed, configured,
and running
** Affects: eucalyptus (Ubuntu)
Importance: Undecided
Status: New
--
Eucalyptus 'Store' tab requires
Public bug reported:
In order for security groups to work properly across two separate
clusters (each with their own potentially unroutable subnets), the CC on
each cluster uses vtund to set up layer two tunnels between the
clusters. The vtun pacakge is not a depndency of eucalyptus-cc as it is
Public bug reported:
The UEC installer configures only one interface (one can choose manually
which to configure), but eucalyptus needs more configuration if a front-
end is using more than one interface. For example, if 'eth0' is
connected to a public (user) facing network, and 'eth1' is
** Tags added: eucalyptus
--
Walrus cannot be registered using the Web UI
https://bugs.launchpad.net/bugs/426197
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Ubuntu-server-bugs mailing list
Public bug reported:
it appears that the libEucalyptusCC.so web service has been compiled
with new code (r645), but not against the generated code from the r645
eucalyptus_cc.wsdl. This causes the web service to fail when a
runInstances or describeInstances to crash the CC with:
eucalyptus-cloud is the bootloader for all three components - it is
shared by clc, walrus, and the sc
--
Eucalyptus Cloud Controller, Walrus and Storage controller services are all in
one package, should ideally be split into three
https://bugs.launchpad.net/bugs/425908
You received this bug
Public bug reported:
the 'eucalyptus-java-common' and 'eucalyptus-cloud' package are both
trying to install antlr.jar in /usr/share/eucalyptus:
r...@cc3:~# apt-cache policy eucalyptus-java-common
eucalyptus-java-common:
Installed: (none)
Candidate: 1.6~bzr672-0ubuntu2
Version table:
Public bug reported:
The axis2/c package currently in karmic (1.6.0-0ubuntu4) segfaults under
load, causing the eucalyptus CC to crash after a few minutes of uptime.
Currently, I have been unable to get a stacktrace when running in a
debugger. When axis2/c is configured from source with
I'm not sure that there is a good way to tell from a script whether they
have been registered, but I can say that the registration command is
idempotent. One can run 'euca_conf --register-walrus ip' many times,
and only the first time will have any effect (consecutive runs will
succeed, but the
Public bug reported:
Immediately after installing a UEC front-end (cluster), the next steps:
euca_conf --register-walrus ip of local machine
euca_conf --register-cc clusname ip of local machine
euca_conf --register-sc clusname ip of local machine
perform the registration of components, but
You will see this exception when one tries to use walrus (upload) before
the walrus service has been registered with the cloud controller. The
registration command (run on the cloud controller machine) is:
euca_conf --register-walrus ip of clc machine
--
Cannot upload bundle to Walrus
** Also affects: eucalyptus (Ubuntu)
Importance: Undecided
Status: New
--
'eucarc' in downloaded credentials zipfile does not contain 'EC2_USER_ID'
https://bugs.launchpad.net/bugs/426389
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Public bug reported:
The eucalyptus-cloud, -walrus, and -sc services all run as web services
under the same process if installed on the same machine. The init
scripts, upon 'start', check if the web service file exists, and the
process is running; if both are true, the init script does nothing
Public bug reported:
the eucalyptus init scripts create the:
/var/run/eucalyptus/*
directory(ies) on start, but do not correctly change the ownership of
the created directory(ies). The init scripts (for example eucalyptus-
cc) call /usr/sbin/euca_conf -check cc on startup:
if [ ! -d
I believe that there are two problems here; first, the latest
apparmor/libvirt is preventing the NC from being able to start VMs:
https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/431090
second, the 'nc-stat' error is caused by /var/run/eucalyptus directories
are not getting the right
Jamie, thank you for taking a look here. First, after your response,
I've been able to modify /etc/apparmor.d/abstractions/libvirt-qemu with
the following:
/var/lib/eucalyptus/instances/**/console.log w,
/var/lib/eucalyptus/instances/**/kernel r,
/var/lib/eucalyptus/instances/**/ramdisk
I've found one more runtime issue with the apparmor profile. Eucalyptus
can provide the ability to dynamically attach/detach block devices to
VMs at runtime using libvirt attach-disk/detach-disk. We currently use
AOE for dynamic block devices, and these appear on the node in:
/dev/etherd/e*
Public bug reported:
The version of KVM currently in karmic does not appear to have a fully
functional dynamic block device attach/detach:
outside VM:
---
r...@explorer:/root# virsh list
Connecting to uri: qemu:///system
Id Name
** Also affects: qemu-kvm
Importance: Undecided
Status: New
** Also affects: qemu-kvm (Ubuntu)
Importance: Undecided
Status: New
--
dynamic block device attach/detach not functional with karmic KVM
https://bugs.launchpad.net/bugs/432154
You received this bug notification
There is another bug, in KVM i suspect, that is preventing
attach/detach of block devices from fully working, however, you can see
some progress (logs indicating activity on the scsi bus in the VM when
you do an attach/detach):
https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/432154
--
I agree with Etienne on this issue; another thing to consider is that
many virtual appliances that are developed for EC2/UEC will be depending
on EBS functionality, due to the persistence observation made above.
--
dynamic block device attach/detach not functional with karmic KVM
(this process with the same
VM/kernel works on Jaunty). Apparmor is disabled.
--
Daniel Nurmi
Co-Founder, Engineer
Eucalyptus Systems, Inc.
130 Castilian Dr. | Goleta, CA | 93117
Office: 805-845-8000 | Cell: 805-259-5269
Email: nu...@eucalyptus.com
www.eucalyptus.com
fully addressed in revno 593
** Also affects: eucalyptus/1.6
Importance: Undecided
Status: New
** Changed in: eucalyptus/1.6
Status: New = Fix Committed
** Changed in: eucalyptus/1.6
Importance: Undecided = High
--
SC registration through web UI fails
fixed in revno 892
--
Part of storage controller setup that should run as the eucalyptus user runs as
root
https://bugs.launchpad.net/bugs/436276
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
If anyone can reproduce this issue, we'll need the logfiles:
/var/log/eucalyptus/cloud-*
in order to diagnose the core issue.
Thank you
--
500 server error when attempting to register ramdisk image
https://bugs.launchpad.net/bugs/428188
You received this bug notification because you are a
** Changed in: eucalyptus/1.6
Status: New = Fix Committed
--
over time, c3p0 causes deadlock condition in CLC
https://bugs.launchpad.net/bugs/436885
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
** Changed in: eucalyptus/1.6
Importance: Undecided = Medium
** Changed in: eucalyptus/1.6
Status: New = Confirmed
--
'eucarc' in downloaded credentials zipfile does not contain 'EC2_USER_ID'
https://bugs.launchpad.net/bugs/426389
You received this bug notification because you are a
** Also affects: eucalyptus/1.6
Importance: Undecided
Status: New
** Changed in: eucalyptus/1.6
Status: New = Fix Committed
** Changed in: eucalyptus/1.6
Importance: Undecided = Critical
--
SYSTEM mode, instances do not run
https://bugs.launchpad.net/bugs/430957
You
This problem is fixed in eucalyptus 1.6 revnos = 760
--
In MANAGED mode, with CLC and CC on same host, on first boot of CLC, Walrus URL
is detected as 169.254.169.254
https://bugs.launchpad.net/bugs/385435
You received this bug notification because you are a member of Ubuntu
Server Team, which
This issue was addressed in Eucalytpus revno 768, and as such should
already be in latest karmic package (854)
** Changed in: eucalyptus (Ubuntu)
Status: Confirmed = Fix Released
--
Invalid S3_URL and EC2_URL in eucarc
https://bugs.launchpad.net/bugs/429734
You received this bug
This issue was resolved in Eucalyptus revnos 754-758, which addressed
multiple register/de-register issues.
--
euca_conf --register-sc returns success even though it fails
https://bugs.launchpad.net/bugs/431832
You received this bug notification because you are a member of Ubuntu
Server Team,
I think there may be some confusion here; the original bug, as we
understood it, was that an administrator could not add a user unless
email was configured and working properly (i.e., every addition of a
user required the system to send an email to the user, for the user to
repond, and for the
all, here is as much information as I could think of in an attempt to
allow for reproducability (see attached file). Here is what each file
in the attached tarball contains:
setup - quick description of machine set up
orig.libvirt.xml - the XML vm description that is passed to libvirt
all, here is as much information as I could think of in an attempt to
allow for reproducability (see attached file). Here is what each file
in the attached tarball contains:
setup - quick description of machine set up
orig.libvirt.xml - the XML vm description that is passed to libvirt
Public bug reported:
When installing a UEC node (from server iso 09272009.1), I'm finding
that the bridge device that is defined in /etc/network/interfaces never
comes up on machine boot. contents of /etc/network/interfaces looks
correct:
---
# This file describes the
** Attachment added: libvirtd-issue.tgz
http://launchpadlibrarian.net/32683674/libvirtd-issue.tgz
** Also affects: eucalyptus (Ubuntu)
Importance: Undecided
Status: New
** Tags added: eucalyptus
--
libvirtd is leaking file descriptors to /var/log/libvirt/qemu/vmid.log
Public bug reported:
It looks like the libvirtd daemon is leaking file descriptors to the
logfile that it sets up for each VM. I've attached a typescript showing
the symptom (start vm, inspect lsof, stop vm, inspect lsof, start vm,
inspect lsof, stop vm, inspect lsof), note that the descriptors
Is it possible that, at some point, a walrus registration was attempted
with 'localhost'? If so, you'll need to deregister walrus:
euca_conf --deregister-walrus
and try registering again with a valid public IP. This error is
implying that the system believes that a registered walrus lives on
** Changed in: eucalyptus (Ubuntu Karmic)
Status: Triaged = In Progress
** Changed in: eucalyptus (Ubuntu Karmic)
Assignee: (unassigned) = Dustin Kirkland (kirkland)
--
over time, c3p0 causes deadlock condition in CLC (database borkage)
https://bugs.launchpad.net/bugs/436885
You
** Changed in: eucalyptus (Ubuntu Karmic)
Assignee: (unassigned) = Dustin Kirkland (kirkland)
** Changed in: eucalyptus (Ubuntu Karmic)
Status: Triaged = In Progress
--
if apache2 is using worker MPM, rampart causing periodic CC segfaults
https://bugs.launchpad.net/bugs/436407
You
** Changed in: eucalyptus (Ubuntu)
Assignee: (unassigned) = Dustin Kirkland (kirkland)
** Changed in: eucalyptus (Ubuntu)
Status: Triaged = In Progress
--
Part of storage controller setup that should run as the eucalyptus user runs as
root
https://bugs.launchpad.net/bugs/436276
You
** Changed in: eucalyptus (Ubuntu)
Status: Triaged = In Progress
** Changed in: eucalyptus (Ubuntu)
Assignee: (unassigned) = Dustin Kirkland (kirkland)
--
SYSTEM mode, instances do not run
https://bugs.launchpad.net/bugs/430957
You received this bug notification because you are a
** Changed in: eucalyptus (Ubuntu Karmic)
Assignee: (unassigned) = Dustin Kirkland (kirkland)
** Changed in: eucalyptus (Ubuntu Karmic)
Status: Triaged = In Progress
--
Eucalyptus restart is needed after autoregistration of components
https://bugs.launchpad.net/bugs/439251
You
** Changed in: eucalyptus (Ubuntu)
Status: Triaged = In Progress
** Changed in: eucalyptus (Ubuntu)
Assignee: (unassigned) = Dustin Kirkland (kirkland)
--
External command failure not handled correctly in some cases
https://bugs.launchpad.net/bugs/440744
You received this bug
** Changed in: eucalyptus (Ubuntu Karmic)
Status: Triaged = In Progress
** Changed in: eucalyptus (Ubuntu Karmic)
Assignee: (unassigned) = Dustin Kirkland (kirkland)
--
excessive number of CLC sockets to the backend cause the system to stop
updating state
** Changed in: eucalyptus
Status: Incomplete = Fix Released
--
euca-* commands stopped responding
https://bugs.launchpad.net/bugs/639639
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Ubuntu-server-bugs
** Also affects: eucalyptus
Importance: Undecided
Status: New
** Changed in: eucalyptus
Importance: Undecided = High
--
Instances from large, fresh EMIs fail to start just after being registered
https://bugs.launchpad.net/bugs/439410
You received this bug notification because you
The problem is that the connection from the NC to Walrus is being
successfully opened, but is being timed out on the server side after two
minutes if no data is written to the wire (which is the case when the
large image is being decrypted/cached). We've increased the retry count
in the NC to 10
My experiments with hot-attaching virtio disks to eucalyptus VMs have
been partially successful. I've been able to attach/detach a virtio
disk to/from a VM once, but the second attach causes a kvm segfault
followed by a libvirtd segfault. Removing eucalyptus from the scenario,
this problem can
Fixed in revno 925
--
Assignment of IP 169.254.169.254 on CC is conflicting with UEC avahi publish
mechanism
https://bugs.launchpad.net/bugs/449143
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
** Changed in: eucalyptus/1.6
Status: In Progress = Fix Committed
** Changed in: eucalyptus
Status: In Progress = Fix Committed
--
Assignment of IP 169.254.169.254 on CC is conflicting with UEC avahi publish
mechanism
https://bugs.launchpad.net/bugs/449143
You received this bug
Niemeyer and I tracked down the issue, which ended up being that the
manifest set by the image store proxy for both the ERI and EMI was
identical.
--
Unable to start images installed/registered via the image store
https://bugs.launchpad.net/bugs/446841
You received this bug notification because
We will be adding the ability for the CC to accept ranges of IPs, using
only the last octet of the IPs, in a near commit of Eucalyptus. All
octets must obviously be between 0 and 255 inclusive. The following
will be accepted:
A.B.C.D-A.B.C.E
where D = E. Multiple ranges can be specified:
committed in eucalyptus revno 926
--
Eucalyptus Public IPs should be submitted in CIDR or range notation
https://bugs.launchpad.net/bugs/438565
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.
--
Ubuntu-server-bugs
Public bug reported:
in the karmic package r931, the version string reported through the
admin UI and on the filesystem is set incorrectly (current=1.6-devel,
should be=1.6)
** Affects: eucalyptus (Ubuntu)
Importance: Undecided
Status: New
** Tags: eucalyptus
** Tags added:
Greetings,
We've analyzed the points in the source tree that are referenced, and
have found that none of them are actually exercised in a Karmic default
eucalyptus running system. More detail on each follows:
GLclient is a testing utility that doesn't get installed by the package (or a
'make
This branch contains a simple fix to change the admin UI version string
to '1.6', in order to help avoid confusion with users having prior
versions of eucalyptus (1.6-devel).
lp:~nurmi/eucalyptus/webuiversion
--
Eucalyptus version string is incorrect (currently 1.6-devel, should be 1.6)
Public bug reported:
When trying to install a UEC node from the 20091017 .iso (amd64), the
installation fails during install of qemu-kvm due to a package conflict. Below
is a snippet of /var/log/syslog during the failure:
.
Oct 18 00:10:35 in-target: python-apt is already the newest
I looks like this bug happens when an authorize is called before the
group is used in another context (run-instances, describe-group, etc).
For example:
euca-authorize (fails)
euca-describe-groups
euca-authorize (success)
Attaching the log file showing exception, and exact commands
**
Public bug reported:
There are several helpful links under the new Eucalyptus UEC Theme
'Services' tab. Adding a section that contains information and links
back to Eucalyptus itself would be helpful to users looking for
Eucalyptus user forums, documentation, downloads, and other Eucalyptus
the java (cloud, walrus, sc) components' logging uses log4j. the
defaults can be found in source under:
clc/modules/core/src/main/resources/log4j.xml
where you'll find the following, which control the file size and the max
number of files of this size that can exist
param
We (Eucalyptus team) have rolled new versions of the images that query
the meta-data service if it exists in preparation for the UEC release
(we've also added a 32 bit versions of each image :). The images are in
testing now, and will be released as soon as they are ready!
--
Non-ubuntu
** Attachment added: rampartc-1.3.0-euca.patch
http://launchpadlibrarian.net/34337608/rampartc-1.3.0-euca.patch
** Also affects: eucalyptus
Importance: Undecided
Status: New
** Also affects: eucalyptus (Ubuntu)
Importance: Undecided
Status: New
--
memory leak;
Public bug reported:
in the eucalyptus-cc upstart script, the line:
rm -f /var/lib/eucalyptus/CC/*
will always clear all CC state when the service is stopped. The
upstream init scripts use:
stop/start/restart
to control the service while maintaining CC state (stored in
** Changed in: eucalyptus
Importance: Undecided = High
--
memory leak; rampart_context not freed (memory leaked per connection)
https://bugs.launchpad.net/bugs/460085
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in
the patch required a small patch to eucalyptus that initializes axis2c
in the CC for each NC client connection (most already were handled this
way, except to StartNetwork/RunInstances).
in r946
--
memory leak; rampart_context not freed (memory leaked per connection)
Network state refers to instance IP addresses and active security group
rules (user defined instance network ingress policies). It is important
to be able to maintain this state in the following scenario:
Eucalyptus is up and running
Users are running VMs and logging in/accessing them via the
300 seconds is the lowest value that can be set for both IDLE and WAKE;
in your 'cc.log', you should see a warning;
POWER_IDLETHRESH set too low (60 seconds), resetting to minimum (300
seconds)
We're trying to be conservative, in order to avoid the condition where
the CC starts putting nodes to
To see the effect of this problem, the simplest setup is a multi-cluster
installation (single clc, walrus, and two clusters (cc/sc) each with one
node (nc)). Choose a security group (default is fine) and run one
instance in one cluster, and one instance in the other cluster (this is
controlled at
Thierry, Shankar,
Thank you both for following up on this issue and finding a potential
patch to the memory leak issue in rampart; I'm testing the
rampartc-1.3.0 with the above patch now with a long term eucalyptus
test, and will report back when the test completes (we usually run for
.5 day to
All,
I've verified that the upstream patch, on top of the patch we've
provided, is both functional and does not exhibit the memory leak
problem; the test was to run the CC/NC against patched rampart/c for
approximately 18 hours, watching the memory footprint of the associated
apache2 processes.
All,
I've been able to confirm that the newest euca/rampart packages, from
proposed, are both functional and do not exhibit the memory leak. To be
specific, i'm running with:
eucalyptus-cc: 1.6~bzr931-0ubuntu7.4
librampart0: 1.3.0-0ubuntu5.1
Thanks!
-Dan
--
Memory leaked per connection
The node controller code currently can service at most one request from
the CC at a time, and as such we set the MaxClients to 1 to ensure that
apache does not send multiple requests to a single NC web service. The
error message can safely be ignored!
Regards,
-Dan
--
eucalyptus-nc: server
Greetings,
We're having trouble reproducing this problem on our lucid systems
against eucalyptus-cloud-1.6.2~bzr1124-0ubuntu3. We think that the
issue is possibly related to some process startup behavior, but it would
be great to get some more system information or a process by which the
issue
Thank Thierry,
We've finally been able to (we believe) reproduce this type of condition
on our Lucid machines, and have figured out the reason why it is being
triggered on lucid UEC installations. The Eucalyptus front-end
components (cloud, walrus, sc) require that, on startup, the network
Some more context: if the eucalyptus DNS feature is disabled (as it is
in the UEC, by default), then we cannot guarantee that the IP addresses
that are specified by the administrator resolve to an actual hostname
(as, often, users are choosing private/unroutable IP addresses for VMs).
Inventing a
This turns out to be a bit deeper of an issue than anticipated; we're
using parted to create a partition/filesystem during image conversion
time for KVM. parted currently does not support the creation of an ext3
partition using mkpartfs (and, since the partition is in the middle of
the disk
All,
Chris has added a bash completion config for euca_conf as of revno 1138;
take a look!
--
euca_conf is missing command-line completion
https://bugs.launchpad.net/bugs/458203
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus
This is really on the (we do our best to keep it)short-list of steps
that one currently needs to perform in order to migrate images (to and
from). Remember that images which are configured to run on xen will
almost surely need some minor modifications (...kernel modules?) in
order to boot
All,
I'm unable to reproduce this problem with (pre) Eucalyptus 1.6.2; with a
running active CC in MANAGED mode (which has the masq rule in place), I
can telnet to localhost port 22 (for example) without a problem, and
sshing to localhost shows that I'm logged in from 'localhost' (implying
that
All,
Mark, Dustin and I have discussed some ideas around the notion that
having a more 'automated' method of choosing and allocating public IP
addresses in the UEC, while keeping Eucalyptus in MANAGED mode in order
to support all of the networking features that Eucalyptus provides
(Elastic IPs,
1 - 100 of 116 matches
Mail list logo
