'file' backend in qemu supports few more options than the current
implementation. Extract it so that changes don't pollute the code.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
---
 src/qemu/qemu_block.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
index c0cf6a95ad..e7bd6c909d 100644
--- a/src/qemu/qemu_block.c
+++ b/src/qemu/qemu_block.c
@@ -974,6 +974,18 @@ qemuBlockStorageSourceGetSshProps(virStorageSourcePtr src)
 }


+static virJSONValuePtr
+qemuBlockStorageSourceGetFileProps(virStorageSourcePtr src)
+{
+    virJSONValuePtr ret = NULL;
+
+    ignore_value(virJSONValueObjectCreate(&ret,
+                                          "s:driver", "file",
+                                          "s:filename", src->path, NULL) < 0);
+    return ret;
+}
+
+
 /**
  * qemuBlockStorageSourceGetBackendProps:
  * @src: disk source
@@ -991,9 +1003,7 @@ qemuBlockStorageSourceGetBackendProps(virStorageSourcePtr src)
     case VIR_STORAGE_TYPE_BLOCK:
     case VIR_STORAGE_TYPE_FILE:
     case VIR_STORAGE_TYPE_DIR:
-        if (virJSONValueObjectCreate(&fileprops,
-                                     "s:driver", "file",
-                                     "s:filename", src->path, NULL) < 0)
+        if (!(fileprops = qemuBlockStorageSourceGetFileProps(src)))
             return NULL;
         break;

-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Am 19.04.2018 um 17:25 hat Peter Krempa geschrieben:
> 'file' backend in qemu supports few more options than the current
> implementation. Extract it so that changes don't pollute the code.
> 
> Signed-off-by: Peter Krempa <pkrempa@redhat.com>
> ---
>  src/qemu/qemu_block.c | 16 +++++++++++++---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
> index c0cf6a95ad..e7bd6c909d 100644
> --- a/src/qemu/qemu_block.c
> +++ b/src/qemu/qemu_block.c
> @@ -974,6 +974,18 @@ qemuBlockStorageSourceGetSshProps(virStorageSourcePtr src)
>  }
> 
> 
> +static virJSONValuePtr
> +qemuBlockStorageSourceGetFileProps(virStorageSourcePtr src)
> +{
> +    virJSONValuePtr ret = NULL;
> +
> +    ignore_value(virJSONValueObjectCreate(&ret,
> +                                          "s:driver", "file",
> +                                          "s:filename", src->path, NULL) < 0);
> +    return ret;
> +}
> +
> +
>  /**
>   * qemuBlockStorageSourceGetBackendProps:
>   * @src: disk source
> @@ -991,9 +1003,7 @@ qemuBlockStorageSourceGetBackendProps(virStorageSourcePtr src)
>      case VIR_STORAGE_TYPE_BLOCK:
>      case VIR_STORAGE_TYPE_FILE:
>      case VIR_STORAGE_TYPE_DIR:
> -        if (virJSONValueObjectCreate(&fileprops,
> -                                     "s:driver", "file",
> -                                     "s:filename", src->path, NULL) < 0)
> +        if (!(fileprops = qemuBlockStorageSourceGetFileProps(src)))
>              return NULL;

Preexisting, but I wonder whether 'driver': 'file' is correct for all
these cases. I see that you handle _DIR separately with a vvfat function
later in this series, but shouldn't _BLOCK be 'host_device' rather than
'file', too?

Kevin

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Apr 20, 2018 at 09:45:40 +0200, Kevin Wolf wrote:
> Am 19.04.2018 um 17:25 hat Peter Krempa geschrieben:
> > 'file' backend in qemu supports few more options than the current
> > implementation. Extract it so that changes don't pollute the code.
> > 
> > Signed-off-by: Peter Krempa <pkrempa@redhat.com>
> > ---
> >  src/qemu/qemu_block.c | 16 +++++++++++++---
> >  1 file changed, 13 insertions(+), 3 deletions(-)
> > 
> > diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
> > index c0cf6a95ad..e7bd6c909d 100644
> > --- a/src/qemu/qemu_block.c
> > +++ b/src/qemu/qemu_block.c
> > @@ -974,6 +974,18 @@ qemuBlockStorageSourceGetSshProps(virStorageSourcePtr src)
> >  }
> > 
> > 
> > +static virJSONValuePtr
> > +qemuBlockStorageSourceGetFileProps(virStorageSourcePtr src)
> > +{
> > +    virJSONValuePtr ret = NULL;
> > +
> > +    ignore_value(virJSONValueObjectCreate(&ret,
> > +                                          "s:driver", "file",
> > +                                          "s:filename", src->path, NULL) < 0);
> > +    return ret;
> > +}
> > +
> > +
> >  /**
> >   * qemuBlockStorageSourceGetBackendProps:
> >   * @src: disk source
> > @@ -991,9 +1003,7 @@ qemuBlockStorageSourceGetBackendProps(virStorageSourcePtr src)
> >      case VIR_STORAGE_TYPE_BLOCK:
> >      case VIR_STORAGE_TYPE_FILE:
> >      case VIR_STORAGE_TYPE_DIR:
> > -        if (virJSONValueObjectCreate(&fileprops,
> > -                                     "s:driver", "file",
> > -                                     "s:filename", src->path, NULL) < 0)
> > +        if (!(fileprops = qemuBlockStorageSourceGetFileProps(src)))
> >              return NULL;
> 
> Preexisting, but I wonder whether 'driver': 'file' is correct for all
> these cases. I see that you handle _DIR separately with a vvfat function
> later in this series, but shouldn't _BLOCK be 'host_device' rather than
> 'file', too?

It should. I just did not notice it. If I try the block storage now I
get:

    {
      "iops_rd": 0,
      "detect_zeroes": "off",
      "image": {
        "virtual-size": 10737418240,
        "filename": "/dev/mapper/angien--storage-ble",
        "format": "host_device",
        "actual-size": 0,
        "dirty-flag": false
      },
      "iops_wr": 0,
      "ro": false,
      "node-name": "#block093",
      "backing_file_depth": 0,
      "drv": "host_device",
      "iops": 0,
      "bps_wr": 0,
      "write_threshold": 0,
      "encrypted": true,
      "bps": 0,
      "bps_rd": 0,
      "cache": {
        "no-flush": false,
        "direct": true,
        "writeback": true
      },
      "file": "/dev/mapper/angien--storage-ble",
      "encryption_key_missing": false
    }

Is there a special need to use 'host_cdrom' explicitly if the CDROM
drive is used? That would complicate things since we don't know when
that will happen.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Am 20.04.2018 um 09:56 hat Peter Krempa geschrieben:
> Is there a special need to use 'host_cdrom' explicitly if the CDROM
> drive is used? That would complicate things since we don't know when
> that will happen.

You don't get the full CD-ROM passthrough functionality with
host_device. Specifically, if you eject the virtual drive, the physical
drive will only be ejected with host_cdrom, and the same is true for
lock_medium.

I think we may also make an attempt at detecting physical media change
ocassionally with host_cdrom, but I doubt that this is working reliably
anyway (the driver function is .bdrv_is_inserted, so it would be polling
rather than processing an event; and I'm not sure when it's called).

Kevin
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Apr 20, 2018 at 10:41:50 +0200, Kevin Wolf wrote:
> Am 20.04.2018 um 09:56 hat Peter Krempa geschrieben:
> > Is there a special need to use 'host_cdrom' explicitly if the CDROM
> > drive is used? That would complicate things since we don't know when
> > that will happen.
> 
> You don't get the full CD-ROM passthrough functionality with
> host_device. Specifically, if you eject the virtual drive, the physical
> drive will only be ejected with host_cdrom, and the same is true for
> lock_medium.
> 
> I think we may also make an attempt at detecting physical media change
> ocassionally with host_cdrom, but I doubt that this is working reliably
> anyway (the driver function is .bdrv_is_inserted, so it would be polling
> rather than processing an event; and I'm not sure when it's called).

Hmm, okay, it seems that we in fact should use it. Is there any drawback
if host_cdrom is used with a device which is not a CDROM? (e.g. a
logical volume containing the image?)

Basically the question is whether we need to add some "smart" handling
or we can just assume that if the guest device is a block-backed CDROM
we can use that.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Am 20.04.2018 um 10:50 hat Peter Krempa geschrieben:
> On Fri, Apr 20, 2018 at 10:41:50 +0200, Kevin Wolf wrote:
> > Am 20.04.2018 um 09:56 hat Peter Krempa geschrieben:
> > > Is there a special need to use 'host_cdrom' explicitly if the CDROM
> > > drive is used? That would complicate things since we don't know when
> > > that will happen.
> > 
> > You don't get the full CD-ROM passthrough functionality with
> > host_device. Specifically, if you eject the virtual drive, the physical
> > drive will only be ejected with host_cdrom, and the same is true for
> > lock_medium.
> > 
> > I think we may also make an attempt at detecting physical media change
> > ocassionally with host_cdrom, but I doubt that this is working reliably
> > anyway (the driver function is .bdrv_is_inserted, so it would be polling
> > rather than processing an event; and I'm not sure when it's called).
> 
> Hmm, okay, it seems that we in fact should use it. Is there any drawback
> if host_cdrom is used with a device which is not a CDROM? (e.g. a
> logical volume containing the image?)
> 
> Basically the question is whether we need to add some "smart" handling
> or we can just assume that if the guest device is a block-backed CDROM
> we can use that.

Hm, looking at the code, it seems that failure is silently ignored in
.bdrv_eject and .bdrv_lock_medium, but .bdrv_is_inserted is implemented
like this:

    ret = ioctl(s->fd, CDROM_DRIVE_STATUS, CDSL_CURRENT);
    return ret == CDS_DISC_OK;

Which probably means that a block device not supporting that ioctl won't
be functional at all because the block layer will return -ENOMEDIUM
almost everywhere.

Kevin
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list