Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
software:rnotes:rn-rel4.4 [2013/12/02 10:57] – nachosoftware:rnotes:rn-rel4.4 [2013/12/04 10:25] – cmartin
Line 3: Line 3:
 <html><div><p class="bigheader">OpenNebula 4.4 Retina</p></div></html> <html><div><p class="bigheader">OpenNebula 4.4 Retina</p></div></html>
  
-**Dec 2nd, 2013**. The OpenNebula team is pleased to approach winter with the immediate availability of the final version of OpenNebula 4.4, codename Retina. As a project driven by user needs, this release includes important features that meet real demands from production environments, with a focus on optimization of storage, monitoring, cloud bursting, and public cloud interfaces.+**Dec 3rd, 2013**. The OpenNebula team is pleased to approach winter with the immediate availability of the final version of OpenNebula 4.4, codename Retina. As a project driven by user needs, this release includes important features that meet real demands from production environments, with a focus on optimization of storage, monitoring, cloud bursting, and public cloud interfaces.
  
 OpenNebula Retina includes support for multiple system datastores, which enables a much more efficient usage of the storage resources for running Virtual Machines. This feature ships with different scheduling policies for storage load balancing, intended to instruct OpenNebula to spread the running Virtual Machines across different storage mediums to optimize their use. This translates in the ability to define more than one disk (or other backend) to hold running VMs in a particular cluster. Monitoring subsystem in OpenNebula underwent a major redesign as well, effectively switching from a pulling mechanism to a pushing model, with the implications in scalability improvements. OpenNebula Retina includes support for multiple system datastores, which enables a much more efficient usage of the storage resources for running Virtual Machines. This feature ships with different scheduling policies for storage load balancing, intended to instruct OpenNebula to spread the running Virtual Machines across different storage mediums to optimize their use. This translates in the ability to define more than one disk (or other backend) to hold running VMs in a particular cluster. Monitoring subsystem in OpenNebula underwent a major redesign as well, effectively switching from a pulling mechanism to a pushing model, with the implications in scalability improvements.
Line 81: Line 81:
 ====== Migrating from OpenNebula 4.2 ====== ====== Migrating from OpenNebula 4.2 ======
  
-A detailed upgrade process can be found in the documentation. For a complete set of changes to migrate from a 4.4 installation please refer to the [[documentation:rel4.4:compatibility|Compatibility Guide]].+A detailed [[documentation:rel4.4:upgrade|upgrade process]] can be found in the documentation. For a complete set of changes to migrate from a 4.4 installation please refer to the [[documentation:rel4.4:compatibility|Compatibility Guide]].
  
 <html><div class="imp"></html> <html><div class="imp"></html>
-:!: After OpenNebula upgrade make use you run "''onehost sync''" to update monitoring probes.+:!: With the new [[documentation:rel4.4:system_ds#multiple_system_datastore_setups|multi-system DS]] functionality, it is now required that the system DS is also part of the cluster. If you are using System DS 0 for Hosts inside a Cluster, any VM saved (stop, suspend, undeploy) **will not be able to be resumed after the upgrade process**. 
 +<html></div></html> 
 + 
 +<html><div class="imp"></html> 
 +:!: After the OpenNebula upgrade make sure you run "''onehost sync''" to update the monitoring probes.
 <html></div></html> <html></div></html>