Live Migration is possible when the relevant storage server is not the one needing to be taken offline for maintenance. Granted a proper Gluster setup would alleviate that however when optimum performance of file backed virtual disks is a factor Gluster is not there yet. - DHC
On Sun, Aug 18, 2013 at 5:47 AM, Ayal Baron <aba...@redhat.com> wrote: > > > ----- Original Message ----- > > Pausing the VM's can work in certain situations for simple maintenance. > > However suppose the purpose of the storage shutdown is to move data > around > > for certain VM's or perhaps change that particular underlying storage > > Then why not live migrate the relevant disks? > > > filesystem or hardware. Thus some of the VM's will have to be down for > sure > > however pausing them all because of the aforementioned would not be an > > option since it would take hours or days depending on the amount of data > and > > the degree of change. > > > > - DHC > > > > > > On Fri, Aug 16, 2013 at 12:14 AM, Karli Sjöberg < karli.sjob...@slu.se > > > wrote: > > > > > > > > tor 2013-08-15 klockan 10:46 -0500 skrev Dead Horse: > > > > > > Itamar this is true (I have noted occasional timing issues with it > actually > > working). > > But what if as the administrator I have a specific storage domain in mind > > that I would like to have become the master (in the case of more then > two)? > > > > > > > > > > @Karli > > > > > > > > The idea is not to not have to shut down all the VM's or the engine just > to > > maintenance a storage domain(s) that may happen to be on disparate > storage > > servers > > . > > > > Yes I understood that. My suggestion was a workaround until such > operations > > are possible, that we use to minimize downtime as much as possible, to > pause > > the VM's, shut down engine, maintenance, bring engine and VM's back. > Since > > the VM's only was paused and engine shut down, the VM's just continue > going > > happily unknowing exactly from where they were, and a reboot of a storage > > takes at most 5mins, which means 5mins total of downtime in the cloud > > environment for that quarter, which is acceptable for just about any SLA. > > > > /Karli > > > > > > > > > > > > > > > > - DHC > > > > > > > > > > > > > > > > On Thu, Aug 15, 2013 at 9:37 AM, Itamar Heim < ih...@redhat.com > wrote: > > > > > > > > On 08/15/2013 06:18 AM, Dead Horse wrote: > > > > > > > > > > > > > > > > Is there any method of designating which domain should be the master > > storage domain or forcibly changing the role to a different storage > domain? > > > > EG: Given the following example > > > > Storage Domain A (Master) --> NFS --> Storage Server 1 > > Storage Domain B --> NFS --> Storage Server 2 > > > > One wants to do maintenance to Storage Server 1 but in doing so the > > Master storage domain is hosted from Storage Server 1. Thus the net > > result of taking down Storage Server 1 is that one must also take down > > Storage Server 2. > > > > Thus we know we must shut down VM's from Storage Domain A to maintenance > > Storage Server 1. Suppose however that VM's are running that we don't > > want to shut down and are hosted from Storage Domain B via Storage > Server 2. > > > > We would want to be able to promote Storage Domain B to Master so that > > we can take down Storage Domain A to do maintenance to Storage Server 1. > > > > Once we are done with maintenance to Storage Server 1 we can bring > > Storage Domain A back on line, re-designate it as Master if desired and > > bring it's VM's back online. > > > > I know I have seen this occur automatically to a point when a Storage > > Domain goes missing that is the Master Domain but I have not noted any > > manual method of doing so given the above scenario. > > > > - DHC > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Users mailing list > > Users@ovirt.org > > http://lists.ovirt.org/ mailman/listinfo/users > > > > > > my understanding is you can move the storage domain A which is master to > > maint. engine will promote storage domain B to master and everything > should > > continue working as is. > > > > > > > > > > > > -- > > > > Med Vänliga Hälsningar > > > ------------------------------------------------------------------------------- > > Karli Sjöberg > > Swedish University of Agricultural Sciences > > Box 7079 (Visiting Address Kronåsvägen 8) > > S-750 07 Uppsala, Sweden > > Phone: +46-(0)18-67 15 66 > > karli.sjob...@slu.se > > > > > > _______________________________________________ > > Users mailing list > > Users@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > >
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users