10:18 p.m.
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
12:05 a.m.
--_000_5F9E965F5A80BC468BE5F40576769F092E70546Dexchange21_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
b25zIDIwMTMtMDgtMTQga2xvY2thbiAyMjoxOCAtMDUwMCBza3JldiBEZWFkIEhvcnNlOg0KSXMg
dGhlcmUgYW55IG1ldGhvZCBvZiBkZXNpZ25hdGluZyB3aGljaCBkb21haW4gc2hvdWxkIGJlIHRo
ZSBtYXN0ZXIgc3RvcmFnZSBkb21haW4gb3IgZm9yY2libHkgY2hhbmdpbmcgdGhlIHJvbGUgdG8g
YSBkaWZmZXJlbnQgc3RvcmFnZSBkb21haW4/DQoNCg0KRUc6IEdpdmVuIHRoZSBmb2xsb3dpbmcg
ZXhhbXBsZQ0KDQoNClN0b3JhZ2UgRG9tYWluIEEgKE1hc3RlcikgLS0+IE5GUyAtLT4gU3RvcmFn
ZSBTZXJ2ZXIgMQ0KDQpTdG9yYWdlIERvbWFpbiBCIC0tPiBORlMgLS0+IFN0b3JhZ2UgU2VydmVy
IDINCg0KDQpPbmUgd2FudHMgdG8gZG8gbWFpbnRlbmFuY2UgdG8gU3RvcmFnZSBTZXJ2ZXIgMSBi
dXQgaW4gZG9pbmcgc28gdGhlIE1hc3RlciBzdG9yYWdlIGRvbWFpbiBpcyBob3N0ZWQgZnJvbSBT
dG9yYWdlIFNlcnZlciAxLiBUaHVzIHRoZSBuZXQgcmVzdWx0IG9mIHRha2luZyBkb3duIFN0b3Jh
Z2UgU2VydmVyIDEgaXMgdGhhdCBvbmUgbXVzdCBhbHNvIHRha2UgZG93biBTdG9yYWdlIFNlcnZl
ciAyLg0KDQoNClRodXMgd2Uga25vdyB3ZSBtdXN0IHNodXQgZG93biBWTSdzIGZyb20gU3RvcmFn
ZSBEb21haW4gQSB0byBtYWludGVuYW5jZSBTdG9yYWdlIFNlcnZlciAxLiBTdXBwb3NlIGhvd2V2
ZXIgdGhhdCBWTSdzIGFyZSBydW5uaW5nIHRoYXQgd2UgZG9uJ3Qgd2FudCB0byBzaHV0IGRvd24g
YW5kIGFyZSBob3N0ZWQgZnJvbSBTdG9yYWdlIERvbWFpbiBCIHZpYSBTdG9yYWdlIFNlcnZlciAy
Lg0KDQoNCldlIHdvdWxkIHdhbnQgdG8gYmUgYWJsZSB0byBwcm9tb3RlIFN0b3JhZ2UgRG9tYWlu
IEIgdG8gTWFzdGVyIHNvIHRoYXQgd2UgY2FuIHRha2UgZG93biBTdG9yYWdlIERvbWFpbiBBIHRv
IGRvIG1haW50ZW5hbmNlIHRvIFN0b3JhZ2UgU2VydmVyIDEuDQoNCg0KT25jZSB3ZSBhcmUgZG9u
ZSB3aXRoIG1haW50ZW5hbmNlIHRvIFN0b3JhZ2UgU2VydmVyIDEgd2UgY2FuIGJyaW5nIFN0b3Jh
Z2UgRG9tYWluIEEgYmFjayBvbiBsaW5lLCByZS1kZXNpZ25hdGUgaXQgYXMgTWFzdGVyIGlmIGRl
c2lyZWQgYW5kIGJyaW5nIGl0J3MgVk0ncyBiYWNrIG9ubGluZS4NCg0KDQpJIGtub3cgSSBoYXZl
IHNlZW4gdGhpcyBvY2N1ciBhdXRvbWF0aWNhbGx5IHRvIGEgcG9pbnQgd2hlbiBhIFN0b3JhZ2Ug
RG9tYWluIGdvZXMgbWlzc2luZyB0aGF0IGlzIHRoZSBNYXN0ZXIgRG9tYWluIGJ1dCBJIGhhdmUg
bm90IG5vdGVkIGFueSBtYW51YWwgbWV0aG9kIG9mIGRvaW5nIHNvIGdpdmVuIHRoZSBhYm92ZSBz
Y2VuYXJpby4NCg0KDQotIERIQw0KDQoNCkhvdyBhYm91dCBqdXN0IHBhdXNpbmcgdGhlIFZNJ3Mg
ZnJvbSB3ZWJhZG1pbiwgc2h1dCBlbmdpbmUgZG93biwgZG8gbWFpbnRlbmFuY2UsIHN0YXJ0IGVu
Z2luZSBiYWNrIHVwIGFuZCB0aGVuIHJ1biB0aGUgVk0ncyBhZ2Fpbj8NCg0KLS0NCg0KTWVkIFbD
pG5saWdhIEjDpGxzbmluZ2FyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpLYXJsaSBTasO2YmVy
Zw0KU3dlZGlzaCBVbml2ZXJzaXR5IG9mIEFncmljdWx0dXJhbCBTY2llbmNlcw0KQm94IDcwNzkg
KFZpc2l0aW5nIEFkZHJlc3MgS3JvbsOlc3bDpGdlbiA4KQ0KUy03NTAgMDcgVXBwc2FsYSwgU3dl
ZGVuDQpQaG9uZTogICs0Ni0oMCkxOC02NyAxNSA2Ng0Ka2FybGkuc2pvYmVyZ0BzbHUuc2U8bWFp
bHRvOmthcmxpLnNqb2JlcmdAYWRtLnNsdS5zZT4NCg==
--_000_5F9E965F5A80BC468BE5F40576769F092E70546Dexchange21_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv
L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv
bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii
IGNvbnRlbnQ9Ikd0a0hUTUwvNC42LjQiPg0KPC9oZWFkPg0KPGJvZHk+DQpvbnMgMjAxMy0wOC0x
NCBrbG9ja2FuIDIyOjE4IC0wNTAwIHNrcmV2IERlYWQgSG9yc2U6DQo8YmxvY2txdW90ZSB0eXBl
PSJDSVRFIj5JcyB0aGVyZSBhbnkgbWV0aG9kIG9mIGRlc2lnbmF0aW5nIHdoaWNoIGRvbWFpbiBz
aG91bGQgYmUgdGhlIG1hc3RlciBzdG9yYWdlIGRvbWFpbiBvciBmb3JjaWJseSBjaGFuZ2luZyB0
aGUgcm9sZSB0byBhIGRpZmZlcmVudCBzdG9yYWdlIGRvbWFpbj88YnI+DQo8YnI+DQo8YnI+DQo8
L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj5FRzogR2l2ZW4gdGhlIGZvbGxv
d2luZyBleGFtcGxlPGJyPg0KPGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg
dHlwZT0iQ0lURSI+U3RvcmFnZSBEb21haW4gQSAoTWFzdGVyKSAtLSZndDsgTkZTIC0tJmd0OyBT
dG9yYWdlIFNlcnZlciAxPGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlw
ZT0iQ0lURSI+U3RvcmFnZSBEb21haW4gQiAtLSZndDsgTkZTIC0tJmd0OyBTdG9yYWdlIFNlcnZl
ciAyPGJyPg0KPGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iQ0lU
RSI+T25lIHdhbnRzIHRvIGRvIG1haW50ZW5hbmNlIHRvIFN0b3JhZ2UgU2VydmVyIDEgYnV0IGlu
IGRvaW5nIHNvIHRoZSBNYXN0ZXIgc3RvcmFnZSBkb21haW4gaXMgaG9zdGVkIGZyb20gU3RvcmFn
ZSBTZXJ2ZXIgMS4gVGh1cyB0aGUgbmV0IHJlc3VsdCBvZiB0YWtpbmcgZG93biBTdG9yYWdlIFNl
cnZlciAxIGlzIHRoYXQgb25lIG11c3QgYWxzbyB0YWtlIGRvd24gU3RvcmFnZSBTZXJ2ZXIgMi4N
Cjxicj4NCjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUi
PlRodXMgd2Uga25vdyB3ZSBtdXN0IHNodXQgZG93biBWTSdzIGZyb20gU3RvcmFnZSBEb21haW4g
QSB0byBtYWludGVuYW5jZSBTdG9yYWdlIFNlcnZlciAxLiBTdXBwb3NlIGhvd2V2ZXIgdGhhdCBW
TSdzIGFyZSBydW5uaW5nIHRoYXQgd2UgZG9uJ3Qgd2FudCB0byBzaHV0IGRvd24gYW5kIGFyZSBo
b3N0ZWQgZnJvbSBTdG9yYWdlIERvbWFpbiBCIHZpYSBTdG9yYWdlIFNlcnZlciAyLjxicj4NCjxi
cj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUiPldlIHdvdWxk
IHdhbnQgdG8gYmUgYWJsZSB0byBwcm9tb3RlIFN0b3JhZ2UgRG9tYWluIEIgdG8gTWFzdGVyIHNv
IHRoYXQgd2UgY2FuIHRha2UgZG93biBTdG9yYWdlIERvbWFpbiBBIHRvIGRvIG1haW50ZW5hbmNl
IHRvIFN0b3JhZ2UgU2VydmVyIDEuPGJyPg0KPGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJs
b2NrcXVvdGUgdHlwZT0iQ0lURSI+T25jZSB3ZSBhcmUgZG9uZSB3aXRoIG1haW50ZW5hbmNlIHRv
IFN0b3JhZ2UgU2VydmVyIDEgd2UgY2FuIGJyaW5nIFN0b3JhZ2UgRG9tYWluIEEgYmFjayBvbiBs
aW5lLCByZS1kZXNpZ25hdGUgaXQgYXMgTWFzdGVyIGlmIGRlc2lyZWQgYW5kIGJyaW5nIGl0J3Mg
Vk0ncyBiYWNrIG9ubGluZS48YnI+DQo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx
dW90ZSB0eXBlPSJDSVRFIj5JIGtub3cgSSBoYXZlIHNlZW4gdGhpcyBvY2N1ciBhdXRvbWF0aWNh
bGx5IHRvIGEgcG9pbnQgd2hlbiBhIFN0b3JhZ2UgRG9tYWluIGdvZXMgbWlzc2luZyB0aGF0IGlz
IHRoZSBNYXN0ZXIgRG9tYWluIGJ1dCBJIGhhdmUgbm90IG5vdGVkIGFueSBtYW51YWwgbWV0aG9k
IG9mIGRvaW5nIHNvIGdpdmVuIHRoZSBhYm92ZSBzY2VuYXJpby48YnI+DQo8YnI+DQo8YnI+DQo8
L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj4tIERIQzxicj4NCjxicj4NCjwv
YmxvY2txdW90ZT4NCjxicj4NCkhvdyBhYm91dCBqdXN0IHBhdXNpbmcgdGhlIFZNJ3MgZnJvbSB3
ZWJhZG1pbiwgc2h1dCBlbmdpbmUgZG93biwgZG8gbWFpbnRlbmFuY2UsIHN0YXJ0IGVuZ2luZSBi
YWNrIHVwIGFuZCB0aGVuIHJ1biB0aGUgVk0ncyBhZ2Fpbj88YnI+DQo8YnI+DQo8dGFibGUgY2Vs
bHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSI+DQo8dGJvZHk+DQo8dHI+
DQo8dGQ+LS0gPGJyPg0KPGJyPg0KTWVkIFbDpG5saWdhIEjDpGxzbmluZ2FyPGJyPg0KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLTxicj4NCkthcmxpIFNqw7ZiZXJnPGJyPg0KU3dlZGlzaCBVbml2ZXJz
aXR5IG9mIEFncmljdWx0dXJhbCBTY2llbmNlczxicj4NCkJveCA3MDc5IChWaXNpdGluZyBBZGRy
ZXNzIEtyb27DpXN2w6RnZW4gOCk8YnI+DQpTLTc1MCAwNyBVcHBzYWxhLCBTd2VkZW48YnI+DQpQ
aG9uZTogJm5ic3A7JiM0Mzs0Ni0oMCkxOC02NyAxNSA2Njxicj4NCjxhIGhyZWY9Im1haWx0bzpr
YXJsaS5zam9iZXJnQGFkbS5zbHUuc2UiPmthcmxpLnNqb2JlcmdAc2x1LnNlPC9hPiA8L3RkPg0K
PC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9ib2R5Pg0KPC9odG1sPg0K
--_000_5F9E965F5A80BC468BE5F40576769F092E70546Dexchange21_--
9:37 a.m.
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(a)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.
10:46 a.m.
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
.
- DHC
On Thu, Aug 15, 2013 at 9:37 AM, Itamar Heim <iheim(a)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(a)ovirt.org
>
http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org...
>
>
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.
11:09 a.m.
----- Original Message -----
From: "Dead Horse" <deadhorseconsulting(a)gmail.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: "<users(a)ovirt.org>" <users(a)ovirt.org>
Sent: Thursday, August 15, 2013 6:46:00 PM
Subject: Re: [Users] Designate Master Storage Domain
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)?
In that case - you could reinitialize the pool using unattached domain (you chose which
one) - this domain will become the new master.
1. Create new unattached domain/Detach the domain that you want to be the master from the
pool (if possible)
2. Move all the pool domain to maintenance (the master should be put to maintenance last
to avoid reconstructing to another domain).
3. Right click on the data center, chose reinitialize storage pool - you can chose which
domain do you want to be the master from the unattached domains.
The other option is manual db intervention :)
Possibly we could add a possibility to manually change the master domain, same as was
added for the spm ("Make SPM" button that was added recently).
@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
.
- DHC
On Thu, Aug 15, 2013 at 9:37 AM, Itamar Heim < iheim(a)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(a)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.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
11:32 a.m.
+1 to Adding a "Make Master Storage Domain Button" ;-)
On Thu, Aug 15, 2013 at 11:09 AM, Liron Aravot <laravot(a)redhat.com> wrote:
----- Original Message -----
> From: "Dead Horse" <deadhorseconsulting(a)gmail.com>
> To: "Itamar Heim" <iheim(a)redhat.com>
> Cc: "<users(a)ovirt.org>" <users(a)ovirt.org>
> Sent: Thursday, August 15, 2013 6:46:00 PM
> Subject: Re: [Users] Designate Master Storage Domain
>
> 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)?
In that case - you could reinitialize the pool using unattached domain
(you chose which one) - this domain will become the new master.
1. Create new unattached domain/Detach the domain that you want to be the
master from the pool (if possible)
2. Move all the pool domain to maintenance (the master should be put to
maintenance last to avoid reconstructing to another domain).
3. Right click on the data center, chose reinitialize storage pool - you
can chose which domain do you want to be the master from the unattached
domains.
The other option is manual db intervention :)
Possibly we could add a possibility to manually change the master domain,
same as was added for the spm ("Make SPM" button that was added recently).
>
> @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
> .
> - DHC
>
>
> On Thu, Aug 15, 2013 at 9:37 AM, Itamar Heim < iheim(a)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(a)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.
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
12:30 p.m.
On 08/15/2013 07:32 PM, Dead Horse wrote:
+1 to Adding a "Make Master Storage Domain Button" ;-)
actually, not sure i'm for this.
if anything, we want to get rid of the master storage domain going
forward to make the storage domains autonomous, allowing to mix and
match storage types, local and shared storage, etc...
rhev-m may reconstruct the master storage domain on any of your SDs over
time automatically
On Thu, Aug 15, 2013 at 11:09 AM, Liron Aravot <laravot(a)redhat.com
<mailto:laravot@redhat.com>> wrote:
----- Original Message -----
> From: "Dead Horse" <deadhorseconsulting(a)gmail.com
<mailto:deadhorseconsulting@gmail.com>>
> To: "Itamar Heim" <iheim(a)redhat.com
<mailto:iheim@redhat.com>>
> Cc: "<users(a)ovirt.org <mailto:users@ovirt.org>>"
<users(a)ovirt.org
<mailto:users@ovirt.org>>
> Sent: Thursday, August 15, 2013 6:46:00 PM
> Subject: Re: [Users] Designate Master Storage Domain
>
> 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)?
In that case - you could reinitialize the pool using unattached
domain (you chose which one) - this domain will become the new master.
1. Create new unattached domain/Detach the domain that you want to
be the master from the pool (if possible)
2. Move all the pool domain to maintenance (the master should be put
to maintenance last to avoid reconstructing to another domain).
3. Right click on the data center, chose reinitialize storage pool -
you can chose which domain do you want to be the master from the
unattached domains.
The other option is manual db intervention :)
Possibly we could add a possibility to manually change the master
domain, same as was added for the spm ("Make SPM" button that was
added recently).
>
> @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
> .
> - DHC
>
>
> On Thu, Aug 15, 2013 at 9:37 AM, Itamar Heim < iheim(a)redhat.com
<mailto:iheim@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(a)ovirt.org <mailto: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.
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org <mailto:Users@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
>
1:45 p.m.
I agree Itamar.
That would actually be the most optimal situation. Freedom in storage
domain types and ability to import or export any given storage domain
freely. Along with this more freedom in the image types allowed on
file-based storage domains as well (EG: not only raw).
On Thu, Aug 15, 2013 at 12:30 PM, Itamar Heim <iheim(a)redhat.com> wrote:
On 08/15/2013 07:32 PM, Dead Horse wrote:
> +1 to Adding a "Make Master Storage Domain Button" ;-)
>
actually, not sure i'm for this.
if anything, we want to get rid of the master storage domain going forward
to make the storage domains autonomous, allowing to mix and match storage
types, local and shared storage, etc...
rhev-m may reconstruct the master storage domain on any of your SDs over
time automatically
>
> On Thu, Aug 15, 2013 at 11:09 AM, Liron Aravot <laravot(a)redhat.com
> <mailto:laravot@redhat.com>> wrote:
>
>
>
> ----- Original Message -----
> > From: "Dead Horse" <deadhorseconsulting(a)gmail.com
> <mailto:deadhorseconsulting@**gmail.com<deadhorseconsulting@gmail.com>
> >>
> > To: "Itamar Heim" <iheim(a)redhat.com
<mailto:iheim@redhat.com>>
> > Cc: "<users(a)ovirt.org <mailto:users@ovirt.org>>"
<users(a)ovirt.org
> <mailto:users@ovirt.org>>
> > Sent: Thursday, August 15, 2013 6:46:00 PM
> > Subject: Re: [Users] Designate Master Storage Domain
> >
> > 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)?
>
> In that case - you could reinitialize the pool using unattached
> domain (you chose which one) - this domain will become the new master.
> 1. Create new unattached domain/Detach the domain that you want to
> be the master from the pool (if possible)
> 2. Move all the pool domain to maintenance (the master should be put
> to maintenance last to avoid reconstructing to another domain).
> 3. Right click on the data center, chose reinitialize storage pool -
> you can chose which domain do you want to be the master from the
> unattached domains.
>
> The other option is manual db intervention :)
> Possibly we could add a possibility to manually change the master
> domain, same as was added for the spm ("Make SPM" button that was
> added recently).
>
>
> >
> > @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
> > .
> > - DHC
> >
> >
> > On Thu, Aug 15, 2013 at 9:37 AM, Itamar Heim < iheim(a)redhat.com
> <mailto:iheim@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(a)ovirt.org <mailto: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.
> >
> >
> > ______________________________**_________________
> > Users mailing list
> > Users(a)ovirt.org <mailto:Users@ovirt.org>
> >
http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org...
> >
>
>
>
3:13 p.m.
I am all for the "mix and match" idea of storage.
On Thu, Aug 15, 2013 at 1:30 PM, Itamar Heim <iheim(a)redhat.com> wrote:
On 08/15/2013 07:32 PM, Dead Horse wrote:
> +1 to Adding a "Make Master Storage Domain Button" ;-)
>
actually, not sure i'm for this.
if anything, we want to get rid of the master storage domain going forward
to make the storage domains autonomous, allowing to mix and match storage
types, local and shared storage, etc...
rhev-m may reconstruct the master storage domain on any of your SDs over
time automatically
>
> On Thu, Aug 15, 2013 at 11:09 AM, Liron Aravot <laravot(a)redhat.com
> <mailto:laravot@redhat.com>> wrote:
>
>
>
> ----- Original Message -----
> > From: "Dead Horse" <deadhorseconsulting(a)gmail.com
> <mailto:deadhorseconsulting@**gmail.com<deadhorseconsulting@gmail.com>
> >>
> > To: "Itamar Heim" <iheim(a)redhat.com
<mailto:iheim@redhat.com>>
> > Cc: "<users(a)ovirt.org <mailto:users@ovirt.org>>"
<users(a)ovirt.org
> <mailto:users@ovirt.org>>
> > Sent: Thursday, August 15, 2013 6:46:00 PM
> > Subject: Re: [Users] Designate Master Storage Domain
> >
> > 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)?
>
> In that case - you could reinitialize the pool using unattached
> domain (you chose which one) - this domain will become the new master.
> 1. Create new unattached domain/Detach the domain that you want to
> be the master from the pool (if possible)
> 2. Move all the pool domain to maintenance (the master should be put
> to maintenance last to avoid reconstructing to another domain).
> 3. Right click on the data center, chose reinitialize storage pool -
> you can chose which domain do you want to be the master from the
> unattached domains.
>
> The other option is manual db intervention :)
> Possibly we could add a possibility to manually change the master
> domain, same as was added for the spm ("Make SPM" button that was
> added recently).
>
>
> >
> > @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
> > .
> > - DHC
> >
> >
> > On Thu, Aug 15, 2013 at 9:37 AM, Itamar Heim < iheim(a)redhat.com
> <mailto:iheim@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(a)ovirt.org <mailto: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.
> >
> >
> > ______________________________**_________________
> > Users mailing list
> > Users(a)ovirt.org <mailto:Users@ovirt.org>
> >
http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org...
> >
>
>
>
______________________________**_________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org...
--
--
James P. Kinney III
*
*Every time you stop a school, you will have to build a jail. What you gain
at one end you lose at the other. It's like feeding a dog on his own tail.
It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
*
http://heretothereideas.blogspot.com/
*
12:14 a.m.
--_000_5F9E965F5A80BC468BE5F40576769F092E705929exchange21_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
dG9yIDIwMTMtMDgtMTUga2xvY2thbiAxMDo0NiAtMDUwMCBza3JldiBEZWFkIEhvcnNlOg0KSXRh
bWFyIHRoaXMgaXMgdHJ1ZSAoSSBoYXZlIG5vdGVkIG9jY2FzaW9uYWwgdGltaW5nIGlzc3VlcyB3
aXRoIGl0IGFjdHVhbGx5IHdvcmtpbmcpLg0KQnV0IHdoYXQgaWYgYXMgdGhlIGFkbWluaXN0cmF0
b3IgSSBoYXZlIGEgc3BlY2lmaWMgc3RvcmFnZSBkb21haW4gaW4gbWluZCB0aGF0IEkgd291bGQg
bGlrZSB0byBoYXZlIGJlY29tZSB0aGUgbWFzdGVyIChpbiB0aGUgY2FzZSBvZiBtb3JlIHRoZW4g
dHdvKT8NCg0KDQpAS2FybGkNCg0KVGhlIGlkZWEgaXMgbm90IHRvIG5vdCBoYXZlIHRvIHNodXQg
ZG93biBhbGwgdGhlIFZNJ3Mgb3IgdGhlIGVuZ2luZSBqdXN0IHRvIG1haW50ZW5hbmNlIGEgc3Rv
cmFnZSBkb21haW4ocykgdGhhdCBtYXkgaGFwcGVuIHRvIGJlIG9uIGRpc3BhcmF0ZSBzdG9yYWdl
IHNlcnZlcnMNCi4NCg0KWWVzIEkgdW5kZXJzdG9vZCB0aGF0LiBNeSBzdWdnZXN0aW9uIHdhcyBh
IHdvcmthcm91bmQgdW50aWwgc3VjaCBvcGVyYXRpb25zIGFyZSBwb3NzaWJsZSwgdGhhdCB3ZSB1
c2UgdG8gbWluaW1pemUgZG93bnRpbWUgYXMgbXVjaCBhcyBwb3NzaWJsZSwgdG8gcGF1c2UgdGhl
IFZNJ3MsIHNodXQgZG93biBlbmdpbmUsIG1haW50ZW5hbmNlLCBicmluZyBlbmdpbmUgYW5kIFZN
J3MgYmFjay4gU2luY2UgdGhlIFZNJ3Mgb25seSB3YXMgcGF1c2VkIGFuZCBlbmdpbmUgc2h1dCBk
b3duLCB0aGUgVk0ncyBqdXN0IGNvbnRpbnVlIGdvaW5nIGhhcHBpbHkgdW5rbm93aW5nIGV4YWN0
bHkgZnJvbSB3aGVyZSB0aGV5IHdlcmUsIGFuZCBhIHJlYm9vdCBvZiBhIHN0b3JhZ2UgdGFrZXMg
YXQgbW9zdCA1bWlucywgd2hpY2ggbWVhbnMgNW1pbnMgdG90YWwgb2YgZG93bnRpbWUgaW4gdGhl
IGNsb3VkIGVudmlyb25tZW50IGZvciB0aGF0IHF1YXJ0ZXIsIHdoaWNoIGlzIGFjY2VwdGFibGUg
Zm9yIGp1c3QgYWJvdXQgYW55IFNMQS4NCg0KL0thcmxpDQoNCg0KLSBESEMNCg0KDQoNCk9uIFRo
dSwgQXVnIDE1LCAyMDEzIGF0IDk6MzcgQU0sIEl0YW1hciBIZWltIDxpaGVpbUByZWRoYXQuY29t
PG1haWx0bzppaGVpbUByZWRoYXQuY29tPj4gd3JvdGU6DQpPbiAwOC8xNS8yMDEzIDA2OjE4IEFN
LCBEZWFkIEhvcnNlIHdyb3RlOg0KDQpJcyB0aGVyZSBhbnkgbWV0aG9kIG9mIGRlc2lnbmF0aW5n
IHdoaWNoIGRvbWFpbiBzaG91bGQgYmUgdGhlIG1hc3Rlcg0Kc3RvcmFnZSBkb21haW4gb3IgZm9y
Y2libHkgY2hhbmdpbmcgdGhlIHJvbGUgdG8gYSBkaWZmZXJlbnQgc3RvcmFnZSBkb21haW4/DQoN
CkVHOiBHaXZlbiB0aGUgZm9sbG93aW5nIGV4YW1wbGUNCg0KU3RvcmFnZSBEb21haW4gQSAoTWFz
dGVyKSAtLT4gTkZTIC0tPiBTdG9yYWdlIFNlcnZlciAxDQpTdG9yYWdlIERvbWFpbiBCIC0tPiBO
RlMgLS0+IFN0b3JhZ2UgU2VydmVyIDINCg0KT25lIHdhbnRzIHRvIGRvIG1haW50ZW5hbmNlIHRv
IFN0b3JhZ2UgU2VydmVyIDEgYnV0IGluIGRvaW5nIHNvIHRoZQ0KTWFzdGVyIHN0b3JhZ2UgZG9t
YWluIGlzIGhvc3RlZCBmcm9tIFN0b3JhZ2UgU2VydmVyIDEuIFRodXMgdGhlIG5ldA0KcmVzdWx0
IG9mIHRha2luZyBkb3duIFN0b3JhZ2UgU2VydmVyIDEgaXMgdGhhdCBvbmUgbXVzdCBhbHNvIHRh
a2UgZG93bg0KU3RvcmFnZSBTZXJ2ZXIgMi4NCg0KVGh1cyB3ZSBrbm93IHdlIG11c3Qgc2h1dCBk
b3duIFZNJ3MgZnJvbSBTdG9yYWdlIERvbWFpbiBBIHRvIG1haW50ZW5hbmNlDQpTdG9yYWdlIFNl
cnZlciAxLiBTdXBwb3NlIGhvd2V2ZXIgdGhhdCBWTSdzIGFyZSBydW5uaW5nIHRoYXQgd2UgZG9u
J3QNCndhbnQgdG8gc2h1dCBkb3duIGFuZCBhcmUgaG9zdGVkIGZyb20gU3RvcmFnZSBEb21haW4g
QiB2aWEgU3RvcmFnZSBTZXJ2ZXIgMi4NCg0KV2Ugd291bGQgd2FudCB0byBiZSBhYmxlIHRvIHBy
b21vdGUgU3RvcmFnZSBEb21haW4gQiB0byBNYXN0ZXIgc28gdGhhdA0Kd2UgY2FuIHRha2UgZG93
biBTdG9yYWdlIERvbWFpbiBBIHRvIGRvIG1haW50ZW5hbmNlIHRvIFN0b3JhZ2UgU2VydmVyIDEu
DQoNCk9uY2Ugd2UgYXJlIGRvbmUgd2l0aCBtYWludGVuYW5jZSB0byBTdG9yYWdlIFNlcnZlciAx
IHdlIGNhbiBicmluZw0KU3RvcmFnZSBEb21haW4gQSBiYWNrIG9uIGxpbmUsIHJlLWRlc2lnbmF0
ZSBpdCBhcyBNYXN0ZXIgaWYgZGVzaXJlZCBhbmQNCmJyaW5nIGl0J3MgVk0ncyBiYWNrIG9ubGlu
ZS4NCg0KSSBrbm93IEkgaGF2ZSBzZWVuIHRoaXMgb2NjdXIgYXV0b21hdGljYWxseSB0byBhIHBv
aW50IHdoZW4gYSBTdG9yYWdlDQpEb21haW4gZ29lcyBtaXNzaW5nIHRoYXQgaXMgdGhlIE1hc3Rl
ciBEb21haW4gYnV0IEkgaGF2ZSBub3Qgbm90ZWQgYW55DQptYW51YWwgbWV0aG9kIG9mIGRvaW5n
IHNvIGdpdmVuIHRoZSBhYm92ZSBzY2VuYXJpby4NCg0KLSBESEMNCg0KDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpVc2VycyBtYWlsaW5nIGxpc3QN
ClVzZXJzQG92aXJ0Lm9yZzxtYWlsdG86VXNlcnNAb3ZpcnQub3JnPg0KaHR0cDovL2xpc3RzLm92
aXJ0Lm9yZy88aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPm1h
aWxtYW4vbGlzdGluZm8vdXNlcnM8aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL3VzZXJzPg0KDQoNCm15IHVuZGVyc3RhbmRpbmcgaXMgeW91IGNhbiBtb3ZlIHRoZSBzdG9y
YWdlIGRvbWFpbiBBIHdoaWNoIGlzIG1hc3RlciB0byBtYWludC4gZW5naW5lIHdpbGwgcHJvbW90
ZSBzdG9yYWdlIGRvbWFpbiBCIHRvIG1hc3RlciBhbmQgZXZlcnl0aGluZyBzaG91bGQgY29udGlu
dWUgd29ya2luZyBhcyBpcy4NCg0KDQoNCi0tDQoNCk1lZCBWw6RubGlnYSBIw6Rsc25pbmdhcg0K
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KS2FybGkgU2rDtmJlcmcNClN3ZWRpc2ggVW5pdmVyc2l0
eSBvZiBBZ3JpY3VsdHVyYWwgU2NpZW5jZXMNCkJveCA3MDc5IChWaXNpdGluZyBBZGRyZXNzIEty
b27DpXN2w6RnZW4gOCkNClMtNzUwIDA3IFVwcHNhbGEsIFN3ZWRlbg0KUGhvbmU6ICArNDYtKDAp
MTgtNjcgMTUgNjYNCmthcmxpLnNqb2JlcmdAc2x1LnNlPG1haWx0bzprYXJsaS5zam9iZXJnQGFk
bS5zbHUuc2U+DQo=
--_000_5F9E965F5A80BC468BE5F40576769F092E705929exchange21_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUUkFOU0lUSU9OQUwv
L0VOIj4NCjxodG1sPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv
bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii
IGNvbnRlbnQ9Ikd0a0hUTUwvNC42LjQiPg0KPC9oZWFkPg0KPGJvZHk+DQp0b3IgMjAxMy0wOC0x
NSBrbG9ja2FuIDEwOjQ2IC0wNTAwIHNrcmV2IERlYWQgSG9yc2U6DQo8YmxvY2txdW90ZSB0eXBl
PSJDSVRFIj5JdGFtYXIgdGhpcyBpcyB0cnVlIChJIGhhdmUgbm90ZWQgb2NjYXNpb25hbCB0aW1p
bmcgaXNzdWVzIHdpdGggaXQgYWN0dWFsbHkgd29ya2luZykuPGJyPg0KQnV0IHdoYXQgaWYgYXMg
dGhlIGFkbWluaXN0cmF0b3IgSSBoYXZlIGEgc3BlY2lmaWMgc3RvcmFnZSBkb21haW4gaW4gbWlu
ZCB0aGF0IEkgd291bGQgbGlrZSB0byBoYXZlIGJlY29tZSB0aGUgbWFzdGVyIChpbiB0aGUgY2Fz
ZSBvZiBtb3JlIHRoZW4gdHdvKT88YnI+DQo8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJDSVRFIj5AS2FybGk8YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJDSVRFIj5UaGUgaWRlYSBpcyBub3QgdG8gbm90IGhhdmUgdG8gc2h1dCBk
b3duIGFsbCB0aGUgVk0ncyBvciB0aGUgZW5naW5lIGp1c3QgdG8gbWFpbnRlbmFuY2UgYSBzdG9y
YWdlIGRvbWFpbihzKSB0aGF0IG1heSBoYXBwZW4gdG8gYmUgb24gZGlzcGFyYXRlIHN0b3JhZ2Ug
c2VydmVyczxicj4NCi48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQpZZXMgSSB1bmRlcnN0b29k
IHRoYXQuIE15IHN1Z2dlc3Rpb24gd2FzIGEgd29ya2Fyb3VuZCB1bnRpbCBzdWNoIG9wZXJhdGlv
bnMgYXJlIHBvc3NpYmxlLCB0aGF0IHdlIHVzZSB0byBtaW5pbWl6ZSBkb3dudGltZSBhcyBtdWNo
IGFzIHBvc3NpYmxlLCB0bw0KPGI+cGF1c2U8L2I+IHRoZSBWTSdzLCBzaHV0IGRvd24gZW5naW5l
LCBtYWludGVuYW5jZSwgYnJpbmcgZW5naW5lIGFuZCBWTSdzIGJhY2suIFNpbmNlIHRoZSBWTSdz
IG9ubHkgd2FzIHBhdXNlZCBhbmQgZW5naW5lIHNodXQgZG93biwgdGhlIFZNJ3MganVzdCBjb250
aW51ZSBnb2luZyBoYXBwaWx5IHVua25vd2luZyBleGFjdGx5IGZyb20gd2hlcmUgdGhleSB3ZXJl
LCBhbmQgYSByZWJvb3Qgb2YgYSBzdG9yYWdlIHRha2VzIGF0IG1vc3QgNW1pbnMsDQogd2hpY2gg
bWVhbnMgNW1pbnMgdG90YWwgb2YgZG93bnRpbWUgaW4gdGhlIGNsb3VkIGVudmlyb25tZW50IGZv
ciB0aGF0IHF1YXJ0ZXIsIHdoaWNoIGlzIGFjY2VwdGFibGUgZm9yIGp1c3QgYWJvdXQgYW55IFNM
QS48YnI+DQo8YnI+DQovS2FybGk8YnI+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj48
YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJDSVRFIj4tIERIQzxicj4NCjxi
cj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUiPjxicj4NCjxicj4NCjwv
YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUiPk9uIFRodSwgQXVnIDE1LCAyMDEz
IGF0IDk6MzcgQU0sIEl0YW1hciBIZWltICZsdDs8YSBocmVmPSJtYWlsdG86aWhlaW1AcmVkaGF0
LmNvbSI+aWhlaW1AcmVkaGF0LmNvbTwvYT4mZ3Q7IHdyb3RlOg0KPC9ibG9ja3F1b3RlPg0KPGJs
b2NrcXVvdGUgdHlwZT0iQ0lURSI+DQo8YmxvY2txdW90ZT5PbiAwOC8xNS8yMDEzIDA2OjE4IEFN
LCBEZWFkIEhvcnNlIHdyb3RlOjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90
ZT4NCjxibG9ja3F1b3RlIHR5cGU9IkNJVEUiPg0KPGJsb2NrcXVvdGU+DQo8YmxvY2txdW90ZT5J
cyB0aGVyZSBhbnkgbWV0aG9kIG9mIGRlc2lnbmF0aW5nIHdoaWNoIGRvbWFpbiBzaG91bGQgYmUg
dGhlIG1hc3Rlcjxicj4NCnN0b3JhZ2UgZG9tYWluIG9yIGZvcmNpYmx5IGNoYW5naW5nIHRoZSBy
b2xlIHRvIGEgZGlmZmVyZW50IHN0b3JhZ2UgZG9tYWluPzxicj4NCjxicj4NCkVHOiBHaXZlbiB0
aGUgZm9sbG93aW5nIGV4YW1wbGU8YnI+DQo8YnI+DQpTdG9yYWdlIERvbWFpbiBBIChNYXN0ZXIp
IC0tJmd0OyBORlMgLS0mZ3Q7IFN0b3JhZ2UgU2VydmVyIDE8YnI+DQpTdG9yYWdlIERvbWFpbiBC
IC0tJmd0OyBORlMgLS0mZ3Q7IFN0b3JhZ2UgU2VydmVyIDI8YnI+DQo8YnI+DQpPbmUgd2FudHMg
dG8gZG8gbWFpbnRlbmFuY2UgdG8gU3RvcmFnZSBTZXJ2ZXIgMSBidXQgaW4gZG9pbmcgc28gdGhl
PGJyPg0KTWFzdGVyIHN0b3JhZ2UgZG9tYWluIGlzIGhvc3RlZCBmcm9tIFN0b3JhZ2UgU2VydmVy
IDEuIFRodXMgdGhlIG5ldDxicj4NCnJlc3VsdCBvZiB0YWtpbmcgZG93biBTdG9yYWdlIFNlcnZl
ciAxIGlzIHRoYXQgb25lIG11c3QgYWxzbyB0YWtlIGRvd248YnI+DQpTdG9yYWdlIFNlcnZlciAy
Ljxicj4NCjxicj4NClRodXMgd2Uga25vdyB3ZSBtdXN0IHNodXQgZG93biBWTSdzIGZyb20gU3Rv
cmFnZSBEb21haW4gQSB0byBtYWludGVuYW5jZTxicj4NClN0b3JhZ2UgU2VydmVyIDEuIFN1cHBv
c2UgaG93ZXZlciB0aGF0IFZNJ3MgYXJlIHJ1bm5pbmcgdGhhdCB3ZSBkb24ndDxicj4NCndhbnQg
dG8gc2h1dCBkb3duIGFuZCBhcmUgaG9zdGVkIGZyb20gU3RvcmFnZSBEb21haW4gQiB2aWEgU3Rv
cmFnZSBTZXJ2ZXIgMi48YnI+DQo8YnI+DQpXZSB3b3VsZCB3YW50IHRvIGJlIGFibGUgdG8gcHJv
bW90ZSBTdG9yYWdlIERvbWFpbiBCIHRvIE1hc3RlciBzbyB0aGF0PGJyPg0Kd2UgY2FuIHRha2Ug
ZG93biBTdG9yYWdlIERvbWFpbiBBIHRvIGRvIG1haW50ZW5hbmNlIHRvIFN0b3JhZ2UgU2VydmVy
IDEuPGJyPg0KPGJyPg0KT25jZSB3ZSBhcmUgZG9uZSB3aXRoIG1haW50ZW5hbmNlIHRvIFN0b3Jh
Z2UgU2VydmVyIDEgd2UgY2FuIGJyaW5nPGJyPg0KU3RvcmFnZSBEb21haW4gQSBiYWNrIG9uIGxp
bmUsIHJlLWRlc2lnbmF0ZSBpdCBhcyBNYXN0ZXIgaWYgZGVzaXJlZCBhbmQ8YnI+DQpicmluZyBp
dCdzIFZNJ3MgYmFjayBvbmxpbmUuPGJyPg0KPGJyPg0KSSBrbm93IEkgaGF2ZSBzZWVuIHRoaXMg
b2NjdXIgYXV0b21hdGljYWxseSB0byBhIHBvaW50IHdoZW4gYSBTdG9yYWdlPGJyPg0KRG9tYWlu
IGdvZXMgbWlzc2luZyB0aGF0IGlzIHRoZSBNYXN0ZXIgRG9tYWluIGJ1dCBJIGhhdmUgbm90IG5v
dGVkIGFueTxicj4NCm1hbnVhbCBtZXRob2Qgb2YgZG9pbmcgc28gZ2l2ZW4gdGhlIGFib3ZlIHNj
ZW5hcmlvLjxicj4NCjxicj4NCi0gREhDPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9ibG9ja3F1
b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iQ0lU
RSI+DQo8YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlPl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KVXNlcnMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl
Zj0ibWFpbHRvOlVzZXJzQG92aXJ0Lm9yZyI+VXNlcnNAb3ZpcnQub3JnPC9hPjxicj4NCjxhIGhy
ZWY9Imh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycyI+aHR0cDov
L2xpc3RzLm92aXJ0Lm9yZy88L2E+PGEgaHJlZj0iaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWls
bWFuL2xpc3RpbmZvL3VzZXJzIj5tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPC9hPjxicj4NCjxicj4N
CjwvYmxvY2txdW90ZT4NCjxicj4NCm15IHVuZGVyc3RhbmRpbmcgaXMgeW91IGNhbiBtb3ZlIHRo
ZSBzdG9yYWdlIGRvbWFpbiBBIHdoaWNoIGlzIG1hc3RlciB0byBtYWludC4gZW5naW5lIHdpbGwg
cHJvbW90ZSBzdG9yYWdlIGRvbWFpbiBCIHRvIG1hc3RlciBhbmQgZXZlcnl0aGluZyBzaG91bGQg
Y29udGludWUgd29ya2luZyBhcyBpcy4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi
bG9ja3F1b3RlIHR5cGU9IkNJVEUiPjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjx0
YWJsZSBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIj4NCjx0Ym9k
eT4NCjx0cj4NCjx0ZD4tLSA8YnI+DQo8YnI+DQpNZWQgVsOkbmxpZ2EgSMOkbHNuaW5nYXI8YnI+
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KS2FybGkgU2rDtmJlcmc8YnI+DQpTd2VkaXNo
IFVuaXZlcnNpdHkgb2YgQWdyaWN1bHR1cmFsIFNjaWVuY2VzPGJyPg0KQm94IDcwNzkgKFZpc2l0
aW5nIEFkZHJlc3MgS3JvbsOlc3bDpGdlbiA4KTxicj4NClMtNzUwIDA3IFVwcHNhbGEsIFN3ZWRl
bjxicj4NClBob25lOiAmbmJzcDsmIzQzOzQ2LSgwKTE4LTY3IDE1IDY2PGJyPg0KPGEgaHJlZj0i
bWFpbHRvOmthcmxpLnNqb2JlcmdAYWRtLnNsdS5zZSI+a2FybGkuc2pvYmVyZ0BzbHUuc2U8L2E+
IDwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo=
--_000_5F9E965F5A80BC468BE5F40576769F092E705929exchange21_--
8:46 a.m.
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
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(a)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(a)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(a)ovirt.org
http://lists.ovirt.org/ <http://lists.ovirt.org/mailman/listinfo/users>
mailman/listinfo/users <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(a)slu.se <karli.sjoberg(a)adm.slu.se>
1:50 a.m.
On 08/16/2013 04:46 PM, Dead Horse wrote:
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 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.
I'm sorry - how is pausing VMs running from a storage domain moved to
maint is related to master storage domain?
- DHC
On Fri, Aug 16, 2013 at 12:14 AM, Karli Sjöberg <Karli.Sjoberg(a)slu.se
<mailto:Karli.Sjoberg@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(a)redhat.com
> <mailto:iheim@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(a)ovirt.org <mailto:Users@ovirt.org>
> http://lists.ovirt.org/
>
<http://lists.ovirt.org/mailman/listinfo/users>mailman/listinfo/users
> <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 <tel:%2B46-%280%2918-67%2015%2066>
karli.sjoberg(a)slu.se <mailto:karli.sjoberg@adm.slu.se>
5:47 a.m.
----- 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(a)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(a)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(a)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(a)slu.se
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
12:08 p.m.
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 <abaron(a)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(a)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(a)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(a)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(a)slu.se
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
1:27 p.m.
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
<deadhorseconsulting(a)gmail.com>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 <abaron(a)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(a)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(a)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(a)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(a)slu.se
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
>
2:12 a.m.
----- 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(a)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(a)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(a)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(a)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(a)slu.se
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
>
3896
days inactive
3909
days old
15 comments
6 participants
participants (6)
-
Ayal Baron -
Dead Horse -
Itamar Heim -
Jim Kinney -
Karli Sjöberg -
Liron Aravot