| |
|
Alert Type: | Updated * |
Bug Id: | CSCux37292 | Title: | Update Port Profile task is failing |
|
Status: | Fixed |
|
Severity: | 2 Severe |
Description: * | Symptom:
Update Port Profile task is failing with error " (Update Port Profile) failed with error - Failed to update port profile in handler: Update Port Profile Emptly Primary VLAN" OR " (Update Port Profile) failed with error - Failed to update port profile in handler: Update Port Profile Emptly Secondary VLAN"
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 24-DEC-2015 |
|
Known Affected Releases: | 5.4(0.0) |
|
Known Fixed Releases: | 5.4(0.1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux67561 | Title: | 5.3.2.1 upgrade causes kernel files to miss and appliance doent bootup |
|
Status: | Open |
|
Severity: | 2 Severe |
Description: | Symptom:
Appliance does not boot up due to missing kernel file after upgrading to 5.3.2.1 from below supported versions
5.3.2.1=5.3.0.0,5.3.0.2,5.3.1.0,5.3.1.1,5.3.1.2,5.3.2.0,5.3.2.0A,5.3.2.1
Conditions:
Upgrade to 5.3.2.1
Workaround:
None - Hotfix on 5.3.2.1 will be posted in CCO
Further Problem Description:
|
|
Last Modified: | 24-DEC-2015 |
|
Known Affected Releases: | 5.3(2.1) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux11103 | Title: | Exporting Workflow with script module does not select script module |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Exporting a workflow with a script module does not select the script module
Please see
https://communities.cisco.com/docs/DOC-63761
Conditions:
UCSD 5.4
Workaround:
Manually select script module to be included in the workflow export.
Further Problem Description:
Please special note
https://communities.cisco.com/docs/DOC-63761
|
|
Last Modified: | 10-DEC-2015 |
|
Known Affected Releases: | 5.4(0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCup73148 | Title: | Multinode::HyperV vm provisioning SR-Request shows VM not discovered.. |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
VM is provisioned is not getting discovered in multinode appliance for hyperv vm as per SR log. As a result vm is getting provisioned twice with same name and not getting discovered under 'Generic' vm catagory.
Conditions:
Only during vm provisioning for hyperv vm for both SP1 and R2 clouds.
Workaround:
Under Administration>System>System Tasks select the hyperV appropriate cloud added and use manage task button, change the system task policy to 'local-run'.
This would help in discovery of the vm during provisioning.
Further Problem Description:
|
|
Last Modified: | 10-DEC-2015 |
|
Known Affected Releases: | 4.1(0.4) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux61497 | Title: | Add PNIC to DVSwitch task random failures |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Add PNIC to DVSwitch task fail randomly.
Conditions:
Last host node of VMware account is passed as an user input to "Host Node" task input.
Workaround:
None.
Further Problem Description:
|
|
Last Modified: | 18-DEC-2015 |
|
Known Affected Releases: | 5.3(2.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux29687 | Title: | Post UCSD5.3 upgrade, VM created in SCVMM becomes non-HA |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Post UCSD5.3 upgrade, VM created in SCVMM becomes non-HA
Conditions:
Using HA for VM provisioning
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 5.3(2.0) |
|
Known Fixed Releases: * | 5.4(0.1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw78757 | Title: | Clone Modify VM n/w task does not have same functionality as the orginal |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: | Symptom:
Clone Modify VM n/w task does not have same functionality as the orginal
Conditions:
Issue noticed on customer setup and the same can be easily replicated in our local environment.
Modify VM network (In-built task)
'Select Network Adapter' and 'Portgoup Name' are dynamically populated when a VM is selected.
But when we clone the task - In Cloned task "Select Network Adapter' and 'Portgoup Name' are not dynamically populated"
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 23-DEC-2015 |
|
Known Affected Releases: | 5.1(0.1), 5.3(1.2), 5.4(0.0) |
|
Known Fixed Releases: | 5.4(0.1) |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux16010 | Title: | CIMCI Account Add errors out used to work in 5.3 not in 5.4 |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Error
2015-11-15 04:51:41,121 [pool-1-thread-2] INFO doFormSubmit(APIProvider.java:1259) - FORM SUBMIT CIMCControllerFeatureFORM_ID_CIMC_ADD_RACK_ACCOUNT
2015-11-15 04:51:41,122 [pool-1-thread-2] INFO definePage(CIMCInfraAccountAddFormImpl.java:50) - CIMCInfraAccountAddFormImpl......
2015-11-15 04:51:41,122 [pool-1-thread-2] INFO buildBindings(FormBindings.java:1092) - LOV Provider for ID_CIMC_ADD_ACCOUNT_FORM.policy=credentialPolicyNameProvider
2015-11-15 04:51:41,122 [pool-1-thread-2] INFO definePage(FormBindings.java:776) - Field = ID_CIMC_ADD_ACCOUNT_FORM.policy, LovProviderName = credentialPolicyNameProvider
2015-11-15 04:51:41,122 [pool-1-thread-2] INFO toPairs(FormBindings.java:72) - LovProviderName = credentialPolicyNameProvider
2015-11-15 04:51:41,125 [pool-1-thread-2] INFO definePage(FormBindings.java:776) - Field = ID_CIMC_ADD_ACCOUNT_FORM.protocol, LovProviderName =
2015-11-15 04:51:41,125 [pool-1-thread-2] INFO definePage(FormBindings.java:776) - Field = ID_CIMC_ADD_ACCOUNT_FORM.rackGroup, LovProviderName =
2015-11-15 04:51:41,125 [pool-1-thread-2] INFO validatePageData(CIMCInfraAccountAddFormImpl.java:82) - CIMCInfraAccountAddFormImpl......
2015-11-15 04:51:41,125 [pool-1-thread-2] INFO validatePageData(CIMCInfraAccountAddFormImpl.java:87) - CONFIG_PORT:443
2015-11-15 04:51:41,125 [pool-1-thread-2] INFO validatePageData(CIMCInfraAccountAddFormImpl.java:90) - acctname =Dalas_Cimci serverIP =172.17.32.40
2015-11-15 04:51:41,125 [pool-1-thread-2] INFO validatePageData(CIMCInfraAccountAddFormImpl.java:93) - isPageSubmitted=true , isHasErrors=false
2015-11-15 04:51:41,126 [pool-1-thread-2] INFO validatePageData(CIMCInfraAccountAddFormImpl.java:99) - Validating account name
2015-11-15 04:51:41,126 [pool-1-thread-2] INFO validatePageData(CIMCInfraAccountAddFormImpl.java:123) - Setting account properties
2015-11-15 04:51:41,126 [pool-1-thread-2] INFO validatePageData(CIMCInfraAccountAddFormImpl.java:156) - jobstatus = done
2015-11-15 04:51:41,126 [pool-1-thread-2] INFO validatePageData(CIMCInfraAccountAddFormImpl.java:185) - status = FAIL , message = Test Connection Failed: Connection to 172.17.32.40 failed. Reason:
https://172.17.32.40/nuova
2015-11-15 04:51:41,126 [pool-1-thread-2] INFO validatePageData(CIMCInfraAccountAddFormImpl.java:198) - Job Failed : Test Connection Failed: Connection to 172.17.32.40 failed. Reason:
https://172.17.32.40/nuova
2015-11-15 04:51:41,126 [pool-1-thread-2] INFO validatePageData(CIMCInfraAccountAddFormImpl.java:203) - Exception hit
java.lang.Exception: Test Connection Failed: Connection to 172.17.32.40 failed. Reason:
https://172.17.32.40/nuova
at com.cloupia.feature.cimc.forms.CIMCInfraAccountAddFormImpl.validatePageData(CIMCInfraAccountAddFormImpl.java:199)
at com.cloupia.service.cIM.inframgr.forms.wizard.WizardController.handlePageValidate(WizardController.java:660)
at com.cloupia.service.cIM.inframgr.forms.wizard.WizardController.handleValidate(WizardController.java:893)
at com.cloupia.service.cIM.inframgr.forms.wizard.WizardController.doFormSubmit(WizardController.java:338)
at com.cloupia.service.cIM.inframgr.APIProvider.doFormSubmit(APIProvider.java:1273)
at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.cloupia.fw.services.provider.ServiceProvider.executeOperation(ServiceProvider.java:752)
at com.cloupia.fw.services.provider.Operation
|
|
Last Modified: | 10-DEC-2015 |
|
Known Affected Releases: | 5.4(0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux37173 | Title: | Cannot add task "Add ACL Policy Rules" to workflow |
|
Status: | Fixed |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Add ACL Policy Rules task cannot be added to a workflow.
Conditions:
Seen on UCSD 5.3.2.0. Have not tried other versions.
Workaround:
In "Task Inputs" screen, set the following:
1) Rule 1:
Name: some name
Protocol/Service: Service
Service Port: change 0 to some dummy port number
2) Rule 2 and Rule 3
Check "Add rule 2" and "Add rule 3" and then setup
dummy rules as done for rule 1.
3) Click on next, at this point screen should have moved
to "User Output Mapping" and "Submit" button should be there.
4) Click on "back"
5) Setup rules as normally done.
Basically, "Service port" needs to be set to some number
other than 0 irrespective of whether it shows up in the UI or not
and irrespective of whether it is used or not.
Further Problem Description:
|
|
Last Modified: | 09-DEC-2015 |
|
Known Affected Releases: | 5.3(2.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux11563 | Title: | Get IP from Pool Task does not pull from duplicate IP pool |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
IP's get assigned only from one IP pool and not from the second pool (coke/pepsi) example
please see screen shots
Conditions:
UCSD 5.4 can not handle duplicated IP pool s and pull the IP from the correct pool
Workaround:
none
Further Problem Description:
|
|
Last Modified: | 10-DEC-2015 |
|
Known Affected Releases: | 5.4(0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux57577 | Title: | Remove Capacity Reservation error during workflow rollback |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Remove Capacity Reservation error is seen during workflow rollback.
Conditions:
This happens when the reserved ip address is assigned to a VM, VMware Inventory Collector runs at least once, and "IP Pool Policy Usage Report" shows the IP as used with usage reported by "VMware-connector"
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.3(2.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw81471 | Title: | InputType modified for Update VMMDomain and Static Path to EPG in EB |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | after migrated From MR2-> EB, 2 tasks got modified with its user-input & Task input
Symptom:
after migrated From MR2-> EB, 2 tasks got modified with its user-input & Task input
Conditions:
after migrated From MR2-> EB, 2 tasks got modified with its user-input & Task input
Workaround:
for both task, user have to create new user input and map to respective fields
Further Problem Description:
after migrated From MR2-> EB, 2 tasks got modified with its user-input & Task input, After migrated From MR2-> EB, 2 tasks got modified with its user-input & Task input
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.4(0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw19195 | Title: | Input Data field is empty for UCSD actions |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Send Email notification for Action has some contents missing in the email
Conditions:
Emails received by performing actions on UCSD
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.4(0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuw10853 | Title: | ASAv in DR site should have DS cluster marked in Protected mode |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
ASAv in DR site should have DS cluster marked in Protected mode.
A common datastore cluster needs to be mapped to the DR vpod - this will be used for asav deployment at DR site
Conditions:
ASAv in DR site should have DS cluster marked in Protected mode.
A common datastore cluster needs to be mapped to the DR vpod - this will be used for asav deployment at DR site
Workaround:
Currently, we do it manually.
There is an admin input in the DR tenant workflow - Tenant Resource Allocation task where we map the input for protected datastore cluster.
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: * | 5.3(2.0), 5.4(0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw97417 | Title: | Need to tag the netapp aggregate before onboarding a tenant |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
NetApp tenant onbording fails with below error if it picks root aggregate for creating root volume
Conditions:
Workaround:
We need to add tag to a non-root aggregate and the add the same tag in service offering before starting the tenant onboarding.
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.4(0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCux03539 | Title: | Group share policy is not working if having two different LDAP account. |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Under Group share policy configurations if sharing configured between two different LDAP account's groups is made in same policy then feature is not working.
Conditions:
Group share policy configured with groups of different LDAP accounts.
Workaround:
Sharing the groups between same LDAP account groups and Local Groups are working fine.
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.4(0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux41320 | Title: | Evaluation of cloupia-cuic for OpenSSL December 2015 vulnerabilities |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * |
Symptom:
Cisco Cloupia Unified Infrastructure Controller includes a version of OpenSSL that is affected by the vulnerability identified by one or more of the following Common Vulnerability and Exposures (CVE) IDs:
CVE-2015-3193, CVE-2015-3194, CVE-2015-3195, CVE-2015-3196 and CVE-2015-1794
And disclosed in http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20151204-openssl
This bug has been opened to address the potential impact on this product.
Conditions:
Exposure is not configuration dependent.
Cisco has reviewed and concluded that this product is not affected by any of these vulnerabilities.
Workaround:
Not available.
Further Problem Description:
Additional details about those vulnerabilities can be found at http://cve.mitre.org/cve/cve.html
PSIRT Evaluation:
The Cisco PSIRT has evaluated these issues and they do not meet the criteria for PSIRT ownership or involvement. Those issues will be addressed via normal resolution channels.
If you believe that there is new information that would cause a change in the severity of those issues, please contact psirt@cisco.com for another evaluation.
Additional information on Cisco's security vulnerability policy can be found at the following URL:
http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.4(0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux57699 | Title: | Custom Approval Tasks not getting exported/imported with workflows |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
When you export a workflow, and that workflow includes a custom approval task, it appears that the custom approval task does not get exported and therefor on import into another UCSD system (same UCSD version as source) the custom approval task does not exist in the custom approval task and the workflow validation fails.
Conditions:
When you export a workflow, and that workflow includes a custom approval task, it appears that the custom approval task does not get exported and therefor on import into another UCSD system (same UCSD version as source) the custom approval task does not exist in the custom approval task and the workflow validation fails.
Workaround:
N/A
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.4(0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | New |
Bug Id: | CSCuw75810 | Title: | Not able to Discover CIMC account from discovery wizard. |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: | Symptom:
Not able to discover the CIMC Rack Accounts from the Discovery wizards
Conditions:
Trying to discover the CIMC Rack Accounts from the Discovery wizards.
Workaround:
Use the option present under Administration -> Physical Accounts -> Rack Server Discovery tab for the discovery.
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.4(0.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux51604 | Title: | Same Static IP Pool is assigned for SRs executed in parallel |
|
Status: | Open |
|
Severity: | 3 Moderate |
Description: * | Symptom:
Parallel Get IP Subnet from IP Subnet Pool tasks return same IP subnet
Conditions:
If two SR are triggered at the same time.
Workaround:
Introduce wait for specific duration in one of the SRs
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.3(2.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux55873 | Title: | Get IP Subnet From IP Subnet Pool Policy task is very slow |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Get IP Subnet From IP Subnet Pool Policy is very slow
Conditions:
Each subnet in the pool has a many ip addresses
Workaround:
None
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.3(2.0) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCuv20451 | Title: | Feature request for option to remove "Lease Time" option |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Customers want to be able to remove the "lease time" option when creating a new service request. Even when a custom workflow is created, this option still appears when creating the service request from a catalog. Customer wants to be able to disable this option for End Users.
Conditions:
Workaround:
Further Problem Description:
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.2(0.2) |
|
Known Fixed Releases: | |
|
|
| |
| |
|
Alert Type: | Updated * |
Bug Id: | CSCux24753 | Title: | UCSD: BMA provision fails when PXE booting to multiple VLANs |
|
Status: | Open |
|
Severity: | 6 Enhancement |
Description: * | Symptom:
Installation fails with the error "(http://.....ks.cfg) connection failed. Made 5 attempts. (urlopen error [Errno 110] Connection timed out)"
In the ESXi weasel.log file, it clearly shows where DHCP assigns the IP address, subnet mask and gateway to the host, but the netmask isn't picked up and the following error is logged:
"IP specified, but no netmask given. Guessing netmask."
It then sets the netmask to "255.0.0.0".
Conditions:
If customer configures BMA to PXE boot across multiple VLANs, this appears to cause baremetal provisioning to fail.
Workaround:
The fix is to remove "IPAPPEND 1" line from the PXE config templates for each OS type you wish to provision (on the BMA at /opt/cnsaroot/templates).
I.e., on most customer environment, the "IPAPPEND 1" line is not an issue. When customer configures BMA to PXE boot across multiple VLANs, then "IPAPPEND 1" line needs to be removed from the PXE config templates.
Further Problem Description:
Per dev engineer who worked case that generated this known issue:
In this particular customer environment he has configured DHCP server (BMA)is serving IP address for multiple network. We need to know what are the VLANs configured for SP. From the screenshot attached to the case what I see is there is network connectivity problem from blade to BMA. That's where its timed out. This is solved by removing the IPAPPEND 1.
What IPAPPEND does is:
For scripted installations, the IPAPPEND option specifies that the same network adapter the machine boots from is also used for connecting to the network.
|
|
Last Modified: | 30-DEC-2015 |
|
Known Affected Releases: | 5.3(1.2) |
|
Known Fixed Releases: | |
|
|
| |
2015 Cisco and/or its affiliates. All rights reserved. 
没有评论:
发表评论