Re: [libvirt] OpenVZ : cannot assign bridge to any interface
On Wed, Jul 22, 2009 at 02:55:59PM +0900, Yuji NISHIDA wrote:
Hi,
I'm bit confuing between 2 problems with libvirt-0.6.5 for OpenVZ.
[1] bridge was created but no interface assigned to it
[2] virsh dumpxml returns xml in which type is qemu
sounds a serious bug
[2] -
I guess type in domain must be 'openvz' but virsh dumpxml returns it
as 'qemu'.
( The configuration of VE 101 remains in [1] )
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[r...@node13 test]# virsh dumpxml 101
domain type='qemu' id='101'
I was able to reproduce it, I'm still puzzled as where it comes from,
basically virsh run that way as root does not call the daemon, it just looks
up in the openvz driver, that driver is initialized and has a domain list,
(gdb) p driver-domains
$9 = {count = 1, objs = 0x734dc0}
(gdb) p driver-domains-objs[0]
$10 = (virDomainObjPtr) 0x734b10
(gdb) p *driver-domains-objs[0]-def
$12 = {virtType = 0, id = -1, uuid = A�\030�̮\025\v\236n�\027\036\001u,
name = 0x734850 101, memory = 0, maxmem = 0, vcpus = 1, cpumasklen =
0,
The domain object definition present is half complete, the virtType is
zero, which translates to a qemu type. One more reason why I dislike the
enum current impleemntation which are based on a significant 0 first
value, this should have raised an error when converting to the string
value.
I have been unable to find out where the driver domain list is being
initialized, breakpoints in virDomainLoadAllConfigs or virDomainObjNew
fail to work, I have no idea yet where those half backed values come
from.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] OpenVZ : cannot assign bridge to any interface
On Wed, Jul 22, 2009 at 02:55:59PM +0900, Yuji NISHIDA wrote:
Hi,
I'm bit confuing between 2 problems with libvirt-0.6.5 for OpenVZ.
The followings are python script and xml that I tested with.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[r...@node13 test]# cat test.py
import libvirt
conn = libvirt.open('openvz:///system')
conn.networkDefineXML( file('net.xml').read() )
conn.defineXML( file('test.xml').read() )
net = conn.networkLookupByName('guestnet101')
net.create()
guest = conn.lookupByName('101')
guest.create()
[2] -
I guess type in domain must be 'openvz' but virsh dumpxml returns it
as 'qemu'.
( The configuration of VE 101 remains in [1] )
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[r...@node13 test]# virsh dumpxml 101
domain type='qemu' id='101'
This is a bug in the openvzLoadDomains() method, with it forgetting to
fill in the virtType field. It shouldn't impact functional behaviour
of the driver though.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] OpenVZ : cannot assign bridge to any interface
Hi,
I'm bit confuing between 2 problems with libvirt-0.6.5 for OpenVZ.
[1] bridge was created but no interface assigned to it
[2] virsh dumpxml returns xml in which type is qemu
[1] -
I tried libvirt-0.6.5 on Fedora8 to create OpenVZ container ( OpenVZ
kernel is linux-2.6.18 ).
A bridge was seemed to successfully create but no interface could not
be assigned to the bridge.
Due to that, ping could not reach the guest in container(10.0.1.2).
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[r...@node13 test]# brctl show
bridge name bridge id STP enabled interfaces
br101 8000. no
[r...@node13 test]# ifconfig -a
br101 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:10.0.1.1 Bcast:10.0.1.15 Mask:255.255.255.240
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:5031 (4.9 KiB)
eth0 Link encap:Ethernet HWaddr 00:1C:C4:xx:xx:xx
inet addr:133.xx.xx.xx Bcast:133.xx.xx.xx Mask:255.255.255.0
inet6 addr: fe80::21c:c4ff::/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:196949 errors:0 dropped:0 overruns:0 frame:0
TX packets:64300 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:228373526 (217.7 MiB) TX bytes:5652593 (5.3 MiB)
Interrupt:169
eth1 Link encap:Ethernet HWaddr 00:1C:C4:xx:xx:xx
BROADCAST 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:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:50
loLink 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:323 errors:0 dropped:0 overruns:0 frame:0
TX packets:323 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:29949 (29.2 KiB) TX bytes:29949 (29.2 KiB)
sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 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)
venet0Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP BROADCAST POINTOPOINT RUNNING NOARP 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)
veth101 Link encap:Ethernet HWaddr 52:54:00:52:C3:FF
inet6 addr: fe80::5054:ff:fe52:c3ff/64 Scope:Link
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)
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
The followings are python script and xml that I tested with.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[r...@node13 test]# cat test.py
import libvirt
conn = libvirt.open('openvz:///system')
conn.networkDefineXML( file('net.xml').read() )
conn.defineXML( file('test.xml').read() )
net = conn.networkLookupByName('guestnet101')
net.create()
guest = conn.lookupByName('101')
guest.create()
[r...@node13 test]# cat test.xml
domain type='openvz' id='101'
name101/name
os
typeexe/type
init/sbin/fakeinit.sh/init
/os
memory524288/memory
devices
filesystem type='template'
source name='fedora-10-x86_64'/
target dir='/'/
/filesystem
console type='pty'/
interface type='bridge'
mac address=52:54:00:00:01:01 /
source bridge='guestnet101'/
target dev='veth101'/
/interface
/devices
/domain
[r...@node13 test]# cat net.xml
network
nameguestnet101/name
bridge name=br101 stp=off /
forward mode=nat/
ip address=10.0.1.1 netmask=255.255.255.240
dhcp
range start=10.0.1.2 end=10.0.1.2 /
/dhcp
/ip
/network
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[2] -
I guess type in domain must be 'openvz' but virsh dumpxml returns it
as 'qemu'.
( The configuration of VE 101 remains in [1] )
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
[r...@node13 test]# virsh dumpxml 101
domain type='qemu' id='101'
name101/name
uuiddedee02b-b74f-6e43-f5ec-27050986efa8/uuid
memory0/memory
currentMemory0/currentMemory
vcpu1/vcpu
os
typeexe/type
init/sbin/init/init
/os
clock
