Re: libvirt-python for alpine linux
Nevermind - I was able to make this work myself by installing via pip, after I installed the alpine libvirt-dev package. Originally, the libvirt-python pip install was failing with errors pointing to pkg-config location. Tom On Sat, Feb 19, 2022 at 11:45 AM Tom Ammon wrote: > Hi everybody, > > Is there a libvirt-python package for alpine linux? I'm looking to > containerize an app that uses libvirt-python, using alpine linux, but all I > found that looked similar to libvirt-python was py-libvirt ( > https://pkgs.alpinelinux.org/package/v3.3/main/x86/py-libvirt) and it > looks pretty old. > > Tom > > -- > > --------- > Tom Ammon > M: (737) 400-9042 > thomasam...@gmail.com > > - > -- --------- Tom Ammon M: (737) 400-9042 thomasam...@gmail.com -
libvirt-python for alpine linux
Hi everybody, Is there a libvirt-python package for alpine linux? I'm looking to containerize an app that uses libvirt-python, using alpine linux, but all I found that looked similar to libvirt-python was py-libvirt ( https://pkgs.alpinelinux.org/package/v3.3/main/x86/py-libvirt) and it looks pretty old. Tom -- - Tom Ammon M: (737) 400-9042 thomasam...@gmail.com -
Re: Public IP on virtual machine network issue
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 > > <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 > <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 <http://www.voipplus.net> > > > > > > > > -- > > > - > > Tom Ammon > > M: (737) 400-9042 > > thomasam...@gmail.com <mailto:thomasam...@gmail.com> > > > - > > -- - Tom Ammon M: (737) 400-9042 thomasam...@gmail.com -
Re: Public IP on virtual machine network issue
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 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: simulating multiple hypervisors with the test driver
Daniel, That got me up and running quickly. The examples were easy to follow, all I had to do was read a couple of the xml documents to figure out how to get what I was after. Thank you, and the rest of the people working on the project, for all the effort you've put into libvirt! Tom On Tue, Jan 4, 2022 at 4:56 AM Daniel P. Berrangé wrote: > On Mon, Jan 03, 2022 at 09:06:35PM -0600, Tom Ammon wrote: > > Hello, > > > > I'm working on a python application that will manage multiple remote > > libvirt hypervisors. I've been using the test:///default uri for > > single-hypervisor tests, and it works great. > > > > I'd like to simulate connecting to two different remote hypervisors, > > however, in my testing so far it appears that multiple connections to the > > test:///default uri just look like different connections to the same > > hypervisor. Here's what I tried : > > Yes, the test:///default URI is shared process-global state. > > > What I would like is to be able to spin up two completely independent > > instances of the test driver so that it can simulate two different > > hypervisors/instances of libvirtd. > > Pass in a path to a custom XML file for the connection > > eg: > >test:///path/to/checkout/of/libvirt.git/examples/xml/test/testnode.xml > > every instance of a file base URL will be unique. See this example > file for guidance on how to write the XML to pre-populate arbitrary > resources > > Regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org-o- > https://www.instagram.com/dberrange :| > > -- - Tom Ammon M: (737) 400-9042 thomasam...@gmail.com -
simulating multiple hypervisors with the test driver
Hello, I'm working on a python application that will manage multiple remote libvirt hypervisors. I've been using the test:///default uri for single-hypervisor tests, and it works great. I'd like to simulate connecting to two different remote hypervisors, however, in my testing so far it appears that multiple connections to the test:///default uri just look like different connections to the same hypervisor. Here's what I tried : conn_one = libvirt.open('test:///default') one_vms = conn_one.listAllDomains(0) for x in one_vms: print(f"The vm in set one is {x.name()}") conn_two = libvirt.open('test:///default') two_vms = conn_two.listAllDomains(0) for z in two_vms: print(f"The vm in set one is {z.name()}") What I would like is to be able to spin up two completely independent instances of the test driver so that it can simulate two different hypervisors/instances of libvirtd. Is that possible? Thanks, Tom -- --------- Tom Ammon M: (737) 400-9042 thomasam...@gmail.com -