All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: "Lukáš Doktor" <ldoktor@redhat.com>,
	"Eric Blake" <eblake@redhat.com>,
	qemu-block@nongnu.org
Cc: kwolf@redhat.com, qemu-devel@nongnu.org,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Aarushi Mehta <mehta.aaru20@gmail.com>
Subject: Re: [PATCH] tests/qemu_iotests: Minimize usage of used ports
Date: Fri, 7 Feb 2020 09:24:15 +0100	[thread overview]
Message-ID: <7393918c-e8c8-f58c-ce6e-34591c27e85c@redhat.com> (raw)
In-Reply-To: <2958ad49-32c2-2157-2d88-7ec8ad14a5ef@redhat.com>

On 06.02.20 19:33, Lukáš Doktor wrote:
> Dne 06. 02. 20 v 17:59 Max Reitz napsal(a):
>> On 06.02.20 17:48, Eric Blake wrote:
>>> On 2/6/20 10:37 AM, Max Reitz wrote:

[...]

>>>> OTOH, would it work if we just did a %s/localhost/127.0.0.1/ in the
>>>> test?  We have specific cases for IPv6, so I think it makes sense to
>>>> force IPv4 in all other cases.
>>>
>>> Except then it will fail on machines configured for IPv6-only.
>>
>> So we’ll just have to test whether IPv4 works, just like we already do
>> for IPv6, no?
>>
> 
> Sure, using ::1 for IPv6 and 127.0.0.1 for IPv4 cases would work. The question is whether the behavior is really expected. In migration it was considered dangerous, because you can have 2 VMs starting the migration at the same time. They both might attempt to get the same port, one would receive IPv4 the other IPv6. Then depending on the order of start migrate you might end-up attempting to migrate the other VMs instead of the intended ones.
> 
> The same can happen here, you might start 2 nbd exports at the same time, get the same port without any failures and then depending on luck get the right or wrong export when attempting to connect. So I think bailing out in case we fail to get all interfaces would be the most appropriate (note the same situation is for 0.0.0.0 where you might end-up serving multiple different disks on different interfaces). Anyway I leave it to you. If you decide you don't want to fail than using ::1/127.0.0.1 sounds like a good idea. Otherwise it'd make sense to create a test that especially uses ::1 and then localhost to make sure it bails-out.

OK.  I’ll defer to Eric on that one. O:-)

Max



      reply	other threads:[~2020-02-07  8:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-03  7:59 [PATCH] tests/qemu_iotests: Minimize usage of used ports Lukáš Doktor
2020-02-03 15:32 ` Eric Blake
2020-02-06 15:03 ` Max Reitz
2020-02-06 16:27   ` Lukáš Doktor
2020-02-06 16:37     ` Max Reitz
2020-02-06 16:48       ` Eric Blake
2020-02-06 16:59         ` Max Reitz
2020-02-06 18:33           ` Lukáš Doktor
2020-02-07  8:24             ` Max Reitz [this message]

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=7393918c-e8c8-f58c-ce6e-34591c27e85c@redhat.com \
    --to=mreitz@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=ldoktor@redhat.com \
    --cc=mehta.aaru20@gmail.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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.