On Wed, Dec 4, 2019 at 4:42 PM Albl, Oliver <[email protected]> wrote:
> Hi Amit, > > > > unfortunately no success. > > > > Dec 4, 2019, 3:41:36 PM > > Storage Domain HOST_LUN_219 (Data Center xxx) was deactivated by system > because it's not visible by any of the hosts. > > > > Dec 4, 2019, 3:35:09 PM > > Failed to update VMs/Templates OVF data for Storage Domain HOST_LUN_219 in > Data Center Production. > > > > Dec 4, 2019, 3:35:09 PM > > Failed to update OVF disks 77c64b39-fe50-4d05-b77f-8131ad1f95f9, OVF data > isn't updated on those OVF stores (Data Center Production, Storage Domain > HOST_LUN_219). > Have you selected the checkbox for "Ignore OVF update failure" before putting into maintenance? > > All the best, > > Oliver > > > > *Von:* Amit Bawer <[email protected]> > *Gesendet:* Mittwoch, 4. Dezember 2019 15:20 > *An:* Albl, Oliver <[email protected]> > *Cc:* [email protected]; Nir Soffer <[email protected]> > *Betreff:* Re: [ovirt-users] Re: Cannot activate/deactivate storage domain > > > > Hi Oliver, > > > > For deactivating the unresponsive storage domains, you can use the Compute > -> Data Centers -> Maintenance option with "Ignore OVF update failure" > checked. > > This will force deactivation of the SD. > > > > Will provide further details about the issue in the ticket. > > > > > > On Tue, Dec 3, 2019 at 12:02 PM Albl, Oliver <[email protected]> > wrote: > > Hi, > > does anybody have an advice how to activate or safely remove that > storage domain? > > Thank you! > Oliver > -----Ursprüngliche Nachricht----- > Von: Oliver Albl <[email protected]> > Gesendet: Dienstag, 5. November 2019 11:20 > An: [email protected] > Betreff: [ovirt-users] Re: Cannot activate/deactivate storage domain > > > On Mon, Nov 4, 2019 at 9:18 PM Albl, Oliver <Oliver.Albl(a)fabasoft.com> > wrote: > > > > What was the last change in the system? upgrade? network change? storage > change? > > > > Last change was four weeks ago ovirt upgrade from 4.3.3 to 4.3.6.7 > (including CentOS hosts to 7.7 1908) > > > > > This is expected if some domain is not accessible on all hosts. > > > > > > This means sanlock timed out renewing the lockspace > > > > > > If a host cannot access all storage domain in the DC, the system set > > it to non-operational, and will probably try to reconnect it later. > > > > > > This means reading 4k from start of the metadata lv took 9.6 seconds. > > Something in > > the way to storage is bad (kernel, network, storage). > > > > > > We 20 seconds (4 retires, 5 seconds per retry) gracetime in multipath > > when there are no active paths, before I/O fails, pausing the VM. We > > also resume paused VMs when storage monitoring works again, so maybe > > the VM were paused and resumed. > > > > However for storage monitoring we have strict 10 seconds timeout. If > > reading from the metadata lv times out or fail and does not operated > > normally after > > 5 minutes, the > > domain will become inactive. > > > > > > This can explain the read timeouts. > > > > > > This looks the right way to troubleshoot this. > > > > > > We need vdsm logs to understand this failure. > > > > > > This does not mean OVF is corrupted, only that we could not store new > > data. The older data on the other OVFSTORE disk is probably fine. > > Hopefuly the system will not try to write to the other OVFSTORE disk > > overwriting the last good version. > > > > > > This is normal, the first 2048 bytes are always zeroes. This area was > > used for domain metadata in older versions. > > > > > > Please share more details: > > > > - output of "lsblk" > > - output of "multipath -ll" > > - output of "/usr/libexec/vdsm/fc-scan -v" > > - output of "vgs -o +tags problem-domain-id" > > - output of "lvs -o +tags problem-domain-id" > > - contents of /etc/multipath.conf > > - contents of /etc/multipath.conf.d/*.conf > > - /var/log/messages since the issue started > > - /var/log/vdsm/vdsm.log* since the issue started on one of the hosts > > > > A bug is probably the best place to keep these logs and make it easy to > trac. > > Please see https://bugzilla.redhat.com/show_bug.cgi?id=1768821 > > > > > Thanks, > > Nir > > Thank you! > Oliver > _______________________________________________ > Users mailing list -- [email protected] > To unsubscribe send an email to [email protected] Privacy Statement: > https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/[email protected]/message/QZ5ZN2S7N54JYVV3RWOYOHTEAWFQ23Q7/ > >
_______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/[email protected]/message/AF2GBIQKW45QVGJCEN2O3ZYV2BVTI4YU/
