All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Kashyap Chamarthy <kchamart@redhat.com>
Cc: Eric Blake <eblake@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Kevin Wolf <kwolf@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 1/2] block: allow blockdev-backup from any source
Date: Mon, 2 Jul 2018 14:13:17 -0400	[thread overview]
Message-ID: <6810783c-a3ad-57ab-cf2e-96e6643c9306@redhat.com> (raw)
In-Reply-To: <20180702075939.GE24405@paraplu>



On 07/02/2018 03:59 AM, Kashyap Chamarthy wrote:
> On Thu, Jun 28, 2018 at 05:19:37PM -0400, John Snow wrote:
>>
>>
>> On 06/28/2018 02:05 PM, Eric Blake wrote:
>>> On 06/28/2018 01:00 PM, John Snow wrote:
>>>> In the case of image fleecing, the node we choose as the source
>>>> for a blockdev-backup is going to be both a root node AND the
>>>> backing node for the exported image. It does not qualify as a root
>>>> image in this case.
>>>>
>>>> Loosen the restriction.
>>>>
>>>> Signed-off-by: John Snow <jsnow@redhat.com>
>>>> ---
>>>>   blockdev.c | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> In v1, you mentioned that this used to work but then regressed,
>>> pinpointing that detail in the commit message might be nice, but not
>>> essential (since we didn't test it until now).  So,
>>>
>>
>> Really not sure when it regressed; I consider it unimportant as nothing
>> uses it presently: no docs, no tests, nothing in libvirt.
>>
>> My guess, though, is that it worked prior to
>> cef34eebf3d0f252a3b3e9a2a459b6c3ecc56f68.
> 
> So the above commit adds the ability to assign node names for
> `blockdev-backup`, which wasn't possible during 2.8 timeframe.
> 
>> In 2.8, possibly?
>>
>> Kashyap might know, I think he's experimented with this sometime in that
>> timezone.
> 
> I don't recall doing the "allow blockdev-backup from any source" test
> with 2.8.  (But I recall gradually moving from figuring out the source
> block device via wading through the output of `query-named-block-nodes`
> to using the 'node-name'.)
> 
> Looking at my test notes with QEMU 2.8, this was my
> workflow (see how `blockdev-backup` still doesn't use 'node-name's):
> 
> (QEMU) blockdev-add driver=qcow2 node-name=node2 file={"driver":"file","filename":"/export/target.qcow2"} backing={"driver":"qcow2","file":{"driver":"file","filename":"/export/base.qcow2"}}
> (QEMU) query-named-block-nodes # To dig through the source block device "#blockYYY"
> (QEMU) blockdev-backup device=#block197 target=node1 sync=none
> (QEMU) nbd-server-start addr={"type":"unix","data":{"path":"./nbd-sock"}}
> (QEMU) nbd-server-add device=node1
> (QEMU) nbd-server-stop
> 
> Later on I moved (thanks to the Git commit you mentioned earlier) to the
> much cleaner approach of using 'node-name' (the below syntax is
> from my test notes with QEMU 2.12):
> 
> (QEMU) blockdev-add driver=qcow2 node-name=node-E file={"driver":"file","filename":"e.qcow2"}
> (QEMU) blockdev-backup device=node-B target=node-E sync=full job-id=job0
> [...]
> 

Without this patch, "allow blockdev-backup from any source", the
fleecing workflow prohibits the blockdev-backup command. We're wondering
when that regressed.

If you managed to get fleecing working without this patch here, then it
was working at that time.

--js

  reply	other threads:[~2018-07-02 18:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28 18:00 [Qemu-devel] [PATCH v2 0/2] block: formalize and test fleecing John Snow
2018-06-28 18:00 ` [Qemu-devel] [PATCH v2 1/2] block: allow blockdev-backup from any source John Snow
2018-06-28 18:05   ` Eric Blake
2018-06-28 21:19     ` John Snow
2018-07-02  7:59       ` Kashyap Chamarthy
2018-07-02 18:13         ` John Snow [this message]
2018-06-28 18:00 ` [Qemu-devel] [PATCH v2 2/2] iotests: add 222 to test basic fleecing John Snow
2018-06-28 18:10   ` Eric Blake
2018-06-28 18:31     ` John Snow
2018-06-28 18:17   ` Eric Blake
2018-06-28 18:30     ` John Snow

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=6810783c-a3ad-57ab-cf2e-96e6643c9306@redhat.com \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kchamart@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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.