Re: Public IP on virtual machine network issue

2022-02-14 Thread Tom Ammon
Laine,

Though I can't remember the particulars, I have a vague memory of the
sysctl settings in that article indeed solving the problem of traffic not
being forwarded on the bridge when I had configured no filtering on the
guest - hence my attempt to share what worked for me. Perhaps it would be
good to update that page. I looked around for a link to create an account
on the libvirt wiki but could find none. I'm happy to go do some more
research around the items you mentioned and add a quick note to that page
to keep from leading people astray in the future, if I could get an account
on the wiki. Do you know how I would do that?

Thanks,
Tom

On Mon, Feb 14, 2022 at 8:12 AM Laine Stump  wrote:

>
>
> On 2/13/22 5:38 PM, Tom Ammon wrote:
> > Can you post the output of iptables -L?
> >
> > By default, the bridge module in the kernel sends packets traversing the
> > bridge to iptables (in the FORWARD chain I believe) for processing. So
> > if you have configured a DENY policy on the FORWARD chain, or are
> > otherwise filtering in the forward chain, you'll be affecting packets
> > traversing the bridge. Check out this page for details on how to change
> > this behavior:
> > https://wiki.libvirt.org/page/Net.bridge.bridge-nf-call_and_sysctl.conf
> >  >
>
> That information is *very* out of date; the situation has changed quite
> a lot since that was written in 2014.
>
> Filtering of packets traversing a bridge device are now only filtered if
> the br_netfilter module is loaded, which isn't done by default. It *is*
> autoloaded if certain types of iptables rules are added(I can't remember
> the details of the type of rule though - there was a bug in iptables a
> year or so ago where autoload of br_netfilter was triggered by libvirt
> attempting to *remove* a rule of whatever type it was).
>
> Anyway, unless "lsmod | grep br_netfilter" shows that you have
> br_netfilter loaded, this entire path is a red herring (if you do have
> it loaded, unload it, and try to figure out why it was loaded).
>
> (Interestingly, this is the 2nd time this particular outdated page has
> come up in the last week. Has something else broken somewhere that's
> causing people to search out this page?)
>
> >
> > Tom
> >
> > On Sun, Feb 13, 2022 at 4:08 PM Marcin Groszek  > > wrote:
> >
> > I have been struggling with this for weeks and I was unable to find
> an
> > answer on line. Perhaps someone here can help me.
> >
> > Oracle linux 8 running virtualization:
> >
> > hardware node has a public IP address on interface bridge0 and
> physical
> > eno1 is a member of the bridge0
> >
> > a virtual OS has interface bridged to lan and source is bridge0, Ip
> > address of virtual OS is also a public from same class as the
> > hardware node.
> >
> > I can route in and out of virtual, I can ping from hardware node to
> > virtual and vice versa, so the routing works as it should, sort of.
> >
> > When I try tracepath or traceroute from outside to virtual I get !H
> on
> > last hup
> >
> > same result when I try to do the same form hardware node to virtual
> > I get !H
> >
> > Also, when I telnet (TCP) to a specific port on virtual where I have
> a
> > daemon LISTENING OR NOT I get: No route to host. Same experiment
> works
> > just fine for ssh port.
> >
> > Firewalld is not running, and I just have very basic iptables rules
> > like
> > allowing external address block to ssh to hardware node and to
> virtual
> > dropping connections from all other sources
> >
> > This issue presented it self when I attempted to setup a galera node
> on
> > virtual and ports 4567 is responding but 4568 and  are not, but
> the
> > daemons are running and I can clearly see lsoft showing "LISTENING"
> >
> > I capture the traffic and the tcp as well as udp are getting to the
> > virtual. Is there a preconfigured netfiltering that I am not aware
> of?
> >
> > What am I missing?
> >
> >
> >
> >
> > --
> > Best Regards:
> > Marcin Groszek
> > Business Voip Resource.
> > http://www.voipplus.net 
> >
> >
> >
> > --
> >
> -
> > Tom Ammon
> > M: (737) 400-9042
> > thomasam...@gmail.com 
> >
> -
>
>

-- 
-
Tom Ammon
M: (737) 400-9042
thomasam...@gmail.com
-


Re: Public IP on virtual machine network issue

2022-02-14 Thread Laine Stump




On 2/13/22 5:38 PM, Tom Ammon wrote:

Can you post the output of iptables -L?

By default, the bridge module in the kernel sends packets traversing the 
bridge to iptables (in the FORWARD chain I believe) for processing. So 
if you have configured a DENY policy on the FORWARD chain, or are 
otherwise filtering in the forward chain, you'll be affecting packets 
traversing the bridge. Check out this page for details on how to change 
this behavior: 
https://wiki.libvirt.org/page/Net.bridge.bridge-nf-call_and_sysctl.conf 



That information is *very* out of date; the situation has changed quite 
a lot since that was written in 2014.


