From: Eric Blake <eblake@redhat.com>
To: Max Reitz <mreitz@redhat.com>, qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/3] iotests: Allow 147 to be run concurrently
Date: Mon, 21 Jan 2019 15:02:37 -0600 [thread overview]
Message-ID: <84e62d4a-bf74-ba1c-d802-e01de14d693c@redhat.com> (raw)
In-Reply-To: <20181221234750.23577-4-mreitz@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]
On 12/21/18 5:47 PM, Max Reitz wrote:
> To do this, we need to allow creating the NBD server on various ports
> instead of a single one (which may not even work if you run just one
> instance, because something entirely else might be using that port).
Can you instead reuse the ideas from nbd_server_set_tcp_port() from
qemu-iotests/common.nbd?
>
> So we just pick a random port in [32768, 32768 + 1024) and try to create
> a server there. If that fails, we just retry until something sticks.
That has the advantage of checking whether a port is actually in use
(using 'ss' - although it does limit the test to Linux-only; perhaps
using socat instead of ss could make the test portable to non-Linux?)
>
> For the IPv6 test, we need a different range, though (just above that
> one). This is because "localhost" resolves to both 127.0.0.1 and ::1.
> This means that if you bind to it, it will bind to both, if possible, or
> just one if the other is already in use. Therefore, if the IPv6 test
> has already taken [::1]:some_port and we then try to take
> localhost:some_port, that will work -- only the second server will be
> bound to 127.0.0.1:some_port alone and not [::1]:some_port in addition.
> So we have two different servers on the same port, one for IPv4 and one
> for IPv6.
>
> But when we then try to connect to the server through
> localhost:some_port, we will always end up at the IPv6 one (as long as
> it is up), and this may not be the one we want.
>
> Thus, we must make sure not to create an IPv6-only NBD server on the
> same port as a normal "dual-stack" NBD server -- which is done by using
> distinct port ranges, as explained above.
>
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
> tests/qemu-iotests/147 | 98 +++++++++++++++++++++++++++++-------------
> 1 file changed, 68 insertions(+), 30 deletions(-)
>
> @@ -88,17 +92,29 @@ class QemuNBD(NBDBlockdevAddBase):
> except OSError:
> pass
>
> + def _try_server_up(self, *args):
> + status, msg = qemu_nbd_pipe('-f', imgfmt, test_img, *args)
> + if status == 0:
> + return True
> + if 'Address already in use' in msg:
> + return False
> + self.fail(msg)
Do you actually need to attempt a qemu-nbd process, if you take my
suggestion of using ss to probe for an unused port? And if not, do we
still need qemu_nbd_pipe() added earlier in the series?
> - address = { 'type': 'inet',
> - 'data': {
> - 'host': 'localhost',
> - 'port': str(NBD_PORT)
> - } }
> - self._server_up(address, export_name)
> + while True:
> + nbd_port = random.randrange(NBD_PORT_START, NBD_PORT_END)
common.nbd just iterates, instead of trying random ports.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-01-21 21:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-21 23:47 [Qemu-devel] [PATCH 0/3] iotests: Allow 147 to be run concurrently Max Reitz
2018-12-21 23:47 ` [Qemu-devel] [PATCH 1/3] iotests.py: Add qemu_nbd_pipe() Max Reitz
2019-01-21 20:55 ` Eric Blake
2019-01-23 13:06 ` Max Reitz
2019-01-23 14:27 ` Eric Blake
2018-12-21 23:47 ` [Qemu-devel] [PATCH 2/3] iotests: Bind qemu-nbd to localhost in 147 Max Reitz
2019-01-21 20:56 ` Eric Blake
2018-12-21 23:47 ` [Qemu-devel] [PATCH 3/3] iotests: Allow 147 to be run concurrently Max Reitz
2019-01-21 20:50 ` [Qemu-devel] [Qemu-block] " John Snow
2019-01-23 13:05 ` Max Reitz
2019-01-23 17:34 ` Max Reitz
2019-01-23 17:47 ` John Snow
2019-01-25 15:01 ` Max Reitz
2019-01-21 21:02 ` Eric Blake [this message]
2019-01-23 13:12 ` [Qemu-devel] " Max Reitz
2019-01-23 14:33 ` Eric Blake
2019-01-23 14:37 ` Max Reitz
2019-01-23 14:43 ` Daniel P. Berrangé
2019-01-31 1:01 ` [Qemu-devel] [PATCH 0/3] " Max Reitz
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=84e62d4a-bf74-ba1c-d802-e01de14d693c@redhat.com \
--to=eblake@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).