6:45 p.m.
I am running KVM virtualization with libvirtd (libvirt) 0.10.2 in bridged
network mode, however I still have the default virtual network
bridge/interfaces and dnsmasq on the host. What I am trying to understand
is whether or not dnsmasq and the virtual network (*virbr0, Vnet0 and Vnet1*)
still play any role. If not, can I remove them?
On most virtual hosts I see they are left around even when a network bridge
has been manually setup and the default virtual network bridge/interfaces
and dnsmasq are not serve any purpose.
Thanks
Mimi
[bigfoot@localhost ~]$ ifconfig
br0 Link encap:Ethernet HWaddr E2:59:52:12:34:4C
inet addr:135.17.1XX.XX Bcast:135.17.1XX.XX Mask:255.255.255.128
inet6 addr: fe80::ea39:35ff:fe12:948e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:564577 errors:0 dropped:0 overruns:0 frame:0
TX packets:303315 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:566465184 (540.2 MiB) TX bytes:83532692 (79.6 MiB)
eth0 Link encap:Ethernet HWaddr E2:59:52:12:34:4C
inet6 addr: fe80::ea39:35ff:fe12:948e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:806142 errors:0 dropped:0 overruns:0 frame:0
TX packets:450977 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:711888772 (678.9 MiB) TX bytes:175377460 (167.2 MiB)
Interrupt:28 Memory:f7100000-f7120000
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:16436 Metric:1
RX packets:276793 errors:0 dropped:0 overruns:0 frame:0
TX packets:276793 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:551259266 (525.7 MiB) TX bytes:551259266 (525.7 MiB)
*virbr0 Link encap:Ethernet HWaddr 52:54:00:2A:1B:AF*
* inet addr:192.168.122.1 Bcast:192.168.122.255
Mask:255.255.255.0*
* UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1*
* RX packets:0 errors:0 dropped:0 overruns:0 frame:0*
* TX packets:0 errors:0 dropped:0 overruns:0 carrier:0*
* collisions:0 txqueuelen:0*
* RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)*
*vnet0 Link encap:Ethernet HWaddr FE:54:00:A0:8D:50*
* inet6 addr: fe80::fc54:ff:fea0:8d50/64 Scope:Link*
* UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1*
* RX packets:124812 errors:0 dropped:0 overruns:0 frame:0*
* TX packets:343055 errors:0 dropped:0 overruns:0 carrier:0*
* collisions:0 txqueuelen:500*
* RX bytes:55075362 (52.5 MiB) TX bytes:138488556 (132.0 MiB)*
*vnet1 Link encap:Ethernet HWaddr FE:54:00:71:A8:78*
* inet6 addr: fe80::fc54:ff:fe71:a878/64 Scope:Link*
* UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1*
* RX packets:17834 errors:0 dropped:0 overruns:0 frame:0*
* TX packets:318816 errors:0 dropped:0 overruns:1 carrier:0*
* collisions:0 txqueuelen:500*
* RX bytes:2279102 (2.1 MiB) TX bytes:20534286 (19.5 MiB)*
[bigfoot@localhost ~]$
8:12 p.m.
On 24.04.2015 12:45, mimicafe(a)gmail.com wrote:
I am running KVM virtualization with libvirtd (libvirt) 0.10.2 in
bridged
network mode, however I still have the default virtual network
bridge/interfaces and dnsmasq on the host. What I am trying to understand
is whether or not dnsmasq and the virtual network (*virbr0, Vnet0 and Vnet1*)
still play any role. If not, can I remove them?
Yes, you can safely remove libvirt-daemon-config-network package. It
should disable the default network. However, dropping dnsmasq is a bit
harder, since libivirt-daemon-driver-network depends on it. We can't
know whether you will not someday like a NATed network with a DHCP
server, even though now you don't. However,
libvirt-daemon-driver-network takes care about all the network types
known to libvirt, so you can't really drop it (unless forcibly removing
the package and let the libvirt just deal with it, which I'd discourage
you from doing anyway).
Michal
11:08 p.m.
HI Michal
Thank you for explaining. I have this situation in a number of production
servers where we would always use static IPs for the host and VMs. In such
case we have no requirement for NATed network in the future. And we we
ever do, we can rely on a DHCP server within the LAN to provide IPs to the
VMs.
I'll look to remove both libivirt-daemon-driver-network,
libvirt-daemon-driver-network
and dnsmasq.
Any further thought from your side?
On 24 April 2015 at 13:12, Michal Privoznik <mprivozn(a)redhat.com> wrote:
On 24.04.2015 12:45, mimicafe(a)gmail.com wrote:
> I am running KVM virtualization with libvirtd (libvirt) 0.10.2 in
bridged
> network mode, however I still have the default virtual network
> bridge/interfaces and dnsmasq on the host. What I am trying to understand
> is whether or not dnsmasq and the virtual network (*virbr0, Vnet0 and
Vnet1*)
> still play any role. If not, can I remove them?
Yes, you can safely remove libvirt-daemon-config-network package. It
should disable the default network. However, dropping dnsmasq is a bit
harder, since libivirt-daemon-driver-network depends on it. We can't
know whether you will not someday like a NATed network with a DHCP
server, even though now you don't. However,
libvirt-daemon-driver-network takes care about all the network types
known to libvirt, so you can't really drop it (unless forcibly removing
the package and let the libvirt just deal with it, which I'd discourage
you from doing anyway).
Michal
1 a.m.
(in before Eric for this :-) Please don't top-post in responses on this
list (or most other technical lists). Posting your responses in the
context of the previous message makes it much easier for followups that
want to respond to points from several messages at once (and also makes
it easier to understand the discussion by reading just one of those
messages).
On 04/24/2015 11:08 AM, mimicafe(a)gmail.com wrote:
HI Michal
Thank you for explaining. I have this situation in a number of
production servers where we would always use static IPs for the host
and VMs. In such case we have no requirement for NATed network in the
future. And we we ever do, we can rely on a DHCP server within the LAN
to provide IPs to the VMs.
I'll look to remove
both libivirt-daemon-driver-network, libvirt-daemon-driver-network
and dnsmasq.
You can't remove libvirt-daemon-driver-network, as
libvirt-daemon-driver-qemu is dependent on it (for very good reasons).
If you try to do this, you will almost surely end up with a crashing
libvirtd.
Any further thought from your side?
On 24 April 2015 at 13:12, Michal Privoznik <mprivozn(a)redhat.com
<mailto:mprivozn@redhat.com>> wrote:
On 24.04.2015 12 <tel:24.04.2015%2012>:45, mimicafe(a)gmail.com
<mailto:mimicafe@gmail.com> wrote:
> I am running KVM virtualization with libvirtd (libvirt) 0.10.2
in bridged
> network mode, however I still have the default virtual network
> bridge/interfaces and dnsmasq on the host. What I am trying to
understand
> is whether or not dnsmasq and the virtual network (*virbr0,
Vnet0 and Vnet1*)
> still play any role. If not, can I remove them?
You are mixing together a couple differnet (but related) things. virbr0
is a bridge device created for libvirt's "default" virtual network, and
the dnsmasq instance that is running is also run by libvirt for that
network. However, the vnet0 and vnet1 devices are tap devices; one of
these is created for each domain interface, whether you use libvirt's
network or you connect to a host bridge that you've configured yourself
- you can't eliminate those devices.
Yes, you can safely remove libvirt-daemon-config-network package. It
should disable the default network.
Actually that won't disable any already-installed default network.
You'll need to do this:
virsh net-destroy default
virsh net-undefine default
Once you've done this, the virbr0 device will no longer appear, and
dnsmasq will not be run (although the binary will still be present on
the disk).
However, dropping dnsmasq is a bit
harder, since libivirt-daemon-driver-network depends on it. We can't
know whether you will not someday like a NATed network with a DHCP
server, even though now you don't. However,
libvirt-daemon-driver-network takes care about all the network types
known to libvirt, so you can't really drop it (unless forcibly
removing
the package and let the libvirt just deal with it, which I'd
discourage
you from doing anyway).
That's not going to work. There are things in the network driver other
than just libvirt's virtual networks, and qemu isn't setup to deal with
the network driver not being present.
2:12 a.m.
On 24 April 2015 at 18:00, Laine Stump <laine(a)laine.org> wrote:
(in before Eric for this :-) Please don't top-post in responses
on this
list (or most other technical lists). Posting your responses in the context
of the previous message makes it much easier for followups that want to
respond to points from several messages at once (and also makes it easier
to understand the discussion by reading just one of those messages).
On 04/24/2015 11:08 AM, mimicafe(a)gmail.com wrote:
HI Michal
Thank you for explaining. I have this situation in a number of
production servers where we would always use static IPs for the host and
VMs. In such case we have no requirement for NATed network in the future.
And we we ever do, we can rely on a DHCP server within the LAN to provide
IPs to the VMs.
I'll look to remove both libivirt-daemon-driver-network,
libvirt-daemon-driver-network
and dnsmasq.
You can't remove libvirt-daemon-driver-network, as
libvirt-daemon-driver-qemu is dependent on it (for very good reasons). If
you try to do this, you will almost surely end up with a crashing libvirtd.
Any further thought from your side?
On 24 April 2015 at 13:12, Michal Privoznik <mprivozn(a)redhat.com> wrote:
> On 24.04.2015 12 <24.04.2015%2012>:45, mimicafe(a)gmail.com wrote:
> > I am running KVM virtualization with libvirtd (libvirt) 0.10.2 in
> bridged
> > network mode, however I still have the default virtual network
> > bridge/interfaces and dnsmasq on the host. What I am trying to
> understand
> > is whether or not dnsmasq and the virtual network (*virbr0, Vnet0 and
> Vnet1*)
> > still play any role. If not, can I remove them?
>
You are mixing together a couple differnet (but related) things. virbr0 is
a bridge device created for libvirt's "default" virtual network, and the
dnsmasq instance that is running is also run by libvirt for that network.
However, the vnet0 and vnet1 devices are tap devices; one of these is
created for each domain interface, whether you use libvirt's network or you
connect to a host bridge that you've configured yourself - you can't
eliminate those devices.
> Yes, you can safely remove libvirt-daemon-config-network package. It
> should disable the default network.
Actually that won't disable any already-installed default network. You'll
need to do this:
virsh net-destroy default
virsh net-undefine default
Once you've done this, the virbr0 device will no longer appear, and
dnsmasq will not be run (although the binary will still be present on the
disk).
However, dropping dnsmasq is a bit
> harder, since libivirt-daemon-driver-network depends on it. We can't
> know whether you will not someday like a NATed network with a DHCP
> server, even though now you don't. However,
> libvirt-daemon-driver-network takes care about all the network types
> known to libvirt, so you can't really drop it (unless forcibly removing
> the package and let the libvirt just deal with it, which I'd discourage
> you from doing anyway).
>
That's not going to work. There are things in the network driver other
than just libvirt's virtual networks, and qemu isn't setup to deal with the
network driver not being present.
The problem of top-posting is from the way reply is composed within
Gmail.
I'll watch out next time.
Thanks
Mimi
2:02 a.m.
On Centos 6.5 both packages cannot be identified. any idea?
sudo yum search libivirt-daemon-driver-network
libvirt-daemon-config-network
[sudo] password for bigfoot:
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* base: www.mirrorservice.org
* extras: centos.openitc.uk
* updates: mirror.mhd.uk.as44574.net
Warning: No matches found for: libivirt-daemon-driver-network
Warning: No matches found for: libvirt-daemon-config-network
No Matches found
[bigfoot@localhost ~]$ sudo yum whatprovide libivirt-daemon-driver-network
libvirt-daemon-config-network
Loaded plugins: fastestmirror, refresh-packagekit, security
No such command: whatprovide. Please use /usr/bin/yum --help
[bigfoot@localhost ~]$ sudo yum whatprovides libivirt-daemon-driver-network
libvirt-daemon-config-network
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
* base: www.mirrorservice.org
* extras: centos.openitc.uk
* updates: mirror.mhd.uk.as44574.net
Warning: 3.0.x versions of yum would erroneously match against filenames.
You can use "*/libivirt-daemon-driver-network" and/or
"*bin/libivirt-daemon-driver-network" to get that behaviour
Warning: 3.0.x versions of yum would erroneously match against filenames.
You can use "*/libvirt-daemon-config-network" and/or
"*bin/libvirt-daemon-config-network" to get that behaviour
No Matches found
[bigfoot@localhost ~]$ sudo rpm -qa | egrep -i
'libivirt-daemon-driver-network|libvirt-daemon-config-network'
[bigfoot@localhost ~]$
[bigfoot@localhost ~]$ yum groupinfo "Virtualization Tools"
"Virtualization
Platform"
Loaded plugins: fastestmirror, refresh-packagekit, security
Setting up Group Process
Loading mirror speeds from cached hostfile
* base: mirror.sov.uk.goscomb.net
* extras: centos.serverspace.co.uk
* updates: centos.serverspace.co.uk
Group: Virtualization Tools
Description: Tools for offline virtual image management.
Default Packages:
libguestfs
Optional Packages:
libguestfs-bash-completion
libguestfs-gfs2
libguestfs-java
libguestfs-mount
libguestfs-rescue
libguestfs-rsync
libguestfs-tools
libguestfs-xfs
virt-v2v
Group: Virtualization Platform
Description: Provides an interface for accessing and controlling
virtualized guests and containers.
Mandatory Packages:
libvirt
libvirt-client
virt-who
Optional Packages:
fence-virtd-libvirt
fence-virtd-multicast
fence-virtd-serial
libvirt-cim
libvirt-java
libvirt-qmf
libvirt-snmp
perl-Sys-Virt
[bigfoot@localhost ~]$ sudo rpm -qa |grep libvirt*
[sudo] password for bigfoot:
Sorry, try again.
[sudo] password for bigfoot:
libvirt-java-javadoc-0.4.9-1.el6.noarch
libvirt-lock-sanlock-0.10.2-46.el6_6.3.x86_64
libvirt-java-0.4.9-1.el6.noarch
libvirt-snmp-0.0.2-4.el6.x86_64
libvirt-python-0.10.2-46.el6_6.3.x86_64
libvirt-java-devel-0.4.9-1.el6.noarch
libvirt-0.10.2-46.el6_6.3.x86_64
libvirt-cim-0.6.1-12.el6.x86_64
libvirt-client-0.10.2-46.el6_6.3.x86_64
libvirt-devel-0.10.2-46.el6_6.3.x86_64
Mimi
On 24 April 2015 at 16:08, mimicafe(a)gmail.com <mimicafe(a)gmail.com> wrote:
HI Michal
Thank you for explaining. I have this situation in a number of production
servers where we would always use static IPs for the host and VMs. In such
case we have no requirement for NATed network in the future. And we we
ever do, we can rely on a DHCP server within the LAN to provide IPs to the
VMs.
I'll look to remove both libivirt-daemon-driver-network,
libvirt-daemon-driver-network
and dnsmasq.
Any further thought from your side?
On 24 April 2015 at 13:12, Michal Privoznik <mprivozn(a)redhat.com> wrote:
> On 24.04.2015 12:45, mimicafe(a)gmail.com wrote:
> > I am running KVM virtualization with libvirtd (libvirt) 0.10.2 in
> bridged
> > network mode, however I still have the default virtual network
> > bridge/interfaces and dnsmasq on the host. What I am trying to
> understand
> > is whether or not dnsmasq and the virtual network (*virbr0, Vnet0 and
> Vnet1*)
> > still play any role. If not, can I remove them?
>
> Yes, you can safely remove libvirt-daemon-config-network package. It
> should disable the default network. However, dropping dnsmasq is a bit
> harder, since libivirt-daemon-driver-network depends on it. We can't
> know whether you will not someday like a NATed network with a DHCP
> server, even though now you don't. However,
> libvirt-daemon-driver-network takes care about all the network types
> known to libvirt, so you can't really drop it (unless forcibly removing
> the package and let the libvirt just deal with it, which I'd discourage
> you from doing anyway).
>
> Michal
>
3:47 a.m.
On 04/24/2015 02:02 PM, mimicafe(a)gmail.com wrote:
On Centos 6.5 both packages cannot be identified. any idea?
Yes. CentS 6 uses libvirt-0.10.2 + a ton of backported patches. The
splitting of libvirt into a bunch of smaller subpackages so that admins
could more easily tailor what was installed on their systems happened
[sometime after that, not motivated to look up the exact version right
now]. In order to maintain as much stability as possible, the patches
that made that split have not been backported to the CentOS6/RHEL6
version of libvirt. Instead, there are just the following packages:
libvirt
libvirt-client
libvirt-debuginfo
libvirt-devel
libvirt-lock-sanlock
libvirt-python
At any rate, you can simply net-destroy and net-undefine the default
network and you will no longer be troubled by them. You don't need to
remove any packages.
4:06 a.m.
On 24 April 2015 at 20:47, Laine Stump <laine(a)laine.org> wrote:
On 04/24/2015 02:02 PM, mimicafe(a)gmail.com wrote:
> On Centos 6.5 both packages cannot be identified. any idea?
>
>
Yes. CentS 6 uses libvirt-0.10.2 + a ton of backported patches. The
splitting of libvirt into a bunch of smaller subpackages so that admins
could more easily tailor what was installed on their systems happened
[sometime after that, not motivated to look up the exact version right
now]. In order to maintain as much stability as possible, the patches
that made that split have not been backported to the CentOS6/RHEL6
version of libvirt. Instead, there are just the following packages:
libvirt
libvirt-client
libvirt-debuginfo
libvirt-devel
libvirt-lock-sanlock
libvirt-python
At any rate, you can simply net-destroy and net-undefine the default
network and you will no longer be troubled by them. You don't need to
remove any packages.
Cool, I'll look at net-destroy and net-undefine, and leave the packages
alone.
Thanks for all the input.
Mimi
3424
days inactive
3424
days old
7 comments
3 participants
participants (3)
-
Laine Stump -
Michal Privoznik -
mimicafe＠gmail.com