Filtering of packets traversing a bridge device are now only filtered if 
the br_netfilter module is loaded, which isn't done by default. It *is* 
autoloaded if certain types of iptables rules are added(I can't remember 
the details of the type of rule though - there was a bug in iptables a 
year or so ago where autoload of br_netfilter was triggered by libvirt 
attempting to *remove* a rule of whatever type it was).


Anyway, unless "lsmod | grep br_netfilter" shows that you have 
br_netfilter loaded, this entire path is a red herring (if you do have 
it loaded, unload it, and try to figure out why it was loaded).


(Interestingly, this is the 2nd time this particular outdated page has 
come up in the last week. Has something else broken somewhere that's 
causing people to search out this page?)




Tom

On Sun, Feb 13, 2022 at 4:08 PM Marcin Groszek > wrote:


I have been struggling with this for weeks and I was unable to find an
answer on line. Perhaps someone here can help me.

Oracle linux 8 running virtualization:

hardware node has a public IP address on interface bridge0 and physical
eno1 is a member of the bridge0

a virtual OS has interface bridged to lan and source is bridge0, Ip
address of virtual OS is also a public from same class as the
hardware node.

I can route in and out of virtual, I can ping from hardware node to
virtual and vice versa, so the routing works as it should, sort of.

When I try tracepath or traceroute from outside to virtual I get !H on
last hup

same result when I try to do the same form hardware node to virtual
I get !H

Also, when I telnet (TCP) to a specific port on virtual where I have a
daemon LISTENING OR NOT I get: No route to host. Same experiment works
just fine for ssh port.

Firewalld is not running, and I just have very basic iptables rules
like
allowing external address block to ssh to hardware node and to virtual
dropping connections from all other sources

This issue presented it self when I attempted to setup a galera node on
virtual and ports 4567 is responding but 4568 and  are not, but the
daemons are running and I can clearly see lsoft showing "LISTENING"

I capture the traffic and the tcp as well as udp are getting to the
virtual. Is there a preconfigured netfiltering that I am not aware of?

What am I missing?




-- 
Best Regards:

Marcin Groszek
Business Voip Resource.
http://www.voipplus.net 



--
-
Tom Ammon
M: (737) 400-9042
thomasam...@gmail.com 
-




Re: Public IP on virtual machine network issue

2022-02-14 Thread Marcin Groszek

The issue has been resolved I had a firewald running on virtual host.

Thank you for the replay.


On 2/13/2022 9:17 PM, Daniel Romero wrote:

Hi,

as Tom says, check iptables forward rules. Also, you can check host 
sysctl ipv4/6 global and per interface rules to double check bridge 
forward capabilities. Finally, check your routes on guest vm, 
especially the default gw, sometimes you can receive the packet and 
the answer is sent through the wrong interface because of bad routes.


Best Regards.
Daniel Romero P.



On Sun, Feb 13, 2022 at 7:39 PM Tom Ammon > wrote:


Can you post the output of iptables -L?

By default, the bridge module in the kernel sends packets
traversing the bridge to iptables (in the FORWARD chain I believe)
for processing. So if you have configured a DENY policy on the
FORWARD chain, or are otherwise filtering in the forward chain,
you'll be affecting packets traversing the bridge. Check out this
page for details on how to change this behavior:
https://wiki.libvirt.org/page/Net.bridge.bridge-nf-call_and_sysctl.conf

Tom

On Sun, Feb 13, 2022 at 4:08 PM Marcin Groszek
mailto:mar...@voipplus.net>> wrote:

I have been struggling with this for weeks and I was unable to
find an
answer on line. Perhaps someone here can help me.

Oracle linux 8 running virtualization:

hardware node has a public IP address on interface bridge0 and
physical
eno1 is a member of the bridge0

a virtual OS has interface bridged to lan and source is
bridge0, Ip
address of virtual OS is also a public from same class as the
hardware node.

I can route in and out of virtual, I can ping from hardware
node to
virtual and vice versa, so the routing works as it should,
sort of.

When I try tracepath or traceroute from outside to virtual I
get !H on
last hup

same result when I try to do the same form hardware node to
virtual I get !H

Also, when I telnet (TCP) to a specific port on virtual where
I have a
daemon LISTENING OR NOT I get: No route to host. Same
experiment works
just fine for ssh port.

Firewalld is not running, and I just have very basic iptables
rules like
allowing external address block to ssh to hardware node and to
virtual
dropping connections from all other sources

This issue presented it self when I attempted to setup a
galera node on
virtual and ports 4567 is responding but 4568 and  are
not, but the
daemons are running and I can clearly see lsoft showing
"LISTENING"

I capture the traffic and the tcp as well as udp are getting
to the
virtual. Is there a preconfigured netfiltering that I am not
aware of?

What am I missing?




-- 
Best Regards:

Marcin Groszek
Business Voip Resource.
http://www.voipplus.net



-- 
-

