[jira] [Commented] (CLOUDSTACK-9849) Cannot migrate VMware VM to host in different cluster

[Rajani Karuturi (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965407#comment-15965407
 ] 

Rajani Karuturi commented on CLOUDSTACK-9849:
-

[~sateeshc] any update? were you able to reproduce? 

> Cannot migrate VMware VM to host in different cluster
> -
>
> Key: CLOUDSTACK-9849
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9849
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.10.0.0
> Environment: VMware 5.5
>Reporter: Mike Tutkowski
>Assignee: Sateesh Chodapuneedi
>Priority: Blocker
> Fix For: 4.10.0.0
>
>
> I have two VMware clusters in the same VMware datacenter. Each cluster has a 
> single ESXi 5.5 host in it.
> I have a shared primary storage in each cluster (I have tried this scenario 
> with both NFS and iSCSI shared primary storage and the results are the same).
> I have a VM with its root disk running on primary storage from a host in the 
> one cluster and I cannot migrate this VM and its root disk to the host in the 
> other cluster (both primary storages even make use of the same storage tag).
> The source host has access to the source datastore, but it does not have 
> access to the target datastore.
> The target host has access to the target datastore, but it does not have 
> access to the source datastore.
> When I try to perform the migration, it fails with the following error 
> message:
> Required property datastore is missing from data object of type 
> VirtualMachineRelocateSpecDiskLocator
> while parsing serialized DataObject of type vim.vm.RelocateSpec.DiskLocator
> at line 1, column 327
> while parsing property "disk" of static type 
> ArrayOfVirtualMachineRelocateSpecDiskLocator
> while parsing serialized DataObject of type vim.vm.RelocateSpec
> at line 1, column 187
> while parsing call information for method RelocateVM_Task
> at line 1, column 110
> while parsing SOAP body
> at line 1, column 102
> while parsing SOAP envelope
> at line 1, column 38
> while parsing HTTP request for method relocate
> on object of type vim.VirtualMachine
> at line 1, column 0
> When I run the test in the debugger and look at the 
> VirtualMachineRelocateSpec instance passed to 
> VirtualMachineMO.changeDatastore, I see the target datastore is populated, 
> but not the source datastore:
> http://imgur.com/a/vtKcq datastore-66 is the target datastore
> Based on an e-mail chain on dev@, it sounds like my scenario should work.
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965396#comment-15965396
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 7b78a22c5e4acb60d3c0ddf57bd54013d7d9add3 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7b78a22 ]

Merge release branch 4.9 to master

* 4.9:
  CLOUDSTACK-9591: Fix guest VM ovf xml to remove network nodes
  CLOUDSTACK-9591: Fix systemvmtemplate to not include network details


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965393#comment-15965393
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 7b78a22c5e4acb60d3c0ddf57bd54013d7d9add3 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7b78a22 ]

Merge release branch 4.9 to master

* 4.9:
  CLOUDSTACK-9591: Fix guest VM ovf xml to remove network nodes
  CLOUDSTACK-9591: Fix systemvmtemplate to not include network details


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965391#comment-15965391
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 96700a04a9ee436ff19d932c111c4078da7eb6b0 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=96700a0 ]

Merge pull request #2022 from shapeblue/4.9-systemvm-fix-vmware-portgroups

[dvswitch blocker] CLOUDSTACK-9591: Fix systemvmtemplate to not include network 
detailsThis removes nic/network specific details while exporting the 
systemvmtemplate for vmware (ova file). Having this causes the ssvms to not 
deploy in dvswitch-based vmware environments that have no vswitch portgroups 
(dummy etc). Tested this on a local Trillian env.

* pr/2022:
  CLOUDSTACK-9591: Fix guest VM ovf xml to remove network nodes
  CLOUDSTACK-9591: Fix systemvmtemplate to not include network details

Signed-off-by: Rajani Karuturi 


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965390#comment-15965390
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 96700a04a9ee436ff19d932c111c4078da7eb6b0 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=96700a0 ]

Merge pull request #2022 from shapeblue/4.9-systemvm-fix-vmware-portgroups

