qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH for 5.2 1/1] qemu-io: add -V flag for read sub-command


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH for 5.2 1/1] qemu-io: add -V flag for read sub-command
Date: Mon, 10 Aug 2020 17:02:46 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

10.08.2020 15:35, Denis V. Lunev wrote:
The problem this patch is trying to address is libguestfs behavior on the
appliance startup. It starts supporting to use root=UUID definition in
the kernel command line of its root filesystem using
     file --  /usr/lib64/guestfs/appliance/root
This works fine with RAW image, but we are using QCOW2 as a storage to
save a bit of file space and in this case we get
     QEMU QCOW Image (v3), 1610612736 bytes
instead of UUID of the root filesystem.

The solution is very simple - we should dump first 256k of the image file
like the follows
     qemu-io -c "read -V 0 256k" appliance | file -
which will provide correct result for all possible types of the appliance
storage.

Unfortunately, additional option for qemu-io is the only and the simplest
solution as '-v' creates very specific output, which requires to be
parsed. 'qemu-img dd of=/dev/stdout' does not work and the fix would be
much more intrusive.

Signed-off-by: Denis V. Lunev <den@openvz.org>
CC: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
CC: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Max Reitz <mreitz@redhat.com>
CC: Richard W.M. Jones <rjones@redhat.com>
---
P.S. Patch to libguestfs will follow.

  qemu-io-cmds.c | 17 +++++++++++++----
  1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
index baeae86d8c..7aae9726cd 100644
--- a/qemu-io-cmds.c
+++ b/qemu-io-cmds.c
@@ -718,7 +718,7 @@ static const cmdinfo_t read_cmd = {
      .cfunc      = read_f,
      .argmin     = 2,
      .argmax     = -1,
-    .args       = "[-abCqv] [-P pattern [-s off] [-l len]] off len",
+    .args       = "[-abCqvV] [-P pattern [-s off] [-l len]] off len",
      .oneline    = "reads a number of bytes at a specified offset",
      .help       = read_help,
  };
@@ -728,6 +728,7 @@ static int read_f(BlockBackend *blk, int argc, char **argv)
      struct timespec t1, t2;
      bool Cflag = false, qflag = false, vflag = false;
      bool Pflag = false, sflag = false, lflag = false, bflag = false;
+    bool vrawflag = true;
      int c, cnt, ret;
      char *buf;
      int64_t offset;
@@ -737,7 +738,7 @@ static int read_f(BlockBackend *blk, int argc, char **argv)
      int pattern = 0;
      int64_t pattern_offset = 0, pattern_count = 0;
- while ((c = getopt(argc, argv, "bCl:pP:qs:v")) != -1) {
+    while ((c = getopt(argc, argv, "bCl:pP:qs:vV")) != -1) {
          switch (c) {
          case 'b':
              bflag = true;
@@ -777,6 +778,9 @@ static int read_f(BlockBackend *blk, int argc, char **argv)
          case 'v':
              vflag = true;
              break;
+        case 'V':
+            vrawflag = true;
+            break;
          default:
              qemuio_command_usage(&read_cmd);
              return -EINVAL;
@@ -869,10 +873,15 @@ static int read_f(BlockBackend *blk, int argc, char 
**argv)
      if (vflag) {
          dump_buffer(buf, offset, count);
      }
+    if (vrawflag) {
+        write(STDOUT_FILENO, buf, count);
+    }
/* Finally, report back -- -C gives a parsable format */
-    t2 = tsub(t2, t1);
-    print_report("read", &t2, offset, count, total, cnt, Cflag);
+    if (!vrawflag) {
+        t2 = tsub(t2, t1);
+        print_report("read", &t2, offset, count, total, cnt, Cflag);
+    }
out:
      qemu_io_free(buf);


I think -v and -V should be mutually exclusive, as combined output doesn't make 
real sense.
Still, I'm OK with it as is (as well as with -V renamed to -r). I can suggest 
also -d (aka dump).

Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>

--
Best regards,
Vladimir



reply via email to

[Prev in Thread] Current Thread [Next in Thread]