[Users] Designate Master Storage Domain

[Ayal Baron]

----- Original Message -----
> 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.

You gave examples where you want to migrate your data and you don't want to kill your VMs, so I suggested live storage migration, where the VM keeps running on the same host, but the underlying disk is moved from one storage domain to another.

You basically have 3 options:
1. live storage migration
2. hotunplug the disk (assuming guest supports it and disk interface supports it) - in case the VM can live without this disk
3. stop the VM

Putting a domain in maintenance while there are paused VMs with disks on this domain is not implemented in the system.

But going back to your original scenario I think this discussion has shifted quite far from what you actually want to achieve, so I'd like to revisit that.
First I'll explain what I understood from your original request to make sure that we're on the same page:
You have 2 storage domains sd1 and sd2.
sd1 is currently master storage domain.
you want to put sd1 in maintenance.
you have running VMs using *sd2* which you do not want to shut down.

For the above scenario (which I hope is what you're aiming for), all you have to do is stop only the VMs which have disks on *sd1* (or live storage migrate or hotunplug as explained above) and once that is done just put sd1 in maintenance.  In this scenario, the system will automatically move the master storage domain to be sd2, no downtime for VMs which don't have disks on sd1.



> - DHC
> 
> 
> On Sun, Aug 18, 2013 at 5:47 AM, Ayal Baron <abaron at 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.Sjoberg at 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 < iheim at 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 at 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.sjoberg at slu.se
> > >
> > >
> > > _______________________________________________
> > > Users mailing list
> > > Users at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/users
> > >
> >
>