----- Original Message ----- > From: "Daniel P. Berrange" <berrange@xxxxxxxxxx> > To: "Francesco Romani" <fromani@xxxxxxxxxx> > Cc: libvir-list@xxxxxxxxxx, "Richard W.M. Jones" <rjones@xxxxxxxxxx> > Sent: Friday, July 4, 2014 6:21:30 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). 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list