[dvswitch blocker] CLOUDSTACK-9591: Fix systemvmtemplate to not include network 
detailsThis removes nic/network specific details while exporting the 
systemvmtemplate for vmware (ova file). Having this causes the ssvms to not 
deploy in dvswitch-based vmware environments that have no vswitch portgroups 
(dummy etc). Tested this on a local Trillian env.

* pr/2022:
  CLOUDSTACK-9591: Fix guest VM ovf xml to remove network nodes
  CLOUDSTACK-9591: Fix systemvmtemplate to not include network details

Signed-off-by: Rajani Karuturi 


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965388#comment-15965388
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 96700a04a9ee436ff19d932c111c4078da7eb6b0 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=96700a0 ]

Merge pull request #2022 from shapeblue/4.9-systemvm-fix-vmware-portgroups

[dvswitch blocker] CLOUDSTACK-9591: Fix systemvmtemplate to not include network 
detailsThis removes nic/network specific details while exporting the 
systemvmtemplate for vmware (ova file). Having this causes the ssvms to not 
deploy in dvswitch-based vmware environments that have no vswitch portgroups 
(dummy etc). Tested this on a local Trillian env.

* pr/2022:
  CLOUDSTACK-9591: Fix guest VM ovf xml to remove network nodes
  CLOUDSTACK-9591: Fix systemvmtemplate to not include network details

Signed-off-by: Rajani Karuturi 


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965385#comment-15965385
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 00e1b462f62366cbe3135c812de2972eb6af68c2 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=00e1b46 ]

CLOUDSTACK-9591: Fix guest VM ovf xml to remove network nodes

This removes network details from the guest VM template OVF xml before deploying
a VM which would fail in case of dvswitch-based vmware environment with no
dummy/existing vswitch.

Signed-off-by: Rohit Yadav 


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965386#comment-15965386
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user jayapalu commented on the issue:

https://github.com/apache/cloudstack/pull/1908
  
Jenkins got timed out. I am force pushing again to trigger jenkins.


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965383#comment-15965383
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 92fd5bee3d827d6811d077098d30c52f1d625ab0 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=92fd5be ]

CLOUDSTACK-9591: Fix systemvmtemplate to not include network details

This removes nic/network specific details while exporting the systemvmtemplate
for vmware (ova file). Having this causes the ssvms to not deploy in
dvswitch-based vmware environments that have no vswitch portgroups (dummy etc).
Tested this on a local Trillian env.

Signed-off-by: Rohit Yadav 


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965379#comment-15965379
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9462:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/2033
  
@rhtyd Can you add "This closes #1950" to the description of this PR?
can you force push to make jenkins happy? 

@ustcweizhou can you review please?



> Systemd packaging for Ubuntu 16.04
> --
>
> Key: CLOUDSTACK-9462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> Support for building deb packages that will work on Ubuntu 16.04



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965377#comment-15965377
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 96700a04a9ee436ff19d932c111c4078da7eb6b0 in cloudstack's branch 
refs/heads/4.9 from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=96700a0 ]

Merge pull request #2022 from shapeblue/4.9-systemvm-fix-vmware-portgroups

[dvswitch blocker] CLOUDSTACK-9591: Fix systemvmtemplate to not include network 
detailsThis removes nic/network specific details while exporting the 
systemvmtemplate for vmware (ova file). Having this causes the ssvms to not 
deploy in dvswitch-based vmware environments that have no vswitch portgroups 
(dummy etc). Tested this on a local Trillian env.

* pr/2022:
  CLOUDSTACK-9591: Fix guest VM ovf xml to remove network nodes
  CLOUDSTACK-9591: Fix systemvmtemplate to not include network details

Signed-off-by: Rajani Karuturi 


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965374#comment-15965374
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 96700a04a9ee436ff19d932c111c4078da7eb6b0 in cloudstack's branch 
refs/heads/4.9 from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=96700a0 ]

Merge pull request #2022 from shapeblue/4.9-systemvm-fix-vmware-portgroups

[dvswitch blocker] CLOUDSTACK-9591: Fix systemvmtemplate to not include network 
detailsThis removes nic/network specific details while exporting the 
systemvmtemplate for vmware (ova file). Having this causes the ssvms to not 
deploy in dvswitch-based vmware environments that have no vswitch portgroups 
(dummy etc). Tested this on a local Trillian env.

