Bug 1018530
| Summary: | qemu live migration port conflicts with other users of ephemeral port(s) | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kaleb KEITHLEY <kkeithle> | |
| Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | urgent | |||
| Version: | 19 | CC: | berrange, cdhouch, clalancette, crobinso, dani-rh, eblake, gianluca.cecchi, gluster-bugs, herrold, itamar, jforbes, jherrman, jtomko, jyang, kkeithle, laine, libvirt-maint, veillard, virt-maint | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | libvirt-1.0.5.9-1.fc19 | Doc Type: | Bug Fix | |
| Doc Text: |
Prior to this update, migrating a virtual machine failed when the libvirtd service used a transmission control protocol (TCP) port that was already in use. Now, it is possible to predefine a custom migration TCP port range in case the default port is in use. In addition, libvirtd now ensures that the port it chooses from the custom range is not used by another process.
|
Story Points: | --- | |
| Clone Of: | 987555 | |||
| : | 1018695 (view as bug list) | Environment: | ||
| Last Closed: | 2014-01-26 11:54:11 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
|
Description
Kaleb KEITHLEY
2013-10-13 00:02:00 UTC
Now fixed on v1.0.5-maint as of:
commit 2dd4b3939407f4216892e0c461f615b3dae53c4f
Author: Zeng Junliang <zengjunliang>
qemu: clean up migration ports when migration cancelled
(cherry picked from commit c92ca769af2bacefdd451802d7eb1adac5e6597c)
Well. Any package to test and give feedback in koji or updates-testing? What does it mean -maint in version name? Thanks Gianluca (In reply to Gianluca Cecchi from comment #3) > Well. > Any package to test and give feedback in koji or updates-testing? Not yet. We are waiting for a CVE embargo to be lifted, to fix multiple BZ in one build. > What does it mean -maint in version name? That is the libvirt.git branch name that contains the patches that will be incorporated into the next Fedora build. You can test from a direct checkout of libvirt.git, if desired: git clone git://libvirt.org/libvirt.git cd libvirt git checkout v1.0.5-maint ./autogen.sh --system make rpc (In reply to Eric Blake from comment #4) > > git clone git://libvirt.org/libvirt.git > cd libvirt > git checkout v1.0.5-maint > ./autogen.sh --system > make rpc Correction: 'make rpm' libvirt-1.0.5.9-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/libvirt-1.0.5.9-1.fc19 Package libvirt-1.0.5.9-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libvirt-1.0.5.9-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-1090/libvirt-1.0.5.9-1.fc19 then log in and leave karma (feedback). Hello I have successfully tested libvirt-1.0.5.9-1.fc19, for both port definition setting and port skipping if busy.
My environment has oVirt 3.3.3beta1 with 2 f19 hosts and oVirt stable+beta repo defined.
My DC is of type Gluster version 3.4.2-1.fc19.x86_64 with two bricks
Initial config is gluster configured with range starting at 50152:
option base-port 50152
So ports occupied are 50152 and 50153
Initial configuration 1.0.5.8-1.fc19
libvirt with its own base config, so bound to 49152-xxx
During live migration netstat command gives:
On source
tcp 0 0 10.4.4.58:42501 10.4.4.59:49152 ESTABLISHED
On destination
tcp6 135382 0 10.4.4.59:49152 10.4.4.58:42501 ESTABLISHED
After updating and setting 51152-51251 for libvirt:
/etc/libvirt/qemu.conf
migration_port_min = 51152
migration_port_max = 51251
I'm able to successfully live migrate
src
tcp 0 57344 10.4.4.59:53761 10.4.4.58:51152 ESTABLISHED
dest
tcp6 0 0 10.4.4.58:51152 10.4.4.59:53761 ESTABLISHED
I also tested libvirt on same range of gluster 50152-50251
My gluster has two bricks and live migration completed at first attempt, silently adapting to the first available port (50154):
On destination netstat gives:
tcp 0 0 0.0.0.0:50152 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:50153 0.0.0.0:* LISTEN
tcp 0 0 192.168.3.3:1008 192.168.3.3:50153 ESTABLISHED
tcp 0 0 192.168.3.3:50153 192.168.3.1:1009 ESTABLISHED
tcp 0 0 192.168.3.3:1007 192.168.3.1:50152 ESTABLISHED
tcp 0 0 192.168.3.3:1014 192.168.3.3:50152 ESTABLISHED
tcp 0 0 192.168.3.3:50152 192.168.3.1:1012 ESTABLISHED
tcp 0 0 192.168.3.3:1006 192.168.3.3:50152 ESTABLISHED
tcp 0 0 192.168.3.3:50152 192.168.3.3:1014 ESTABLISHED
tcp 0 0 192.168.3.3:50152 192.168.3.3:1018 ESTABLISHED
tcp 0 0 192.168.3.3:1017 192.168.3.1:50153 ESTABLISHED
tcp 0 0 192.168.3.3:50153 192.168.3.3:1020 ESTABLISHED
tcp 0 0 192.168.3.3:50152 192.168.3.1:1000 ESTABLISHED
tcp 0 0 192.168.3.3:50152 192.168.3.3:1006 ESTABLISHED
tcp 0 0 192.168.3.3:1020 192.168.3.3:50153 ESTABLISHED
tcp 0 0 192.168.3.3:1018 192.168.3.3:50152 ESTABLISHED
tcp 0 0 192.168.3.3:50153 192.168.3.1:1001 ESTABLISHED
tcp 0 0 192.168.3.3:1019 192.168.3.1:50152 ESTABLISHED
tcp 0 0 192.168.3.3:1005 192.168.3.1:50153 ESTABLISHED
tcp 0 0 192.168.3.3:50153 192.168.3.3:1008 ESTABLISHED
tcp 0 0 192.168.3.3:1013 192.168.3.1:50153 ESTABLISHED
tcp 0 0 192.168.3.3:50152 192.168.3.1:1006 ESTABLISHED
tcp6 0 0 10.4.4.59:50154 10.4.4.58:37323 ESTABLISHED
udp 0 0 0.0.0.0:35011 0.0.0.0:*
I don't remember if there was a specific bugzilla for port busy management or if it is ok here...
Gianluca
Thanks for the detailed results Gianluca! They are fine here, there isn't any other bug that I know of libvirt-1.0.5.9-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. |