[GitHub] [cloudstack] blueorangutan commented on issue #3540: [WIP DO NOT MERGE] VM ingestion
blueorangutan commented on issue #3540: [WIP DO NOT MERGE] VM ingestion URL: https://github.com/apache/cloudstack/pull/3540#issuecomment-525028477 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-265 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [cloudstack] GabrielBrascher opened a new pull request #3571: Unable to deploy VMs via UI in advanced networks with SG and IPv6 cidr
GabrielBrascher opened a new pull request #3571: Unable to deploy VMs via UI in advanced networks with SG and IPv6 cidr URL: https://github.com/apache/cloudstack/pull/3571 ## Description When deploying a VM via UI, networks that have all the following characteristics are not listed on the wizard: - advanced networking with security groups - traffic type of "Guest" - guest type of "Shared" - IPv6 CIDR not null This PR fixes it by removing the verification that counts the IPs from UserIpv6AddressVO in order to check if it can use the network for deploying new VMs in UI [1]. Table "user_ipv6_address" (UserIpv6AddressVO) is empty and will always be as it is a legacy code/table, not used in any IP allocation flow. Therefore, the removed verification should be removed. [1] com.cloud.network.NetworkModelImpl.canUseForDeploy(Network) This PR fixes #3570 ### Why it happens The Javascript code adds the parameter `canusefordeploy=true` on the API call when the network is an advanced network with security groups. With that, the endpoint (management server) expects "canUseForDeploy" to be _true_; however, the returned value is false due to not finding IPv6 addresses available in the network, which makes the UI to not list those networks. **#3569 IPv6 code cleanup:** several PRs will be created in the near future aiming a complete cleanup on IPv6 code in order to avoid such mistakes to repeat ## Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [x] Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [cloudstack] GabrielBrascher opened a new issue #3570: Cannot choose network on UI when network has SG and IPv6 cidr not null
GabrielBrascher opened a new issue #3570: Cannot choose network on UI when network has SG and IPv6 cidr not null URL: https://github.com/apache/cloudstack/issues/3570 # ISSUE TYPE * Bug Report # COMPONENT NAME ~~~ UI and Network (NetworkModelImpl) ~~~ # CLOUDSTACK VERSION ~~~ +4.12 ~~~ # CONFIGURATION This issue happens when a network has all the following characteristics: - advanced networking with security groups - traffic type of "Guest" - guest type of "Shared" - IPv6 cidr not null # SUMMARY The Javascript code adds the parameter `canusefordeploy=true` on the API call when the network is an advanced network with security groups. With that, the endpoint (management server) expects "canUseForDeploy" == true; however, the returned value is false due to not finding IPv6 addresses available in the network which makes the UI to not list the networks. Table "user_ipv6_address" (UserIpv6AddressVO) is empty and will always be (as it is a legacy code/table, not used in any IP allocation flow). I will be soon sending a PR fixing it by removing that IPv6 address verification. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [cloudstack] wido opened a new issue #3569: IPv6 code cleanup
wido opened a new issue #3569: IPv6 code cleanup URL: https://github.com/apache/cloudstack/issues/3569 # ISSUE TYPE * Improvement Request # COMPONENT NAME ~~~ IPv6 Basic Networking Advanced Networking ~~~ # CLOUDSTACK VERSION ~~~ master ~~~ # CONFIGURATION IPv6 # SUMMARY A lot of the current IPv6 code dates back to 2013 and is poorly implemented. This code copied IPv4 logic like allocating addresses in a table and then handing them out through DHCP to an Instance to IPv6 and that is not how it works with IPv6. In Basic Networking and Advanced Networking with Shared Networks IPv6 already works and Security Grouping also supports IPv6. A lot of the code around IPv6 in CloudStack however still applies logic like "startip" and "endip" for IPv6 while this isn't needed as just the "cidr" is sufficient. Cleaning up this code will not break existing functionality, but it will remove a lot of dead code and make it more clear for other developers on how the flow works. This issue is here so that future PRs (which me and @GabrielBrascher will open) can refer to this issue. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [cloudstack] onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present
onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present URL: https://github.com/apache/cloudstack/issues/3557#issuecomment-524920883 @joschi36 has pushed a proposed fix: https://code.launchpad.net/~joschi36/cloud-init/+git/cloud-init/+merge/371807 With this fix, cloud-init will first consult the host `data-server` before falling back on the previous behaviour. While this doesn't address the case where multiple default gateways are available with only some running the metadata server, it should at least be much more reliable than just looking at the latest DHCP lease. @ustcweizhou @rhtyd @DaanHoogland @PaulAngus Please let me know what you think. I'll gladly push an update to http://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html if you think this is the right way to go. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [cloudstack] wido commented on issue #3568: Security Groups are not properly applied on KVM with multiple NICs
wido commented on issue #3568: Security Groups are not properly applied on KVM with multiple NICs URL: https://github.com/apache/cloudstack/issues/3568#issuecomment-524907799 I've been reading the code a bit more and things go horribly wrong here. *security_group.py* is called twice, one time for each NIC. Now, when this is called with the argument *default_network_rules* it creates (and clears existing) a ipset for the VM: - i-2-185-VM - i-2-185-VM-6 When you call this *twice* the ipset will *only* contain the last arguments: root@hv-138-a05-24:~# ipset list i-2-185-VM Name: i-2-185-VM Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem 65536 Size in memory: 136 References: 4 Number of entries: 1 Members: 185.109.216.175 root@hv-138-a05-24:~# ipset list i-2-185-VM-6 Name: i-2-185-VM-6 Type: hash:net Revision: 6 Header: family inet6 hashsize 1024 maxelem 65536 Size in memory: 1352 References: 9 Number of entries: 2 Members: 2a05:1500:600::21ff:fe5b:2 fe80::21ff:fe5b:2 root@hv-138-a05-24:~# As you can see the ips in both the IPv4 and IPv6 ipset are only the IPs of the second NIC. What we should do here is create separate ipsets for *each* NIC. Or we add *all* IPs to the ipset. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [cloudstack] wido commented on issue #3526: Incorrect work of getFreeMemory() in LibvirtStartCommandWrapper.java
wido commented on issue #3526: Incorrect work of getFreeMemory() in LibvirtStartCommandWrapper.java URL: https://github.com/apache/cloudstack/issues/3526#issuecomment-524885236 @GabrielBrascher Could you look into this? Seems like a valid scenario. We probably need a try/catch around the point where we query the domain from libvirt. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [cloudstack] wido commented on a change in pull request #3563: Limit API from trying to start a VM that is already running
wido commented on a change in pull request #3563: Limit API from trying to
start a VM that is already running
URL: https://github.com/apache/cloudstack/pull/3563#discussion_r317629660
##
File path: server/src/main/java/com/cloud/vm/UserVmManagerImpl.java
##
@@ -4591,6 +4591,10 @@ public void finalizeStop(VirtualMachineProfile profile,
Answer answer) {
throw new PermissionDeniedException("The owner of " + vm + " is
disabled: " + vm.getAccountId());
}
+if (vm.getState()== State.Running){
+throw new InvalidParameterValueException("The virtual machine "+
vm.getDisplayName()+ " is already running");
Review comment:
Do we want to return ths displayname here and not the regular name of the VM?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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] [cloudstack] wido commented on issue #3568: Security Groups are not properly applied on KVM with multiple NICs
wido commented on issue #3568: Security Groups are not properly applied on KVM with multiple NICs URL: https://github.com/apache/cloudstack/issues/3568#issuecomment-524881364 Ping @ustcweizhou as this might be related to issue #3045 he created. Can you comment? This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [cloudstack] wido opened a new issue #3568: Security Groups are not properly applied on KVM with multiple NICs
wido opened a new issue #3568: Security Groups are not properly applied on KVM
with multiple NICs
URL: https://github.com/apache/cloudstack/issues/3568
# ISSUE TYPE
* Bug Report
Might be related to #3045
# COMPONENT NAME
~~~
KVM
Security Groups
~~~
# CLOUDSTACK VERSION
~~~
4.12
~~~
# CONFIGURATION
* Advanced Networking
* Instance with NICs in two different networks
# OS / ENVIRONMENT
Ubuntu 18.04
# SUMMARY
We have two networks:
Network 1: 10.100.16.0/24
Network 2: 185.109.216.0/24
A Virtual Machine has it's primary NIC in *Network 1* and a Second NIC is
attached in *Network 2*.
After a Stop/Start the VM doesn't respond anymore as the improper Security
Group rules are applied.
The *nics* part of the StartCommand:
[
{
"deviceId": 0,
"networkRateMbps": 5000,
"defaultNic": true,
"pxeDisable": false,
"nicUuid": "9137ceb6-3911-4f58-a027-cd62e9b6d383",
"details": {
"PromiscuousMode": "false",
"MacAddressChanges": "true",
"ForgedTransmits": "true"
},
"dpdkDisabled": false,
"uuid": "ad2f94f1-3b6e-4351-bda7-481195681ab8",
"ip": "10.100.16.228",
"netmask": "255.255.255.0",
"gateway": "10.100.16.1",
"mac": "1e:00:82:00:04:48",
"dns1": "93.180.70.22",
"dns2": "93.180.70.30",
"broadcastType": "Vlan",
"type": "Guest",
"broadcastUri": "vxlan://504",
"isolationUri": "vxlan://504",
"isSecurityGroupEnabled": true,
"ip6address": "2a05:1500:600:1:1c00:82ff:fe00:448",
"ip6cidr": "2a05:1500:600:1::/64"
},
{
"deviceId": 1,
"networkRateMbps": 200,
"defaultNic": false,
"pxeDisable": false,
"nicUuid": "c778c9c4-864b-4fe9-8422-ee8689bf60a4",
"details": {
"PromiscuousMode": "false",
"MacAddressChanges": "true",
"ForgedTransmits": "true"
},
"dpdkDisabled": false,
"uuid": "a0234ec3-bdb6-46b8-80a1-37144d7c3928",
"ip": "185.109.216.175",
"netmask": "255.255.255.0",
"gateway": "185.109.216.3",
"mac": "02:00:21:5b:00:02",
"dns1": "93.180.70.22",
"dns2": "93.180.70.30",
"broadcastType": "Vlan",
"type": "Guest",
"broadcastUri": "vxlan://500",
"isolationUri": "vxlan://500",
"isSecurityGroupEnabled": true,
"ip6address": "2a05:1500:600::21ff:fe5b:2",
"ip6cidr": "2a05:1500:600::/64"
}
]
Here you see both NICs and their different networks and VNI.
When the VM is started the Security Groups are applied to the incorrect
bridges and vnet devices.
2019-08-26 15:12:36,486 DEBUG [kvm.resource.BridgeVifDriver]
(agentRequest-Handler-9:null) (logid:c3238d85)
nic=[Nic:Guest-10.100.16.228-vxlan://504]
2019-08-26 15:12:36,486 DEBUG [kvm.resource.BridgeVifDriver]
(agentRequest-Handler-9:null) (logid:c3238d85) Executing:
/usr/share/modifyvxlan.sh -v 504 -p vxlan100 -b brvx-504 -o add
2019-08-26 15:12:36,517 DEBUG [kvm.resource.BridgeVifDriver]
(agentRequest-Handler-9:null) (logid:c3238d85)
nic=[Nic:Guest-185.109.216.175-vxlan://500]
2019-08-26 15:12:36,517 DEBUG [kvm.resource.BridgeVifDriver]
(agentRequest-Handler-9:null) (logid:c3238d85) Executing:
/usr/share/modifyvxlan.sh -v 500 -p vxlan100 -b brvx-500 -o add
So far so good.
VNI 504: 10.100.16.228
VNI 500: 185.109.216.175
The XML definition of the VM now looks like:
~~~
~~~
Now we see:
| VNI | Address | VNET |
|--|-|-|
| 504 | 10.100.16.228 | vnet13 |
| 500 | 185.109.216.175 | vnet90 |
The KVM Agent now starts to apply the Security Group rules:
2019-08-26 15:12:37,243 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-9:null) (logid:c3238d85) Executing:
/usr/share/cloudstack-common/scripts/vm/network/security_group.py
default_network_rules --vmname i-2-185-VM --vmid 185 --vmip 10.100.16.228
--vmip6 2a05:1500:600:1:1c00:82ff:fe00:448 --vmmac 1e:00:82:00:04:48 --vif
vnet13 --brname brvx-504 --nicsecips 0;
That looks good! *vnet13* is indeed the proper device for *10.100.16.228*.
It now continues to execute security group rules:
2019-08-26 15:12:38,837 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-9:null) (logid:c3238d85) Executing:
/usr/share/cloudstack-common/scripts/vm/network/security_group.py
default_network_rules --vmname i-2-185-VM --vmid 185 --vmip 185.109.216.175
--vmip6 2a05:1
[GitHub] [cloudstack] DaanHoogland closed pull request #3567: fix xenserver 7.0.1 os mapping typo
DaanHoogland closed pull request #3567: fix xenserver 7.0.1 os mapping typo URL: https://github.com/apache/cloudstack/pull/3567 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [cloudstack] PaulAngus opened a new pull request #3567: fix xenserver 7.0.1 os mapping typo
PaulAngus opened a new pull request #3567: fix xenserver 7.0.1 os mapping typo URL: https://github.com/apache/cloudstack/pull/3567 ## Description ## Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases) ## Screenshots (if appropriate): ## How Has This Been Tested? This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [cloudstack] onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present
onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present URL: https://github.com/apache/cloudstack/issues/3557#issuecomment-524793882 I think we found the "right" way to do this: If the metadata server is enabled on an interface, it will offer the special hostname `data-server` on its DNS server. This is already the case, and I really don't understand why cloud-init isn't already using that. This should always be the first host that cloud-init checks. As a second step, the "only latest lease" heuristic should go be replaced with "try all leases in reverse chronological order". Ideally, _all_ virtual routers should allow resolving the `data-server` hostname, returning the IP address of a router that has the metadata server enabled. If none of them do, the hostname shouldn't exist. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [cloudstack] blueorangutan commented on issue #3567: fix xenserver 7.0.1 os mapping typo
blueorangutan commented on issue #3567: fix xenserver 7.0.1 os mapping typo URL: https://github.com/apache/cloudstack/pull/3567#issuecomment-524747638 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-264 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
