Info on manual operations after removing FC storage domain
Hello, I'm relocating some disks from some storage domains to other ones. At the end I'm going to remove source storage domains. All the SD involved are FC and the hosts are CentOS 7.4 I see that after removing an SD from oVirt, the multipath part on host remains. What is the correct sequence of operations to do at hosts' side after completing the Webadmin Gui part? Some questions: - do the remove SD from gui imply vgchange -an of the VG and vgremove of the vg? Or are they delegated to post actions? - do it imply the pvremove on the LUN? After clearing what above I would imagine remaining steps would be, based on my previous similar experience with iSCSI removal on physical servers: - take note of the paths sdY, ... of mpathX - remove the multipath device with multipath -f mpathX - flush the single paths devices blockdev --flushbufs sdY for every path of the previous taken note ones - remove single path devices echo 1 > /sys/block/sdY/device/delete - remove LUN from storage array when previous steps done on all the hypervisors Any comment? Any further step at vdsm level files..? Thanks in advance, Gianluca
On Oct 6, 2017 2:41 PM, "Gianluca Cecchi" <gianluca.cecchi@gmail.com> wrote: Hello, I'm relocating some disks from some storage domains to other ones. At the end I'm going to remove source storage domains. All the SD involved are FC and the hosts are CentOS 7.4 I see that after removing an SD from oVirt, the multipath part on host remains. What is the correct sequence of operations to do at hosts' side after completing the Webadmin Gui part? https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm... (which seems to be similar to your steps below. I'd remove it from the storage side after flushing though). Y. Some questions: - do the remove SD from gui imply vgchange -an of the VG and vgremove of the vg? Or are they delegated to post actions? - do it imply the pvremove on the LUN? After clearing what above I would imagine remaining steps would be, based on my previous similar experience with iSCSI removal on physical servers: - take note of the paths sdY, ... of mpathX - remove the multipath device with multipath -f mpathX - flush the single paths devices blockdev --flushbufs sdY for every path of the previous taken note ones - remove single path devices echo 1 > /sys/block/sdY/device/delete - remove LUN from storage array when previous steps done on all the hypervisors Any comment? Any further step at vdsm level files..? Thanks in advance, Gianluca _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Tue, Oct 10, 2017 at 1:29 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Oct 6, 2017 2:41 PM, "Gianluca Cecchi" <gianluca.cecchi@gmail.com> wrote:
Hello, I'm relocating some disks from some storage domains to other ones. At the end I'm going to remove source storage domains. All the SD involved are FC and the hosts are CentOS 7.4 I see that after removing an SD from oVirt, the multipath part on host remains. What is the correct sequence of operations to do at hosts' side after completing the Webadmin Gui part?
https://access.redhat.com/documentation/en-us/red_hat_enterp rise_linux/7/html/storage_administration_guide/removing_devices
(which seems to be similar to your steps below. I'd remove it from the storage side after flushing though). Y.
Yes, when removing from physical servers I took that link as reference and my steps reproduce them in practice. I have not understood what do you mean with " I'd remove it from the storage side after flushing though " Do yo mean this sequence: 1) flush the single path devices 2) remove the multipath device with multipath -f ?? O another thing? Also I found in the mean time this bugzilla (for RHEV) https://bugzilla.redhat.com/show_bug.cgi?id=1310330 where you replied and have work in progress... thanks! I also found a reference (I miss the bugzilla id right now), that if you have vdsm > of a certain version there are "no problems" on hosts in case some unused (from oVirt point of view) LUNs are removed from storage array while the hosts still enumerating them in their multipath listing. So that this can lower potential problems... I don't now if the enhancement s related to some sort of blacklisting or what has been done at vdsm level.... Gianluca
On Tue, Oct 10, 2017 at 2:57 PM, Gianluca Cecchi <gianluca.cecchi@gmail.com> wrote:
On Tue, Oct 10, 2017 at 1:29 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Oct 6, 2017 2:41 PM, "Gianluca Cecchi" <gianluca.cecchi@gmail.com> wrote:
Hello, I'm relocating some disks from some storage domains to other ones. At the end I'm going to remove source storage domains. All the SD involved are FC and the hosts are CentOS 7.4 I see that after removing an SD from oVirt, the multipath part on host remains. What is the correct sequence of operations to do at hosts' side after completing the Webadmin Gui part?
https://access.redhat.com/documentation/en-us/red_hat_enterp rise_linux/7/html/storage_administration_guide/removing_devices
(which seems to be similar to your steps below. I'd remove it from the storage side after flushing though). Y.
Yes, when removing from physical servers I took that link as reference and my steps reproduce them in practice. I have not understood what do you mean with
" I'd remove it from the storage side after flushing though "
Do yo mean this sequence: 1) flush the single path devices 2) remove the multipath device with multipath -f ?? O another thing?
As soon as you are done flushing IO, I'd remove the device (unzone). The reason is that you do not want it to be re-discovered. Y.
Also I found in the mean time this bugzilla (for RHEV) https://bugzilla.redhat.com/show_bug.cgi?id=1310330 where you replied and have work in progress... thanks!
I also found a reference (I miss the bugzilla id right now), that if you have vdsm > of a certain version there are "no problems" on hosts in case some unused (from oVirt point of view) LUNs are removed from storage array while the hosts still enumerating them in their multipath listing. So that this can lower potential problems... I don't now if the enhancement s related to some sort of blacklisting or what has been done at vdsm level....
Gianluca
participants (2)
-
Gianluca Cecchi -
Yaniv Kaul