[libvirt] [RFC][scale] new API for querying domains stats

Francesco Romani fromani at redhat.com
Fri Jul 4 16:44:07 UTC 2014

----- Original Message -----
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: "Francesco Romani" <fromani at redhat.com>
> Cc: libvir-list at redhat.com, "Richard W.M. Jones" <rjones at redhat.com>
> Sent: Friday, July 4, 2014 6:21:30 PM
> Subject: Re: [libvirt] [RFC][scale] new API for querying domains stats

> > However, a question here about bulk APIs.
> > One cornerstone of oVirt is shared storage (NFS, ISCSI...); another is
> > qemu/kvm,
> > and COW images are supported (probably even the default, need to check).
> > 
> > Due to storage being unavailable because a network outage, it happened that
> > virDomainGetBlockInfo blocked beyond recover.
> > 
> > On such scenarios, how will a bulk API behave? There will be a timeout or
> > something else?
> It depends on the storage and the way it is configured. If NFS is mounted
> with 'hard' + 'nointr' any call libvirt makes to dead storage will get
> stuck in an uninterruptable sleep in kernel space. There's no way for
> libvirt to time out since by the very definition of 'hard' mount option
> it does not time out. If you mount with 'soft' then the calls libvirt
> makes will time out.

My bad, I worded poorly my question.

What I mean is: on top of what the kernel or QEMU (libnfs, libiscsi) does,
there are plans for any additional mechanism/safeguard?
(I guess no, I'm asking just to be sure).

VDSM already uses soft mount for NFS (need to check what we do for ISCSI and
the other supported storage).

Thanks and bests,

Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani

More information about the libvir-list mailing list