* pr/2022:
  CLOUDSTACK-9591: Fix guest VM ovf xml to remove network nodes
  CLOUDSTACK-9591: Fix systemvmtemplate to not include network details

Signed-off-by: Rajani Karuturi 


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965372#comment-15965372
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 96700a04a9ee436ff19d932c111c4078da7eb6b0 in cloudstack's branch 
refs/heads/4.9 from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=96700a0 ]

Merge pull request #2022 from shapeblue/4.9-systemvm-fix-vmware-portgroups

[dvswitch blocker] CLOUDSTACK-9591: Fix systemvmtemplate to not include network 
detailsThis removes nic/network specific details while exporting the 
systemvmtemplate for vmware (ova file). Having this causes the ssvms to not 
deploy in dvswitch-based vmware environments that have no vswitch portgroups 
(dummy etc). Tested this on a local Trillian env.

* pr/2022:
  CLOUDSTACK-9591: Fix guest VM ovf xml to remove network nodes
  CLOUDSTACK-9591: Fix systemvmtemplate to not include network details

Signed-off-by: Rajani Karuturi 


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965370#comment-15965370
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 00e1b462f62366cbe3135c812de2972eb6af68c2 in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=00e1b46 ]

CLOUDSTACK-9591: Fix guest VM ovf xml to remove network nodes

This removes network details from the guest VM template OVF xml before deploying
a VM which would fail in case of dvswitch-based vmware environment with no
dummy/existing vswitch.

Signed-off-by: Rohit Yadav 


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965368#comment-15965368
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9591:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/2022


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965366#comment-15965366
 ] 

ASF subversion and git services commented on CLOUDSTACK-9591:
-

Commit 92fd5bee3d827d6811d077098d30c52f1d625ab0 in cloudstack's branch 
refs/heads/4.9 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=92fd5be ]

CLOUDSTACK-9591: Fix systemvmtemplate to not include network details

This removes nic/network specific details while exporting the systemvmtemplate
for vmware (ova file). Having this causes the ssvms to not deploy in
dvswitch-based vmware environments that have no vswitch portgroups (dummy etc).
Tested this on a local Trillian env.

