[Top][All Lists]

[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 18:07:58 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

10.08.2020 17:20, Eric Blake wrote:
On 8/10/20 7:35 AM, 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

Is 'appliance' a qcow2 file?  If so, another way to accomplish this could 

nbdkit streaming --run 'qemu-img convert --image-opts 
"$uri"' | file -

This adds a dependency on nbdkit streaming plugin, not installed by default in 
our RH-based distributive. Probably the simplest thing is just create a 
temporary file for qemu-img convert (or dd) target, and then call file command 
on it.

which says to use qemu-img to open a length-limited view of the file, and 
stream the entire thing to an NBD server, where nbdkit then provides a way to 
convert that to a pipeline to feed into file (since qemu's NBD server doesn't 
directly like writing into a pipe).

I'm also wondering if the 'nbdcopy' program (not yet released in a stable 
version, but available in libnbd.git) could be put to use on this front, with 
some way to quickly combine it with qemu-nbd serving appliance.qcow2.

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.

'qemu-img dd' _should_ be merely syntactic sugar for 'qemu-img convert', but it 
isn't yet.  Until we rectify that feature parity (there are things that dd 
can't do like better output control and skipping, and there are things that 
convert can't do like length limiting and offset selection), hacking up 
'qemu-io' (which is for debugging use only) is a tolerable short-term solution; 
but qemu-io was NEVER intended for stable use cases.  If adding this makes 
debugging qemu easier, then go for it; but if the real problem is that qemu-img 
is missing functionality, we should instead be focusing on fixing qemu-img.

Thanks for clarifying this!

If we are going to improve qemu-img at some point, I'm not sure that convert or 
dd is correct places to do it, as they want target to be a block node. But how 
to create a block-node on top of /dev/stdout? Detect it and behave another way 
in img_dd function? Or may be better create another command qemu-img dump, for 
dumping the contents to stdout?

Best regards,

reply via email to

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