[libvirt-users] libvirtd -- iptables
by Kurian Thayil
Hi All,
I created a couple of virtual networks (forward mode=nat) in my
rhel6-kvm box. I've come across 2 weird issues.
1. My Iptables rule chainset contains repeated rules. The same rule gets
repeated block by block
2. For connecting to guest using SSH, I created a custom IPTables chain.
I want this chain to be on top of the FORWARD chain, but everytime the
libvirtd is restarted the rule comes to the bottom of the chain (Appended).
Can anyone suggest me what the solution could be? My IPtable rules are
given below: Let me know if any further info is needed.
[root@santiago Packages]# iptables -L -n -v
Chain INPUT (policy ACCEPT 41 packets, 5818 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT udp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:67
0 0 ACCEPT udp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:67
0 0 ACCEPT udp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:67
0 0 ACCEPT udp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:67
0 0 ACCEPT udp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:67
0 0 ACCEPT udp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:67
0 0 ACCEPT udp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:67
0 0 ACCEPT udp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:67
0 0 ACCEPT udp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- vbr0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:67
0 0 ACCEPT udp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- vbr1 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:67
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * vbr0 0.0.0.0/0
10.10.0.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- vbr0 * 10.10.0.0/24
0.0.0.0/0
0 0 ACCEPT all -- vbr0 vbr0 0.0.0.0/0
0.0.0.0/0
0 0 REJECT all -- * vbr0 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- vbr0 * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * vbr1 0.0.0.0/0
10.10.1.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- vbr1 * 10.10.1.0/24
0.0.0.0/0
0 0 ACCEPT all -- vbr1 vbr1 0.0.0.0/0
0.0.0.0/0
0 0 REJECT all -- * vbr1 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- vbr1 * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
5688 588K rhel-virt-forward-1 all -- * *
0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * vbr0 0.0.0.0/0
10.10.0.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- vbr0 * 10.10.0.0/24
0.0.0.0/0
0 0 ACCEPT all -- vbr0 vbr0 0.0.0.0/0
0.0.0.0/0
0 0 REJECT all -- * vbr0 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- vbr0 * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * vbr1 0.0.0.0/0
10.10.1.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- vbr1 * 10.10.1.0/24
0.0.0.0/0
0 0 ACCEPT all -- vbr1 vbr1 0.0.0.0/0
0.0.0.0/0
0 0 REJECT all -- * vbr1 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- vbr1 * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * vbr0 0.0.0.0/0
10.10.0.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- vbr0 * 10.10.0.0/24
0.0.0.0/0
0 0 ACCEPT all -- vbr0 vbr0 0.0.0.0/0
0.0.0.0/0
0 0 REJECT all -- * vbr0 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- vbr0 * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * vbr1 0.0.0.0/0
10.10.1.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- vbr1 * 10.10.1.0/24
0.0.0.0/0
0 0 ACCEPT all -- vbr1 vbr1 0.0.0.0/0
0.0.0.0/0
0 0 REJECT all -- * vbr1 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- vbr1 * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * vbr0 0.0.0.0/0
10.10.0.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- vbr0 * 10.10.0.0/24
0.0.0.0/0
0 0 ACCEPT all -- vbr0 vbr0 0.0.0.0/0
0.0.0.0/0
0 0 REJECT all -- * vbr0 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- vbr0 * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * vbr1 0.0.0.0/0
10.10.1.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- vbr1 * 10.10.1.0/24
0.0.0.0/0
0 0 ACCEPT all -- vbr1 vbr1 0.0.0.0/0
0.0.0.0/0
0 0 REJECT all -- * vbr1 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- vbr1 * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * vbr0 0.0.0.0/0
10.10.0.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- vbr0 * 10.10.0.0/24
0.0.0.0/0
0 0 ACCEPT all -- vbr0 vbr0 0.0.0.0/0
0.0.0.0/0
0 0 REJECT all -- * vbr0 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- vbr0 * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * vbr1 0.0.0.0/0
10.10.1.0/24 state RELATED,ESTABLISHED
0 0 ACCEPT all -- vbr1 * 10.10.1.0/24
0.0.0.0/0
0 0 ACCEPT all -- vbr1 vbr1 0.0.0.0/0
0.0.0.0/0
0 0 REJECT all -- * vbr1 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- vbr1 * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-is-bridged
Chain OUTPUT (policy ACCEPT 38 packets, 4234 bytes)
pkts bytes target prot opt in out source
destination
Chain rhel-virt-forward-1 (1 references)
pkts bytes target prot opt in out source
destination
25 2100 ACCEPT icmp -- eth0 vbr1 0.0.0.0/0
0.0.0.0/0
3515 262K ACCEPT tcp -- eth0 vbr1 0.0.0.0/0
0.0.0.0/0 tcp dpt:22
0 0 ACCEPT icmp -- eth0 vbr0 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT tcp -- eth0 vbr0 0.0.0.0/0
0.0.0.0/0 tcp dpt:22
**************Details about my virtual network interfaces are given below:
[root@santiago Packages]# virsh net-list --all
Name State Autostart
-----------------------------------------
vir0 active yes
vir1 active yes
Thank you in advance.
Regards,
--Kurian.
14 years
[libvirt-users] RH6 qemu expects driver name
by Robert Šmol
Hi,
I am trying to start machine on RH6.
virsh # start ulp-001
error: Failed to start domain ulp-001
error: internal error process exited while connecting to monitor: char
device redirected to /dev/pts/1
qemu-kvm: -device lsi,id=scsi0,bus=pci.0,addr=0x5: Parameter 'driver'
expects a driver name
Try with argument '?' for a list.
virsh # version
Compiled against library: libvir 0.8.1
Using library: libvir 0.8.1
Using API: QEMU 0.8.1
Running hypervisor: QEMU 0.12.1
This is part of the config
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/rhev-data/defaultStore/ulp-001a.img'/>
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0' unit='0'/>
</disk>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<controller type='scsi' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</controller>
Any tips?
--
stereoIT - Open Source Technology Partners
http://www.stereoit.com
mobile: +420 776 762378
14 years
[libvirt-users] SSH recovery console
by Nikita A Menkovich
Hello,
Is there available to create ssh recovery console except vnc console,
that is default by libvirt.
For example connect to kvm@host:2220 and go to first console
For example like here
<serial type="tcp">
<source mode="bind" host="127.0.0.1" service="2445"/>
<protocol type="telnet"/>
<target port="1"/>
</serial>
But not plain format
--
Nikita A Menkovich
http://libc6.org/
JID: menkovich(a)gmail.com
14 years
[libvirt-users] With which VMM ,libvirt cooperates the most?
by kadir yüceer
Hi all,
I'm trying to develop some applications that communicate with VMM about
guest OSs. Libvirt has drivers for many VMMs like Qemu, Vbox, etc. I'm
currently using Vbox and time to time I get the error that says "this
function is not supported by the connection driver".
So, for which VMM, libvirt has the most compatible driver, regarding your
experiences?
Kind regards
Kadir
14 years
[libvirt-users] remote xen+ssh://host
by sd
Hello,
Is there a way where I can connect remote via ssh on a host and specify the
username / password ?
So far I found out that only the username can be specified and that
will ssh keys.
I would like something like
xen+ssh://user:password@host
thanks
sd
14 years
[libvirt-users] Beware! Newbie is in town
by kadir yüceer
Hello everyone,
I'm working on Ubuntu 10.10, installed libvirt and created a project in
Netbeans, I included jna.jar and libvirt-0.4.7.jar. And guess what, I get
the exception below when I'm trying to run test.java which connects to
test:///default.
Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load
library 'virt': libvirt.so: cannot open shared object file: No such file or
directory
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:164)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:237)
at com.sun.jna.Library$Handler.<init>(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:374)
at com.sun.jna.Native.loadLibrary(Native.java:359)
at org.libvirt.jna.Libvirt.<clinit>(Unknown Source)
at org.libvirt.Connect.<clinit>(Unknown Source)
at novatest_v01.Main.main(Main.java:21)
I'm sure this question has been asked dozens of times, sorry.
But any answer/comment is appreciated.
Thanks
Kadir
14 years
[libvirt-users] cgroups limitations on Virtual machines
by Zvi Dubitzky
I have 2 VMs launched by : 'virsh create <xml file>' . Both VMs get 2
vcpus (out of total 2 cores of the host)
I then try bias their cpu cycle quota by manipulating the cpu_shares (
virsh schedinfo --set cpu_shares=<value> vm1/2 ) so that VM1 will get 3
times the cpu cycles VM2 gets.
(e.g : VM1 cpu_shares = 150 . VM2 cpu_shares = 50) .
There are no other VMs defined or any other significant process running on
the host .
Each VM runs the same process (2 threads endless loop ).
Still both VM1 and VM2 get equal share of the 2 cores - running top
utility
at the host shows each is consuming 100% CPU.
At each VM console cat /proc/cpuinfo shows 2 cores assigned to the VM.
At the host : virsh vcpuinfo <vm1/2> shows each has 2 vcpus (0 an 1 )but
actually a single separate CPU is used for either vcpu0 or vcpu1 at each
VM at any check point in time (this is reasonable as it does not say what
portion of the core cycles is used by each VM) .
Can anyone explain that and how to bias the core usage of the 2 VMs by
manipulating the cpu_shares parameter (or other parameters) so that 'top'
at the host will reflect the bias . I would expect 'top' at the host to
show 150% CPU for VM1 ( qemu-system-x86) and 50% CPU for VM2 (the other
qemu-system-x86) with above set cpu_share values .
Doing the same test with 2 plain processes (instead VMs udner libvirt)
with same cpu_shares bias gives the expected biased cpu usage between the
2 processes
My system is fedora14 and kernel 2.6.35.6-45.fc14.x86_64 .
thanks
Zvi Dubitzky
Email:dubi@il.ibm.com
14 years
[libvirt-users] QEMU monitor
by Nikita A Menkovich
Hello,
Is there any way to change VNC password without rebooting virtual machine?
It is available through qemu monitor, but, it seems, there is no way
to do add monitor to kvm.
--
Nikita A Menkovich
http://libc6.org/
JID: menkovich(a)gmail.com
14 years
[libvirt-users] ruby bindings has two gems (I think)
by James Barkley
When I look at remote gems I see:
- libvirt (0.2.0), "A ruby client library providing an interface to libvirt
via FFI"
- ruby-libvirt (0.3.0), "Provides bindings for libvirt"
I've been using ruby-libvirt, but maybe I should give libvirt a try? Has
anyone used libvirt (0.2.0) and developed opinions they'd like to share?
-jb
14 years
[libvirt-users] Libvirt with multipath devices and/or FC on NPIV
by C.D.
Hello,
I am trying to find out a best practice for a specific scenario.
First of all I would like to know what is the proper way to set up
multipath, who should care about it the host or the guest. Right now I have
a setup where I have one multipath which sets my host to boot from FC SAN. I
have another multipathed LUN in the host which is essentially a dm which I
attached to a guest, however through virtio. I added the devices through
virsh with pool type of "mpath" and path through /dev/mapper/. So here is my
first question: with such a setup the multipath and eventual fail-over is
taken care by the host OS, right, the guest will not notice is I suppose?
But what about migration. What if I decide to migrate the guest to another
host. How would that work out? WIth shared directory it is easy, you just
have the images in it, but what about such a setup. I can always add the
aforementioned LUN, where the guest resides to another Storage Group on the
SAN where the new host has access and I can make sure that the mpath device
name is persistent across all hosts, but is that the right approach.
Here is another question that is bugging me. I have FC HBA-s on all hosts
and I would like to make a HBA visible through my guest. I stumbled upon a
bug that is documented in redhat's bugzilla that attempted creation of NPIV
on pci_0000_blah_blah instead on the scsi_hostX device, but I fixed that
easily in the xml and although virsh doesn't seem to think I completed the
nodedev-create NPIV_for_my_FC.xml the device is seen as a child in
nodedev-list and what is more important the WWN are seen on the SAN switch.
So this seems to be working OK, however I don't know how to attach this new
shiny device that I created to a guest. Could someone give me a hint? What
is the proper way to attach this new devices to a guest OS and do that
persistently. Do I do that with virsh's attach-device and if so what is the
proper XML format? Should I dump the XML for the newly created NPIV nodedev
and try to attach that? And again with multipathing. What if I decided to
create NPIV on my two FC cards in every host, then do the zoning and attach
those newly created NPIV nodes to the guests? Will that produce the same
effect that such a multipath does on the host? It doesn't really matter if I
would use it for root drive or a shared gfs2 storage between guests, I just
want to know is this possible and is it the right thing to do, or should I
stick to setup in my previous paragraph? And last question: what about
migration with such NPIV FC devices. I can move a guest around, but will
that move my NPIV FC with it's WWN so that I can continue using my zoning (I
think I just realized that this might be impossible because I'm migrating
the guest, not the entire setup of libvirt, but probably I'm wrong and I'm
not aware of a proper method to do it correctly?).
Probably those questions are easy to answer, but please bare with me, I'm
playing with libvirt in an enterprise setup only for the last couple of days
and I would really like to make it right and kick some VMware ass.
By the way, all my hosts are Fedora 14, with kernel 2.6.37 (rebuild of the
one for Fedora 15 from koji, because there was a small glitch with Qlogic's
driver in the stock 2.6.35). Most of my guests will be SL6,CentOS5/6(when it
arrives) and a couple of windows XP guests (but I'm not really concerned
with that).
Thanks for the support in advance
P.S. please keep me in CC, as I'm not on the list. Thank you
14 years