Signed-off-by: Rohit Yadav 


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9719) [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965357#comment-15965357
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9719:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1879
  
@rhtyd at this stage, I am not looking at more PRs/features for 4.10. I 
need help on fixing the blockers for releasing 4.10 


> [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery
> --
>
> Key: CLOUDSTACK-9719
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9719
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> After HA being triggered on VMware, some VMs fail to acquire DHCP address 
> from a VR. These VMs are live migrated as part of vCenter HA to another 
> available host before the VR and couldn't acquire DHCP address as VR is not 
> migrated yet and these VMs request failed to reach the VR.
> Resolving this requires manual intervention by the CloudStack administrator; 
> the router must be rebooted or the network restarted. This behavior is not 
> ideal and will prolong downtime caused by an HA event and there is no point 
> for the non-functional virtual router to even be running. CloudStack should 
> handle this situation by setting VR restart priority to high in the vCenter 
> when HA is enabled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15965356#comment-15965356
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9591:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/2022
  
ok. merging


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CLOUDSTACK-9859) Retirement of midonet plugin (final removal ticket)

[JIRA]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rafael Weingärtner updated CLOUDSTACK-9859:
---
Description: 
Following the component retirement process defined in [1], a vote thread was 
started in [2]. The community decided to retire this Midonet plugin. This task 
represents the final step of the retirement, which is the removal of the plugin 
from CloudStacks code base.

ATTENTION: do not forget to remove midonet entries of the documentation.

[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68720798
[2] http://markmail.org/message/qigrtfirwnmct4hr

  was:
Following the component retirement process defined in [1], a vote thread was 
started in [2]. The community decided to retire this Midonet plugin. This task 
represents the final step of the retirement, which is the removal of the plugin 
from CloudStacks code base.
[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68720798
[2] http://markmail.org/message/qigrtfirwnmct4hr


> Retirement of midonet plugin (final removal ticket)
> ---
>
> Key: CLOUDSTACK-9859
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9859
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>
> Following the component retirement process defined in [1], a vote thread was 
> started in [2]. The community decided to retire this Midonet plugin. This 
> task represents the final step of the retirement, which is the removal of the 
> plugin from CloudStacks code base.
> ATTENTION: do not forget to remove midonet entries of the documentation.
> [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68720798
> [2] http://markmail.org/message/qigrtfirwnmct4hr



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9858) Retirement of midonet plugin (disabling ticket)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964894#comment-15964894
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9858:


GitHub user rafaelweingartner opened a pull request:

https://github.com/apache/cloudstack/pull/2036

[CLOUDSTACK-9858] Retirement of midonet plugin (build disabling)

Recently there have been two threads asking and discussing the “midonet” 
integration with Apache CloudStack (ACS) [1-2].

After quite some discussions, we noticed that despite having some people 
willing to use it, the plugin has never been fully developed by its vendor 
(Midokura). Further, nobody else has put the effort on fully testing and 
finishing its implementation. It seems that the plugin was incorporated into 
our code base without being fully finished. Moreover, I have asked around at 
the Midonet community, and the java client they use has changed quite a bit 
from the one we use.

It begs the question if it does not work, why do we advertise such 
integration? [3]. 
Following the component retirement process defined in [4], a vote thread 
was started in [5]. The community decided to retire this Midonet plugin. This 
task represents the first step of the retirement, which is the disabling of the 
plugin in CloudStack`s build process.
 
[1] 
http://cloudstack.markmail.org/thread/qyedle5jb2c34gsc#query:+page:1+mid:xn2zq2v3eim5vl2q+state:results
[2] 
http://cloudstack.markmail.org/message/rewzk4v7dgzpsxkm?q=midonet+order:date-backward=1#query:midonet%20order%3Adate-backward+page:1+mid:i563khxlginf6smg+state:results
[3] http://docs.cloudstack.apache.org/en/latest/networking/midonet.html
[4] 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68720798
[5] http://markmail.org/message/qigrtfirwnmct4hr

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rafaelweingartner/cloudstack 
midoneDisablingForRetirement

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/2036.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2036


commit a3f351c07e73e4a207d10e3d23003c81cb3ab58b
Author: Rafael Weingartner 
Date:   2017-04-11T20:04:10Z

[CLOUDSTACK-9858] Retirement of midonet plugin (build disabling)




> Retirement of midonet plugin (disabling ticket)
> ---
>
> Key: CLOUDSTACK-9858
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9858
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>
> Recently there have been two threads asking and discussing the “midonet” 
> integration with Apache CloudStack (ACS) [1-2].
> After quite some discussions, we noticed that despite having some people 
> willing to use it, the plugin has never been fully developed by its vendor 
> (Midokura). Further, nobody else has put the effort on fully testing and 
> finishing its implementation. It seems that the plugin was incorporated into 
> our code base without being fully finished. Moreover, I have asked around at 
> the Midonet community, and the java client they use has changed quite a bit 
> from the one we use.
> It begs the question if it does not work, why do we advertise such 
> integration? [3]. 
> Following the component retirement process defined in [4], a vote thread was 
> started in [5]. The community decided to retire this Midonet plugin. This 
> task represents the first step of the retirement, which is the disabling of 
> the plugin in CloudStack`s build process.
>  
> [1] 
> http://cloudstack.markmail.org/thread/qyedle5jb2c34gsc#query:+page:1+mid:xn2zq2v3eim5vl2q+state:results
> [2] 
> http://cloudstack.markmail.org/message/rewzk4v7dgzpsxkm?q=midonet+order:date-backward=1#query:midonet%20order%3Adate-backward+page:1+mid:i563khxlginf6smg+state:results
> [3] http://docs.cloudstack.apache.org/en/latest/networking/midonet.html
> [4] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68720798
> [5] http://markmail.org/message/qigrtfirwnmct4hr



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964527#comment-15964527
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user ProjectMoon commented on the issue:

https://github.com/apache/cloudstack/pull/1908
  
Looks good now. Not sure what's up with Jenkins though.


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9794) Unable to attach more than 14 devices to a VM

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964261#comment-15964261
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9794:


Github user sureshanaparti commented on the issue:

https://github.com/apache/cloudstack/pull/1953
  
Changes in the PR #2019.

Maximum data volumes supported field, in the _hypervisor_capabilities_ 
table, should be the attachable data volumes to the VM. This excludes the ROOT 
disk and CD-ROM. So, the hypervisor has to support max devices = maximum data 
volumes supported + 2 (ROOT and CD-ROM).

0(zero) index is considered in `getDeviceId()` for ROOT disk as the ROOT 
disk attach cmd uses this method. This has to be refactored.


> Unable to attach more than 14 devices to a VM
> -
>
> Key: CLOUDSTACK-9794
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9794
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> A limit of 13 disks is set in hypervisor_capabilities for VMware hypervisor. 
> Changed this limit to a higher value in the DB directly for the VMware and 
> tried attaching more than 14 disks. This was failing with the below exception:
> {noformat}
> 2016-08-12 18:42:53,694 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-40:ctx-56068c6b job-1015) (logid:b22938fd) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin
> java.util.NoSuchElementException
>   at java.util.ArrayList$Itr.next(ArrayList.java:794)
>   at 
> com.cloud.storage.VolumeApiServiceImpl.getDeviceId(VolumeApiServiceImpl.java:2439)
>   at 
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1308)
>   at 
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1173)
>   at sun.reflect.GeneratedMethodAccessor248.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>   at 
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
> {noformat}
> There was a hardcoded limit of 15 on the number of devices for a VM.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9557) Deploy from VMsnapshot fails with exception if source template is removed or made private

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964209#comment-15964209
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9557:


