[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003703#comment-15003703 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/985#issuecomment-156360759 @ustcweizhou Yes, it does. See the patches I posted above. > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wilder Rodrigues updated CLOUDSTACK-9015: - Fix Version/s: 4.6.1 > Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER > -- > > Key: CLOUDSTACK-9015 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 > Environment: CloudStack master(2015/10/31) 4.6.0-snapshot > Hypervisor CentOS6/KVM > SystemVM > build #654 (2015/10/22 19:27:55) > http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2 >Reporter: satoru nakaya >Assignee: Wilder Rodrigues >Priority: Critical > Fix For: 4.6.1 > > > Steps of reproduce. > 1)Create VPC (Redundant VPC offering) > 2)Create tier > 3)Create VM Instance on this tier > 4)Check Redundant state (good) >r-14-VM Redundant state:MASTER >r-15-VM Redundant state:BACKUP > 5) Reboot Router r-14-VM > 6)Check Redundant state (good) >r-14-VM Redundant state:BACKUP >r-15-VM Redundant state:MASTER > 7) Reboot Router r-15-VM > 8)Check Redundant state (bad) >r-14-VM Redundant state:BACKUP >r-15-VM Redundant state:BACKUP > 9)Check Log(r-14-VM's /var/log/messages) > Nov 1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) > sending 0 priority > Nov 1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error > Nov 1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter > function error > Nov 1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter > function error > Nov 1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error > Nov 1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter > function error > Nov 1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error > 10)Check Log(r-15-VM's /var/log/messages) > Nov 1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) > sending 0 priority > Nov 1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error > Nov 1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter > function error > Nov 1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter > function error > Nov 1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error > Nov 1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter > function error > Nov 1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9057) upgrade to 4.6 requires 4.5 templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003732#comment-15003732 ] ASF GitHub Bot commented on CLOUDSTACK-9057: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1061#issuecomment-156365263 I will test the upgrade, @DaanHoogland and LGTM afterwards. Cheers, Wilder > upgrade to 4.6 requires 4.5 templates > - > > Key: CLOUDSTACK-9057 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9057 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.2 >Reporter: Daan Hoogland >Assignee: Daan Hoogland >Priority: Minor > > the upgrade coe requiring 4.5 system templates can be removed. > There is a ticket somewhere to make the upgrade code more generic. for this > the maps in the method(s) have to be moved to a central location. The update > call can be an API using those maps. this for prosperity, now remove! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9050) Virtual Router Static-NAT rules bind to wrong public interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003738#comment-15003738 ] ASF GitHub Bot commented on CLOUDSTACK-9050: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1063#issuecomment-156368254 @ustcweizhou @dsclose Dude, this script is not used anymore! Please test it with maven, or manually, and you will see that it doesn't apply. The only place the file is reference is here ==>  It should have been removed with the Routers Persistent Configuration / Redundant VPCs. I'm glad to help to get the fix in the right place, but please test against 4.6.0/master using a 4.6.0 SystemVM. Cheers, Wilder > Virtual Router Static-NAT rules bind to wrong public interface > -- > > Key: CLOUDSTACK-9050 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose > > When a virtual router has multiple public NICs (in a scenario where multiple > guest subnets are available) the router is liable to create static-NAT rules > for certain IP addresses that refer to incorrect interfaces. > Example > -- > A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are > used for guest IP addresses. This may lead to the following IP addresses > being assigned to a virtual router: > eth0: 10.1.1.1/24 > eth1: 169.254.3.82/16 > eth2: 123.123.123.130/26 and 123.123.123.150/26 > eth3: 123.123.123.19/25 and 123.123.123.120/25 > Scenario: > The user decides to create two static NATs. One from 123.123.123.120/25, the > other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range. > Result: > 123.123.123.120/25 is successfully configured as a static NAT and works > immediately. All NAT rules in the resulting iptables correctly refer to eth3 > as the source or destination interface. Cloudstack reports that > 123.123.123.19/25 is successfully configured but it does not work. All NAT > rules in the resulting iptables INCORRECTLY refer to eth2 as the source or > destination interface. > Cause: > The virtual router greps the output of "ip addr show dev ethN" until it finds > the IP address. However, this command also prints out the broadcast address > for the subnet which may partially include an IP address from a similar > range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2 > because the IP address was matched by the broadcast address of > 123.123.123.191. > This is liable to occur on any router with NICs on two similar subnets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9050) Virtual Router Static-NAT rules bind to wrong public interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003783#comment-15003783 ] ASF GitHub Bot commented on CLOUDSTACK-9050: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1063#issuecomment-156379177 @dsclose, please have a look at: ``` ./cloud-systemvm/patches/debian/config/opt/cloud/bin/configure.py ``` Cheers, Wilder > Virtual Router Static-NAT rules bind to wrong public interface > -- > > Key: CLOUDSTACK-9050 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose > > When a virtual router has multiple public NICs (in a scenario where multiple > guest subnets are available) the router is liable to create static-NAT rules > for certain IP addresses that refer to incorrect interfaces. > Example > -- > A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are > used for guest IP addresses. This may lead to the following IP addresses > being assigned to a virtual router: > eth0: 10.1.1.1/24 > eth1: 169.254.3.82/16 > eth2: 123.123.123.130/26 and 123.123.123.150/26 > eth3: 123.123.123.19/25 and 123.123.123.120/25 > Scenario: > The user decides to create two static NATs. One from 123.123.123.120/25, the > other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range. > Result: > 123.123.123.120/25 is successfully configured as a static NAT and works > immediately. All NAT rules in the resulting iptables correctly refer to eth3 > as the source or destination interface. Cloudstack reports that > 123.123.123.19/25 is successfully configured but it does not work. All NAT > rules in the resulting iptables INCORRECTLY refer to eth2 as the source or > destination interface. > Cause: > The virtual router greps the output of "ip addr show dev ethN" until it finds > the IP address. However, this command also prints out the broadcast address > for the subnet which may partially include an IP address from a similar > range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2 > because the IP address was matched by the broadcast address of > 123.123.123.191. > This is liable to occur on any router with NICs on two similar subnets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9050) Virtual Router Static-NAT rules bind to wrong public interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003793#comment-15003793 ] ASF GitHub Bot commented on CLOUDSTACK-9050: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1063#issuecomment-156382390 @dsclose Scripts not in use since 4.6.0: ``` public static final String FIREWALL_EGRESS = "firewall_egress.sh"; public static final String IPASSOC = "ipassoc.sh"; public static final String VMDATA = "vmdata.py"; public static final String VPC_ACL = "vpc_acl.sh"; public static final String VPC_GUEST_NETWORK = "vpc_guestnw.sh"; public static final String VPC_PRIVATEGW_ACL = "vpc_privategw_acl.sh"; public static final String VPC_STATIC_NAT = "vpc_staticnat.sh"; public static final String VPC_STATIC_ROUTE = "vpc_staticroute.sh"; public static final String S2SVPN_IPSEC = "ipsectunnel.sh"; public static final String DHCP = "edithosts.sh"; public static final String DNSMASQ_CONFIG = "dnsmasq.sh"; public static final String FIREWALL_INGRESS = "firewall_ingress.sh"; public static final String FIREWALL_NAT = "firewall_nat.sh"; public static final String IPALIAS_CREATE = "createipAlias.sh"; public static final String IPALIAS_DELETE = "deleteipAlias.sh"; public static final String LB = "loadbalancer.sh"; public static final String MONITOR_SERVICE = "monitor_service.sh"; public static final String PASSWORD = "savepassword.sh"; public static final String VPC_IPASSOC = "vpc_ipassoc.sh"; public static final String VPC_LB = "vpc_loadbalancer.sh"; public static final String VPC_PRIVATEGW = "vpc_privateGateway.sh"; public static final String VPC_PORTFORWARDING = "vpc_portforwarding.sh"; public static final String VPC_SOURCE_NAT = "vpc_snat.sh"; public static final String VPN_L2TP = "vpn_l2tp.sh"; ``` I will remove all of them from the project to avoid misunderstands. Cheers, Wilder > Virtual Router Static-NAT rules bind to wrong public interface > -- > > Key: CLOUDSTACK-9050 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose > > When a virtual router has multiple public NICs (in a scenario where multiple > guest subnets are available) the router is liable to create static-NAT rules > for certain IP addresses that refer to incorrect interfaces. > Example > -- > A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are > used for guest IP addresses. This may lead to the following IP addresses > being assigned to a virtual router: > eth0: 10.1.1.1/24 > eth1: 169.254.3.82/16 > eth2: 123.123.123.130/26 and 123.123.123.150/26 > eth3: 123.123.123.19/25 and 123.123.123.120/25 > Scenario: > The user decides to create two static NATs. One from 123.123.123.120/25, the > other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range. > Result: > 123.123.123.120/25 is successfully configured as a static NAT and works > immediately. All NAT rules in the resulting iptables correctly refer to eth3 > as the source or destination interface. Cloudstack reports that > 123.123.123.19/25 is successfully configured but it does not work. All NAT > rules in the resulting iptables INCORRECTLY refer to eth2 as the source or > destination interface. > Cause: > The virtual router greps the output of "ip addr show dev ethN" until it finds > the IP address. However, this command also prints out the broadcast address > for the subnet which may partially include an IP address from a similar > range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2 > because the IP address was matched by the broadcast address of > 123.123.123.191. > This is liable to occur on any router with NICs on two similar subnets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9050) Virtual Router Static-NAT rules bind to wrong public interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003802#comment-15003802 ] ASF GitHub Bot commented on CLOUDSTACK-9050: Github user borisroman commented on the pull request: https://github.com/apache/cloudstack/pull/1063#issuecomment-156384240 @dsclose Thanks for your PR, it shows support! As the script is not in use anymore, would you close the PR? > Virtual Router Static-NAT rules bind to wrong public interface > -- > > Key: CLOUDSTACK-9050 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose > > When a virtual router has multiple public NICs (in a scenario where multiple > guest subnets are available) the router is liable to create static-NAT rules > for certain IP addresses that refer to incorrect interfaces. > Example > -- > A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are > used for guest IP addresses. This may lead to the following IP addresses > being assigned to a virtual router: > eth0: 10.1.1.1/24 > eth1: 169.254.3.82/16 > eth2: 123.123.123.130/26 and 123.123.123.150/26 > eth3: 123.123.123.19/25 and 123.123.123.120/25 > Scenario: > The user decides to create two static NATs. One from 123.123.123.120/25, the > other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range. > Result: > 123.123.123.120/25 is successfully configured as a static NAT and works > immediately. All NAT rules in the resulting iptables correctly refer to eth3 > as the source or destination interface. Cloudstack reports that > 123.123.123.19/25 is successfully configured but it does not work. All NAT > rules in the resulting iptables INCORRECTLY refer to eth2 as the source or > destination interface. > Cause: > The virtual router greps the output of "ip addr show dev ethN" until it finds > the IP address. However, this command also prints out the broadcast address > for the subnet which may partially include an IP address from a similar > range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2 > because the IP address was matched by the broadcast address of > 123.123.123.191. > This is liable to occur on any router with NICs on two similar subnets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9050) Virtual Router Static-NAT rules bind to wrong public interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003856#comment-15003856 ] ASF GitHub Bot commented on CLOUDSTACK-9050: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1063#issuecomment-15648 @borisroman @dsclose how about changing it to a pr that removes the script ;) > Virtual Router Static-NAT rules bind to wrong public interface > -- > > Key: CLOUDSTACK-9050 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose > > When a virtual router has multiple public NICs (in a scenario where multiple > guest subnets are available) the router is liable to create static-NAT rules > for certain IP addresses that refer to incorrect interfaces. > Example > -- > A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are > used for guest IP addresses. This may lead to the following IP addresses > being assigned to a virtual router: > eth0: 10.1.1.1/24 > eth1: 169.254.3.82/16 > eth2: 123.123.123.130/26 and 123.123.123.150/26 > eth3: 123.123.123.19/25 and 123.123.123.120/25 > Scenario: > The user decides to create two static NATs. One from 123.123.123.120/25, the > other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range. > Result: > 123.123.123.120/25 is successfully configured as a static NAT and works > immediately. All NAT rules in the resulting iptables correctly refer to eth3 > as the source or destination interface. Cloudstack reports that > 123.123.123.19/25 is successfully configured but it does not work. All NAT > rules in the resulting iptables INCORRECTLY refer to eth2 as the source or > destination interface. > Cause: > The virtual router greps the output of "ip addr show dev ethN" until it finds > the IP address. However, this command also prints out the broadcast address > for the subnet which may partially include an IP address from a similar > range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2 > because the IP address was matched by the broadcast address of > 123.123.123.191. > This is liable to occur on any router with NICs on two similar subnets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9050) Virtual Router Static-NAT rules bind to wrong public interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003910#comment-15003910 ] ASF GitHub Bot commented on CLOUDSTACK-9050: Github user borisroman commented on the pull request: https://github.com/apache/cloudstack/pull/1063#issuecomment-156414832 @DaanHoogland That's already being done by @wilderrodrigues. Therefore this one is obsolete. > Virtual Router Static-NAT rules bind to wrong public interface > -- > > Key: CLOUDSTACK-9050 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose > > When a virtual router has multiple public NICs (in a scenario where multiple > guest subnets are available) the router is liable to create static-NAT rules > for certain IP addresses that refer to incorrect interfaces. > Example > -- > A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are > used for guest IP addresses. This may lead to the following IP addresses > being assigned to a virtual router: > eth0: 10.1.1.1/24 > eth1: 169.254.3.82/16 > eth2: 123.123.123.130/26 and 123.123.123.150/26 > eth3: 123.123.123.19/25 and 123.123.123.120/25 > Scenario: > The user decides to create two static NATs. One from 123.123.123.120/25, the > other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range. > Result: > 123.123.123.120/25 is successfully configured as a static NAT and works > immediately. All NAT rules in the resulting iptables correctly refer to eth3 > as the source or destination interface. Cloudstack reports that > 123.123.123.19/25 is successfully configured but it does not work. All NAT > rules in the resulting iptables INCORRECTLY refer to eth2 as the source or > destination interface. > Cause: > The virtual router greps the output of "ip addr show dev ethN" until it finds > the IP address. However, this command also prints out the broadcast address > for the subnet which may partially include an IP address from a similar > range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2 > because the IP address was matched by the broadcast address of > 123.123.123.191. > This is liable to occur on any router with NICs on two similar subnets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8444) [Hyper-V] Add a Failover Clustering of Hyper-V support in CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15005043#comment-15005043 ] Thomas commented on CLOUDSTACK-8444: Hey any updates in this ? 4.6 will be released soon, so will this be a new feature? > [Hyper-V] Add a Failover Clustering of Hyper-V support in CloudStack > > > Key: CLOUDSTACK-8444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8444 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > > This will enable us to add support for HA and cluster shared volume in Hyper-V -- This message was sent by Atlassian JIRA (v6.3.4#6332)
