[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] Query block allocation extent from QEMU monitor



On 05/13/2010 05:09 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.
> 

> +    /* Set default value .. */
>      info->allocation = info->physical;
>  
> -    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) &&
> +        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);

This sets info->allocation to 0 if...

> +int qemuMonitorGetBlockExtent(qemuMonitorPtr mon,
> +                              const char *devname,
> +                              unsigned long long *extent)
> +{
> +    int ret;
> +    DEBUG("mon=%p, fd=%d, devname=%p",
> +          mon, mon->fd, devname);
> +
> +    if (mon->json)
> +        ret = qemuMonitorJSONGetBlockExtent(mon, devname, extent);
> +    else
> +        ret = qemuMonitorTextGetBlockExtent(mon, devname, extent);

...we don't have JSON support...

> +int qemuMonitorTextGetBlockExtent(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
> +                                  const char *devname ATTRIBUTE_UNUSED,
> +                                  unsigned long long *extent)
> +{
> +    /* Not supported in text monitor, but we don't want to
> +     * cause an error in callers in this scenario, just
> +     * fallback to marking the data unavailable */
> +    *extent = 0;
> +    return 0;
> +}

Wouldn't it be better to check if qemu sets things to 0 (because max
extent is not supported), and in that case, fall back to the original
default of info->physical?

-- 
Eric Blake   eblake redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]