Github user yvsubhash commented on the issue:

https://github.com/apache/cloudstack/pull/1721
  
Closing this as change would be added to #1664 


> Deploy from VMsnapshot fails with exception if source template is removed or 
> made private
> -
>
> Key: CLOUDSTACK-9557
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9557
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Template
>Affects Versions: 4.8.0
> Environment: Any Hypervisor
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Steps to reproduce the issue
> i) Upload a template as admin user and make sure "public" is selected when 
> uploading it.
> ii) Now login as a user to CloudStack and deploy a VM with the template 
> created in step i).
> iii) Create a VM snapshot as the user for the VM in step ii). Once created 
> deploy a VM from the snapshot ( this will work as expected)
> iv) Now login as admin again , edit the template created in step i) and 
> Uncheck "public". This is make the template as private ( or else delete the 
> template from UI)
> v) Login as same user as in step ii) and try to create a VM from the same 
> snapshot ( created in step iii)). This will fail now.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9557) Deploy from VMsnapshot fails with exception if source template is removed or made private

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964208#comment-15964208
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9557:


Github user yvsubhash closed the pull request at:

https://github.com/apache/cloudstack/pull/1721


> Deploy from VMsnapshot fails with exception if source template is removed or 
> made private
> -
>
> Key: CLOUDSTACK-9557
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9557
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Template
>Affects Versions: 4.8.0
> Environment: Any Hypervisor
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Steps to reproduce the issue
> i) Upload a template as admin user and make sure "public" is selected when 
> uploading it.
> ii) Now login as a user to CloudStack and deploy a VM with the template 
> created in step i).
> iii) Create a VM snapshot as the user for the VM in step ii). Once created 
> deploy a VM from the snapshot ( this will work as expected)
> iv) Now login as admin again , edit the template created in step i) and 
> Uncheck "public". This is make the template as private ( or else delete the 
> template from UI)
> v) Login as same user as in step ii) and try to create a VM from the same 
> snapshot ( created in step iii)). This will fail now.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8676) Deploy user instance from vm snapshot for VMware hypervisor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964207#comment-15964207
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8676:


Github user yvsubhash commented on the issue:

https://github.com/apache/cloudstack/pull/1664
  
@sateesh-chodapuneedi  Please take care of the code change in the following 
PR as well  as i am closing 
https://github.com/apache/cloudstack/pull/1721

