On Fri, May 14, 2010 at 10:39:08AM -0600, Eric Blake wrote:
> On 05/14/2010 07:10 AM, Daniel P. Berrange wrote:
> > The virDomainGetBlockInfo API allows query physical block
> > extent and allocated block extent. These are normally the
> > same value unless storing a special format like qcow2
> > inside a block device. In this scenario we can query QEMU
> > to get the actual allocated extent.
> >
> > Since last time:
> >
> > - Return fatal error in text monitor
>
> Good, but...
>
> > - ret = 0;
> > + /* ..but if guest is running & not using raw
> > + disk format and on a block device, then query
> > + highest allocated extent from QEMU */
> > + if (virDomainObjIsActive(vm) &&
> > + disk->type == VIR_DOMAIN_DISK_TYPE_BLOCK &&
> > + meta.format != VIR_STORAGE_FILE_RAW &&
> > + S_ISBLK(sb.st_mode)) {
> > + qemuDomainObjPrivatePtr priv = vm->privateData;
> > + if (qemuDomainObjBeginJob(vm) < 0)
> > + goto cleanup;
> > +
> > + qemuDomainObjEnterMonitor(vm);
> > + ret = qemuMonitorGetBlockExtent(priv->mon,
> > + disk->info.alias,
> > + &info->allocation);
>
> that means you now propagate that fatal error out of the call, rather
> than falling back on the default.
Yes, that is the intended behaviour here. If it is a block device + not using
the raw format, then we want the caller to be able to see the error
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list