Tom Ammon
M: (737) 400-9042
thomasam...@gmail.com 

-


--
Best Regards:
Marcin Groszek
Business Voip Resource.
http://www.voipplus.net



Re: libvirtd daemon missing in LFS

2022-02-14 Thread Michal Prívozník
On 2/14/22 10:09, Sai Kiran Kumar Reddy wrote:
> Hi Peter,
> 
> Thanks for your inputs. I have looked at all the dependencies and built
> libvirt with the appropriate dependencies enabled. I am able to run
> virt-manager also, without any errors. I am trying to create a VM using
> virsh. I get an error saying "domain configuration does not support
> video mode qxl". Could you please let me know if it is libvirt related
> error or qemu related one?

This is QEMU related and your qemu was probably build without SPICE support:

  https://www.spice-space.org/

pass --enable-spice to QEMU ./configure script. Alternatively, Gentoo
has all these dependencies recorded and maintained. So it's easier to
install.

Michal



Re: libvirtd daemon missing in LFS

2022-02-14 Thread Sai Kiran Kumar Reddy
Hi Peter,

Thanks for your inputs. I have looked at all the dependencies and built
libvirt with the appropriate dependencies enabled. I am able to run
virt-manager also, without any errors. I am trying to create a VM using
virsh. I get an error saying "domain configuration does not support video
mode qxl". Could you please let me know if it is libvirt related error or
qemu related one?

On Thu, Feb 10, 2022 at 1:50 PM Peter Krempa  wrote:

> On Thu, Feb 10, 2022 at 11:39:17 +0530, Sai Kiran Kumar Reddy wrote:
> > Hi,
> >
> > There was some issue with pkg-config-path. I have fixed it. I see that it
> > looks for wireshark and other dependencies. I get an error saying "remote
> > driver is required for libvirtd daemon". I am not sure what this error
>
> So you are missing some of the dependencies needed by the remote driver
> which is needed for the libvirtd daemon. Similarly to what I've
> suggested before can be used for any other option.
>
> To list full configuration of the project along with options that were
> selected you can run 'meson configure' from the builddir and it will
> print all options:
>
> $ meson configure
>
> [... snipped ... ]
>
>   Project optionsCurrent ValuePossible Values
> Description
>   -------
> ---
>   apparmor   auto [enabled,
> disabled, auto]apparmor support
>   apparmor_profiles  auto [enabled,
> disabled, auto]install apparmor profiles
>   attr   auto [enabled,
> disabled, auto]attr support
>   audit  auto [enabled,
> disabled, auto]audit support
>   bash_completionauto [enabled,
> disabled, auto]bash-completion support
>   bash_completion_dir
> directory containing bash completion scripts
>   blkid  auto [enabled,
> disabled, auto]blkid support
>   capng  auto [enabled,
> disabled, auto]cap-ng support
>   ch_group
>  groupname to run Cloud-Hypervisor system instance as
>   ch_user
> username to run Cloud-Hypervisor system instance as
>   chrdev_lock_files
> location for UUCP style lock files for character devices
>
>  (leave empty for default paths on some platforms)
>   curl   auto [enabled,
> disabled, auto]curl support
>   docdir
>  documentation installation directory
>   docs   auto [enabled,
> disabled, auto]whether to generate documentation
>   driver_bhyve   auto [enabled,
> disabled, auto]bhyve driver
>   driver_ch  auto [enabled,
> disabled, auto]Cloud-Hypervisor driver
>   driver_esx auto [enabled,
> disabled, auto]esx driver
>   driver_hyperv  auto [enabled,
> disabled, auto]Hyper-V driver
>   driver_interface   auto [enabled,
> disabled, auto]host interface driver
>   driver_libvirtdauto [enabled,
> disabled, auto]libvirtd driver
>   driver_libxl   auto [enabled,
> disabled, auto]libxenlight driver
>   driver_lxc auto [enabled,
> disabled, auto]Linux Container driver
>   driver_network auto [enabled,
> disabled, auto]virtual network driver
>   driver_openvz  auto [enabled,
> disabled, auto]OpenVZ driver
>   driver_qemuauto [enabled,
> disabled, auto]QEMU/KVM driver
>   driver_remote  auto [enabled,
> disabled, auto]remote driver
>   driver_secrets auto [enabled,
> disabled, auto]local secrets management driver
>   driver_testauto [enabled,
> disabled, auto]test driver
>   driver_vboxauto [enabled,
> disabled, auto]VirtualBox XPCOMC driver
>   driver_vmware  auto [enabled,
> disabled, auto]VMware driver
>   driver_vz  auto [enabled,
> disabled, auto]Virtuozzo driver
>   dtrace auto [enabled,
> disabled, auto]use dtrace for static probing
>   expensive_testsauto [enabled,
> disabled, auto]set the default for enabling expensive tests (long
>
> [...]
>
>
> > means. Does it mean that I have to