Hi Dr. Tsao, One could argue that anything is possible on OpenSolaris. I personally like the recent quotes from Jonathan, i.e. http://blogs.sun.com/jonathan/entry/sun_solaris_and_virtualization
"The objective of virtualization is to increase the level of utilization in pursuit of more value, efficiency and affordability." "Because this is all about efficiency - and the most efficient virtualization solution is the one you didn't have to pay extra to use." Concerning live migration, please note that I am _not_ suggesting that SC/OHAC is required for live migration. If I may quote from the Xen v3.0 User Manual, "To perform a live migration, both hosts must be running Xen / xend and the destination host must have suf?cient resources (e.g. memory capacity) to accommodate the domain after the move. Furthermore we currently require both source and destination machines to be on the same L2 subnet. Currently, there is no support for providing automatic remote access to ?lesystems stored on local disk when a domain is migrated. Administrators should choose an appropriate storage solution (i.e. SAN, NAS, etc.) to ensure that domain ?lesystems are also available on their destination node. GNBD is a good method for exporting a volume from one machine to another. iSCSI can do a similar job, but is more complex to set up." Just to be clear, I am simply articulating that should a filesystem be "accessible" to the destination node then if configured appropriately the HA-Xen DomU resource would perform migration or live limgration as the method for switchover. In this regard, a global file system could be used as perhaps could shared QFS. Regards Neil LaoTsao(Dr. Tsao) wrote: > hi > with the upcoming opensource of all SC and QFS > it seem that we have the opps to build a VMS cluster like cluster > solutions > it is my understanding that in that environment there is no HA-agents. > the infrastracture take care of the movement of the VIP and > V-disk-group, mastered by the primary or secondary node. > using SMF, one should be able to take care of the interdependence of > various resources. > One should able to integrate QFS into the base opensolaris and many SC > feature like globaldevices could all be in opensolaris. > Is this possible? > As for live migration of xen, there seems work to achive this without > SC framework:-( > my 2c > > > Neil Garthwaite wrote: > >> Hi Ashu, >> Concerning migration it would be triggered by a "clrg switch" >> command, although migration or live migration would be resource >> specific. By this I mean that when a "DomU resource" is registered >> with OHAC, the switchover method will be determined, i.e. migration, >> live migration or just failover (stop/relocate/start). However >> whatever method is chosen, the appropriate method would be triggered >> by a "clrg switch" and implemented by the HA-Xen agent. >> There are some restrictions for migration, in that the DomU's virtual >> block devices (VBD) need to be accessible by both nodes that are >> participating in such a migration. One could think of "accessible" in >> terms of a global file system. If a Zpool/ZFS was being used by a >> DomU's VBD list, then that Zpool/ZFS would only be available to both >> nodes participating in a migration and not accessible. In this >> regard, it's my belief that migration or live migration would not be >> possible for a DomU using a Zpool/ZFS VBD. However, my belief my >> change once we are engaged with the Xen community. >> >> Concerning placing a DomU offline. For those familiar with Solaris >> Cluster, this is akin to RG_affinities and in particular a strong >> negative affinity. For those not familiar with this terminology >> please see http://blogs.sun.com/SC/entry/how_does_sun_cluster_decide >> for an informative article about affinities. >> With the above in mind, "Allow for important DomUs where lesser DomUs >> are "offlined" means that using HA-Xen with OHAC and assuming a >> 2-node cluster, under normal operations both nodes could be running >> several domUs. However, some DomUs maybe more important than others >> and in the event of a node failure it maybe desirable to favor an >> important DomU over another DomU. >> Utilizing RG_affinities it would be possible to offline a less >> important DomU in favor or an important DomU to free up system >> resources so that upon failover the important DomU maintains a >> specific service level. >> In summary, this is an important feature and one that already exists >> within Solaris Cluster and therefore OHAC. However, in my opinion >> perhaps the greatest strength of RG_affinities is the knowledge that >> one could utilize all nodes thereby not having any idle nodes with >> the comfort of knowing that in the event of a node failure, OHAC + >> HA-Xen will favor important DomUs over lesser DomUs when using >> RG_affinities. >> >> Many thanks for your support with the remainder. >> >> Regards >> Neil >> -- >> >> This message posted from opensolaris.org >> >> _______________________________________________ >> ha-clusters-discuss mailing list >> ha-clusters-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/ha-clusters-discuss >> >> >
