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