July 2016 - Users - libvirt List Archives

[libvirt-users] ceph rbd pool and libvirt manageability (virt-install)
by Jelle de Jong 28 Aug '18

28 Aug '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, I created a rbd pool and activated it, but I can't seem to create volumes in it with virsh or virt-install? # virsh pool-dumpxml myrbdpool <pool type='rbd'> <name>myrbdpool</name> <uuid>2d786f7a-2df3-4d79-ae60-1535bcf1c6b5</uuid> <capacity unit='bytes'>6997998301184</capacity> <allocation unit='bytes'>10309227031</allocation> <available unit='bytes'>6977204658176</available> <source> <host name='ceph01.powercraft.nl' port='6789'/> <host name='ceph02.powercraft.nl' port='6789'/> <host name='ceph03.powercraft.nl' port='6789'/> <name>libvirt-pool</name> <auth type='ceph' username='libvirt'> <secret uuid='029a334e-ed57-4293-bb99-ffafa8867122'/> </auth> </source> </pool> # virt-install --version 1.0.1 # virsh --version 1.2.9 I ended using virsh edit ceph-test.powercraft.nl and making creating the disk manually. <disk type='network' device='disk'> <auth username='libvirt'> <secret type='ceph' uuid='029a334e-ed57-4293-bb99-ffafa8867122'/> </auth> <source protocol='rbd' name='libvirt-pool/kvm01-storage'> <host name='ceph01.powercraft.nl' port='6789'/> <host name='ceph02.powercraft.nl' port='6789'/> <host name='ceph03.powercraft.nl' port='6789'/> </source> <target dev='vdc' bus='virtio'/> </disk> I use virt-install a lot to define, import and undefine domains, how can I use virt-install to manage my rdb disks? Kind regards, Jelle de Jong -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iJwEAQECAAYFAlV1xlQACgkQ1WclBW9j5HkbPQP+PjNrzvlqysslOp2Yk7wH4Mxy 2sh2dn96G0KOAHEeEn3BN6IWlnD1TADZbHdpTtMwkdv48Xwn0sP1s+3QDM4pb3gP n+z+dVxS8FouDIy/eiso3IBCj3g4TWbEX8ZHqs3jKqe0lZgAXBzB9xYSUowcEBrZ ddkPbr8p8ozWyOG+9V8= =lkK7 -----END PGP SIGNATURE-----

2 3

[libvirt-users] virRandomBits - not very random
by Brian Rak 01 Jun '18

01 Jun '18

I just ran into an issue where I had about 30 guests get duplicate mac addresses assigned. These were scattered across 30 different machines. Some debugging revealed that: 1) All the host machines were restarted within a couple seconds of each other 2) All the host machines had fairly similar libvirtd pids (within ~100 PIDs of each other) 3) Libvirt seeds the RNG using 'time(NULL) ^ getpid()' This perfectly explains why I saw so many duplicate mac addresses. Why is the RNG seed such a predictable value? Surely there has to be a better source of a random seed then the timestamp and the pid? The PID seems to me to be a very bad source of any randomness. I just ran a test across 60 of our hosts. 43 of them shared their PID with at least one other machine.

7 13

[libvirt-users] stream finish throws exception via python API
by Shahar Havivi 27 Nov '16

27 Nov '16

Hi, The following snippet works fine e.g. receiving the data but when calling stream.finish() we get the following error: stream = con.newStream() vol.download(stream, 0, 0, 0) buf = stream.recv(1024) stream.finish() libvirt: I/O Stream Utils error : internal error: I/O helper exited abnormally Traceback (most recent call last): File "./helpers/kvm2ovirt", line 149, in <module> download_volume(vol, item[1], diskno, disksitems, pksize) File "./helpers/kvm2ovirt", line 102, in download_volume stream.finish() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 5501, in finish if ret == -1: raise libvirtError ('virStreamFinish() failed') libvirt.libvirtError: internal error: I/O helper exited abnormally Am I doing something wrong? Thank you, Shahar.

5 12

[libvirt-users] Lifecycle of a connection to libvirtd
by Vincent Bernat 26 Aug '16

26 Aug '16

Hey! I am trying to figure out how to reliably maintain a connection to libvirtd. From the documentation, I would expect something like that: - virConnectOpen() - virConnectRegisterCloseCallback() - virConnectSetKeepAlive() - Application logic And in the registered callback, I would: - virConnectUnregisterCloseCallback() - virConnectClose() - virConnectOpen() - virConnectRegisterCloseCallback() - virConnectSetKeepAlive() However, looking at the source code of virsh, I see that it additional stuff, notably: - virConnectIsAlive() - checking error codes of all calls to check if they are the result of a disconnect Are those steps needed? Randomly checking virConnectIsAlive() doesn't seem reliable. Checking individual error codes either (maybe I will miss one of them or misinterpret another one). virsh code uses those error codes to check if there is a disconnection: (((last_error->code == VIR_ERR_SYSTEM_ERROR) && (last_error->domain == VIR_FROM_REMOTE)) || (last_error->code == VIR_ERR_RPC) || (last_error->code == VIR_ERR_NO_CONNECT) || (last_error->code == VIR_ERR_INVALID_CONN)))) Any hint? -- Program defensively. - The Elements of Programming Style (Kernighan & Plauger)

2 3

[libvirt-users] QEMU IMG vs Libvirt block commit
by Erlon Cruz 12 Aug '16

12 Aug '16

Hi folks, I'm having a issue in the standard NFS driver on OpenStack, that uses qemu-img and libvirt to create snapshots of volumes. It uses qemu-img in the Controller to manage the snapshots when the volume is not attached (offline) or calls the Compute (which calls libvirt) to manage snapshots if the volume is attached (online). When I try to create/delete snapshots from a snapshot chain. There are 3 situations: 1 - I create/delete the snapshots in Cinder (it uses qemu-img). It goes OK! I can delete and I can create snapshots. 2 - I create/delete the snapshots, in online mode (it uses libvirt). It goes Ok, as weel. 3 - I create the snapshots in Cinder (offline) and delete then in online mode (using libvirt), then it fails with this message[1]: libvirtError: invalid argument: could not find image 'volume-13cb83a2-880f-40e8-b60e-7e805eed76f9.d024731c-bdc3-4943-91c0-215a93ee2cf4' in chain for '/opt/stack/data/nova/mnt/a3b4c6ddd9bf82edd4f726872be58d05/volume-13cb83a2-880f-40e8-b60e-7e805eed76f9' But, in this folder, there the backing files are there[2] and they are chained as think it suppose to be[3]. The version for the 2 hosts in tests are: Controller/Cinder node: qemu-img version 2.0.0 && libvirt 1.2.2-0ubuntu13 Compute node: qemu-img version 2.5.0 && libvirt-1.3.1-1ubuntu10 Is there any compatibility problem between libvirt and qemu-img snapshots? Have you guys found any problem like that? Erlon ---------------------------------- [1] http://paste.openstack.org/show/543270/ [2] http://paste.openstack.org/show/543273/ [3] http://paste.openstack.org/show/543274/

