On Fri, Apr 23, 2021 at 6:25 AM Vojtech Juranek <[email protected]> wrote:
> On Friday, 23 April 2021 02:44:43 CEST Ryan Chewning wrote: > > Hi List, > > > > We need to add and remove directly mapped LUNs to multiple VMs in our > > Non-Production environment. The environment is backed by an iSCSI SAN. In > > testing when removing a directly mapped LUN it doesn't remove the > > underlying multipath and devices. Several questions. > > > > 1) Is this the expected behavior? > > yes, before removing multipath devices, you need to unzone LUN on storage > server. As oVirt doesn't manage storage server in case of iSCSI, it has to > be > done by storage sever admin and therefore oVirt cannot manage whole flow. > > Thank you for the information. Perhaps you can expand then on how the volumes are picked up once mapped from the Storage system? Traditionally when mapping storage from an iSCSI or Fibre Channel storage we have to initiate a LIP or iSCSI login. How is it that oVirt doesn't need to do this? > 2) Are we supposed to go to each KVM host and manually remove the > > underlying multipath devices? > > oVirt provides ansible script for it: > > https://github.com/oVirt/ovirt-ansible-collection/blob/master/examples/ > remove_mpath_device.yml > > Usage is as follows: > > ansible-playbook --extra-vars "lun=<LUN_ID>" remove_mpath_device.yml > We'll look into this. At least in our Non Production environment when we take down a development environment or refresh the data there are at least 14 volumes that have to be removed and readded. > > > 3) Is there a technical reason that oVirt doesn't do this as part of the > > steps to removing the storage? > > as mentioned above, oVirt doesn't manage iSCSI server and cannot unzone > LUN > from the server. For managed storage oVirt does that. > I understand ovirt is not able to unzoning the LUN as that is managed on the Storage system. However oVirt does create the multipath device and underlying block devices. We expected that to be cleaned up when a LUN is deleted. > > > This is something that was handled by the manager in the previous > > virtualization that we used, Oracle's Xen based Oracle VM. > > > > Thanks! > > > > Ryan > > _______________________________________________ > Users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/[email protected]/message/FR4PIIUO325VT5KE2FUTWNHKFGLYZACC/ >
_______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/[email protected]/message/L3G4R23BJ5TZW7ZUQ4PLB2UBQY3T6XON/
