On 11/25/15 12:00, Daniel P. Berrange wrote:
On Wed, Nov 25, 2015 at 11:52:21AM +0100, Laszlo Ersek wrote:
I recently upgraded my laptop from RHEL-7.1 to RHEL-7.2.
I always pay attention to *.rpmnew config files, and I manually diff and merge them with the ones I have in place.
I did the same with "/etc/libvirt/qemu.conf" this time.
Now libvirtd doesn't start for me. Systemd doesn't actually notice the startup failure (insert bitter joke about systemd being so much better than startup scripts); it only reports the service inactive/dead (= unstarted), rather than failed.
But, the libvirtd log file gives the reason:
migration_address must not be the address of the local machine: 127.0.0.1
The error is easy to fix up in the config file, but my question is:
Why must migration_address not be the address of the local machine?
The migration address for incoming migration over TCP needs to be a public facing IP address, otherwise the remote machine won't be able to connect to it. If you configure migration_address on the target machine to be 127.0.0.1, then obviously no migration client connection will ever succeed, hence we consider 127.0.0.1 as an invalid configuration.
BTW, my purpose is not in-host migration (perhaps that's indeed unsupported, I don't know); I just want to lock down the incoming migration port (and not just with firewall rules).
What's wrong with using firewall rules ? IMHO you are describing exactly the scenario that are intended to deal with.
I certainly use firewall rules. But, I like to disable listeners, especially public listeners, on the individual application level too, if I don't have a good use for the service.
If there's a way to disable incoming migration in libvirtd, I'd be interested in that.
You could setup libvirt's API access control rules to deny the "migrate" privilege to all users. Using firewall rules is a more secure solution though IMHO
I agree about that. Thanks Laszlo
Regards, Daniel