-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs/dev/libvirt: update libvirt/firewalld setup instructions #3677
docs/dev/libvirt: update libvirt/firewalld setup instructions #3677
Conversation
travier
commented
May 28, 2020
- Update libvirt setup instructions to clearly separate the systemd activated version from the classic one.
- Update firewalld setup to take into account recent libvirt integration.
- Also include some minor Markdown styling fixes.
Skipping CI for Draft Pull Request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of comments, but overall nice cleanup!
/lgtm
various zones. | ||
If using `firewalld`, the specifics will depend on how your distribution setup | ||
the various zones. The following instructions should work as is for Fedora, | ||
CentOS, RHEL and Arch Linux. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CentOS8/RHEL8 ? Or even EL7 distros?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the "libvirt version less than 5.1" covers EL7. Maybe the phrasing here is misleading?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, you differentiate between the misc distro versions through libvirt version, which makes sense.
sudo firewall-cmd --zone=dmz --change-interface=tt0 | ||
sudo firewall-cmd --zone=dmz --add-service=libvirt | ||
sudo firewall-cmd --zone=dmz --add-service=dns | ||
sudo firewall-cmd --zone=dmz --add-service=dhcp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the change from the previous rules?
sudo firewall-cmd --zone=dmz --change-interface=virbr0
sudo firewall-cmd --zone=dmz --change-interface=tt0
sudo firewall-cmd --zone=dmz --add-service=libvirt
I assume the rules in this PR are enough to allow connections from the cluster VMs to qemu+tcp://192.168.122.1/system?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not re-checked this but by default the dmz zone does not allow DNS/DHCP access and the nodes in the cluster need to get DHCP & DNS from the host dnsmasq daemon started by libvirt.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The virbr0
change is never required as far as I understand as nodes traffic will get routed through the tt0 bridge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not re-checked this but by default the dmz zone does not allow DNS/DHCP access and the nodes in the cluster need to get DHCP & DNS from the host dnsmasq daemon started by libvirt.
Yep, makes sense, dunno why I did not need that when I tried this :)
The virbr0 change is never required as far as I understand as nodes traffic will get routed through the tt0 bridge.
I ran some tests, and seems to be fine indeed. Not quite sure why the VMs on the tt0 bridge can reach virbr0 (we need to be able to reach qemu+tcp://192.168.122.1/system from the guest OS).
8e73108
to
3fcc846
Compare
/lgtm |
/ok-to-test |
3fcc846
to
2d62b38
Compare
Updated to take into account the changes from: #3638. |
2d62b38
to
dad757c
Compare
Updated to not make the TCP socket unit enabled at boot by default to reduce security issue (i.e. a reboot will default to a safe state on modern systems). I removed the draft state. |
dad757c
to
12744f6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the last commit shortlog, there's a 'socket' typo.
docs/dev/libvirt/README.md
Outdated
running a telnet server with no root password set. It is critical | ||
to follow the steps below to **configure the firewall to prevent | ||
access to libvirt from other hosts on the LAN/WAN**. | ||
To make this change persistent accross reboots you can optionnaly enable it: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
optionnaly->optionally
sudo systemctl start libvirtd-tcp.socket | ||
``` | ||
|
||
after which you need to restart libvirtd. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this still applies?
docs/dev/libvirt/README.md
Outdated
activation via the `libvirt-tcp.socket` systemd unit, the `--listen` | ||
argument should not be added and thus this step can be skipped. | ||
This applies only if the libvirt daemon is configured to start and listen on | ||
UNIX/TCP sockets by itself and not through system activation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/system/socket?
After your changes, it is sometimes not clear whether you are talking about libvirtd.service started through systemd (when configuring through /etc/sysconfig/libvirt would still apply), and about libvirtd systemd socket activation, where libvirtd.socket is the only systemd unit running, and this unit starts libvirtd.service upon connections on this socket.
|
||
``` | ||
libvirtd_opts="--listen" | ||
``` | ||
|
||
Next, restart libvirt: `systemctl restart libvirtd` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this #### Configure the service runner to pass
--listen to libvirtd
section, I think the previous wording was better.
Next, restart libvirt: `systemctl restart libvirtd` | ||
Then to enable TCP access to libvirtd, modify `/etc/libvirt/libvirtd.conf` and | ||
set the following: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this coming so late? I think this is always needed, and must be done in all cases, even in the socket activated case. From looking at this diff, it seems it's only in the "#### Configure the service runner to pass --listen
to libvirtd" section
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would keep most of the previous order and not move most of the text. Splitting the libvirt-tcp.socket
discussion from its paragraph could be useful indeed, and being more explicit about what enable
does is good too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok, most of the libvirtd.conf
changes are not needed with tcp socket activation.auth_tcp = none
is needed:
$ LC_ALL=C virsh -c qemu+tcp://localhost/system
error: failed to connect to the hypervisor
error: l'authentification a échoué : échec de l'authentification
12744f6
to
051d578
Compare
Updated to take into account comments. As this reorders lots of sections of text in the README, I find it more practical to directly read the final version than to make sense of the diff: https://github.com/travier/installer/blob/master-docs-dev-libvirt-update/docs/dev/libvirt/README.md |
listen_tcp = 1 | ||
auth_tcp = "none" | ||
tcp_port = "16509" | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still a bit dubious with the splitting of the libvirtd.conf instructions, even if they are ignored, it's not harmful to set them in socket-activation setups
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not harmful but it's also unnecessary and might trigger questions. I think we need to have two clearly separated cases to avoid confusion and keeping each case to the point helps with that.
docs/dev/libvirt/README.md
Outdated
activation via the `libvirt-tcp.socket` systemd unit, the `--listen` | ||
argument should not be added and thus this step can be skipped. | ||
This applies only if the libvirt daemon is configured to start and listen on | ||
UNIX/TCP sockets by itself and not through socket activation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reads to me as if this section is when starting libvirtd 'by hand', while it really is about systems using libvirtd.service
without socket activation (ie without using libvirtd.socket
)
Maybe This applies only if the libvirt daemon is started through libvirtd.service without making use of socket activation (through libvirtd.socket and similar systemd units)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
051d578
to
5d7e32f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cfergeau The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |