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 > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list