I should note that pausing the VM's does not seem to be an option or it is not working. Currently pausing all VM's associated with a particular storage domain then trying to place that domain into maintenance mode yields: "Error while executing action: Cannot deactivate Storage. Active VMs were detected." "-Please ensure all VMs associated with this Storage Domain are stopped and in the Down state first."
This is with engine built from latest master. - DHC On Mon, Aug 26, 2013 at 12:08 PM, Dead Horse <[email protected]>wrote: > 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 <[email protected]> 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 < [email protected]> >> > 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 < [email protected] > >> 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 >> > [email protected] >> > 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 >> > [email protected] >> > >> > >> > _______________________________________________ >> > Users mailing list >> > [email protected] >> > http://lists.ovirt.org/mailman/listinfo/users >> > >> > >
_______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
