[Users] Designate Master Storage Domain
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
--_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_--
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.
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@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<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.
----- Original Message -----
From: "Dead Horse" <deadhorseconsulting@gmail.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "<users@ovirt.org>" <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@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.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
+1 to Adding a "Make Master Storage Domain Button" ;-) On Thu, Aug 15, 2013 at 11:09 AM, Liron Aravot <laravot@redhat.com> wrote:
----- Original Message -----
From: "Dead Horse" <deadhorseconsulting@gmail.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "<users@ovirt.org>" <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@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.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@redhat.com <mailto:laravot@redhat.com>> wrote:
----- Original Message ----- > From: "Dead Horse" <deadhorseconsulting@gmail.com <mailto:deadhorseconsulting@gmail.com>> > To: "Itamar Heim" <iheim@redhat.com <mailto:iheim@redhat.com>> > Cc: "<users@ovirt.org <mailto:users@ovirt.org>>" <users@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@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@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@ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/users >
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@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@redhat.com <mailto:laravot@redhat.com>> wrote:
----- Original Message ----- > From: "Dead Horse" <deadhorseconsulting@gmail.com <mailto:deadhorseconsulting@**gmail.com<deadhorseconsulting@gmail.com>
> To: "Itamar Heim" <iheim@redhat.com <mailto:iheim@redhat.com>> > Cc: "<users@ovirt.org <mailto:users@ovirt.org>>" <users@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@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@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@ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org/mailman/listinfo/users> >
I am all for the "mix and match" idea of storage. On Thu, Aug 15, 2013 at 1:30 PM, Itamar Heim <iheim@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@redhat.com <mailto:laravot@redhat.com>> wrote:
----- Original Message ----- > From: "Dead Horse" <deadhorseconsulting@gmail.com <mailto:deadhorseconsulting@**gmail.com<deadhorseconsulting@gmail.com>
> To: "Itamar Heim" <iheim@redhat.com <mailto:iheim@redhat.com>> > Cc: "<users@ovirt.org <mailto:users@ovirt.org>>" <users@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@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@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@ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org/mailman/listinfo/users> >
______________________________**_________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org/mailman/listinfo/users>
-- -- 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/ *
--_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_--
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@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@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/ <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@slu.se <karli.sjoberg@adm.slu.se>
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@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@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@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@slu.se <mailto:karli.sjoberg@adm.slu.se>
----- 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@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@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.sjoberg@slu.se
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@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@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@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.sjoberg@slu.se
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@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@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@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@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.sjoberg@slu.se
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
----- 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@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@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@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.sjoberg@slu.se
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (6)
-
Ayal Baron -
Dead Horse -
Itamar Heim -
Jim Kinney -
Karli Sjöberg -
Liron Aravot