From: "Richard W.M. Jones" <rjones@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, vsementsov@virtuozzo.com,
qemu-block@nongnu.org, thuth@redhat.com,
"reviewer:Incompatible changes" <libvir-list@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qemu-nbd: Deprecate qemu-nbd --partition
Date: Wed, 23 Jan 2019 22:25:29 +0000 [thread overview]
Message-ID: <20190123222529.GF12500@redhat.com> (raw)
In-Reply-To: <5bd946ae-0f88-375b-072f-40b0aa850ab2@redhat.com>
On Wed, Jan 23, 2019 at 04:18:16PM -0600, Eric Blake wrote:
> On 1/23/19 3:55 PM, Richard W.M. Jones wrote:
> > On Wed, Jan 23, 2019 at 03:19:53PM -0600, Eric Blake wrote:
> >> The existing qemu-nbd --partition code claims to handle logical
> >> partitions up to 8, since its introduction in 2008 (commit 7a5ca86).
> >> However, the implementation is bogus (actual MBR logical partitions
> >> form a sort of linked list, with one partition per extended table
> >> entry, rather than four logical partitions in a single extended
> >> table), making the code unlikely to work for anything beyond -P5 on
> >> actual guest images. What's more, the code does not support GPT
> >> partitions, which are becoming more popular, and maintaining device
> >> subsetting in both NBD and the raw device is unnecessary maintenance
> >> burden. And nbdkit has just added code to properly handle an
> >> arbitrary number of MBR partitions, along with its existing code
> >> for handling GPT partitions.
> >>
> >> Note that obtaining the offsets of a partition can be learned by
> >> using 'qemu-nbd -c /dev/nbd0 file.qcow2 && sfdisk --dump /dev/nbd0',
> >> but by the time you've done that, you might as well just mount
> >> /dev/nbd0p1 that the kernel creates for you.
> >>
> >> Start the clock on the deprecation cycle, with an example of how
> >> to write device subsetting without using -P.
> >>
>
> >> +For example, if partition 1 is 100MiB starting at 1MiB, the old command
> >> +
> >> +@example{qemu-nbd -P 1 -f qcow2 file.qcow2}
> >> +
> >> +can be rewritten as:
> >> +
> >> +@example{qemu-nbd --image-opts driver=raw,offset=1M,size=100M,file.driver=qcow2,file.backing.driver=file,file.backing.filename=file.qcow2}
> >> +
> >> +Alternatively, the @code{nbdkit} project provides a more powerful
> >> +partition filter on top of its nbd plugin, which can be used to select
> >> +an arbitrary MBR or GPT partition on top of any other full-image NBD
> >> +export.
> >
> > You might want to add the actual command here.
>
> Good idea - as long as we are deprecating something, telling the user
> how to get the same functionality (in this case, user-space partition
> detection, without involving /dev/nbd) is worth the extra effort.
>
> > Unfortunately nbdkit
> > cannot read qcow2 files meaning (as you note already) that you have to
> > forward the connection through the nbdkit-nbd-plugin to qemu-nbd.
> > This worked for me:
> >
> > qemu-nbd -t -k /tmp/sock -f qcow2 file.qcow2 &
> > nbdkit -f --filter=partition nbd socket=/tmp/sock partition=1 &
>
> Is the -f necessary? Otherwise, yes, this looks reasonable. I'll add it
> for v2.
It's not necessary, but it makes nbdkit behave the same way with
respect to remaining in the foreground as qemu-nbd.
Rich.
> > If you drop the requirement to demonstrate this with qcow2 then the
> > command would be just this:
> >
> > nbdkit --filter=partition file disk.raw partition=1
> >
>
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3226
> Virtualization: qemu.org | libvirt.org
>
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
next prev parent reply other threads:[~2019-01-23 22:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-23 21:19 [Qemu-devel] [PATCH] qemu-nbd: Deprecate qemu-nbd --partition Eric Blake
2019-01-23 21:55 ` Richard W.M. Jones
2019-01-23 22:18 ` Eric Blake
2019-01-23 22:25 ` Richard W.M. Jones [this message]
2019-01-24 7:57 ` [Qemu-devel] [libvirt] " Peter Krempa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190123222529.GF12500@redhat.com \
--to=rjones@redhat.com \
--cc=eblake@redhat.com \
--cc=libvir-list@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.