mimicafe@gmail.com
2015-Apr-24 15:08 UTC
Re: [libvirt-users] Remove Virtual bridge and DNSMASQ
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@redhat.com> wrote:> On 24.04.2015 12:45, 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? > > 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 >
mimicafe@gmail.com
2015-Apr-24 18:02 UTC
Re: [libvirt-users] Remove Virtual bridge and DNSMASQ
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@gmail.com <mimicafe@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@redhat.com> wrote: > >> On 24.04.2015 12:45, 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? >> >> 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 >> > >
mimicafe@gmail.com
2015-Apr-24 18:12 UTC
Re: [libvirt-users] Remove Virtual bridge and DNSMASQ
On 24 April 2015 at 18:00, Laine Stump <laine@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@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@redhat.com> wrote: > >> On 24.04.2015 12 <24.04.2015%2012>:45, 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. > > > The problem of top-posting is from the way reply is composed withinGmail. I'll watch out next time. Thanks Mimi
On 04/24/2015 02:02 PM, mimicafe@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.