The change is as follows 

  server/src/com/cloud/vm/UserVmManagerImpl.java
 @@ -3242,8 +3242,9 @@ protected UserVm createVirtualMachine(DataCenter 
zone, ServiceOffering serviceOf
  throw new InvalidParameterValueException("Installing from ISO 
requires an ISO that is bootable: " + template.getId());
  }
  
 -// Check templates permissions
 -_accountMgr.checkAccess(owner, AccessType.UseEntry, false, 
template);
 +// Check templates permissions when the create vm is not from 
snapshot
 +if(vmSnapshot == null)
 +_accountMgr.checkAccess(owner, AccessType.UseEntry, false, 
template);
  
  // check if the user data is correct
  validateUserData(userData, httpmethod);



> Deploy user instance from vm snapshot for VMware hypervisor
> ---
>
> Key: CLOUDSTACK-8676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8676
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, VMware
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: Future
>
>
> Currently, ACS provides the ability to deploy a VM from a template or ISO. 
> However, ACS does not provide the ability to deploy a VM(s) directly from a 
> VM snapshot. 
> VM snapshots are stored in the primary storage and have a hierarchical or 
> parent/child relationship. The requirement would be to provide the ability to 
> deploy user instances from selected VM snapshots. Additionally, any VM 
> snapshot in the hierarchy can be deployed concurrently.  
> Even though this can be  supported and applicable to all hypervisors, to 
> start with this feature is supported only for VMware hypervisor.
> Feature specification is at 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Deploy+instance+from+VM+snapshot



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8849) Usage job should stop usage generation in case of any exception

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964201#comment-15964201
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8849:


Github user yvsubhash commented on the issue:

https://github.com/apache/cloudstack/pull/827
  
Closing this PR


> Usage job should stop usage generation in case of any exception
> ---
>
> Key: CLOUDSTACK-8849
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8849
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.5.2
>Reporter: subhash yedugundla
>
> usage server should stop completely after getting an exception. When it 
> continues it can result in wrong usage data



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8849) Usage job should stop usage generation in case of any exception

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964202#comment-15964202
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8849:


Github user yvsubhash closed the pull request at:

https://github.com/apache/cloudstack/pull/827