1 2

[libvirt-users] NPIV storage pools do not map to same LUN units across hosts.
by Nitesh Konkar 04 Aug '16

04 Aug '16

Link: http://wiki.libvirt.org/page/NPIV_in_libvirt Topic: Virtual machine configuration change to use vHBA LUN There is a NPIV storage pool defined on two hosts and pool contains a total of 8 volumes, allocated from a storage device. Source: # virsh vol-list poolvhba0 Name Path ------------------------------------------------------------------------------ unit:0:0:0 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000366 unit:0:0:1 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000367 unit:0:0:2 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000368 unit:0:0:3 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000369 unit:0:0:4 /dev/disk/by-id/wwn-0x6005076802818bda300000000000036a unit:0:0:5 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000380 unit:0:0:6 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000381 unit:0:0:7 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000382 -------------------------------------------------------------------- Destination: -------------------------------------------------------------------- # virsh vol-list poolvhba0 Name Path ------------------------------------------------------------------------------ unit:0:0:0 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000380 unit:0:0:1 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000381 unit:0:0:2 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000382 unit:0:0:3 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000367 unit:0:0:4 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000368 unit:0:0:5 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000366 unit:0:0:6 /dev/disk/by-id/wwn-0x6005076802818bda300000000000036a unit:0:0:7 /dev/disk/by-id/wwn-0x6005076802818bda3000000000000369 -------------------------------------------------------------------- As you can see in the above output,the same set of eight LUNs from the storage server have been mapped, but the order that the LUNs are probed on each host is different, resulting in different unit names on the two different hosts . If the the guest XMLs is referencing its storage by "unit" number then is it safe to migrate such guests because the "unit number" is assigned by the driver according to the specific way it probes the storage and hence when you migrate these guests , it results in different unit names on the destination hosts. Thus the migrated guest gets mapped to the wrong LUNs and is given the wrong disks. The problem is that the LUN numbers on the destination host and source host do not agree. Example, LUN 0 on source_host, for example, may be LUN 5 on destination_host. When the guest is given the wrong disk, it suffers a fatal I/O error. (This is manifested as fatal I/O errors since the guest has no idea that its disks just changed out under it.)The migration does not take into account that the unit numbers do match on on the source and destination sides. So, should libvirt make sure that the guest domains reference NPIV pool volumes by their globally-unique wwn instead of by "unit" numbers? The guest XML references its storage by "unit" number. Eg:- <disk type='volume' device='lun'> <driver name='qemu' type='raw' cache='none'/> <source pool='poolvhba0' volume='unit:0:0:0'/> <backingStore/> <target dev='vdb' bus='virtio'/> <alias name='virtio-disk1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> I am planning to write a patch for it. Any comments on the above observation/approach would be appreciated. Thanks, Nitesh.

1 1

[libvirt-users] Live Disk Backup
by Prof. Dr. Michael Schefczyk 01 Aug '16

01 Aug '16

Dear All, using CentOS 7.2.1511, and libvirt from ovirt repositories (currently 1.2.17-13.el7_2.5, but without otherwise using ovirt) I am regularly backing up my VMs which are on qcow2 files. In general, I am trying to follow http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit A typical backup script would be #!/bin/bash dt=`date +%y%m%d` if virsh dominfo dockers10a | grep -q -E '^Status: *laufend|^State: *running' then virsh snapshot-create-as --domain dockers10a dockers10a --diskspec vda,file=/home/dockers10asnap.qcow2 --disk-only --no-metadata --atomic cp /kvm01/dockers10a.qcow2 /backup/dockers10a$dt.qcow2 virsh blockcommit dockers10a vda --active --verbose --pivot virsh snapshot-delete dockers10a dockers10a rm /home/dockers10asnap.qcow2 fi I am fully aware that the third line from the end "virsh snapshot-delete ..." will fail under regular circumstances. It is just there as a precaution to delete unnecessary snapshots should a previous backup have failed. For some time, I am noticing that from time to time backup fails in the way that the xml definition file of the VM backed up keeps the temporary file (in the example above /home/dockers10asnap.qcow2) as the source file. Then, at least upon rebooting the host, it will be unable to restart the VM. In addition, lots of other troubles can arise (following backups failing, storage issues). I am using a similar setup on four hosts. It seems that the better the resources of the host are, the lower the likelihood of the problem occurring - but that cannot be an acceptable state. Can someone please point me to how to avoid this? Regards, Michael Schefczyk

2 2

[libvirt-users] Network without forward mode
by Vincent Bernat 28 Jul '16

28 Jul '16

Hey! Another question. The documentation about networks say: ╭─────┤ http://libvirt.org/formatnetwork.html#elementsConnect ├───── │Inclusion of the forward element indicates that the virtual network is │to be connected to the physical LAN.Since 0.3.0. The mode attribute │determines the method of forwarding. If there is no forward element, the │network will be isolated from any other network (unless a guest │connected to that network is acting as a router, of course). ╰───── That's exactly what I want: just a vnet interface, no bridge, no routing, no forwarding. However, if I create a network with just that: #v+ <network> <name>public</name> <uuid>4629ba54-9e33-4a1f-9e45-78a1c8faaddc</uuid> </network> #v- libvirt (2.0.0) adds a bridge stanza: #v+ <network> <name>public</name> <uuid>4629ba54-9e33-4a1f-9e45-78a1c8faaddc</uuid> <bridge name='virbr1' stp='on' delay='0'/> <mac address='52:54:00:15:45:da'/> </network> #v- The bridge is created. If I spawn a VM attached to this network, it gets added to the bridge. Any way to have a network where absolutely no setup is done? Thanks! -- Use the "telephone test" for readability. - The Elements of Programming Style (Kernighan & Plauger)

3 6

[libvirt-users] Routing isolated network
by Erwin Straver 28 Jul '16

28 Jul '16

