On Wed, Jul 09, 2014 at 06:14:12AM -0400, Francesco Romani wrote: > > > ----- 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? 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list