=== dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [02:15] FATAL [SystemClock:SystemClockTimer] java.lang.OutOfMemoryError [02:22] nice [05:25] :< [05:25] I think this the OOM condition that Obino said before [05:26] but this time is occured on CC + SC [05:26] btw after move Walrus into CLC , it's work fine [07:25] 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] thinkng [07:49] the answer is not [08:05] ivacau: I think they should be different [08:22] 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] ivacau: try reaching the instance from the clc machine, if that works, then it's just a port forwarding issue [08:24] 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] I'm getting a 'destination unreachable' message [08:27] I've looked at the iptables list, and all rules seem to be there [09:40] 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] 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] what's the usage of this process ? [09:41] it almost uses all my mem , CLC+Walrus [10:13] 709 eucalypt 20 0 79160 3628 2832 S 0.0 0.7 0:03.92 image-store-pro [10:14] from top [10:30] ? [11:45] hi all, err, how to scp a file from cc to an instance ? [11:46] i never do something like this before.. [11:53] superxgl: scp -i : [11:55] TeTeT: tnx a lot :) [11:56] hmm...it's like ssh [11:56] i see.. [12:08] 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] The NC shouldn't use that range, right ?! [12:08] thread is at http://ubuntuforums.org/showthread.php?t=1693373 [12:17] hmm..looks like i find my problem now [12:17] it seems like the dns problem [12:18] so when ssh/scp from one VM to another VM got delay.. === Kiall|AFK is now known as Kiall === dendro-afk is now known as dendrobates === niemeyer_ is now known as niemeyer [16:11] hi all, how to set VNET_DNS ? i am using private IP addresses [16:12] --addressing private [16:13] can i set VNET_DNS to any ip addresses ? [16:17] VNET_DNS should be set to the IP address of a DNS server [16:17] you can set any IP address reachable by the instance [16:18] obino: so i need to configure a DNS server on CC ? [16:19] because i don't use public ip, so i can not set to the DNS server which CC uses [16:26] [root@CLC etc]# netstat -lntp | grep 53 [16:26] tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 4043/dnsmasq [16:28] 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] ok, i see [17:14] how might one see one which node an instance was assigned/is running? [17:24] 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] 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] kirkland might have an idea, with his UEC livecd work. [17:26] i've got a few more ideas about where i'm going wrong... [17:27] 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] 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] 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] 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] hallyn: actually.... [17:43] 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] hallyn: [17:44] # Add a special iptables rule for metadata service [17:44] 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] hallyn: and Daviey was right... this comes from the livecd work [17:44] Daviey: which, by the way, is now *kicking ass* on Ubuntu 10.10 [17:46] 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] smoser: not to stress you, but did you have a chance to look at the ebs based instance exercise? [17:47] no i did not. but i planned on reading today [17:47] i promise :) [17:47] he he, ok [17:48] after using euca-authorize to open access to an instance isn't euca-describe-groups supposed to show current f/w rules? [17:48] 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] TeTeT: awesome please do :) === dendrobates is now known as dendro-afk [17:49] * benlake checks his microphone [17:49] kim0: will there be a possibility of screen sharing at the event, or will it be IRC only? [17:50] traditionally it's irc only .. although even for myself, I wish there would be some "screen" session that everyone can see [17:50] ideally over the web [17:50] still haven't figured that one yet [17:51] ok, if you find anything, let me know [17:52] bye now [17:56] kirkland: if you're using that iptables rule, what device are you using for 169.x.x.x? [17:56] 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] anyone here good with java? [18:25] pmatulis, you have to be more verbose with euca-authorize than with ec2-authorize [18:26] smoser: more verbose to set a rule? [18:26] euca-authorize default -P tcp -p 22 -s 0.0.0.0/0 [18:26] with the ec2-api-tools you can just: [18:26] ec2-authorize default -p 22 [18:26] smoser: will try [18:27] after doing so, i see something like: [18:27] $ euca-describe-groups [18:27] GROUP smoser default default group [18:27] PERMISSION smoser default ALLOWS tcp 22 22 FROM CIDR 0.0.0.0/0 [18:27] * hallyn out for long lunch === dendro-afk is now known as dendrobates [19:04] 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? === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates