[libvirt] [RFC][scale] new API for querying domains stats
Daniel P. Berrange
berrange at redhat.com
Wed Jul 9 10:16:05 UTC 2014
On Wed, Jul 09, 2014 at 06:14:12AM -0400, Francesco Romani wrote:
>
>
> ----- Original Message -----
> > From: "Francesco Romani" <fromani at redhat.com>
> > To: libvir-list at redhat.com
> > Sent: Friday, July 4, 2014 6:44:07 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).
>
> Hi,
>
> maybe borderline offtopic, but still about blocking calls:
>
> We (VDSM/oVirt developers) are reviewing our usage of libvirt in sampling.
> Afer a (quick) inspection of the code, I believe the following calls cannot
> block due to FS/storage issues, as they do not need it in any way
>
> I'm quite confident about these
> * virDomainGetCPUStats: uses cgroups only (no FS/storage access)
> * virDomainInterfaceStats: uses /proc/net/dev (no FS/storage access)
> * virDomainGetVcpus: uses uses /proc and syscall for PCPU affinity (no FS/storage access)
> * virDomainSchedulerParameters: which uses cgroups (no FS/storage access)
>
> Not sure about this, but it looks to me they don't need to access FS/storage either:
> * virDomainGetVcpusFlags
> * virDomainGetMetadata
>
>
> Can please anyone confirm or deny?
If there is a prior call to libvirt that involves that guest domain
which has blocked on storage, then this can prevent subsequent calls
from completely since the prior call may hold a lock.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
More information about the libvir-list
mailing list