[jira] [Commented] (CLOUDSTACK-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962505#comment-15962505 ] ASF GitHub Bot commented on CLOUDSTACK-9591: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2022 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-630 > 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-9782) Host HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962496#comment-15962496 ] ASF GitHub Bot commented on CLOUDSTACK-9782: Github user abhinandanprateek commented on the issue: https://github.com/apache/cloudstack/pull/1960 @koushik-das I see that main issue is that this is being confused as VM HA framework. Will like to again add that this framework is not for VM-HA but for host HA. With this implementation of OOBM framework, Cloudstack is now in the position to control and HA a host. These developments helped us in putting together a Host HA framework. Only that while designing and coding we tried to keep it flexible so that later other entities that can be HAed can be added to the framework. > 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-9591) VMware dvSwitch Requires a Dummy, Standard vSwitch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962484#comment-15962484 ] ASF GitHub Bot commented on CLOUDSTACK-9591: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2022 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962483#comment-15962483 ] ASF GitHub Bot commented on CLOUDSTACK-9591: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/2022 @karuturi the failures around vpc are known to be intermittent for vmware env, the failures are not related to the changes. The environments where you dont see more than three failures are usually KVM based. I can kick the tests once again. @blueorangutan package > 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] [Assigned] (CLOUDSTACK-9849) Cannot migrate VMware VM to host in different cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi reassigned CLOUDSTACK-9849: Assignee: Sateesh Chodapuneedi > 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962464#comment-15962464 ] ASF GitHub Bot commented on CLOUDSTACK-9591: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/2022 @rhtyd can you check on the failures? I think there are more failures on this PR. I usually see three failures. > 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
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962429#comment-15962429 ] ASF GitHub Bot commented on CLOUDSTACK-9719: Github user sateesh-chodapuneedi commented on the issue: https://github.com/apache/cloudstack/pull/1879 tag:mergeready > [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-8922) Unable to delete IP tag
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962133#comment-15962133
]
ASF GitHub Bot commented on CLOUDSTACK-8922:
Github user yvsubhash commented on the issue:
https://github.com/apache/cloudstack/pull/905
tag:mergeready
> Unable to delete IP tag
> ---
>
> Key: CLOUDSTACK-8922
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8922
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.2
>Reporter: subhash yedugundla
>
> 1. Acquire new IP address
> 2. Create tags for the IP
> 3. Delete the tag from Step#2
> an error occurs at Step#3 whereby the delete tag operation fails with
> "Acct[f4d0c381-e0b7-4aed-aa90-3336d42f7540-7100017] does not have
> permission to operate within domain id\u003d632"
> TROUBLESHOOTING
> ==
> Acquire new IP address
> *
> {noformat}
> 2014-11-19 15:08:15,870 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-20:ctx-faed32b5 ctx-712308cb ctx-401bfcaf) submit async
> job-72419, details: AsyncJobVO {id:72419, userId: 17, accountId: 15,
> instanceType: IpAddress, instanceId: 672, cmd:
> org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd, cmdInfo:
> {"id":"672","response":"json","cmdEventType":"NET.IPASSIGN","ctxUserId":"17","zoneid":"a117e75f-d02e-4074-806d-889c61261394","httpmethod":"GET","ctxAccountId":"15","networkid":"0ca7c69e-c281-407b-a152-2559c10a81a6","ctxStartEventId":"166725","signature":"3NZRU6dIBxg1HMDiP/MkY2agRn4\u003d","apikey":"tuwHXs1AfpQheJeJ9BcLdoVxIBCItASnguAbus76AMUcIXuyFgHOJiIB44fO57p_bBaqyfppmxrC-rQSb-nxXg"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 345048681027, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-11-19 15:08:15,870 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-68:ctx-fca9add6 job-72419) Executing AsyncJobVO {id:72419,
> userId: 17, accountId: 15, instanceType: IpAddress, instanceId: 672, cmd:
> org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd, cmdInfo:
> {"id":"672","response":"json","cmdEventType":"NET.IPASSIGN","ctxUserId":"17","zoneid":"a117e75f-d02e-4074-806d-889c61261394","httpmethod":"GET","ctxAccountId":"15","networkid":"0ca7c69e-c281-407b-a152-2559c10a81a6","ctxStartEventId":"166725","signature":"3NZRU6dIBxg1HMDiP/MkY2agRn4\u003d","apikey":"tuwHXs1AfpQheJeJ9BcLdoVxIBCItASnguAbus76AMUcIXuyFgHOJiIB44fO57p_bBaqyfppmxrC-rQSb-nxXg"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 345048681027, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-11-19 15:08:15,890 DEBUG [c.c.u.AccountManagerImpl]
> (API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Access to
> Ntwk[216|Guest|8] granted to
> Acct[f4d0c381-e0b7-4aed-aa90-3336d42f7540-7100017] by DomainChecker
> 2014-11-19 15:08:15,911 DEBUG [c.c.n.IpAddressManagerImpl]
> (API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Successfully
> associated ip address 210.140.170.160 to network Ntwk[216|Guest|8]
> 2014-11-19 15:08:15,922 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Complete async
> job-72419, jobStatus: SUCCEEDED, resultCode: 0, result:
> org.apache.cloudstack.api.response.IPAddressResponse/ipaddress/{"id":"3d7c3a2a-1f2d-46dc-9905-4a7ce620e7e9","ipaddress":"210.140.170.160","allocated":"2014-11-19T15:08:15+0900","zoneid":"a117e75f-d02e-4074-806d-889c61261394","zonename":"tesla","issourcenat":false,"account":"7100017","domainid":"cc27e32c-6acd-4fdf-a1e5-734cef8a7fe0","domain":"7100017","forvirtualnetwork":true,"isstaticnat":false,"issystem":false,"associatednetworkid":"0ca7c69e-c281-407b-a152-2559c10a81a6","associatednetworkname":"network1","networkid":"79132c74-fe77-4bd5-9915-ce7c577fb95f","state":"Allocating","physicalnetworkid":"4a00ce42-6a30-4494-afdd-3531d883237b","tags":[],"isportable":false}
> 2014-11-19 15:08:15,932 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-68:ctx-fca9add6 job-72419) Remove job-72419 from job
> monitoring
> +---+---++---+---+-+-+
> | id| job_cmd |
> job_status | job_init_msid | job_complete_msid | created |
> last_updated|
> +---+---++---+---+-+
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962069#comment-15962069 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/2033 @karuturi this is ready for merge Pinging for review - @wido @ @ustcweizhou > 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)
