On 10.04.2013 17:57, Daniel P. Berrange wrote:
> On Wed, Apr 10, 2013 at 05:52:26PM +0200, Michal Privoznik wrote:
>>
https://bugzilla.redhat.com/show_bug.cgi?id=920441
>>
>> Currently, we are discarding listen attribute from qemu cookie even though
>> we strive to gather it. This result in not so cool bug: if user have
>> different networks, one for management/migration, and one for VNC/SPICE we
>> pass incorrect host to the qemu in client_migrate_info. What we actually
>> pass is remote hostname, while we should be passing remote listen address.
>> It doesn't matter as long as these two are the same, but they don't
need
>> necessary to be like that.
>> ---
>> src/conf/domain_conf.c | 4 +++-
>> src/qemu/qemu_migration.c | 2 +-
>> 2 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
>> index e00a532..2afa982 100644
>> --- a/src/conf/domain_conf.c
>> +++ b/src/conf/domain_conf.c
>> @@ -16557,8 +16557,10 @@
virDomainGraphicsListenGetAddress(virDomainGraphicsDefPtr def, size_t ii)
>> virDomainGraphicsListenDefPtr listenInfo
>> = virDomainGraphicsGetListen(def, ii, false);
>>
>> + /* even a network can have a listen address */
>> if (!listenInfo ||
>> - (listenInfo->type != VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_ADDRESS))
>> + !(listenInfo->type == VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_ADDRESS ||
>> + listenInfo->type == VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_NETWORK))
>> return NULL;
>> return listenInfo->address;
>> }
>> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
>> index 41ad768..089b75a 100644
>> --- a/src/qemu/qemu_migration.c
>> +++ b/src/qemu/qemu_migration.c
>> @@ -1738,7 +1738,7 @@ qemuDomainMigrateGraphicsRelocate(virQEMUDriverPtr
driver,
>> if (ret == 0) {
>> ret = qemuMonitorGraphicsRelocate(priv->mon,
>> cookie->graphics->type,
>> - cookie->remoteHostname,
>> + cookie->graphics->listen,
>
> So how do this work if the user has configured
>
> <graphics listen="0.0.0.0">
>
> this is not an address you tell the spice client to reconnect to.
> This is why it originally used the 'remoteHostname' becuase that
> is a valid address to connect to.
>
> Daniel
>
Aaah, didn't catch that. I suppose in that specific case we should be
passing remoteHostname. In such conditions, is 127.0.0.1 specific
address as well? I believe so. But I don't see any other specific address.
127.0.0.1 is a valid address - it means that any client would have
been using SSH tunnelling to connect to it.
Daniel
--
|: