[Bug 757258] Re: Unable to reach instances from their public IP address
** Changed in: eucalyptus (Ubuntu) Status: Incomplete = New -- 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/757258 Title: Unable to reach instances from their public IP address -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 757258] Re: Unable to reach instances from their public IP address
Sorry, I was out of the office for a while and was not able to handle this request I used elasticfox, and yes added ssh port: sysadmin@europe:~$ euca-describe-groups GROUP build build Build group PERMISSION build build ALLOWS icmp-1 -1 FROMCIDR 0.0.0.0/32 PERMISSION build build ALLOWS tcp 22 22 FROMCIDR 0.0.0.0/32 GROUP build default default group Obviously, the instance is launched using the 'build' security group Cheers. -- 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/757258 Title: Unable to reach instances from their public IP address -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 757258] [NEW] Unable to reach instances from their public IP address
Public bug reported: On Ubuntu Maverick (Eucalyptus 2.0) I'm not able to reach the eucalyptus instances, due to the firewall rules. I didn't find exactly the problem, but I only know that it's iptables which drops packages. Our setup is, a server with CC, Walrus and SC and two additional servers with NC, all servers have two network cards, one connected to our public LAN and another one connected to an isolated switch. CC and walrus listen on the public LAN network, the SC and NC listen on the private LAN network. We are able to launch instances and to connect EBS volumes without problems. From within the instances, we are able to connect to Internet without problems, either. However our problem comes when we try to connect to the instances using the public LAN IP address we assigned on installation time, all packages are dropped. For the iptables rules I'm going to attach, we have the public IP address 10.82.3.1 assigned to the CC public interface (br0), which points to the 172.19.1.2 ip address assigned to the eucalyputs instance. I just opened the ping port: sysadmin@europe:~$ sudo iptables -n -L -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- 172.19.0.0/16169.254.169.254 tcp dpt:80 to:169.254.169.254:8773 DNAT all -- 0.0.0.0/010.82.3.1 to:172.19.1.2 Chain OUTPUT (policy ACCEPT) target prot opt source destination DNAT all -- 0.0.0.0/010.82.3.1 to:172.19.1.2 Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 172.19.1.2 !172.19.0.0/16 to:10.82.3.1 MASQUERADE all -- 172.19.0.0/16 !172.19.0.0/16 sysadmin@europe:~$ sudo iptables -n -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- 0.0.0.0/00.0.0.0/0 ctstate ESTABLISHED ACCEPT all -- 0.0.0.0/0 !172.19.0.0/16 build-build all -- 0.0.0.0/00.0.0.0/0 ACCEPT all -- 172.19.1.0/27172.19.1.0/27 LOGall -- 0.0.0.0/00.0.0.0/0 limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables denied (input): ' Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain build-build (1 references) target prot opt source destination ACCEPT icmp -- 0.0.0.0 172.19.1.0/27 sysadmin@europe:~$ sudo iptables -n -L -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- 172.19.0.0/16169.254.169.254 tcp dpt:80 to:169.254.169.254:8773 DNAT all -- 0.0.0.0/010.82.3.1 to:172.19.1.2 Chain OUTPUT (policy ACCEPT) target prot opt source destination DNAT all -- 0.0.0.0/010.82.3.1 to:172.19.1.2 Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 172.19.1.2 !172.19.0.0/16 to:10.82.3.1 MASQUERADE all -- 172.19.0.0/16 !172.19.0.0/16 And the configured network interfaces: sysadmin@europe:~$ ifconfig br0 Link encap:Ethernet HWaddr inet addr:10.82.0.10 Bcast:10.82.3.255 Mask:255.255.252.0 inet6 addr: fe80::222:19ff:fe55:abd1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3154360 errors:0 dropped:0 overruns:0 frame:0 TX packets:252607 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:250658946 (250.6 MB) TX bytes:555159076 (555.1 MB) br1 Link encap:Ethernet HWaddr XXX inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::222:19ff:fe55:abd3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2727761 errors:0 dropped:0 overruns:0 frame:0 TX packets:3336571 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1876704895 (1.8 GB) TX bytes:1622792007 (1.6 GB) br0:pub Link encap:Ethernet HWaddr XX inet addr:10.82.3.1 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 br1:metadata Link encap:Ethernet HWaddr 00:22:19:55:ab:d3 inet addr:169.254.169.254 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 br1:priv Link encap:Ethernet HWaddr XXX inet addr:172.19.1.1 Bcast:172.19.1.31 Mask:255.255.255.224 UP BROADCAST RUNNING MULTICAST MTU:1500
[Bug 750565] Re: Unable to attach an EBS volume
Confirmed, it fixes the issue. Thanks for the speed fixing it! -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in Ubuntu. https://bugs.launchpad.net/bugs/750565 Title: Unable to attach an EBS volume -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 750565] [NEW] Unable to attach an EBS volume
Public bug reported: With Maverick's UEC / Euclayptus, there is no way to mount EBS volumes because libvirt gives the error: sdh uses scsi:1, rather than scsi:0. The error and the patch applied upstream can be seen at: http://osdir.com/ml/libvir-list/2011-01/msg01268.html As you can see it's a single line change, the affected file for the maverick version is: src/qemu/qemu_driver.c (seems like they did some code refactoring on the version used on that email ) I applied the patch by hand, recompiled and installed it and the ebs mount worked. ** Affects: libvirt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in Ubuntu. https://bugs.launchpad.net/bugs/750565 Title: Unable to attach an EBS volume -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 517086] Re: euca-create-volume fails at times with Error communicating with Storage Controller
Is there any workaround to remove those stalled volumes completely? We are creating big volumes and thus, the volume limit is reached easily, but we cannot remove completely the volumes that fail on creation time. -- euca-create-volume fails at times with Error communicating with Storage Controller https://bugs.launchpad.net/bugs/517086 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 Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 588802] [NEW] Unable to create a new volume from a snapshot
Public bug reported: We are no able to create a new volume based on an existing snapshot. We tried using bigger volumes than the original volume from where the snapshot was created and also using the same size, but in both cases, we get the same error: 17:56:11 [JDBCExceptionReporter:pool-10-thread-1] ERROR Couldn't perform the operation prepareStatement: You can't perform any operations on this connection. It has been automatica lly closed by Proxool for some reason (see logs). 17:56:11 [AbstractFlushingEventListener:pool-10-thread-1] ERROR Could not synchronize database state with session org.hibernate.exception.GenericJDBCException: could not insert: [edu.ucsb.eucalyptus.cloud.entities.AOEVolumeInfo] at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:126) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:114) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2295) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2688) at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:137) at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:54) at com.eucalyptus.util.TxHandle.commit(TxHandle.java:104) at com.eucalyptus.util.EntityWrapper.commit(EntityWrapper.java:173) at edu.ucsb.eucalyptus.storage.LVM2Manager$VolumeEntityWrapperManager.finish(LVM2Manager.java:952) at edu.ucsb.eucalyptus.storage.LVM2Manager$VolumeEntityWrapperManager.access$400(LVM2Manager.java:841) at edu.ucsb.eucalyptus.storage.LVM2Manager.createVolume(LVM2Manager.java:507) at edu.ucsb.eucalyptus.cloud.ws.BlockStorage$VolumeCreator.run(BlockStorage.java:779) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) Caused by: java.sql.SQLException: Couldn't perform the operation prepareStatement: You can't perform any operations on this connection. It has been automatically closed by Proxool f or some reason (see logs). at org.logicalcobwebs.proxool.WrappedConnection.invoke(WrappedConnection.java:207) at $Proxy27.prepareStatement(Unknown Source)at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:534) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:116) at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:109) at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:244) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2252) ... 20 more 17:56:11 [JDBCTransaction:pool-10-thread-1] ERROR Could not toggle autocommit java.sql.SQLException: Couldn't perform the operation setAutoCommit: You can't perform any operations on this connection. It has been automatically closed by Proxool for some reason (see logs). at org.logicalcobwebs.proxool.WrappedConnection.invoke(WrappedConnection.java:207) at $Proxy27.setAutoCommit(Unknown Source) at org.hibernate.transaction.JDBCTransaction.toggleAutoCommit(JDBCTransaction.java:228) at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:220) at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:196) at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:66) at com.eucalyptus.util.TxHandle.commit(TxHandle.java:104) at com.eucalyptus.util.EntityWrapper.commit(EntityWrapper.java:173) at edu.ucsb.eucalyptus.storage.LVM2Manager$VolumeEntityWrapperManager.finish(LVM2Manager.java:952) at edu.ucsb.eucalyptus.storage.LVM2Manager$VolumeEntityWrapperManager.access$400(LVM2Manager.java:841) at edu.ucsb.eucalyptus.storage.LVM2Manager.createVolume(LVM2Manager.java:507) at
[Bug 579892] Re: libvirt should not use the MAC address assigned to tap devices/vnet interfaces by the TAP/TUN driver
This is my network configuration: auto br0 iface br0 inet dhcp bridge_ports eth0 bridge_fd 9 bridge_hello 2 bridge_maxage 12 bridge_stp off pre-up ifconfig eth0 hw ether 00:00:00:00:00:01 The macaddress change is the workaround I'm using right now so I'm able to avoid this issue. The libvirt network configuration is disabled on this server, because I'm using the main bridge and I don't want it to do NAT. ** Attachment added: Machine XML file http://launchpadlibrarian.net/48736588/paris.xml ** Changed in: libvirt (Ubuntu) Status: Incomplete = New -- libvirt should not use the MAC address assigned to tap devices/vnet interfaces by the TAP/TUN driver https://bugs.launchpad.net/bugs/579892 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 579868] Re: Unable to use Eucalyptus' iptables-preload feature with UEC
I know about ufw, the problem is that eucalyptus is not aware of ufw (at least from what I saw in the source code) and the cloud controller resets the iptables rules EVERY TIME it's restarted, not just on reboot. The only documented way to prevent it from clear your custom rules is to use the iptables-preload file I talked about. I know that the ideal solution would be that Eucalyptus use ufw, however I'm not sure that would be a trivial task so, until then, I just want to be able to use the official way to get it working instead of a hack I had to add so the file is copied there after each reboot. ** Changed in: eucalyptus (Ubuntu) Status: Incomplete = New -- Unable to use Eucalyptus' iptables-preload feature with UEC https://bugs.launchpad.net/bugs/579868 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 Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 579868] [NEW] Unable to use Eucalyptus' iptables-preload feature with UEC
Public bug reported: We are using UEC cloud controller in a server that also runs regular KVM servers with libvirt and bridge interface. Everything is working more or less as expected, however, UEC configures iptable to use NAT for all traffic that is forwarded, even if it's not for the cloud itself. This causes that when we connect from an outside machine to any of the regular KVM machines, we are seen as coming always from the UEC cloud and KVM host. That's not a big problem, given that is easy to solve adding this rule to iptables on that machine: iptables -t nat -A POSTROUTING -d 10.82.0.0/22 -s 10.82.0.0/22 -j ACCEPT (where 10.82.0.0/22 is our local net), the problem comes on how to inject it in a way that UEC doesn't drop that rule on boot. From Eucalyptus documentation (http://open.eucalyptus.com/wiki/EucalyptusNetworking_v1.6), we are able to put it on /var/run/eucalyptus/net/iptables-preload with the iptables- save command, however, that location is not valid for Ubuntu, because it's on a ram disk and thus, discarded with every reboot. UEC should have a way to put that file in some other persistent place or a way to inject that file on boot time, any of those solutions would be valid for us. ** Affects: eucalyptus (Ubuntu) Importance: Undecided Status: New -- Unable to use Eucalyptus' iptables-preload feature with UEC https://bugs.launchpad.net/bugs/579868 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 Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 579868] Re: Unable to use Eucalyptus' iptables-preload feature with UEC
I forgot to mention that I'm talking about Ubuntu 10.04 -- Unable to use Eucalyptus' iptables-preload feature with UEC https://bugs.launchpad.net/bugs/579868 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 Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 579892] [NEW] libvirt should not use the MAC address assigned to tap devices/vnet interfaces by the TAP/TUN driver
Public bug reported: On Ubuntu 10.04 I have problems using libvirt with a bridge because the TUN devices get random mac addresses and thus, change the bridge device mac address, which takes the lower mac addres of all devices attached to the bridge. The main and most critical problem is that, sometimes, we lose network connectivity for several seconds (usually 10-20 seconds) on the libvirt host and all its guests when a guest is powered off. Searching for similar problems I found my problem described at https://bugzilla.redhat.com/show_bug.cgi?id=571991 ** Affects: libvirt (Ubuntu) Importance: Undecided Status: New ** Affects: fedora Importance: Unknown Status: Unknown ** Bug watch added: Red Hat Bugzilla #571991 https://bugzilla.redhat.com/show_bug.cgi?id=571991 ** Also affects: fedora via https://bugzilla.redhat.com/show_bug.cgi?id=571991 Importance: Unknown Status: Unknown -- libvirt should not use the MAC address assigned to tap devices/vnet interfaces by the TAP/TUN driver https://bugs.launchpad.net/bugs/579892 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to libvirt in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