I want to create a network like this: Internet -- physical router -- host (network 192.168.178.x) -- virtual machine dmz -- eth0 (connected to pyshical router) -- eth1 (connect to isolated network 10.0.0.x) -- virtual machine www - eth0 (connect to isolated network 10.0.0.x) [image: network design] <http://i.stack.imgur.com/QoCz9.png> I have a virtual host which is conntected to my physical router with eth0 and ip4 address 192.168.178.100. I create a virtual machine dmz which connects 'direct' to my router via my physical device eth0 on the virtual host: <network connections='1'> <name>direct</name> <uuid>379d4687-445e-4bc6-8354-b555c7f18b15</uuid> <forward dev='eth0' mode='bridge'> <interface dev='eth0' connections='1'/> </forward> </network> On my virtual machine i create a second nic eth1 which is connected on a virtual network virbr-local: <network> <name>local</name> <uuid>d31b2e0d-810b-4ba0-8ac4-02bc53746142</uuid> <bridge name='virbr-local' stp='on' delay='0'/> <mac address='52:54:00:92:06:5c'/> <domain name='local.box'/> <dns> <forwarder addr='192.168.178.1'/> </dns> <ip address='10.0.0.1' netmask='255.0.0.0'> <dhcp> <range start='10.0.0.100' end='10.0.0.255'/> <host mac='52:54:00:51:31:86' ip='10.0.0.30'/> </dhcp> </ip> <route address='10.0.0.0' prefix='8' gateway='10.0.0.30'/> </network> Now I want to create a second virtual machine which connects to the internet through the virtual machine dmz on the virbr-local subnet. Is there a way to accomplish this kind of setup? My routing table on the virtual host looks likes this: Destination Gateway Genmask Flags Metric Ref Use Iface default fritz.box 0.0.0.0 UG 0 0 0 eth0 10.0.0.0 * 255.0.0.0 U 0 0 0 virbr-local 10.0.0.0 10.0.0.30 255.0.0.0 UG 1 0 0 virbr-local 192.168.178.0 * 255.255.255.0 U 0 0 0 eth0 But when I want to ping an address from the www virtual machine I get a unreachable network message. I setup a DNAT om the virtual machine dmz. But looking witch tcpdump on eht1 there's no traffic.I appreciate some help to setup the network. I clearly missing something. Get a signature like this: Click here! <http://ws-promos.appspot.com/r?rdata=eyJydXJsIjogImh0dHA6Ly93d3cud2lzZXN0YW…>

2 1

Re: [libvirt-users] How can I run command in containers on the host?
by Daniel P. Berrange 26 Jul '16

26 Jul '16

On Tue, Jul 26, 2016 at 05:19:22PM +0800, John Y. wrote: > Hi Daniel, > > I forgot to tell you that I using mips64 fedora. Has any effect on this > case? > 2016-07-26 09:05:59.634+0000: 16406: debug : virDomainLxcEnterNamespace:131 > : dom=0xaaad4067c0, (VM: name=fedora2, > uuid=42b97e4d-54dc-41b4-b009-2321a1477a9a), nfdlist=0, fdlist=0xaaad4007c0, > noldfdlist=(nil), oldfdlist=(nil), flags=0 > libvirt: error : Expected at least one file descriptor > error: internal error: Child process (16406) unexpected exit status 125 This is shows nfdlist=0, whicih means that virDomainLxcOpenNamespace didn't provide any file descriptors. This in turn seems to suggest that /proc/$PID/ns didn't contain any files. Is this perhaps a misconfiguration of the mips kernel. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 0

[libvirt-users] How can I run command in containers on the host?
by John Y. 26 Jul '16

26 Jul '16

How can I run command in containers on the host? Just like the lxc command lxc-attach. I run : virsh -c lxc:/// lxc-enter-namespace fedora2 --noseclabel /bin/ls but get error: libvirt: error : Expected at least one file descriptor error: internal error: Child process (14930) unexpected exit status 125 Here is my libvirt.xml <domain type='lxc'> <name>fedora2</name> <memory>190000</memory> <vcpu>2</vcpu> <cputune> <shares>1000</shares> </cputune> <os> <features> <privnet/> <capabilities policy='allow'> </capabilities> </features> <type>exe</type> <init>/sbin/init</init> </os> <devices> <filesystem type="mount"> <source dir="/home/lxc-fedora"></source> <target dir="/"></target> </filesystem> <console type='pty'/> <interface type='bridge'> <mac address='52:54:00:e8:96:88'/> <source bridge='virbr0'/> <target dev='vnet0'/> <guest dev='eth0'/> </interface> </devices> </domain> version of libvirt: Compiled against library: libvirt 1.2.9 Using library: libvirt 1.2.9 Using API: QEMU 1.2.9 Running hypervisor: QEMU 2.1.2 Is there any mistake? Thanks, John

2 1

[libvirt-users] Blockpull behavior when interrupted
by Andrew Martin 25 Jul '16

25 Jul '16

Hello, I use snapshot-create-as followed by blockpull when creating external snapshots of VMs. This works well, however I am curious about the behavior of blockpull after an unexpected shutdown (or SIGKILL). If a blockpull is in progress and an unexpected power loss occurs, will the VM continue to reference the backing file for the parts of it that have not yet been copied? Or, will will the disk image no longer be usable? Thanks, Andrew

2 5

[libvirt-users] libvirtd terminates running instances after monitor's socket inode id is changed
by Gavin Nicholson 25 Jul '16

25 Jul '16

We accidentally moved /var/lib/libvirt/qemu to another directory which is on a different disk partition, then we moved it back; however, that caused changing the inode ids of the files inside /var/lib/libvirt/qemu including the socket files ( <instance>.monitor ) of the running VMs. The problem we are facing is that when libvirtd is restarted it terminates the running VMs with "error : qemuMonitorOpenUnix:315 : monitor socket did not show up.: Connection refused” We are trying to find a workaround so that when libvirtd is restarted it doesn’t stop the running VMs. We are running libvirt 0.9.13 Any help is appreciated. Thanks, Gavin

2 1

Re: [libvirt-users] [Qemu-devel] VFIO PCIe Extended Capabilities
by Spenser Gilliland 19 Jul '16

19 Jul '16

