[GitHub] rhtyd closed issue #2771: Followup 2613: remove buildw profile and tools/wix-cloudstack-maven-plugin
rhtyd closed issue #2771: Followup 2613: remove buildw profile and tools/wix-cloudstack-maven-plugin URL: https://github.com/apache/cloudstack/issues/2771 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rhtyd commented on issue #2869: Fix some Marvin smoke tests
rhtyd commented on issue #2869: Fix some Marvin smoke tests URL: https://github.com/apache/cloudstack/pull/2869#issuecomment-426847632 Let's also change base branch to 4.11? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] wido commented on issue #2872: Improve ConfigDrive to store network information
wido commented on issue #2872: Improve ConfigDrive to store network information URL: https://github.com/apache/cloudstack/issues/2872#issuecomment-426797170 @rhtyd Yes, it would be great! It would allow for much larger scaling without the need of DHCP. That removes the VR in many use-cases. I haven't got ConfigDrive to work yet (offerings which wouldn't work...), but from the code I saw it only generates a empty network_data.json file. Happy to work on this and write against 4.11 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] bdonnahue commented on issue #2863: Cloudstack 4.11.1.0 - Unable to create shared network in advanced zone
bdonnahue commented on issue #2863: Cloudstack 4.11.1.0 - Unable to create shared network in advanced zone URL: https://github.com/apache/cloudstack/issues/2863#issuecomment-426755778 @rhtyd what information would you like specifically (sorry just new to CS and not sure what might be common knowledge) I am not sure how to reconcile the comments maid in the mail archive that @rhtyd linked to and the comments that @fmaximus made. It sounds like the bug was fixed by removing the components to setup GRE tunnels (formerly implemented by the OVS plugin in 4.1)? Is that an accurate statement? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] fmaximus commented on issue #2863: Cloudstack 4.11.1.0 - Unable to create shared network in advanced zone
fmaximus commented on issue #2863: Cloudstack 4.11.1.0 - Unable to create shared network in advanced zone URL: https://github.com/apache/cloudstack/issues/2863#issuecomment-426667382 The error means it can't find a NetworkGuru who wants to design the network. I also took a look at the NetworkGurus: Neither ExternalGuestNetworkGuru nor OvsGuestNetworkGuru have Shared Network support. DirectNetworkGuru has Shared support, but doesn't support GRE. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] PaulAngus commented on issue #2719: Restarting of non-redundant VPC with private gateway fails sometimes
PaulAngus commented on issue #2719: Restarting of non-redundant VPC with private gateway fails sometimes URL: https://github.com/apache/cloudstack/issues/2719#issuecomment-426660005 Reference PR #2128 is not fully implemented and causes issues when deploying VRs with private gateways on VMware. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rhtyd commented on issue #2863: Cloudstack 4.11.1.0 - Unable to create shared network in advanced zone
rhtyd commented on issue #2863: Cloudstack 4.11.1.0 - Unable to create shared network in advanced zone URL: https://github.com/apache/cloudstack/issues/2863#issuecomment-426631670 @bdonnahue according to the list https://www.mail-archive.com/dev@cloudstack.apache.org/msg17396.html the feature may have been broken since 4.2. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rhtyd opened a new issue #2873: VR seen to have memory leaks
rhtyd opened a new issue #2873: VR seen to have memory leaks URL: https://github.com/apache/cloudstack/issues/2873 In one of the 4.11.x environments, it is seen that VR memory consumption increases the maximum leading to swapping. # ISSUE TYPE * Bug Report # COMPONENT NAME ~~~ VR ~~~ # CLOUDSTACK VERSION ~~~ 4.11.1.0/4.11.2.0-rc2 ~~~ # CONFIGURATION Advanced zone + adv networking # OS / ENVIRONMENT Seen in case of VMware 5.5.x # STEPS TO REPRODUCE ~~~ Deploy VPC VR Wait for 3 days See the VR has consumed all the RAM, swapping could be seen ~~~ # EXPECTED RESULTS ~~~ VR should run without causing memory leaks ~~~ # ACTUAL RESULTS ~~~ VR found thrashing and swapping ~~~ This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rhtyd commented on issue #2863: Cloudstack 4.11.1.0 - Unable to create shared network in advanced zone
rhtyd commented on issue #2863: Cloudstack 4.11.1.0 - Unable to create shared network in advanced zone URL: https://github.com/apache/cloudstack/issues/2863#issuecomment-426614097 @bdonnahue can you share more details about your zone/infra setup? How you have setup and deployed your zone with XenServer 7.x and openvswitch? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rhtyd commented on issue #2865: DNS records for additional local IP addresses
rhtyd commented on issue #2865: DNS records for additional local IP addresses URL: https://github.com/apache/cloudstack/issues/2865#issuecomment-426613372 Notes: the feature is about VIP for an internal IP, inside the isolated network. A floating IP like feature for the internal guest network would suffice the requirement. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] izenk edited a comment on issue #2856: VR dhcp domain-name-servers
izenk edited a comment on issue #2856: VR dhcp domain-name-servers URL: https://github.com/apache/cloudstack/issues/2856#issuecomment-426612042 @rhtyd thanks, now its clear. but unfortunately dnsmasq has [(multiple resolvers)](https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1726017) bug So, now only equivalent dns servers can be used in "ZONE public dns" settings This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] izenk edited a comment on issue #2856: VR dhcp domain-name-servers
izenk edited a comment on issue #2856: VR dhcp domain-name-servers URL: https://github.com/apache/cloudstack/issues/2856#issuecomment-426612042 @rhtyd thanks, now its clear. but unfortunately dnsmasq has [(multiple resolvers)](https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1726017) So, now only equivalent dns servers can be used in "ZONE public dns" settings This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] izenk commented on issue #2856: VR dhcp domain-name-servers
izenk commented on issue #2856: VR dhcp domain-name-servers URL: https://github.com/apache/cloudstack/issues/2856#issuecomment-426612042 @rhtyd thanks, now its clear. but unfortunately dnsmasq has [(multiple resolvers)](https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1726017) So, now only equivalent dns servers can be used in ZONE public dns settings This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rhtyd commented on issue #2872: Improve ConfigDrive to store network information
rhtyd commented on issue #2872: Improve ConfigDrive to store network information URL: https://github.com/apache/cloudstack/issues/2872#issuecomment-426611880 @wido yes ideally that's the use of config drive feature. I would see this as a bug, if currently it's not possible to share/send the network (ip and dns) currently. If you do decide to implement the fix, please open PR for 4.11 branch. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rhtyd commented on issue #2856: VR dhcp domain-name-servers
rhtyd commented on issue #2856: VR dhcp domain-name-servers URL: https://github.com/apache/cloudstack/issues/2856#issuecomment-426610978 Thanks for sharing @izenk, yes it's possible that we've fixed the issue. The current behaviour you're seeing with latest 4.11.1/2 is the expected/ideal behaviour. The dnsmasq service on the VR should act as forwarding dns/agent, so ideally we would only expect to see the VR IP in the `domain-name-servers` list. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] izenk commented on issue #2856: VR dhcp domain-name-servers
izenk commented on issue #2856: VR dhcp domain-name-servers
URL: https://github.com/apache/cloudstack/issues/2856#issuecomment-426603920
@rhtyd I can't say how it should be. I noticed that behavior has been
changed...
For example, before upgrade I had such dhcp leases on vms:
~~~
lease {
interface "eth0";
fixed-address 172.16.0.25;
option subnet-mask 255.255.255.240;
option routers 172.16.0.17;
option dhcp-lease-time 2692800;
option dhcp-message-type 5;
option domain-name-servers 172.16.0.17,8.8.8.8; 10.9.x.x; <-
172.16.0.17 is gateway on VR, 8.8.8.8 and 10.9.x.x - is public dns ips which
are set in ZONE settings: public dns1, public dns2
option dhcp-server-identifier 172.16.0.17;
option dhcp-renewal-time 1346400;
option broadcast-address 172.16.0.31;
option dhcp-rebinding-time 2356200;
option host-name "front-web-vm1";
option domain-name "cs16cloud.internal";
renew 2 2018/08/14 02:14:34;
rebind 0 2018/08/26 20:54:45;
expire 4 2018/08/30 18:24:45;
}
~~~
now I have
~~~
lease {
interface "eth0";
fixed-address 172.16.0.25;
option subnet-mask 255.255.255.240;
option routers 172.16.0.17;
option dhcp-lease-time 2692800;
option dhcp-message-type 5;
option domain-name-servers 172.16.0.17<- only VR ip stayed
option dhcp-server-identifier 172.16.0.17;
option dhcp-renewal-time 1346400;
option broadcast-address 172.16.0.31;
option dhcp-rebinding-time 2356200;
option host-name "front-web-vm1";
option domain-name "cs16cloud.internal";
renew 2 2018/08/14 02:14:34;
rebind 0 2018/08/26 20:54:45;
expire 4 2018/08/30 18:24:45;
}
~~~
So, from my point of view the behavior has been changed
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] rhtyd commented on issue #2856: VR dhcp domain-name-servers
rhtyd commented on issue #2856: VR dhcp domain-name-servers URL: https://github.com/apache/cloudstack/issues/2856#issuecomment-426602362 @izenk can you check again? I misunderstood, the guest VMs should query, by default, dns via the VR. The VR is supposed to be the source of truth for dns queries which is why guest VMs as part of dhcp response should only get VR as the dns IP. I'll close this ticket wrt 4.11.2.0, please reopen if you disagree. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rhtyd closed issue #2856: VR dhcp domain-name-servers
rhtyd closed issue #2856: VR dhcp domain-name-servers URL: https://github.com/apache/cloudstack/issues/2856 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rhtyd closed pull request #2866: systemvm: baremetal-vr: reduce memory usage
rhtyd closed pull request #2866: systemvm: baremetal-vr: reduce memory usage
URL: https://github.com/apache/cloudstack/pull/2866
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/systemvm/debian/opt/cloud/bin/baremetal-vr.py
b/systemvm/debian/opt/cloud/bin/baremetal-vr.py
index 20352ddeeab..b8dacc78325 100755
--- a/systemvm/debian/opt/cloud/bin/baremetal-vr.py
+++ b/systemvm/debian/opt/cloud/bin/baremetal-vr.py
@@ -156,4 +156,4 @@ def notify_provisioning_done(mac):
if __name__ == '__main__':
server = Server()
shell("iptables-save | grep -- '-A INPUT -i eth0 -p tcp -m tcp --dport
10086 -j ACCEPT' > /dev/null || iptables -I INPUT -i eth0 -p tcp -m tcp --dport
10086 -j ACCEPT")
-app.run(host='0.0.0.0', port=10086, debug=True)
+app.run(host='0.0.0.0', port=10086)
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[cloudstack] branch 4.11 updated: systemvm: baremetal-vr: reduce memory usage (#2866)
This is an automated email from the ASF dual-hosted git repository.
rohit pushed a commit to branch 4.11
in repository https://gitbox.apache.org/repos/asf/cloudstack.git
The following commit(s) were added to refs/heads/4.11 by this push:
new 8c0b9d6 systemvm: baremetal-vr: reduce memory usage (#2866)
8c0b9d6 is described below
commit 8c0b9d6202728499481240f4c95aa9bada363344
Author: René Moser
AuthorDate: Wed Oct 3 13:08:32 2018 +0200
systemvm: baremetal-vr: reduce memory usage (#2866)
We see a suspicious continuous increase in memory usage. Kind of looks like
a memory leak.
One thing noted during debugging is that flask is started in debug mode.
This is not best practice for a production system.
---
systemvm/debian/opt/cloud/bin/baremetal-vr.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/systemvm/debian/opt/cloud/bin/baremetal-vr.py
b/systemvm/debian/opt/cloud/bin/baremetal-vr.py
index 20352dd..b8dacc7 100755
--- a/systemvm/debian/opt/cloud/bin/baremetal-vr.py
+++ b/systemvm/debian/opt/cloud/bin/baremetal-vr.py
@@ -156,4 +156,4 @@ def notify_provisioning_done(mac):
if __name__ == '__main__':
server = Server()
shell("iptables-save | grep -- '-A INPUT -i eth0 -p tcp -m tcp --dport
10086 -j ACCEPT' > /dev/null || iptables -I INPUT -i eth0 -p tcp -m tcp --dport
10086 -j ACCEPT")
-app.run(host='0.0.0.0', port=10086, debug=True)
+app.run(host='0.0.0.0', port=10086)
[GitHub] blueorangutan commented on issue #2376: [4.11] Smoketest Health Check
blueorangutan commented on issue #2376: [4.11] Smoketest Health Check URL: https://github.com/apache/cloudstack/pull/2376#issuecomment-426584750 Packaging result: ✔centos6 ✔centos7 ✖debian. JID-2328 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] blueorangutan commented on issue #2376: [4.11] Smoketest Health Check
blueorangutan commented on issue #2376: [4.11] Smoketest Health Check URL: https://github.com/apache/cloudstack/pull/2376#issuecomment-426577854 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rhtyd commented on issue #2376: [4.11] Smoketest Health Check
rhtyd commented on issue #2376: [4.11] Smoketest Health Check URL: https://github.com/apache/cloudstack/pull/2376#issuecomment-426577592 @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] izenk edited a comment on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs
izenk edited a comment on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs URL: https://github.com/apache/cloudstack/pull/2514#issuecomment-426552700 @rhtyd may be this helps.. Looks like routing goes in such way, that packets do not go through SNAT rule on VR, what leads to such situation: if two vms are in one TIER and vm1 wants to connect to vm2 through PUBLIC IP, it should look like: vm1 internal ip -> VR SNAT -> VR DNAT -> vm2 internal ip **right now**, on vm2 I can see packets from vm1, **but** source ip is set to **vm1 internal ip** (not VR SNAT) So if I try telnet from vm1 to VR publicIP:80 (which is forwarded to vm2:80), on vm2 I can see packets on port 80, but these packets are from vm1 internal ip(should be from VR SNAT). Next, **I even can see replies from vm2 on vm1**, but because this replies are coming from vm2 directly (to vm1:internal ip) - in fact connection is not established. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] izenk edited a comment on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs
izenk edited a comment on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs URL: https://github.com/apache/cloudstack/pull/2514#issuecomment-426552700 @rhtyd may be this helps.. Looks like routing goes in such way, that packets do not go through SNAT rule on VR, what leads to such situation: if two vms are in one TIER and vm1 wants to connect to vm2 through PUBLIC IP, it should look like: vm1 internal ip -> VR SNAT -> VR DNAT -> vm2 internal ip **right now**, on vm2 I can see packets from vm1, **but** source ip is set to **vm1 internal ip** (not VR SNAT) So if I try telnet from vm1 to VR publicIP:80 (which is forwarded to vm2:80), on vm2 I can see packets on port 80, but these packets are from vm1 internal ip(should be from VR SNAT). Next, **I even can see replies from vm2 on vm1**, but because this replies are coming from vm2 directly to vm1:internal ip and not from VR (how it should be), in fact connection is not established This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] izenk edited a comment on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs
izenk edited a comment on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs URL: https://github.com/apache/cloudstack/pull/2514#issuecomment-426552700 @rhtyd may be this helps.. Looks like routing goes in such way, that packets do not go through SNAT rule on VR, what leads to such situation: if two vms are in one TIER and vm1 wants to connect to vm2 through PUBLIC IP, it should look like: vm1 internal ip -> VR SNAT -> VR DNAT -> vm2 internal ip **right now**, on vm2 I can see packets from vm1, **but** source ip is set to **vm1 internal ip** (not VR SNAT) So if I try telnet from vm1 to VR publicIP:80 (which is forwarded to vm2:80), on vm2 I can see packets on port 80, but these packets are from vm1 internal ip. Next, **I even can see replies from vm2 on vm1**, but because this replies are coming from vm2 directly to vm1:internal ip and not from VR (how it should be), in fact connection is not established This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] izenk edited a comment on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs
izenk edited a comment on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs URL: https://github.com/apache/cloudstack/pull/2514#issuecomment-426552700 @rhtyd may be this helps.. Looks like routing goes in such way, that packets do not go through SNAT rule on VR, what leads to such situation: if two vms are in one TIER and vm1 wants to connect to vm2 through PUBLIC IP, it should look like: vm1 internal ip -> VR SNAT -> VR DNAT -> vm2 internal ip **now on vm2 I can see packets from vm1, but** source ip is set to vm1 internal ip (not VR SNAT) So if I try telnet from vm1 to VR publicIP:80 (which is forwarded to vm2:80), on vm2 I can see packets on port 80, but these packets are from vm1 internal ip. Next, **I even can see replies from vm2 on vm1**, but because this replies are coming from vm2 directly to vm1:internal ip and not from VR (how it should be), in fact connection is not established This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] izenk edited a comment on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs
izenk edited a comment on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs URL: https://github.com/apache/cloudstack/pull/2514#issuecomment-426552700 @rhtyd may be this helps.. Looks like routing goes in such way, that packets do not go through SNAT rule on VR, what leads to such situation: if two vms are in on TIER and vm1 wants to connect to vm2 through PUBLIC IP, it should look like: vm1 internal ip -> VR SNAT -> VR DNAT -> vm2 internal ip **now on vm2 I can see packets from vm1, but** source ip is set to vm1 internal ip (not VR SNAT) So if I try telnet from vm1 to VR publicIP:80 (which is forwarded to vm2:80), on vm2 I can see packets on port 80, but these packets are from vm1 internal ip. Next, **I even can see replies from vm2 on vm1**, but because this replies are coming from vm2 directly to vm1:internal ip and not from VR (how it should be), in fact connection is not established This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] izenk commented on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs
izenk commented on issue #2514: [CLOUDSTACK-10346] Problem with NAT configuration and VMs not accessing each other via public IPs URL: https://github.com/apache/cloudstack/pull/2514#issuecomment-426552700 @rhtyd may be this helps.. Looks like routing goes in such way, that packets do not go through SNAT rule if two vms are in on TIER and vm1 wants to connect to vm2 through PUBLIC IP, it should look like: vm1 internal ip -> VR SNAT -> VR DNAT -> vm2 internal ip **now on vm2 I can see packets from vm1, but** source ip is set to vm1 internal ip (not VR SNAT) So if I try telnet from vm1 to VR publicIP:80 (which is forwarded to vm2:80), on vm2 I can see packets on port 80, but these packets are from vm1 internal ip. Next, **I even can see replies from vm2 on vm1**, but because this replies are coming from vm2 directly to vm1:internal ip and not from VR (how it should be), in fact connection is not established This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] izenk edited a comment on issue #2862: VR stop/start/reboot commands failed
izenk edited a comment on issue #2862: VR stop/start/reboot commands failed URL: https://github.com/apache/cloudstack/issues/2862#issuecomment-424362909 apache2 service is not started even after VPC restart. Don't now if it is related to described problem... There only logs related to apache2 is: ~~~ root@r-190-VM:~# grep apache /var/log/cloud.log Tue Sep 25 13:59:41 UTC 2018 Setting up apache web server for VPC 2018-09-25 13:59:52,686 CsHelper.py copy:264 Copied /etc/apache2/vhost.template to /etc/apache2/sites-enabled/vhost-172.16.0.17.conf 2018-09-25 13:59:52,690 CsFile.py commit:66 Wrote edited file /etc/apache2/sites-enabled/vhost-172.16.0.17.conf 2018-09-25 13:59:54,456 CsHelper.py copy:264 Copied /etc/apache2/vhost.template to /etc/apache2/sites-enabled/vhost-172.16.0.1.conf 2018-09-25 13:59:54,461 CsFile.py commit:66 Wrote edited file /etc/apache2/sites-enabled/vhost-172.16.0.1.conf 2018-09-25 13:59:55,773 CsHelper.py copy:264 Copied /etc/apache2/vhost.template to /etc/apache2/sites-enabled/vhost-172.16.0.33.conf 2018-09-25 13:59:55,776 CsFile.py commit:66 Wrote edited file /etc/apache2/sites-enabled/vhost-172.16.0.33.conf 2018-09-25 13:59:57,076 CsHelper.py copy:264 Copied /etc/apache2/vhost.template to /etc/apache2/sites-enabled/vhost-172.16.0.49.conf 2018-09-25 13:59:57,080 CsFile.py commit:66 Wrote edited file /etc/apache2/sites-enabled/vhost-172.16.0.49.conf 2018-09-25 13:59:58,459 CsHelper.py copy:264 Copied /etc/apache2/vhost.template to /etc/apache2/sites-enabled/vhost-172.16.0.65.conf 2018-09-25 13:59:58,463 CsFile.py commit:66 Wrote edited file /etc/apache2/sites-enabled/vhost-172.16.0.65.conf 2018-09-25 13:59:59,926 CsHelper.py copy:264 Copied /etc/apache2/vhost.template to /etc/apache2/sites-enabled/vhost-172.16.0.81.conf 2018-09-25 13:59:59,930 CsFile.py commit:66 Wrote edited file /etc/apache2/sites-enabled/vhost-172.16.0.81.conf ~~~ apache2 error log is clean. How apache2 should be started? By systemd or by some cloud scripts? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] resmo edited a comment on issue #2862: VR stop/start/reboot commands failed
resmo edited a comment on issue #2862: VR stop/start/reboot commands failed URL: https://github.com/apache/cloudstack/issues/2862#issuecomment-426533039 we also hit this issue. vmware 5.5. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] resmo commented on issue #2862: VR stop/start/reboot commands failed
resmo commented on issue #2862: VR stop/start/reboot commands failed URL: https://github.com/apache/cloudstack/issues/2862#issuecomment-426533039 we also hit this issue. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] resmo edited a comment on issue #2862: VR stop/start/reboot commands failed
resmo edited a comment on issue #2862: VR stop/start/reboot commands failed URL: https://github.com/apache/cloudstack/issues/2862#issuecomment-426533039 we also hit this issue. vmware 5.5 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
