[02:15] <HugoKuo> FATAL [SystemClock:SystemClockTimer] java.lang.OutOfMemoryError
[02:22] <flaccid> nice
[05:25] <HugoKuo> :<
[05:25] <HugoKuo> I think this the OOM condition that Obino said before
[05:26] <HugoKuo> but this time is occured on CC + SC
[05:26] <HugoKuo> btw after move Walrus into CLC   , it's work fine
[07:25] <ivacau> does anyone know whether in MANAGED-NOVLAN mode, the MAC address of VMs should be the same as the physical address of the node controller?  I've found that the cluster controller is assigning/expecting a different MAC address and configuring this in the DHCP server
[07:48] <HugoKuo> thinkng
[07:49] <HugoKuo> the answer is not
[08:05] <kim0> ivacau: I think they should be different
[08:22] <ivacau> although euca-describe-instances indicates that the instance has an ip address, the node controller does not indicate that an ip address has been allocated.  A tcpdump does not show any dhcp activity, and I cannot reach the instance using icmp or ssh, even after creating the necessary security rules.
[08:23] <kim0> ivacau: try reaching the instance from the clc machine, if that works, then it's just a port forwarding issue
[08:24] <ivacau> my configuration is node A = clc/walrus/cc/sc, node B = nc, node C = client machine.  I've tried to reach the instance from each machine, using both the public and private address, without success
[08:26] <ivacau> I'm getting a 'destination unreachable' message
[08:27] <ivacau> I've looked at the iptables list, and all rules seem to be there
[09:40] <HugoKuo> 109       1118  0.0  1.0 238808 20248 ?        SLl  10:26   0:09 /usr/bin/python /usr/bin/image-store-proxy --log-file /var/log/image-store-proxy/image-store-proxy.log
[09:40] <HugoKuo> 109       1199  6.0 31.6 1691748 639540 ?      Sl   10:26  26:18 eucalyptus-cloud -h / -u eucalyptus --pidfile /var/run/eucalyptus/eucalyptus.pid -l DEBUG -L console-log -Xmx512m --disable-storage
[09:40] <HugoKuo> what's the usage of this process ?
[09:41] <HugoKuo> it almost uses all my mem , CLC+Walrus
[10:13] <ivacau>   709 eucalypt  20   0 79160 3628 2832 S  0.0  0.7   0:03.92 image-store-pro
[10:14] <ivacau> from top
[10:30] <HugoKuo> ?
[11:45] <superxgl> hi all, err, how to scp a file from cc to an instance ?
[11:46] <superxgl> i never do something like this before..
[11:53] <TeTeT> superxgl: scp -i <identity file> <source> <instance ip>:<target>
[11:55] <superxgl> TeTeT: tnx a lot :)
[11:56] <superxgl> hmm...it's like ssh
[11:56] <superxgl> i see..
[12:08] <kim0> guys I'm trying to help someone on the forms. He says "I'm using 10.12.10.230 - 10.12.10.250 for the cloud range. My CLC uses 10.12.10.100 and the NC uses 10.12.10.102"
[12:08] <kim0> The NC shouldn't use that range, right ?!
[12:08] <kim0> thread is at  http://ubuntuforums.org/showthread.php?t=1693373
[12:17] <superxgl> hmm..looks like i find my problem now
[12:17] <superxgl> it seems like the dns problem
[12:18] <superxgl> so when ssh/scp from one VM to another VM got delay..
[16:11] <superxgl> hi all, how to  set VNET_DNS ? i am using private IP addresses
[16:12] <superxgl> --addressing private
[16:13] <superxgl> can i set  VNET_DNS to any ip addresses ?
[16:17] <obino> VNET_DNS should be set to the IP address of a DNS server
[16:17] <obino> you can set any IP address reachable by the instance
[16:18] <superxgl> obino: so i need to configure a DNS server on CC ?
[16:19] <superxgl> because i don't use public ip, so i can not set to the DNS server which CC uses
[16:26] <superxgl> [root@CLC etc]# netstat -lntp | grep 53
[16:26] <superxgl> tcp        0      0 192.168.122.1:53            0.0.0.0:*                   LISTEN      4043/dnsmasq
[16:28] <superxgl> oh, i found that i already have a dns server running , so i should set VNET_DNS to 192.168.122.1, isn't it ?
[16:28] <superxgl> ok, i see
[17:14] <benlake> how might one see one which node an instance was assigned/is running?
[17:24] <hallyn> Daviey: I'm getting http://169.254.169.254/2009-04-04/meta-data/.  I'm pretty sure it's not a uec bug, but rather an unexpected network config (between eth1 (wireless) being netif, and virbr0 being uec bridge)
[17:26] <Daviey> hallyn, Running all in one like that has always been traumatic with the networking.. A long time ago i did manage to get it working, but that wasn't using wifi.
[17:26] <Daviey> kirkland might have an idea, with his UEC livecd work.
[17:26] <hallyn> i've got a few more ideas about where i'm going wrong...
[17:27] <hallyn> btw, all this is just while i wait for buildd to get around to building my tiny spice package that i queued up hours ago :)
[17:32] <hallyn> Daviey: muhaha, I'm up.  dog slow, but I'm up.  Just had to nix eth0:{metadata,priv,pub} and point them at the right places (virbr0, virbr0, eth1 respectively)
[17:39] <benlake> while you guys are talking networking... is there any way I can get the firewall rules to not use my WAN IP when connecting to instances?
[17:41] <benlake> context: LAN 192.168.1.*, instance = 192.168.1.200, my desktop = 192.168.1.150. The rule I have to put in the default security group is my WAN IP and not anything on the 192.168.1.* network will work. What gives?
[17:43] <kirkland> hallyn: actually....
[17:43] <kirkland> hallyn: you can work around this trivially by adding an iptables rule to route that metadata traffic to 192.168.122.1, if you're using virbr0
[17:44] <kirkland> hallyn:
[17:44] <kirkland>         # Add a special iptables rule for metadata service
[17:44] <kirkland>         iptables -t nat -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.122.1:8773
[17:44] <kirkland> hallyn: and Daviey was right... this comes from the livecd work
[17:44] <kirkland> Daviey: which, by the way, is now *kicking ass* on Ubuntu 10.10
[17:46] <TeTeT> kim0: I've asked for mgmt approval to present one of the casy study scenarios from the UEC class at your cloud event. I'll let you know if it gets approved
[17:46] <TeTeT> smoser: not to stress you, but did you have a chance to look at the ebs based instance exercise?
[17:47] <smoser> no i did not. but i planned on reading today
[17:47] <smoser> i promise :)
[17:47] <TeTeT> he he, ok
[17:48] <pmatulis> after using euca-authorize to open access to an instance isn't euca-describe-groups supposed to show current f/w rules?
[17:48] <TeTeT> you don't need to care about grammar and formatting, just the content is relevant right now, rest will be checked later on
[17:48] <kim0> TeTeT: awesome please do :)
[17:49]  * benlake checks his microphone
[17:49] <TeTeT> kim0: will there be a possibility of screen sharing at the event, or will it be IRC only?
[17:50] <kim0> traditionally it's irc only .. although even for myself, I wish there would be some "screen" session that everyone can see
[17:50] <kim0> ideally over the web
[17:50] <kim0> still haven't figured that one yet
[17:51] <TeTeT> ok, if you find anything, let me know
[17:52] <TeTeT> bye now
[17:56] <hallyn> kirkland: if you're using that iptables rule, what device are you using for 169.x.x.x?
[17:56] <hallyn> kirkland: i can boot and ssh into iamges now, but can't get out to the world.  I think I need to just hand-create my own (non-libvirt) bridge for euc
[17:58] <jmgalloway> anyone here good with java?
[18:25] <smoser> pmatulis, you have to be more verbose with euca-authorize than with ec2-authorize
[18:26] <pmatulis> smoser: more verbose to set a rule?
[18:26] <smoser> euca-authorize default -P tcp -p 22 -s 0.0.0.0/0
[18:26] <smoser> with the ec2-api-tools you can just:
[18:26] <smoser> ec2-authorize default -p 22
[18:26] <pmatulis> smoser: will try
[18:27] <smoser> after doing so, i see something like:
[18:27] <smoser> $ euca-describe-groups
[18:27] <smoser> GROUP	smoser	default	default group
[18:27] <smoser> PERMISSION	smoser	default	ALLOWS	tcp	22	22	FROM	CIDR	0.0.0.0/0
[18:27]  * hallyn out for long lunch
[19:04] <benlake> is there any way I can get the firewall rules to not use my WAN IP when connecting to instances? Context: LAN 192.168.1.*, instance = 192.168.1.200, my desktop = 192.168.1.150. The only rule that lets me access the instance is my WAN IP, not my local IP/network. Is this odd?