----- Original Message ----- > From: "Francesco Romani" <fromani@xxxxxxxxxx> > To: libvir-list@xxxxxxxxxx > Sent: Friday, July 4, 2014 6:44:07 PM > Subject: Re: [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? Thanks and best regards -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list