Hi Marcel, >> Indeed, if a device is attached to a PCI bus it makes no sense to advertise the extended configuration space. >> Can you please share the QEMU command line? Maybe is possible to make the device's bus PCIe in QEMU? Changing the following should make the tweak I proposed irrelevant. - device vfio-pci,host=03:00.0,id=hostdev0,bus=pci.2,addr=0x4 + device vfio-pci,host=03:00.0,id=hostdev0,bus=pcie.0,addr=0x4 Here's the full command for reference. 2016-07-19 18:42:22.110+0000: starting up libvirt version: 1.2.17, package: 13.el7 (CentOS BuildSystem <http://bugs.centos.org>, 2015-11-20-16:24:10, worker1.bsys.centos.org) qemu version: 2.3.0 (qemu-kvm-ev-2.3.0-31.el7_2.10.9) LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name instance-00000019 -S -machine pc-q35-rhel7.2.0,accel=kvm,usb=off -cpu Haswell-noTSX,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 8192 -realtime mlock=off -smp 8,sockets=8,cores=1,threads=1 -uuid 8b6865eb-2118-430e-a7e0-2989696576b1 -smbios type=1,manufacturer=Fedora Project,product=OpenStack Nova,version=13.1.0-1.el7,serial=a1068a93-24d1-4da2-8903-f9b8307fb0d8,uuid=8b6865eb-2118-430e-a7e0-2989696576b1,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-instance-00000019/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x1 -drive file=/var/lib/nova/instances/8b6865eb-2118-430e-a7e0-2989696576b1/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.2,addr=0x2,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/nova/instances/8b6865eb-2118-430e-a7e0-2989696576b1/disk.swap,if=none,id=drive-virtio-disk1,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.2,addr=0x3,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:9c:cf:60,bus=pci.2,addr=0x1 -chardev file,id=charserial0,path=/var/lib/nova/instances/8b6865eb-2118-430e-a7e0-2989696576b1/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pcie.0,addr=0x1 -device vfio-pci,host=03:00.0,id=hostdev0,bus=pci.2,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.2,addr=0x5 -msg timestamp=on char device redirected to /dev/pts/3 (label charserial1) It seems very reasonable to change the qemu command line. However, I'm using OpenStack Nova to launch the instance, which then uses libvirt, which finally uses qemu. So, the issues is very buried. > I think that any instance of a q35 machine where the assigned device is > placed on the conventional PCI bridge will create this scenario. It's > the default for attaching devices to a libvirt managed q35 VM AFAIK. > Yes, I discussed with Laine from libvirt the possibility to assign > devices to a PCIe port instead. Yes, I see this as the issue as well. The VM is being created by libvirt with the following xml. The problem is that the device is auto-assigned to the pci-bridge by default. <domain type="kvm"> <uuid>8b6865eb-2118-430e-a7e0-2989696576b1</uuid> <name>instance-00000019</name> <memory>8388608</memory> <vcpu>8</vcpu> ... <snip> ... <devices> ... <snip> ... <hostdev mode="subsystem" type="pci" managed="yes"> <source> <address bus="0x03" domain="0x0000" function="0x0" slot="0x00"/> </source> </hostdev> ... <snip> ... </devices> </domain> If I do a dumpxml I get the following <domain type="kvm"> <uuid>8b6865eb-2118-430e-a7e0-2989696576b1</uuid> <name>instance-00000019</name> <memory>8388608</memory> <vcpu>8</vcpu> ... <snip> ... <devices> ... <snip> ... <controller type='pci' index='0' model='pcie-root'> <alias name='pcie.0'/> </controller> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <alias name='pci.1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <alias name='pci.2'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </controller> <interface type='bridge'> ... <snip> ... <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> </hostdev> </devices> </domain> If I manually change the domain as follows <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> - <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </hostdev> I can reimport and the device and it attaches successfully to the pcie-root hub. The problem is I need to either manually specify this in nova or update the behavior of libvirt to auto assign pcie devices to pcie busses. This would involve reading pci configuration space to check if the device is a pcie devices. Then attaching to the pcie-root, if possible. >>> >>> In fact, I've tried to fix this multiple times: >>> >>> https://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05384.html >>> https://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg02422.html >>> https://lists.nongnu.org/archive/html/qemu-devel/2016-01/msg03259.html >>> >>> Yet the patch remains unapplied :( >> >> I thought is it in already. Maybe Michael can add it as part of the hard freeze. >> And if the patch will be applied, the tweak above wouldn't help, right Alex? > > The tweak Spenser suggested above should be unnecessary with my proposed > patch applied. > I think I finally understand this. The bus is not pcie -> we return > from vfio_add_ext_cap without "breaking" the extended capabilities > chain and the bare metal SR-IOV capability will be visible to guest. > With your patch the PCI bridge will "interfere" and mask the extended > configuration space completely. > Only now searching for that patch did I notice Michael's > comment hidden at the bottom of his reply, which I assume is why it > never got applied: > > https://patchwork.kernel.org/patch/8057411/ > > I just saw it too! It seems Michael wants to cache this info > in device instead of re-calculating it every time. >> Anyway, the current behavior is clearly a bug, so QEMU hard freeze >> should be irrelevant. If anyone wants to take over the patch, feel >> free. Thanks, > I suppose I can handle it, but sadly not for 2.7. > If Spencer has some time now he can help by testing it and reviewing it quickly :) I'd be happy to help; but that patch really just more permanently breaks my current workaround ;-) . Thanks, Spenser This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

2 2

[libvirt-users] Fwd: Please help see issue: conn.storageVolLookupByPath('/var/lib/xen/images/xen-pv-rhel5.9-x64-nolvm.img')
by Junqin Zhou 15 Jul '16

15 Jul '16

Hi all, Please see the attachment for vdsm.log details, thanks. Best Regards, juzhou. ----- Forwarded Message ----- > From: "Junqin Zhou" <juzhou(a)redhat.com> > To: libvirt-users(a)redhat.com > Cc: "Shahar Havivi" <shavivi(a)redhat.com>, "Tingting Zheng" <tzheng(a)redhat.com>, "Min Zhan" <mzhan(a)redhat.com>, "Ming > Xie" <mxie(a)redhat.com> > Sent: Wednesday, July 13, 2016 6:24:15 PM > Subject: Please help see issue: conn.storageVolLookupByPath('/var/lib/xen/images/xen-pv-rhel5.9-x64-nolvm.img') > > Hi guys, > While testing v2v integration to rhevm4.0, I met following error when import > virtual machine from xen server. > > I.rhevm4.0 prompt error message > Failed to communicate with the external provider, see log for additional > details > > Steps： > 1. In order to import VMs password-less SSH access has to be enabled between > VDSM host and the Xen host. The following steps needed to be done at the > VDSM host: > Refer to > https://github.com/oVirt/ovirt-site/blob/master/source/develop/release-mana… > > 2. Then login rhevm 4.0 and try to import virtual machine from Xen. > Virtual Machines-->Import-->Fill items on 'Import Virtual Machine(s)' window > with: > Data Center:xx > Source: Xen(via RHEL) > URI: xen+ssh://root@xxxxxx > Proxy Host: xxxxxx > > Result: > Step2 failed to load xen server's guests with error: > Failed to communicate with the external provider, see log for additional > details > > Part of vdsm.log > ... > jsonrpc.Executor/3::WARNING::2016-07-13 > 08:18:40,588::v2v::959::root::(_add_disks) Disk {'alias': > '/var/lib/xen/images/xen-pv-rhel5.9-x64-nolvm.img', 'type': 'disk', 'dev': > 'xvda'} has unsupported format: <built-in function format> > jsonrpc.Executor/3::ERROR::2016-07-13 > 08:18:41,504::v2v::923::root::(_add_disk_info) Error getting disk size > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 920, in > _add_disk_info > vol = conn.storageVolLookupByPath(disk['alias']) > File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4596, in > storageVolLookupByPath > if ret is None:raise libvirtError('virStorageVolLookupByPath() failed', > conn=self) > libvirtError: Storage volume not found: no storage vol with matching path > > Please help me check how to resolve this issue, thanks. > > > Best Regards, > juzhou. > > >

1 0

[libvirt-users] virt-login-shell: Security model none cannot be entered
by james＠lottspot.com 13 Jul '16

13 Jul '16

Hello! I am currently experimenting a bit with some of the LXC support under libvirt, and in trying to utilize the tool virt-login-shell, I encounter the following error: [james@lxchost ~]$ virt-login-shell libvirt: error : argument unsupported: Security model none cannot be entered Though it should be apparent from the lack of error, the domain is most definitely running. [root@lxchost ~]# virsh -c lxc:/// list Id Name State ---------------------------------------------------- 4909 james running Config information: [root@lxchost ~]# grep -vE '^(#|$)' /etc/libvirt/virt-login-shell.conf allowed_users = [ "*" ] OS information: [root@lxchost ~]# cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" Am I simply missing something here? Any tips or pointers are greatly appreciated!

3 2

[libvirt-users] nested vms and nested macvtaps
by jsl6uy js16uy 11 Jul '16

11 Jul '16

Hello all, hope all is well this maybe outside of libvirt-users.... Can you nest macvtap devices to ultimately receive a real routable ip on the nested vm? I have a nested vm up and running. Both vm and nested vm are centos 7 on arch linux host. The first vm uses a macvtap in bridge mode receives dhcp from an external dhcp server. I start the second vm and dhclient hangs and never receives an offer. I stood up a static interface on the nested vm. If I initiate a ping from within the nested vm, I can see via tcpdump that the echo request is seen on the non-nested vm and the hosting server. The reply comes back and stops/is answered on the hosting OS interface. rp_filter is off. No firewall rules in play blocking dhcp or icmp Any/all help appreciated thanks very much

2 5

[libvirt-users] lxc containers won't start in a f24 custom install - odd cgroup fs layout observed
by Thierry Parmentelat 10 Jul '16

10 Jul '16

Hi folks I use libvirt to programmatically spawn lxc containers I am facing an issue when migrating from fedora23 to fedora24 I use the stock kernel and libvirt version on both deployments, i.e.: f23: libvirt-1.2.18.3-2.fc23.x86_64 - kernel 4.5.7-202.fc23.x86_64 f24: libvirt-1.3.3.1-4.fc24.x86_64 - kernel 4.6.3-300.fc24.x86_64 First off, I need to outline that the host installation is done through some ad hoc procedure, as all this happens in the context of the centrally-managed PlanetLab global infrastructure I could not reproduce this problem on a host that is installed with the standard fedora install However I could use any clue that would point at a possible reason for this IMHO odd behaviour from libvirt, so that I can narrow down the potential flaws in my host installation procedure At first sight, it looks like the f24 deployment uses a different cgroup fs layout - see below and I suspect this could be the problem, but I am not aware of anything in my install. procedure that could cause that change, and as per this document https://libvirt.org/cgroups.html#systemdScope this change in the naming scheme looks odd - unless the doc is out of date of course So again, any clue is most welcome; many thanks in advance -- Thierry ------ All is fine with f23/libvirt-1.2.18.3-2.fc23.x86_64 However with f24/libvirt-1.3.3.1-4.fc24.x86_64 my lxc containers won't start and I am seeing this message in the libvirtd logfile 2016-07-09 11:52:33.416+0000: 3479: debug : virCgroupValidateMachineGroup:317 : Name 'lxc-3555-inrisl1.libvirt-lxc' for controller 'cpu' does not match 'inri_sl1', 'lxc-3555-inrisl1', 'inri_sl1.libvirt-lxc', '\ machine-lxc\x2dinri_sl1.scope' or 'machine-lxc\x2d3555\x2dinrisl1.scope' 2016-07-09 11:52:33.416+0000: 3479: debug : virCgroupNewDetectMachine:1501 : Failed to validate machine name for 'inri_sl1' driver 'lxc' 2016-07-09 11:52:33.416+0000: 3479: error : virLXCProcessStart:1501 : internal error: No valid cgroup for machine inri_sl1 At first it looked like the issue could be linked to the domain name having an underscore (example below uses inri_sl1 as a domain name) But trying with a regular name 'plain' without an underscore exhibits a similar issue ------------------------- Here's the set of files under /sys/fs/cgroup/memory that contains 'inri' in their name (other susbsytems have similar naming schemes in both cases) ========= f23 / libvirt-1.2.18.3-2.fc23.x86_64 (works fine) [root@vnode06 log]# cat /etc/fedora-release Fedora release 23 (Twenty Three) [root@vnode06 log]# uname -r 4.5.7-202.fc23.x86_64 [root@vnode06 log]# rpm -q libvirt libvirt-1.2.18.3-2.fc23.x86_64 [root@vnode06 log]# find /sys/fs/cgroup/memory/ -name '*inri*' /sys/fs/cgroup/memory/machine.slice/machine-lxc\x2dinri_sl1.scope ========= f24 / libvirt-1.3.3.1-4.fc24.x86_64 (container won't start) [root@vnode05 libvirt]# cat /etc/fedora-release Fedora release 24 (Twenty Four) [root@vnode05 libvirt]# uname -r 4.6.3-300.fc24.x86_64 [root@vnode05 libvirt]# rpm -q libvirt libvirt-1.3.3.1-4.fc24.x86_64 [root@vnode05 libvirt]# find /sys/fs/cgroup/memory/ -name '*inri*' /sys/fs/cgroup/memory/machine/lxc-3237-inrisl1.libvirt-lxc /sys/fs/cgroup/memory/machine/lxc-3555-inrisl1.libvirt-lxc /sys/fs/cgroup/memory/machine/lxc-2989-inrisl1.libvirt-lxc

1 1

[libvirt-users] vfio driver using libvirt
by abhishek jain 07 Jul '16

07 Jul '16

Hi Team I need to run vfio driver using qemu and I'm using below xml file for this.. <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>instance</name> <memory unit='KiB'>4194304</memory> <currentMemory unit='KiB'>4194304</currentMemory> <vcpu placement='static'>8</vcpu> <os> <type arch='aarch64' machine='virt'>hvm</type> <kernel>/home/root/Image</kernel> <initrd>/home/root/fsl-image-minimal-ls2085ardb.ext2.gz</initrd> <cmdline>'root=/dev/ram0 rw console=ttyAMA0,115200 rootwait earlyprintk ramdisk_size=1000000'</cmdline> </os> <cpu mode='custom' match='exact'> <model fallback='allow'>host</model> </cpu> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu-system-aarch64</emulator> <memballoon model='none'/> </devices> <qemu:commandline> <qemu:arg value='-mem-path'/> <qemu:arg value='/hugepages'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-fsl-mc,host=dprc.2'/> </qemu:commandline> </domain> I'm able to launch VM succesfully using the above xml file and it produces the below process running in the background.. *ps -ef | grep qemu* root 6767 1 34 22:11 ? 00:00:02 /usr/bin/qemu-system-aarch64 -name instance -S -machine virt,accel=kvm,usb=off -cpu host -m 4096 -realtime mlock=off -smp 8,sockets=8,cores=1,threads=1 -uuid 3b527012-c15d-46b3-862d-9a7fd3b04e01 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -kernel /home/root/Image -initrd /home/root/fsl-image-minimal-ls2085ardb.ext2.gz -append 'root=/dev/ram0 rw console=ttyAMA0,115200 rootwait earlyprintk ramdisk_size=1000000' -usb -mem-path /hugepages *-device vfio-fsl-mc,host=dprc.2* -msg timestamp=on Although the driver appears in the above process,actually that driver is not loaded as there is no output of cat /proc/interrupts | grep dpio on the host. However when I'm using the same command as that of the above process i.e .. /usr/bin/qemu-system-aarch64 -name instance -S -machine virt,accel=kvm,usb=off -cpu host -m 4096 -realtime mlock=off -smp 8,sockets=8,cores=1,threads=1 -uuid 3b527012-c15d-46b3-862d-9a7fd3b04e01 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -kernel /home/root/Image -initrd /home/root/fsl-image-minimal-ls2085ardb.ext2.gz -append 'root=/dev/ram0 rw console=ttyAMA0,115200 rootwait earlyprintk ramdisk_size=1000000' -usb -mem-path /hugepages *-device vfio-fsl-mc,host=dprc.2* -msg timestamp=on the driver is getting loaded and I'm able to see the output of cat /proc/interrupts | grep dpio on the host. Please help me regarding this. Thanks Abhishek Jain

1 0

[libvirt-users] Permanently change default virsh editor
by J Travis Lindsey 07 Jul '16

07 Jul '16

Hello, I found in the docs that I can change the editor I use on a per vm bases with the following: *EDITOR=$your-favorite-editor virsh edit $your-vm-name* But how do I change it permanently so when I run: *virsh edit $your-vm-name* It defaults to my favorite editor (vim)? Ref: http://wiki.libvirt.org/page/FAQ

4 4

[libvirt-users] Backups failing due to snapshot already exists
by Phill Edwards 06 Jul '16

06 Jul '16

My VMs are raw disk images as logical volumes. My backup script takes a snapshot of a VM's volume, copies it off to another machine and then deletes the snapshot. For some reason I have a snapshot that didn't delete which is now preventing the backups from proceeding: ... Friday 1 July 02:10:01 AEST 2016: Taking snapshot of /dev/vms-lvm/MBE3-MythUbu-14.04-64bit.raw... ERR: The specified snapshot volume /dev/vms-lvm/MBE3-MythUbu-14.04-64bit.snap already exists. Operation canceled. ... But if I try to remove the snapshot volume I get an error that it's in use: $ sudo lvremove /dev/vms-lvm/MBE3-MythUbu-14.04-64bit.snap Logical volume vms-lvm/MBE3-MythUbu-14.04-64bit.snap in use. Can anyone please advise on how I find out what's using the snapshot, then kill that process so I can remove the snapshot so my backups can work again?

1 0

[libvirt-users] Virtual machine in state "in shutdown"
by Roland Everaert 06 Jul '16

06 Jul '16

Hello, We are currently facing a strange situation. One of our VM is shown by 'virsh list' as in state "in shutdown" but there is no more a qemu-kvm process linked to it. So we have a few questions: 1. What does means the state in shutdown (I have not found much information about it)? 2. How to cleanly "shutdown" the vm, or more correctly, clean the status in virsh/libvirt? Regards, Roland Everaert.

2 4

[libvirt-users] Problem in bridged networking
by Aditya Gupta 06 Jul '16

06 Jul '16

Hello, I am facing some problems in bridged networking. I have successfully created a bridge br0 and added a virtual machine to it. Now the address of virtual machine is 10.1.3.31. I am able to connect to this virtual machine by another computer on same network. The virtual machine is hosting a simple python http server on port 8000, while some other service is running on port 80 When I try his on my main server : # curl 10.1.3.31:80 Response I get is this : * Rebuilt URL to: 10.1.3.31:80/ * Hostname was NOT found in DNS cache * Trying 10.1.3.31... * Connected to 10.1.3.31 (10.1.3.31) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.35.0 > Host: 10.1.3.31 > Accept: */* > * Recv failure: Connection reset by peer * Closing connection 0 curl: (56) Recv failure: Connection reset by peer But when I try this on any other port # curl 10.1.3.31:8000 Response I get is this: * Rebuilt URL to: 10.1.3.31:8000/ * Hostname was NOT found in DNS cache * Trying 10.1.3.31... * connect to 10.1.3.31 port 8000 failed: Connection timed out * Failed to connect to 10.1.3.31 port 8000: Connection timed out * Closing connection 0 curl: (7) Failed to connect to 10.1.3.31 port 8000: Connection timed out Output of iptables -L: Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:ftp ACCEPT tcp -- anywhere anywhere tcp dpt:8000 ACCEPT tcp -- anywhere anywhere tcp dpt:1022 Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere 10.0.0.0/16 state RELATED,ESTABLISHED ACCEPT tcp -- anywhere 10.0.2.4 tcp dpt:http-alt ACCEPT tcp -- anywhere 10.0.2.4 tcp dpt:1883 ACCEPT tcp -- anywhere 10.0.2.4 tcp dpt:1883 TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU Chain OUTPUT (policy ACCEPT) target prot opt source destination Output of ifconfig: br0 Link encap:Ethernet HWaddr 00:1a:64:c1:31:2e inet addr:10.1.3.33 Bcast:10.1.3.255 Mask:255.255.255.0 inet6 addr: fe80::21a:64ff:fec1:312e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1578351 errors:0 dropped:15619 overruns:0 frame:0 TX packets:1327458 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:198829729 (198.8 MB) TX bytes:346380435 (346.3 MB) eth1 Link encap:Ethernet HWaddr 00:1a:64:c1:31:2e UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7429105 errors:0 dropped:31238 overruns:0 frame:0 TX packets:7684361 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:782334104 (782.3 MB) TX bytes:2221485458 (2.2 GB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:87278 errors:0 dropped:0 overruns:0 frame:0 TX packets:87278 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:12350508 (12.3 MB) TX bytes:12350508 (12.3 MB) vnet0 Link encap:Ethernet HWaddr fe:54:00:14:0e:98 inet6 addr: fe80::fc54:ff:fe14:e98/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6411332 errors:0 dropped:0 overruns:0 frame:0 TX packets:6277721 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:1909595770 (1.9 GB) TX bytes:656284846 (656.2 MB) Output of cat /etc/network/interfaces : auto lo iface lo inet loopback auto eth1 iface eth1 inet static address 10.1.3.33 netmask 255.255.255.0 gateway 10.1.3.1 dns-nameservers 192.168.2.11 192.168.2.12 auto br0 iface br0 inet static address 10.1.3.33 netmask 255.255.255.0 gateway 10.1.3.1 dns-nameservers 192.168.2.11 192.168.2.12 bridge_ports eth1 bridge_stp off bridge_maxwait 5 dns-nameservers 192.168.2.11 192.168.2.12

2 1

[libvirt-users] virsh channel
by Tadas 04 Jul '16

04 Jul '16

Hello, Is there any command to list all available channels for specific machine? For example, i have a additional spice serial device: <channel type='unix'> <source mode='bind'/> <target type='virtio' name='com.redhat.kvm-vdi.0'/> <address type='virtio-serial' controller='0' bus='0' port='2'/> </channel> Is there any way to get full path to this socket on hypervisor side?

3 4

[libvirt-users] problem with dnsmasq and dhclient - loosing IP address after a while
by Patrick Pichon 01 Jul '16

01 Jul '16

Hello, I have a problem which is that some of my VMs are loosing there IP addresses from time to time. What I saw in the log is when this VM loose its IP address there are DHCPREQUEST send from the VM by dhclient and the server responded only 50 minutes later ! Any help, advise on how to debug would be welcome. Thanks in advance Patrick Here after is an extract from the log July 1st 2016, 05:08:46.156 zen.pipiche.net <http://zen.pipiche.net/> dnsmasq-dhcp DHCPREQUEST(virbr1) 10.10.0.10 52:54:10:7d:3a:3f 10.10.0.10 July 1st 2016, 05:08:46.156 zen.pipiche.net <http://zen.pipiche.net/> dnsmasq-dhcp DHCPACK(virbr1) 10.10.0.10 52:54:10:7d:3a:3f mail 10.10.0.10 July 1st 2016, 05:08:32.003 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:08:18.274 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:08:03.793 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:07:54.504 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:07:40.642 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:07:22.978 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:07:04.180 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:06:45.233 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:06:30.417 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:06:15.304 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:06:02.203 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:05:55.780 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:05:38.227 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:05:27.970 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:05:15.183 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:05:04.425 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:04:56.008 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:04:39.227 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:04:24.531 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:04:10.306 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:03:56.149 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:03:45.917 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:03:34.480 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:03:24.189 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:03:07.038 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:02:51.557 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:02:40.088 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:02:29.963 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:02:11.446 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:01:53.245 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:01:32.646 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:01:23.725 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:01:12.691 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:00:53.537 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:00:32.797 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:00:18.520 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 05:00:11.831 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:59:53.649 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:59:45.510 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:59:38.236 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:59:18.089 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:58:59.930 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:58:52.521 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:58:37.193 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:58:18.742 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:58:05.088 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:57:53.879 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:57:36.308 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:57:16.716 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:57:07.594 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:56:54.607 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:56:34.286 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:56:24.307 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:56:10.593 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:55:56.460 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:55:37.165 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:55:28.171 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:55:18.719 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:55:01.360 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:54:44.150 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:54:37.490 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:54:26.746 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:54:12.103 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:53:54.381 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:53:42.322 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:53:30.937 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:53:14.144 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:52:55.999 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:52:47.948 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:52:39.143 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:52:28.188 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:52:07.857 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:51:53.381 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:51:39.750 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:51:27.260 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:51:06.864 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:50:53.216 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:50:36.366 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:50:27.696 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:50:07.898 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:49:46.721 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:49:37.941 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:49:27.940 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:49:17.156 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:18:02.398 mail.pipiche.net <http://mail.pipiche.net/> dhclient bound to 10.10.0.10 -- renewal in 1614 seconds. 10.10.0.10 July 1st 2016, 04:18:02.260 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPACK from 10.10.0.1 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 04:18:02.260 zen.pipiche.net <http://zen.pipiche.net/> dnsmasq-dhcp DHCPACK(virbr1) 10.10.0.10 52:54:10:7d:3a:3f mail 10.10.0.10 July 1st 2016, 03:55:03.644 mail.pipiche.net <http://mail.pipiche.net/> dhclient bound to 10.10.0.10 -- renewal in 1379 seconds. 10.10.0.10 July 1st 2016, 03:55:02.777 zen.pipiche.net <http://zen.pipiche.net/> dnsmasq-dhcp DHCPREQUEST(virbr1) 10.10.0.10 52:54:10:7d:3a:3f 10.10.0.10 July 1st 2016, 03:55:02.777 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPACK from 10.10.0.1 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 03:55:02.777 zen.pipiche.net <http://zen.pipiche.net/> dnsmasq-dhcp DHCPACK(virbr1) 10.10.0.10 52:54:10:7d:3a:3f mail 10.10.0.10 July 1st 2016, 03:55:02.776 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 03:31:20.065 mail.pipiche.net <http://mail.pipiche.net/> dhclient bound to 10.10.0.10 -- renewal in 1422 seconds. 10.10.0.10 July 1st 2016, 03:31:16.303 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPACK from 10.10.0.1 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 03:31:16.225 zen.pipiche.net <http://zen.pipiche.net/> dnsmasq-dhcp DHCPREQUEST(virbr1) 10.10.0.10 52:54:10:7d:3a:3f 10.10.0.10 July 1st 2016, 03:31:16.225 mail.pipiche.net <http://mail.pipiche.net/> dhclient DHCPREQUEST on eth0 to 10.10.0.1 port 67 (xid=0x3d60085a) 10.10.0.1 July 1st 2016, 03:31:16.225 zen.pipiche.net <http://zen.pipiche.net/> dnsmasq-dhcp DHCPACK(virbr1) 10.10.0.10 52:54:10:7d:3a:3f mail 10.10.0.10 My setup is as followed - Fedora 24 / Kernel 4.5.7 libvirt-daemon-driver-qemu-1.3.3.1-4.fc24.x86_64 libvirt-daemon-driver-nodedev-1.3.3.1-4.fc24.x86_64 libvirt-daemon-driver-secret-1.3.3.1-4.fc24.x86_64 libvirt-daemon-1.3.3.1-4.fc24.x86_64 libvirt-daemon-driver-storage-1.3.3.1-4.fc24.x86_64 libvirt-daemon-kvm-1.3.3.1-4.fc24.x86_64 libvirt-client-1.3.3.1-4.fc24.x86_64 libvirt-daemon-driver-interface-1.3.3.1-4.fc24.x86_64 libvirt-daemon-driver-nwfilter-1.3.3.1-4.fc24.x86_64 libvirt-daemon-config-network-1.3.3.1-4.fc24.x86_64 libvirt-daemon-driver-network-1.3.3.1-4.fc24.x86_64 libvirt-daemon-config-nwfilter-1.3.3.1-4.fc24.x86_64 - dnsmasq / 2.75-4 - Setup Network - hypervisor side. There is a bridge configuration, as I have one VM listening to the Internet as well. ifconfig br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 net my ip address netmask 255.255.255.0 broadcast my ip address inet6 fe80::d6ae:52ff:fec7:6694 prefixlen 64 scopeid 0x20<link> ether d4:ae:52:c7:66:94 txqueuelen 1000 (Ethernet) RX packets 1395299 bytes 291328394 (277.8 MiB) RX errors 0 dropped 66 overruns 0 frame 0 TX packets 629001 bytes 777811458 (741.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 inet6 fe80::d6ae:52ff:fec7:6694 prefixlen 64 scopeid 0x20<link> ether d4:ae:52:c7:66:94 txqueuelen 1000 (Ethernet) RX packets 7254272 bytes 2658859144 (2.4 GiB) RX errors 0 dropped 4923 overruns 0 frame 0 TX packets 7302074 bytes 6556766298 (6.1 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 sudo iptables-save [sudo] password for support: # Generated by iptables-save v1.4.21 on Fri Jul 1 10:50:45 2016 *mangle :PREROUTING ACCEPT [313661:46683942] :INPUT ACCEPT [312868:46455263] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [204754:109339610] :POSTROUTING ACCEPT [204754:109339610] -A POSTROUTING -o virbr1 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill COMMIT # Completed on Fri Jul 1 10:50:45 2016 # Generated by iptables-save v1.4.21 on Fri Jul 1 10:50:45 2016 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [204361:109206834] -A INPUT -i virbr1 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i virbr1 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT -A INPUT -i br0 -m set --match-set banned src -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i br0 -p tcp -m state --state NEW -m tcp --dport 23 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -i virbr1 -o virbr1 -j ACCEPT -A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT -A FORWARD -m set --match-set banned src -j DROP -A FORWARD -j REJECT --reject-with icmp-host-prohibited -A OUTPUT -o virbr1 -p udp -m udp --dport 68 -j ACCEPT COMMIT # Completed on Fri Jul 1 10:50:45 2016 <network> <name>prd-private-lan</name> <uuid>255083f4-05a1-4a24-bc66-d3a3a9ab0724</uuid> <bridge name='virbr1' stp='off' delay='0'/> <mac address='52:54:00:08:1e:d8'/> <domain name='prd.pipiche.net <http://prd.pipiche.net/>'/> <dns> <forwarder addr='8.8.4.4'/> <forwarder addr='8.8.8.8'/> </dns> <ip address='10.10.0.1' netmask='255.255.255.0'> <dhcp> <range start='10.10.0.128' end='10.10.0.254'/> <host mac='52:54:10:b6:35:ca' name='svc.prd.pipiche.net <http://svc.prd.pipiche.net/>' ip='10.10.0.3'/> <host mac='52:54:10:32:88:ac' name='admin.prd.pipiche.net <http://admin.prd.pipiche.net/>' ip='10.10.0.5'/> <host mac='52:54:10:5f:92:05' name='frontend.prd.pipiche.net <http://frontend.prd.pipiche.net/>' ip='10.10.0.7'/> <host mac='52:54:10:7d:3a:3f' name='mail.prd.pipiche.net <http://mail.prd.pipiche.net/>' ip='10.10.0.10'/> <host mac='52:54:10:30:93:56' name='blog.prd.pipiche.net <http://blog.prd.pipiche.net/>' ip='10.10.0.21'/> <host mac='52:54:10:78:c1:c2' name='cloud.prd.pipiche.net <http://cloud.prd.pipiche.net/>' ip='10.10.0.22'/> <host mac='52:54:10:64:00:21' name='web.prd.pipiche.net <http://web.prd.pipiche.net/>' ip='10.10.0.25'/> <host mac='52:54:10:5a:5f:63' name='dcroche.prd.pipiche.net <http://dcroche.prd.pipiche.net/>' ip='10.10.0.26'/> <host mac='52:54:10:4c:b2:61' name='trac.prd.pipiche.net <http://trac.prd.pipiche.net/>' ip='10.10.0.27'/> <host mac='52:54:10:62:de:5f' name='git.prd.pipiche.net <http://git.prd.pipiche.net/>' ip='10.10.0.62'/> </dhcp> </ip> </network> On the VM side, I’m using NetworkManager ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.10.0.10 netmask 255.255.255.0 broadcast 10.10.0.255 inet6 fe80::5054:10ff:fe7d:3a3f prefixlen 64 scopeid 0x20<link> ether 52:54:10:7d:3a:3f txqueuelen 1000 (Ethernet) RX packets 1368559 bytes 304901897 (290.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1219893 bytes 2157040102 (2.0 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0 # Generated by dracut initrd HWADDR="52:54:10:7d:3a:3f" DEVICE="eth0" NAME="eth0" ONBOOT=yes NETBOOT=yes IPV6INIT=no BOOTPROTO=dhcp TYPE=Ethernet DNS1=10.10.0.1 DNS2=8.8.8.8 DNS3=8.8.4.4

1 0