4:45 p.m.
On 10/30/2013 09:14 PM, Dan Sa wrote:
I created another Virtual Machine with DHCP enabled 192.168.0.0/16
<http://192.168.0.0/16> DHCP Range 192.168.0.2 192.168.0.2 (as I want
same IP to all three guests) Forwarding : NAT to em2
now on host I see two instances of dnsmasq
netstat -anlp | grep -w dnsmasq
tcp 0 0 192.168.0.1:53 <http://192.168.0.1:53>
0.0.0.0:* LISTEN 1907/dnsmasq <<<< is this right ?
I created
tcp 0 0 192.168.122.1:53 <http://192.168.122.1:53>
0.0.0.0:* LISTEN 6666/dnsmasq <<< default NAT
however I am seeing dnsmasq is not Active
systemctl status dnsmasq.service
dnsmasq.service - DNS caching server.
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service;
enabled)
Active: failed (Result: exit-code) since Wed, 30 Oct 2013
12:30:39 -0600; 41min ago
all my guest are on physical VLAN so how I should go about giving them
192.168.0.2 address using dnsmasq ?
1) PLEASE stop top-posting new random information and guesses at
solutions to the top of your old messages. You are quickly creating a
cascade of text that is so large and rambling that nobody will have the
ambition to unscramble it and make a reply.
It is generally accepted good etiquette to post responses to earlier
messages in-line with the original, so that the flow of the conversation
can be easily followed by someone reading just the last message. (If
there is no "flow" to the conversation, then something more fundamental
has gone wrong.)
2) If you've now realized (as I told you in my first response) that you
need to run a system instance of dhcpd or dnsmasq to service dhcp for
the vlan of your guests, then what you have is a networking problem, not
a virtualization problem. There are tutorials for setting up dnsmasq in
various places on the web, or you can simply read the comments in
/etc/dnsmasq.conf to figure out how to make it listen on just a specific
interface, and how to tell it what addresses to serve for that interface.
See below for more comments.
thanks
dan
On Wed, Oct 30, 2013 at 11:20 AM, Dan Sa <dreamrider787(a)gmail.com
<mailto:dreamrider787@gmail.com>> wrote:
UPDATE :
Adding more information about dnsmasq on box running fedora (host)
dispatcher.d]# nmcli nm status
RUNNING STATE WIFI-HARDWARE WIFI
WWAN-HARDWARE WWAN
running connecting enabled enabled
enabled disabled
nmcli nm status
RUNNING STATE WIFI-HARDWARE WIFI
WWAN-HARDWARE WWAN
running disconnected enabled enabled
enabled disabled
systemctl --all|grep -i network
NetworkManager.service loaded active running Network
Manager
dnsmasq.d]# ls -al
total 8
drwxr-xr-x 2 root root 4096 Nov 20 2012 .
drwxr-xr-x. 6 root root 4096 Oct 30 08:56 ..
dispatcher.d]# ls -al
total 32
drwxr-xr-x. 2 root root 4096 Sep 23 12:59 .
drwxr-xr-x. 6 root root 4096 Oct 30 08:56 ..
-rwxr-xr-x 1 root root 175 Nov 15 2012 00-netreport
-rwxr-xr-x. 1 root root 335 Feb 14 2012 04-iscsi
-rwxr-xr-x. 1 root root 111 Jun 25 2012 10-sendmail
-rwxr-xr-x 1 root root 933 Jul 10 04:38 11-dhclient
-rwxr-xr-x. 1 root root 317 Apr 27 2012 20-chrony
-rwxr-xr-x 1 root root 138 Mar 19 2013 20-squid
cat dnsmasq.conf
all lines are commented only line active is
# Include another lot of configuration options.
#conf-file=/etc/dnsmasq.more.conf
conf-dir=/etc/dnsmasq.d
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
*All* of the above is just random data, which says nothing. Please try
to spend more time figuring out what you are trying to do and what has
gone wrong before just pasting random bits into a message to a mailing
list. Remember that the people reading the messages on this list are
doing it for free, and they also have day jobs they need to attend to.
The less excess garbage is in a message, the less time they have to use
up sifting through it for useful information.
On Wed, Oct 30, 2013 at 10:10 AM, Dan Sa <dreamrider787(a)gmail.com
<mailto:dreamrider787@gmail.com>> wrote:
BRCTL SHOW
bridge name bridge id STP enabled interfaces
br0 8000.00237de0a132 no em1
vnet0
guest1-lan 8000.00237de0a133 no em2.620
vnet3
guest1-wan 8000.0022642b6586 no p1p1.110
guest2-lan 8000.00237de0a133 no em2.619
guest2-wan 8000.0022642b6586 no p1p1.108
guest3-lan 8000.00237de0a133 no em2.621
guest3-wan 8000.0022642b6586 no p1p1.111
virbr0 8000.5254003e19b3 yes virbr0-nic
vnet2
The above list of bridges connected to vlan interfaces implies that, for
some reason, you are putting each interface of each guest on a separate
vlan. Is this really what you think you want to do? Why? How will these
guests connect to the rest of the network? Unless you have a requirement
to isolate each guest entirely from every other guest and force each
guest's traffic to travel through a different path out to the rest of
the network, then I think you've misunderstood when/why vlans should be
used. It is much more common to just setup a single network that many
(or even all) guests will attach to, and generally you don't need a vlan
tag to do this.
(an earlier comment you made implying that a *host* bridge attached to a
host vlan interface *was actually the guest interface* makes me believe
you are confused about the function of each bit and how they all fit
together. I think it would be useful for you to step back from all of
this and just explain how you want your guests to connect to the rest of
the network. Do you have a specific requirement for each to be connected
to a separate vlan on the physical network? Or do they just need to be
connected "somehow"? Do they need to be prevented from communicating
with each other, or was this just a side effect of a mistaken network
configuration?
On Wed, Oct 30, 2013 at 10:10 AM, Dan Sa
<dreamrider787(a)gmail.com <mailto:dreamrider787@gmail.com>> wrote:
Laine,
first thank you very much for your input, it cleared some
doubts ... please find below the information in the
desired format.
Versions:
1) Virtual Machine Manager 0.9.5[root@dsl-test qemu]# uname -a
2) Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14
01:31:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
3) Fedora release 17 (Beefy Miracle) Kernel \r on an \m (\l)
Fedora 17 is > 1 year old, and thus no longer gets any updates, not even
security updates. You need to upgrade to a newer release of Fedora (F20
is already in beta, so that may be a good choice)
4) virsh --version 0.9.11.10
Likewise, 0.9.11 is very old. *Many* improvements have been made since
then, which is another good reason to upgrade your OS.
5) rpm -qa | grep kvm
libvirt-daemon-kvm-0.9.11.10-1.fc17.x86_64
qemu-kvm-1.0.1-6.fc17.x86_64
I have 3 Guest information for guest1 follows : (my
questions are after that)
virsh dumpxml guest1 :
virsh dumpxml guest1
<domain type='kvm' id='5'>
<name>guest1</name>
<uuid>bcc29de1-ba90-5dd8-81fe-7450852df7f6</uuid>
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu>4</vcpu>
<os>
<type arch='x86_64'
machine='pc-0.15'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<cpu mode='custom' match='exact'>
<model fallback='allow'>Penryn</model>
<vendor>Intel</vendor>
<feature policy='require' name='tm2'/>
<feature policy='require' name='est'/>
<feature policy='require' name='monitor'/>
<feature policy='require' name='osxsave'/>
<feature policy='require' name='ss'/>
<feature policy='require' name='ds'/>
<feature policy='require' name='vme'/>
<feature policy='require' name='dtes64'/>
<feature policy='require' name='ht'/>
<feature policy='require' name='dca'/>
<feature policy='require' name='pbe'/>
<feature policy='require' name='xsave'/>
<feature policy='require' name='tm'/>
<feature policy='require' name='pdcm'/>
<feature policy='require' name='vmx'/>
<feature policy='require' name='ds_cpl'/>
<feature policy='require' name='xtpr'/>
<feature policy='require' name='acpi'/>
</cpu>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/qemu-kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/guest1.img'/>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000'
bus='0x00'
slot='0x05' function='0x0'/>
</disk>
<controller type='usb' index='0'>
<alias name='usb0'/>
<address type='pci' domain='0x0000'
bus='0x00'
slot='0x01' function='0x2'/>
</controller>
<controller type='virtio-serial' index='0'>
<alias name='virtio-serial0'/>
<address type='pci' domain='0x0000'
bus='0x00'
slot='0x04' function='0x0'/>
</controller>
<interface type='network'>
<mac address='52:54:00:ea:80:df'/>
<source network='default'/>
<target dev='vnet2'/>
<alias name='net0'/>
<address type='pci' domain='0x0000'
bus='0x00'
slot='0x03' function='0x0'/>
</interface>
<interface type='bridge'>
<mac address='52:54:00:d5:1d:01'/>
<source bridge='guest1-lan'/>
<target dev='vnet3'/>
<model type='virtio'/>
<alias name='net1'/>
<address type='pci' domain='0x0000'
bus='0x00'
slot='0x07' function='0x0'/>
</interface>
<serial type='pty'>
<source path='/dev/pts/3'/>
<target port='0'/>
<alias name='serial0'/>
</serial>
<console type='pty' tty='/dev/pts/3'>
<source path='/dev/pts/3'/>
<target type='serial' port='0'/>
<alias name='serial0'/>
</console>
<input type='mouse' bus='ps2'/>
<graphics type='vnc' port='5901'
autoport='yes'/>
<video>
<model type='cirrus' vram='9216'
heads='1'/>
<alias name='video0'/>
<address type='pci' domain='0x0000'
bus='0x00'
slot='0x02' function='0x0'/>
</video>
<memballoon model='virtio'>
<alias name='balloon0'/>
<address type='pci' domain='0x0000'
bus='0x00'
slot='0x06' function='0x0'/>
</memballoon>
</devices>
<seclabel type='none'/>
</domain>
Here is revised BRCTL Show after guest1 is running
BRCTL SHOW
bridge name bridge id STP enabled interfaces
br0 8000.00237de0a132
no em1
vnet0
c1000z-lan 8000.00237de0a133
no em2.620
vnet3
c1000z-wan 8000.0022642b6586
no p1p1.110
c2000t-lan 8000.00237de0a133
no em2.619
c2000t-wan 8000.0022642b6586 no
p1p1.108
pk5001a-lan 8000.00237de0a133
no em2.621
pk5001a-wan 8000.0022642b6586
no p1p1.111
virbr0 8000.5254003e19b3 yes
virbr0-nic
vnet2
The above is obviously *not* the output of brctl on the same host as the
above-listed guest, since that guest connects to a bridge called
"guest1-lan", which isn't even in the brctl output at all.
----------------------------------------------------------------------------------------------------------
on guest1-lan terminal I see following :
route -n
destination gateway genmask flags
metric ref use iface
0.0.0.0 192.168.122.1 0.0.0.0 UG
100 0 eth0
192.168.122.0 0.0.0.0 255.255.255.0 U
0 0 eth0
DHCPDISCOVER on eth 1 to 255.255.255.255 port 67 interval
6 then 14, 13, 15
and then sleeping
so you are right I am not getting DHCP IP and I have
"forward mode bridge" so libvirt is ignoring it
I want 192.168.0.2 on this with gateway 192.168.0.1
so looks like my problem is DHCP .... how can I able to
run DHCP for all three guest which are part of em2
interface like em2.629, em2.621 and em2/622
Again, WHY do you need a separate vlan for each guest? I think you may
be confused.
awaiting your suggestions....
1) stop top-posting.
2) either explain why you need each guest on a separate vlan, or give up
on that idea and just connect all guest interfaces to a single network
(or possible 2 networks - on lan and one wan, which you seen to have
some requirement for).
3) if you really do require the guests to each be on a separate vlan,
and you don't have any other host on the network that already serves
dhcp on those vlans, then read /etc/dnsmasq.conf to learn how to
configure it.
regards
dan
On Wed, Oct 30, 2013 at 9:56 AM, Dan Sa
<dreamrider787(a)gmail.com <mailto:dreamrider787@gmail.com>>
wrote:
Laine,
first thank you very much for your input, it cleared
some doubts ... please find below the information in
the desired format.
Versions:
1) Virtual Machine Manager 0.9.5[root@dsl-test qemu]#
uname -a
2) Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14
01:31:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
3) Fedora release 17 (Beefy Miracle) Kernel \r on an
\m (\l)
4) virsh --version 0.9.11.10
5) rpm -qa | grep kvm
libvirt-daemon-kvm-0.9.11.10-1.fc17.x86_64
qemu-kvm-1.0.1-6.fc17.x86_64
I have 3 Guest and here is
On Wed, Oct 30, 2013 at 5:19 AM, Laine Stump
<laine(a)laine.org <mailto:laine@laine.org>> wrote:
(There is no need or advantage to Cc'ing
individuals who are already
subscribed to the mailing list.)
On 10/28/2013 05:34 PM, Dan Sa wrote:
> hello all,
>
> I have been trying to set-up bridged network
with VLAN and not able to
> succeed as many tutorials address only single NIC.
>
> I am trying to setup 2 guests (backtrack
instance) each guest has NIC1
> and NIC2. following is snippet for guest1
>
> I am not able to get 192.168.0.2 address back on
guest eth0.
See the comment below about <forward
mode='bridge'>. you'll need some
other entity on your vlan to run a dhcp server,
because libvirt won't be
doing it for you in this case.
>
>
> VIRT-MANAGER GUI :
>
> guest1-lan details radio button
>
> left side panel
>
> NIC1 ------------------> Virtual Network Interface
> Source Device :
Virtual Network "default" NAT
> Device Model :
Hypervisor default
> MAc Address :
xxxxxxxxxxxxxx
>
> NIC2 ------------------> Virtual Network Interface
> Source Device :
Specify Shared Device Name
> Bridge
name : guest1-lan
> Device Model : virto
> MAc Address :
xxxxxxxxxxxxxx
The output of "virsh dumpxml $guestname" is much
more useful than a
transcription of the virt-manager screens.
>
> HOST MACHINE :
>
> brctl show has br0 for bridge
> and virbr0 with 192.168.122.x address (created
by default virtual
> network NAT)
>
>
> /etc/sysconfig/network-scripts/
>
> 1) Bridge BR0 (cat ifcfg-br0)
>
> DEVICE="br0"
> TYPE="Bridge"
> ONBOOT="yes"
> NM_CONTROLLED="no"
> BOOTPROTO="static"
> IPADDR="xx.xx.xx.xx"
> NETMASK="255.255.254.0"
> GATEWAY="xx.xx.xx.xx"
> DNS1="x.y.z.s"
> DNS2="x.y.q.s"
>
> 2) cat ifcfg-em1
> NM_CONTROLLED="yes"
> HWADDR="02:12D:E2:B1:32"
> BOOTPROTO="static"
> DEVICE="em1"
> BRIDGE="br0"
> ONBOOT="yes"
>
> 3) ifcfg-em2
> NM_CONTROLLED="yes"
> HWADDR="02:24:7e:d0:b1:42"
> BOOTPROTO="static"
> DEVICE="em2"
> ONBOOT="yes"
>
> 4) THIS IS GUEST (cat ifcfg-guest1-lan)
I don't understand what you mean by "this is
guest". It isn't a part of
the guest; it is a bridge on the host that could
be *used* by a guest.
> DEVICE=guest1-lan
> TYPE=Bridge
> ONBOOT=yes
> BOOTPROTO=static
> DELAY=1
>
> 5) GUEST VLAN (cat ifcfg-em2.620)
>
> DEVICE=em2.620
> VLAN=yes
> ONBOOT=yes
> BRIDGE=guest1-lan
>
> BRCTL Show Command :
>
> br0 8000.00237de0a132 no em1
>
vnet0
> guest1-lan 8000.00237de0a133 no em2.620
> virbr0 8000.5254003e19b3 yes virbr0-nic
From the above, it appears that there is only a
single guest running,
and that it is connected via the br0 bridge;
apparently you took this
output when neither of your dual-nic guests were
running, as they should
have each attached tun devices to both guest1-lan
and virbr0.
>
>
> VIRSH :
>
> virsh # net-list
> Name State Autostart
> -----------------------------------------
> guest1-lan active yes
> default active yes
>
>
> virsh # iface-list
> Name State MAC Address
> --------------------------------------------
> br0 active 00:23:7d:e0:a1:32
> guest1-lan active 00:23:7d:e0:a1:33
>
>
> iface-edit :
>
> virsh # iface-edit guest1-lan
>
> <interface type='bridge'
name='guest1-lan'>
> <start mode='onboot'/>
> <bridge delay='1'>
> <interface type='vlan'
name='em2.620'>
> <vlan tag='620'>
> <interface name='em2'/>
> </vlan>
> </interface>
> </bridge>
> </interface>
>
>
------------------------------------------------------------------
>
> /etc/libvirt/qemu/networks
(You shouldn't be looking at/modifying the files in
/etc/libvirt/qemu/networks directly. Instead, use
"virsh net-dumpxml
guest1-lan" (for example) to look at the network
config, and "virsh
net-edit guest1-lan" to modify it.)
>
> cat guest1-lan.xml
> <network>
> <name>guest1-lan</name>
> <uuid>a12747ec-21c9-0d21-ab06-064ba204bc52</uuid>
> <forward mode='bridge' dev="br0"/>
> <bridge name='guest1-lan' />
> <ip address='192.168.0.1'
netmask='255.255.255.0'>
> <dhcp>
> <range start='192.168.0.2'
end='192.168.0.254' />
> </dhcp>
> </ip>
Any network with <forward mode='bridge'...> is an
"unmanaged" network
from libvirt's POV, and thus the <ip> element and
all its subelements
are ignored. If you use <forward mode='bridge'>
then libvirt assumes
that the bridge device is already configured by
the base OS config.
As of libvirt-1.0.1, attempts to define an <ip>
element in a network
with <forward mode='bridge'> are flagged as an
error. (It would be
helpful in future reports if you indicate your 1)
libvirt version, 2)
qemu version, 3) distro and version, 4) kernel
version. Although not
always applicable, sometime it can help in framing
the issue.
> </network>
>
>
> cat default.xml
>
> <network>
> <name>default</name>
> <uuid>8778244b-1a0c-c15f-c348-26462a07a639</uuid>
> <forward mode='nat'/>
> <bridge name='virbr0' stp='on'
delay='0' />
> <mac address='52:54:00:3E:19:B3'/>
> <ip address='192.168.122.1'
netmask='255.255.255.0'>
> <dhcp>
> <range start='192.168.122.2'
end='192.168.122.254' />
> </dhcp>
> </ip>
> </network>
>
> any guidance will be appriciated
Since you're defining a vlan tag, I assume that
the physical network
attached to your host's em2 is actually using vlan
620? If not, and you
just need a network that's private to your guests
and the host, I would
recommend simply defining a libvirt network with
no <forward> element at
all. This network *will* be managed by libvirt, so
libvirt will create a
bridge and give it an IP address, as well as
running a dnsmasq instance
to serve up IP addresses to guests, but the guests
won't be able to get
traffic anywhere beyond that bridge via their
interface connected to the
bridge.
If you *are* using vlan 620 on the physical
network, then you'll need to
setup some other dhcp server somewhere on that
network (either run a
system instance of dnsmasq on the host that
listens on em2.620, or run
dnsmasq or dhcpd on some other physical host or
guest that listens on
its own vlan-tagged interface).