Veritas Storage Foundation™ and High Availability Solutions ...

Veritas Storage Foundation™ and High Availability Solutions ... Veritas Storage Foundation™ and High Availability Solutions ...

sfdoccentral.symantec.com
from sfdoccentral.symantec.com More from this publisher
12.07.2015 Views

100Storage Foundation and High Availability Solutions support for Oracle VM Server for SPARCKnown issuesongoing I/O to a UFS file system on another disk which is not under VxVM. Thisissue has been observed typically in a large configuration such as 14 virtual CPUsand around 10Gig of memory configured for the guest domain running VxVM.Relevant Oracle (Sun) bug id: 6744348This known issue has been fixed and verified in the 5.0 MP3 RP1 release.For the latest information on updates, patches, documentation, and known issuesregarding this 5.0 MP3 RP1 release, see the following TechNote on the SymantecTechnical Support website:For Solaris SPARC:http://entsupport.symantec.com/docs/281987For Solaris x64:http://entsupport.symantec.com/docs/286955Split Storage Foundation stack known issuesThe following are new known issues in this release of Veritas Storage Foundationand High Availability Solutions Support for Oracle VM Server for SPARC.Caching of data writes on the backend volume in the servicedomainThis was observed by a customer during their evaluation of Oracle VM Server forSPARC with Storage Foundation. This issue occurs because data written to thevirtual disk might get cached into the service domain before it is effectively writtento the virtual disk backend. This can cause potential data loss if the service domaincrashes while the data is still cached.Oracle (Sun) bug id is: 6684721 (file backed virtual I/O should be synchronous)This Oracle (Sun) bug is fixed in Oracle (Sun) patch 139562-02 that has beenobsoleted by 138888-07.See “Solaris patch requirements” on page 80.A volume can become inaccessible from the guest in the eventof control domain rebootAll access to such a volume hangs if the primary domain is rebooted. This is dueto the vdisk corresponding to the volume does not come back online after thecontrol domain reboots.This issue has been identified and fixed under Oracle (Sun) bug id: 6795836(vd_setup_vd() should handle errors from vd_identify_dev() better)

Storage Foundation and High Availability Solutions support for Oracle VM Server for SPARCKnown issues101This Oracle (Sun) bug is fixed in Oracle (Sun) patch 141777-01.

100<strong>Storage</strong> Foundation <strong>and</strong> <strong>High</strong> <strong>Availability</strong> <strong>Solutions</strong> support for Oracle VM Server for SPARCKnown issuesongoing I/O to a UFS file system on another disk which is not under VxVM. Thisissue has been observed typically in a large configuration such as 14 virtual CPUs<strong>and</strong> around 10Gig of memory configured for the guest domain running VxVM.Relevant Oracle (Sun) bug id: 6744348This known issue has been fixed <strong>and</strong> verified in the 5.0 MP3 RP1 release.For the latest information on updates, patches, documentation, <strong>and</strong> known issuesregarding this 5.0 MP3 RP1 release, see the following TechNote on the SymantecTechnical Support website:For Solaris SPARC:http://entsupport.symantec.com/docs/281987For Solaris x64:http://entsupport.symantec.com/docs/286955Split <strong>Storage</strong> Foundation stack known issuesThe following are new known issues in this release of <strong>Veritas</strong> <strong>Storage</strong> Foundation<strong>and</strong> <strong>High</strong> <strong>Availability</strong> <strong>Solutions</strong> Support for Oracle VM Server for SPARC.Caching of data writes on the backend volume in the servicedomainThis was observed by a customer during their evaluation of Oracle VM Server forSPARC with <strong>Storage</strong> Foundation. This issue occurs because data written to thevirtual disk might get cached into the service domain before it is effectively writtento the virtual disk backend. This can cause potential data loss if the service domaincrashes while the data is still cached.Oracle (Sun) bug id is: 6684721 (file backed virtual I/O should be synchronous)This Oracle (Sun) bug is fixed in Oracle (Sun) patch 139562-02 that has beenobsoleted by 138888-07.See “Solaris patch requirements” on page 80.A volume can become inaccessible from the guest in the eventof control domain rebootAll access to such a volume hangs if the primary domain is rebooted. This is dueto the vdisk corresponding to the volume does not come back online after thecontrol domain reboots.This issue has been identified <strong>and</strong> fixed under Oracle (Sun) bug id: 6795836(vd_setup_vd() should h<strong>and</strong>le errors from vd_identify_dev() better)

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!