Which libvirt version are you using?

BTW: There is no trusted mode in the firewall. The p6p1 interface is trusted.

Name        : libvirt
Arch        : x86_64
Version     : 0.10.2
Release     : 3.fc18

(In reply to comment #2)
> BTW: There is no trusted mode in the firewall. The p6p1 interface is trusted.

Well firewall-config makes it look like 'trusted' is a global thing with wording like: 'Default Zone: trusted', and 'Change Default Zone'.

There is one limitation in libvirt: firewalld has to be active before libvirt gets started. Otherweise libvirt will not use firewalld.

Your firewall configuration is not complete, there are no filter rules for libvirt.

(In reply to comment #4)
> There is one limitation in libvirt: firewalld has to be active before
> libvirt gets started. Otherweise libvirt will not use firewalld.
> 
> Your firewall configuration is not complete, there are no filter rules for
> libvirt.

I'm not clear on whether this is _the_ problem here, or an unrelated issue. As a user or sysadmin, it would be very confusing if firewall configuration was dependent on a race condition between libvirtd and firewalld at boot time. Is that what's going on?

If I *had* started services in the right order, would there be an easy way to configure guest-to-host firewall rules?

@Stef

If your connection is not configured to be part of another zone, it is part of the default zone and therefore trusted. But libvirt is creating rules for guests and these are not in the default zone.

@Matthew

libvirt is taking care of firewall rules for guests. And at libvirt start it decides if it is using firewalld or not. THis iwas a design decision in libvirt. There has been a proposed patch for libvirt to do this dynamically. But the libvirt team decided to do this only at the start.

(In reply to comment #6)
> libvirt is taking care of firewall rules for guests. And at libvirt start it
> decides if it is using firewalld or not. THis iwas a design decision in
> libvirt. There has been a proposed patch for libvirt to do this dynamically.
> But the libvirt team decided to do this only at the start.

So, just so I'm extra clear:

If firewalld is in use, but libvirtd happens to start before firewalld, the behaviour will be different than if firewalld started first?

@Matthew: Yes.

Ah, but we do have "Before=libvirtd.service" in the systemd startup script, so that shouldn't happen in the normal case. However, if firewalld happens to not be running, weird things might occur. Sounds like another argument for bug #876683. :)

F18-TC2+updates, libvirt-1.0.1

F17+availeable-updates, libvirt-1.0.1

Each system is a virtualization host.  On each is a F18-TC2+updates guest.

I am getting very different behavior on the two systems.  On the F17 system, the guest can ssh and scp to the host as well as other systems.  On the F18 system, the guest canNOT ssh or scp to the host of any other systems.

I cannot find any documentation that says this is working correctly.  Therefore, bug!

Are there libvirt errors in the /var/log/messages file?

Created attachment 665018 [details]
log during time trying ssh

Sorry no.  I did a fresh boot and then a boot of a freshly installed F18 guest.

I am attaching the log but there is not much there.

For "ssh -4 hawk.lcl" I got "port 22 No route to host

and for "ssh -6 hawk.lcl" I got port 22 Permission denied.

More or less identical guest on F17 host works.

I did find some selinux problems with qemu-kvm but after updating the policy, it still did not work (I did not expect this to have an effect).

Some of the comments I have seen concerning the "ssh problem" say that restarting firewalld sometimes fixed things ... so I gave it a try.

Now that generated a large number of error messages from libvirtd ... do you wnat to see them?

(In reply to comment #13)
> Now that generated a large number of error messages from libvirtd ... do you
> wnat to see them?

Probably bug #884346 ?

It's a bit hard to know what Gene's talking about, but I can say this. I just switched from iptables to firewalld on my F18 system. Then I restarted libvirt. Now I cannot do 'ssh 192.168.122.1' on either an F17 or F18 guest with default configuration: they both give 'No route to host'. This works fine when the host is using iptables (it lets the guest connect to the host). This is with the default libvirt networking config, straightforward NAT.

This is with all current updates-testing F18 stuff on the host.

Oh, I do see the errors from 884346 around the time I restarted libvirtd.service .

I think we should keep this bug for the case where firewalld is started after libvirtd, and use https://bugzilla.redhat.com/show_bug.cgi?id=888288 for the problem Gene is reporting and I think I've reproduced. Otherwise things will get confused.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.