> Usage job should stop usage generation in case of any exception
> ---
>
> Key: CLOUDSTACK-8849
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8849
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.5.2
>Reporter: subhash yedugundla
>
> usage server should stop completely after getting an exception. When it 
> continues it can result in wrong usage data



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9719) [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964107#comment-15964107
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9719:


Github user sureshanaparti commented on the issue:

https://github.com/apache/cloudstack/pull/1879
  
@karuturi Can you merge this PR. Current base branch is 4.9. Is that OK or 
Shall I change to master?


> [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery
> --
>
> Key: CLOUDSTACK-9719
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9719
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> After HA being triggered on VMware, some VMs fail to acquire DHCP address 
> from a VR. These VMs are live migrated as part of vCenter HA to another 
> available host before the VR and couldn't acquire DHCP address as VR is not 
> migrated yet and these VMs request failed to reach the VR.
> Resolving this requires manual intervention by the CloudStack administrator; 
> the router must be rebooted or the network restarted. This behavior is not 
> ideal and will prolong downtime caused by an HA event and there is no point 
> for the non-functional virtual router to even be running. CloudStack should 
> handle this situation by setting VR restart priority to high in the vCenter 
> when HA is enabled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9782) Host HA

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964098#comment-15964098
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9782:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1960
  
@abhinandanprateek Initially I also thought that this is about host HA. But 
after reading the FS I had doubts and asked about the definition of "host HA". 
If you refer to the discussion on dev@, it was mentioned that "host HA" would 
trigger VM HA so that they are started on other hosts. This is the same as 
existing VM HA and I don't think we should refer to it as host HA.

@rhtyd I had replied with some specific questions/comments on the 
discussion thread. I didn't see any responses on those.

Basically I would like to see a clear definition of "host HA". When a host 
is HA'd what all should happen? If the definition provided is nothing but VM HA 
then the question comes why a new framework when the existing framework is 
already there. 


> Host HA
> ---
>
> Key: CLOUDSTACK-9782
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9782
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.11.0.0
>
>
> CloudStack lacks a way to reliably fence a host, the idea of the host-ha 
> feature is to provide a general purpose HA framework and implementation 
> specific for hypervisor that can use additional mechanism such as OOBM (ipmi 
> based power management) to reliably investigate, recover and fencing a host. 
> This feature can handle scenarios associated with server crash issues and 
> reliable fencing of hosts and HA of VM.
> FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Host+HA



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9719) [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964094#comment-15964094
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9719:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1879
  
Thanks @sureshanaparti, since @karuturi is the RM I've avoided merging any 
PRs. @karuturi if you're busy and need a co-pilot I can help review and merge 
some outstanding PRs that have enough LGTMs and regression test results.


> [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery
> --
>
> Key: CLOUDSTACK-9719
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9719
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> After HA being triggered on VMware, some VMs fail to acquire DHCP address 
> from a VR. These VMs are live migrated as part of vCenter HA to another 
> available host before the VR and couldn't acquire DHCP address as VR is not 
> migrated yet and these VMs request failed to reach the VR.
> Resolving this requires manual intervention by the CloudStack administrator; 
> the router must be rebooted or the network restarted. This behavior is not 
> ideal and will prolong downtime caused by an HA event and there is no point 
> for the non-functional virtual router to even be running. CloudStack should 
> handle this situation by setting VR restart priority to high in the vCenter 
> when HA is enabled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964066#comment-15964066
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user jayapalu commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1908#discussion_r110854129
  
--- Diff: server/src/com/cloud/network/router/CommandSetupHelper.java ---
@@ -848,13 +849,38 @@ public int compare(final PublicIpAddress o1, final 
PublicIpAddress o2) {
 associatedWithNetworkId = ipAddrList.get(0).getNetworkId();
 }
 
+// for network if the ips does not have any rules, then only 
last ip
+List userIps = 
_ipAddressDao.listByAssociatedNetwork(associatedWithNetworkId, null);
+
+int ipsWithrules = 0;
+int ipsStaticNat = 0;
+for (IPAddressVO ip : userIps) {
+if ( _rulesDao.countRulesByIpIdAndState(ip.getId(), 
FirewallRule.State.Active) > 0 ) {
--- End diff --

Updated


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964065#comment-15964065
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user jayapalu commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1908#discussion_r110854097
  
--- Diff: setup/db/db/schema-4920to41000.sql ---
@@ -230,5 +230,11 @@ JOIN `cloud`.`vm_snapshots` s ON 
(s.service_offering_id = o.id AND s.vm_id = v.i
 WHERE (o.cpu is null AND o.speed IS NULL AND o.ram_size IS NULL) AND
 (d.name = 'cpuNumber' OR d.name = 'cpuSpeed' OR d.name = 'memory');
 
+<<< 1c48deefe9b534198cad19b5528ce0dcfa8d04a5
 -- CLOUDSTACK-9827: Storage tags stored in multiple places
 DROP VIEW IF EXISTS `cloud`.`storage_tag_view`;
+
+ALTER TABLE `user_ip_address` ADD COLUMN `rule_state` VARCHAR(32) COMMENT 
'static  rule state while removing';
+===
--- End diff --

Corrected


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964064#comment-15964064
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user jayapalu commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1908#discussion_r110854055
  
--- Diff: setup/db/db/schema-4920to41000.sql ---
@@ -230,5 +230,11 @@ JOIN `cloud`.`vm_snapshots` s ON 
(s.service_offering_id = o.id AND s.vm_id = v.i
 WHERE (o.cpu is null AND o.speed IS NULL AND o.ram_size IS NULL) AND
 (d.name = 'cpuNumber' OR d.name = 'cpuSpeed' OR d.name = 'memory');
 
+<<< 1c48deefe9b534198cad19b5528ce0dcfa8d04a5
--- End diff --

My bad, on multiple times rebase some how I missed it. Corrected now.


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964042#comment-15964042
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user ProjectMoon commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1908#discussion_r110848750
  
--- Diff: setup/db/db/schema-4920to41000.sql ---
@@ -230,5 +230,11 @@ JOIN `cloud`.`vm_snapshots` s ON 
(s.service_offering_id = o.id AND s.vm_id = v.i
 WHERE (o.cpu is null AND o.speed IS NULL AND o.ram_size IS NULL) AND
 (d.name = 'cpuNumber' OR d.name = 'cpuSpeed' OR d.name = 'memory');
 
+<<< 1c48deefe9b534198cad19b5528ce0dcfa8d04a5
 -- CLOUDSTACK-9827: Storage tags stored in multiple places
 DROP VIEW IF EXISTS `cloud`.`storage_tag_view`;
+
+ALTER TABLE `user_ip_address` ADD COLUMN `rule_state` VARCHAR(32) COMMENT 
'static  rule state while removing';
+===
--- End diff --

Conflict line.


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964043#comment-15964043
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user ProjectMoon commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1908#discussion_r110848709
  
--- Diff: setup/db/db/schema-4920to41000.sql ---
@@ -230,5 +230,11 @@ JOIN `cloud`.`vm_snapshots` s ON 
(s.service_offering_id = o.id AND s.vm_id = v.i
 WHERE (o.cpu is null AND o.speed IS NULL AND o.ram_size IS NULL) AND
 (d.name = 'cpuNumber' OR d.name = 'cpuSpeed' OR d.name = 'memory');
 
+<<< 1c48deefe9b534198cad19b5528ce0dcfa8d04a5
--- End diff --

It seems you got a conflict stuck in the file.


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964041#comment-15964041
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user ProjectMoon commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1908#discussion_r110849362
  
--- Diff: server/src/com/cloud/network/router/CommandSetupHelper.java ---
@@ -848,13 +849,38 @@ public int compare(final PublicIpAddress o1, final 
PublicIpAddress o2) {
 associatedWithNetworkId = ipAddrList.get(0).getNetworkId();
 }
 
+// for network if the ips does not have any rules, then only 
last ip
+List userIps = 
_ipAddressDao.listByAssociatedNetwork(associatedWithNetworkId, null);
+
+int ipsWithrules = 0;
+int ipsStaticNat = 0;
+for (IPAddressVO ip : userIps) {
+if ( _rulesDao.countRulesByIpIdAndState(ip.getId(), 
FirewallRule.State.Active) > 0 ) {
--- End diff --

Inconsistent formatting of the parentheses in the `if`. A bit nitpicky, but 
the code has to adhere to format.


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9719) [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15963923#comment-15963923
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9719:


Github user sureshanaparti commented on the issue:

https://github.com/apache/cloudstack/pull/1879
  
@rhtyd This PR has 2 LGTMs, is targeted to 4.9. Can you merge this PR to 
4.9 or Shall I change the base branch to master?


> [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery
> --
>
> Key: CLOUDSTACK-9719
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9719
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
> Fix For: 4.10.0.0
>
>
> After HA being triggered on VMware, some VMs fail to acquire DHCP address 
> from a VR. These VMs are live migrated as part of vCenter HA to another 
> available host before the VR and couldn't acquire DHCP address as VR is not 
> migrated yet and these VMs request failed to reach the VR.
> Resolving this requires manual intervention by the CloudStack administrator; 
> the router must be rebooted or the network restarted. This behavior is not 
> ideal and will prolong downtime caused by an HA event and there is no point 
> for the non-functional virtual router to even be running. CloudStack should 
> handle this situation by setting VR restart priority to high in the vCenter 
> when HA is enabled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15963902#comment-15963902
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9591:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/2022
  
I don't think BO tests failures are related to this change. I think this is 
ready to merge.
cc: @karuturi 


> VMware dvSwitch Requires a Dummy, Standard vSwitch
> --
>
> Key: CLOUDSTACK-9591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9591
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.6.2, 4.7.0, 4.7.1, 4.8.0, 4.9.0
>Reporter: John Burwell
>Priority: Minor
>
> When using the VMware dvSwitch, templates fail to register and VMs with the 
> following secondary storage error:
> createImportSpec error: Host did not have any virtual network defined.
> Defining dummy, standard vSwitch on the same network works around this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)