[libvirt] [RFC] migration encryption

Nikolay Shirokovskiy nshirokovskiy at virtuozzo.com
Thu Nov 12 13:20:21 UTC 2015


Actually we need to specify 4 ports. state and nbd transfer ports for both source
and destination because they have to be allocated independently on source and destination.
Allocation will be done externally on both sides.

On 12.11.2015 15:57, Nikolay Shirokovskiy wrote:
> add CC
> 
> On 10.11.2015 14:24, Nikolay Shirokovskiy wrote:
>>
>>
>> On 10.11.2015 14:08, Ján Tomko wrote:
>>> On Tue, Nov 10, 2015 at 01:52:16PM +0300, Nikolay Shirokovskiy wrote:
>>>> Hi guys.
>>>>
>>>>  I have a problem getting migration traffic encrypted for some scenarios. I need to
>>>> migrate domain with non shared disks and can't use tunelled migration because of RHEL7 qemu.
>>>> Without tunnel i get both vm state and disk state traffic unencrypted between
>>>> peer's qemus. AFAIK there is a work in progress in qemu to bring TLS encryption
>>>> to all channels and eventually I get desired functionality but what are my options
>>>> now?
>>>>  I thinking of forwarding ports from destination to source and use localhost in
>>>> hypervisor uri. The only problem is that port for disk migration is auto selected.
>>>> Can we add a patch to pass this port as a migration parameter?
>>>>
>>>
>>> We already have a migration URI, where you can specify the port:
>>> http://libvirt.org/migration.html#uris
>>> so working around the lack of encryption should be possible.
>> True, but I need to specify 2 ports: one for vm state migration and
>> one for vm disks migration (in case of non shared disks).
>>>
>>> The listen address can now also be specified if you don't want QEMU to
>>> listen on all interfaces:
>>> http://libvirt.org/html/libvirt-libvirt-domain.html#VIR_MIGRATE_PARAM_LISTEN_ADDRESS
>>>
>>> Jan
>>>
>>
>> --
>> libvir-list mailing list
>> libvir-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
>>
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 




More information about the libvir-list mailing list