[libvirt] [PATCH] Fix python error reporting for some storage operations
by Cole Robinson
In the python bindings, all vir* classes expect to be
passed a virConnect object when instantiated. Before
the storage stuff, these classes were only instantiated
in virConnect methods, so the generator is hardcoded to
pass 'self' as the connection instance to these classes.
Problem is there are some methods that return pool or vol
instances which aren't called from virConnect: you can
lookup a storage volume's associated pool, and can lookup
volumes from a pool. In these cases passing 'self' doesn't
give the vir* instance a connection, so when it comes time
to raise an exception crap hits the fan.
Rather than rework the generator to accomodate this edge
case, I just fixed the init functions for virStorage* to
pull the associated connection out of the passed value
if it's not a virConnect instance.
Thanks,
Cole
diff --git a/python/generator.py b/python/generator.py
index 01a17da..c706b19 100755
--- a/python/generator.py
+++ b/python/generator.py
@@ -962,8 +962,12 @@ def buildWrappers():
list = reference_keepers[classname]
for ref in list:
classes.write(" self.%s = None\n" % ref[1])
- if classname in [ "virDomain", "virNetwork", "virStoragePool", "virStorageVol" ]:
+ if classname in [ "virDomain", "virNetwork" ]:
classes.write(" self._conn = conn\n")
+ elif classname in [ "virStorageVol", "virStoragePool" ]:
+ classes.write(" self._conn = conn\n" + \
+ " if not isinstance(conn, virConnect):\n" + \
+ " self._conn = conn._conn\n")
classes.write(" if _obj != None:self._o = _obj;return\n")
classes.write(" self._o = None\n\n");
destruct=None
3 weeks, 5 days
[libvirt] virDomainInterfaceStats why is there a size?
by Stefan de Konink
Another simple question, what is the reasoning about the size field in
this call. I would really be a happy boy if anyone said:
if you put in path == NULL, it will fill your stats structure up to size
interfaces.
...but since this is not the case (yet) what is the reason behind it?
Stefan
16 years, 3 months
[libvirt] anyone implementing host device enumeration?
by David Lively
Hi -
I'm about to start working on host device enumeration, along the
(HAL-ish) lines of what was discussed back in April:
https://www.redhat.com/archives/libvir-list/2008-April/msg00005.html
I know the xml details haven't been fully fleshed out, but there seems
to be agreement that it will be a fairly direct mapping from (a subset
of the) HAL info to the details that we need in the xml. Doubtless it
will take a while to figure out exactly what subset suffices (and, for
that matter, if everything needed is available via HAL ...), but I think
the work is well-defined for some of the obvious details (discussed in
the above thread) on which there's broad agreement.
Is anyone working on such an implementation?
Thanks,
Dave
16 years, 5 months
[libvirt] Live migration sanity checks
by Chris Lalancette
All,
One thing that oVirt would like to have (and that might be useful for other
users) is a call that would do some basic sanity checking for live migration.
This call would go over to the remote libvirtd, do some checks, and
return whether we think migration is likely to succeed. Note that I say
"likely to succeed", because there are certainly things that can cause migration
to fail after we've made checks, but anything is better than what we have today
("try it and pray").
Now, in order for this call to be widely useful, I think we would have to allow
the caller to specify *which* of the available checks they would like to
perform, and then have some sort of return value that indicated if there are
show-stopper problems, or just problems that may cause things to be sub-optimal
on the remote side. The caller could then decide what action it wants to take.
There is also a corollary to the "is it sane for me to migrate", which is, given
two hosts A and B, what's the lowest common denominator I need to run my guest
at so that migration will likely be successful between them. This could also be
used by management apps to make sure things are configured properly for the
guest before ever starting it.
The biggest problem with implementing these calls, however, is that there is no
comprehensive list of things we should check. This e-mail is an attempt to
write down some of the more obvious things we need to check, and to garner
discussion of things I might have missed. Once I have a proper list, I'll add
it to the TODO page on the libvirt Wiki so it's at least somewhere permanent.
Note that we don't have to implement *all* of these as a first go at this; if we
leave it open enough, we can add more checks as we go along without breaking
compatibility.
MIGRATION CRITERIA:
0) Matching hypervisors - seems obvious, but I'm not sure if we have these
checks today. Make sure we don't try to migrate Xen to KVM or vice-versa. We
also might want to think of at least warning the caller if you try to migrate
from a "newer" hypervisor (say, Xen 3.2) to an "older" hypervisor (say, Xen
3.1). That should, in theory, work, but maybe the caller would prefer not to do
that if possible. Rich has pointed out that KVM and Xen are accidentally
incompatible in libvirt, but we should make it explicit.
1) Matching CPU architectures - also obvious, but as far as I know today,
there's no checking for this (well, at least in Xen; I don't know about
libvirt). So you can happily attempt to migrate from i386 -> ia64, and watch
the fireworks. We also need to make sure you can't migrate x86_64 -> i386. I
believe i386 -> x86_64 should work, but this might be hypervisor dependent.
2) Matching CPU vendors - this one isn't a hard requirement; given the things
below, we may still be likely to succeed even if we go from AMD to Intel or
vice-versa. It still might be useful information for the caller to know.
3) CPU flags - the CPU flags of the destination *must* be a superset of the CPU
flags that were presented to the guest at startup. Many OS's and application
check for CPU flags once at startup to choose optimized routines, and then never
check again; if they happened to select sse3, and sse3 is not there on the
destination, then they will (eventually) crash.
This is where the CPU masking technology and the lowest common denominator
libvirt call can make a big difference. If you make sure to mask some of the
CPU flags off of the guest when you are first creating it, then the destination
host just needs a superset of the flags that were presented to the guest at
bootup, which makes the problem easier.
4) Number of CPUs - generally, you want the destination to have at least one
physical CPU for each virtual CPU assigned to the guest. However, I can see use
cases where this might not be the case (temporary or emergency migrations). So
this would probably be a warning, and the caller can make the choice of whether
to proceed.
5a) Memory - non-NUMA -> non-NUMA - fairly straightforward. The destination
must have enough memory to fit the guest memory. We might want to do some
"extra" checking on the destination to make sure we aren't going to OOM the
destination as soon as we arrive.
5b) Memory - non-NUMA -> NUMA - A little trickier. There are no cpusets we
have to worry about, since we are coming from non-NUMA, but for absolute best
performance, we should try to fit the whole guest into a single NUMA node. Of
course, if that node is overloaded, that may be a bad idea. NUMA placement
problem, basically.
5c) Memory - NUMA -> non-NUMA - Less tricky. On the destination, all memory is
"equally" far away, so no need to worry about cpusets. Just have to make sure
that there is enough memory on the destination for the guest.
5d) Memory - NUMA -> NUMA - Tricky, just like case 5b). Need to determine if
there is enough memory in the machine first, then check if we can fit the guest
in a single node, and also check if we can match the cpuset from the source on
the destination.
6a) Networks - at the very least, the destination must have the same bridges
configured as the source side. Whether those bridges are hooked to the same
physical networks as the source or not is another question, and may be outside
the bounds of what we can/should check.
6b) Networks - we need to make sure that the device model on the remote side
supports the same devices as the source side. That is, if you have a e1000 nic
on the source side, but your destination doesn't support it, you are going to
fail the migration.
7a) Disks - we have to make sure that all of the disks on the source side are
available on the destination side, at the same paths. To be entirely clear, we
have to make sure that the file on the destination side is the *same* file as on
the source side, not just a file with the same name. For traditional
file-based, the best we can do may be path names. For device names (like LVM,
actual disk partitions, etc.), we might be able to take advantage of device
enumaration API's and validate that the device info is the same (UUID matching,
etc.).
7b) Disks - Additionally, we need to make sure that the device model on the
remote side supports the same devices as the source side. That is, if you have
a virtio drive on the source side, but your destination host doesn't support
virtio on the backend, you are going to fail. (virtio might be a bad example,
but there might be further things in the device model in the future that we
might not necessarily have on both ends).
------ That's the absolute basic criteria. More esoteric/less thought-out
criteria follow:
8) Time skew - this is less thought out at the moment, but if you calibrated
your lpj at boot time, and now you migrate to a host with a different clock
frequency, your time will run either fast or slow compared to what you expect.
Also synchronized vs. unsynchronized TSC could cause issues, etc.
9) PCI-passthrough - this is actually a check on the *source* side. If the
guest is using a PCI passthrough device, it *usually* doesn't make sense to
live migrate it. On the other hand, it looks like various groups are trying to
make this work (with the bonding of a PV NIC to a PCI-passthrough NIC), so we
need to keep that in mind, and not necessarily make this a hard failure.
10) MSR's?? - I've thought about this one before, but I'm not sure what the
answer is. Unfortunately, MSR's in virtualization are sort of done hodge-podge.
That is, some MSR's are emulated for the guests, some MSR's guests have direct
control over, and some aren't emulated at all. This one can get ugly fast; it's
probably something we want to leave until later.
11) CPUID?? - Not entirely sure about this one; there is a lot of
model-specific information encoded in the various CPUID calls (things like cache
size, cache line size, etc. etc). However, I don't know if CPUID instructions
are trapped-n-emulated under the different hypervisors, or if they are done
right on the processor itself. I guess if an OS or application called this at
startup, cached the information, and then checked again later it might get
upset, but it seems somewhat unlikely.
Things that I've missed?
Thanks,
Chris Lalancette
16 years, 5 months
[libvirt] [PATCH] Add .gitignore files
by James Morris
Add .gitignore files to make developing with git easier. These
are simply copies of the .cvsignore files.
Signed-off-by: James Morris <jmorris(a)namei.org>
---
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..5e055a6
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,32 @@
+.git
+Makefile
+aclocal.m4
+autom4te.cache
+stamp-h.in
+Makefile.in
+configure
+config.cache
+config.h
+config.h.in
+config.log
+config.status
+config.guess
+config.sub
+config.rpath
+stamp-h
+stamp-h1
+libtool
+ltconfig
+update.log
+libvirt.pc
+libvirt.spec
+mingw-libvirt.spec
+COPYING
+m4
+ABOUT-NLS
+coverage
+results.log
+libvirt-*.tar.gz
+INSTALL
+ltmain.sh
+mkinstalldirs
diff --git a/build-aux/.gitignore b/build-aux/.gitignore
new file mode 100644
index 0000000..096cccb
--- /dev/null
+++ b/build-aux/.gitignore
@@ -0,0 +1,10 @@
+compile
+config.guess
+config.rpath
+config.sub
+depcomp
+install-sh
+ltmain.sh
+missing
+mkinstalldirs
+mktempd
diff --git a/docs/.gitignore b/docs/.gitignore
new file mode 100644
index 0000000..f284184
--- /dev/null
+++ b/docs/.gitignore
@@ -0,0 +1,4 @@
+Makefile
+Makefile.in
+.memdump
+apibuild.pyc
diff --git a/docs/devhelp/.gitignore b/docs/devhelp/.gitignore
new file mode 100644
index 0000000..cc4abab
--- /dev/null
+++ b/docs/devhelp/.gitignore
@@ -0,0 +1,3 @@
+Makefile
+Makefile.in
+libvirt.devhelp
diff --git a/docs/examples/.gitignore b/docs/examples/.gitignore
new file mode 100644
index 0000000..5f0e251
--- /dev/null
+++ b/docs/examples/.gitignore
@@ -0,0 +1,7 @@
+.memdump
+Makefile.in
+Makefile
+.deps
+.libs
+info1
+suspend
diff --git a/docs/examples/python/.gitignore b/docs/examples/python/.gitignore
new file mode 100644
index 0000000..282522d
--- /dev/null
+++ b/docs/examples/python/.gitignore
@@ -0,0 +1,2 @@
+Makefile
+Makefile.in
diff --git a/gnulib/lib/.gitignore b/gnulib/lib/.gitignore
new file mode 100644
index 0000000..2849ca9
--- /dev/null
+++ b/gnulib/lib/.gitignore
@@ -0,0 +1,23 @@
+*.la
+*.lo
+.deps
+.libs
+Makefile
+Makefile.in
+alloca.h
+arpa_inet.h
+float.h
+netinet_in.h
+poll.h
+stdbool.h
+stdint.h
+stdio-impl.h
+stdio.h
+stdlib.h
+string.h
+sys_select.h
+sys_socket.h
+sys_stat.h
+sys_time.h
+unistd.h
+wchar.h
diff --git a/gnulib/lib/arpa/.gitignore b/gnulib/lib/arpa/.gitignore
new file mode 100644
index 0000000..b9013ae
--- /dev/null
+++ b/gnulib/lib/arpa/.gitignore
@@ -0,0 +1 @@
+inet.h
diff --git a/gnulib/lib/netinet/.gitignore b/gnulib/lib/netinet/.gitignore
new file mode 100644
index 0000000..95f1a2e
--- /dev/null
+++ b/gnulib/lib/netinet/.gitignore
@@ -0,0 +1 @@
+in.h
\ No newline at end of file
diff --git a/gnulib/lib/sys/.gitignore b/gnulib/lib/sys/.gitignore
new file mode 100644
index 0000000..f6e392f
--- /dev/null
+++ b/gnulib/lib/sys/.gitignore
@@ -0,0 +1,4 @@
+select.h
+socket.h
+stat.h
+time.h
\ No newline at end of file
diff --git a/gnulib/tests/.gitignore b/gnulib/tests/.gitignore
new file mode 100644
index 0000000..5b93dc2
--- /dev/null
+++ b/gnulib/tests/.gitignore
@@ -0,0 +1,29 @@
+.deps
+.libs
+Makefile
+Makefile.in
+test-alloca-opt
+test-arpa_inet
+test-fseeko
+test-getaddrinfo
+test-getdelim
+test-getline
+test-lseek
+test-netinet_in
+test-snprintf
+test-stdbool
+test-stdint
+test-stdio
+test-stdlib
+test-string
+test-sys_select
+test-sys_socket
+test-sys_stat
+test-sys_time
+test-unistd
+test-vasnprintf
+test-vasprintf
+test-wchar
+test-EOVERFLOW.c
+test-EOVERFLOW
+test-c-ctype
diff --git a/include/.gitignore b/include/.gitignore
new file mode 100644
index 0000000..282522d
--- /dev/null
+++ b/include/.gitignore
@@ -0,0 +1,2 @@
+Makefile
+Makefile.in
diff --git a/include/libvirt/.gitignore b/include/libvirt/.gitignore
new file mode 100644
index 0000000..282522d
--- /dev/null
+++ b/include/libvirt/.gitignore
@@ -0,0 +1,2 @@
+Makefile
+Makefile.in
diff --git a/po/.gitignore b/po/.gitignore
new file mode 100644
index 0000000..a0b63f3
--- /dev/null
+++ b/po/.gitignore
@@ -0,0 +1,15 @@
+stamp-po
+remove-potcdate.sin
+quot.sed
+insert-header.sin
+*.gmo
+en(a)quot.header
+en(a)boldquot.header
+boldquot.sed
+Rules-quot
+POTFILES
+Makevars.template
+Makefile.in.in
+Makefile.in
+Makefile
+remove-potcdate.sed
diff --git a/proxy/.gitignore b/proxy/.gitignore
new file mode 100644
index 0000000..f3d6ec7
--- /dev/null
+++ b/proxy/.gitignore
@@ -0,0 +1,5 @@
+Makefile
+Makefile.in
+.deps
+.libs
+libvirt_proxy
diff --git a/python/.gitignore b/python/.gitignore
new file mode 100644
index 0000000..079e574
--- /dev/null
+++ b/python/.gitignore
@@ -0,0 +1,14 @@
+Makefile
+Makefile.in
+.deps
+.libs
+*.lo
+*.la
+*.loT
+libvirt.py
+libvirt-export.c
+libvirtclass.txt
+libvirt-py.[ch]
+libvirtclass.py
+gen_prog
+*.pyc
diff --git a/python/tests/.gitignore b/python/tests/.gitignore
new file mode 100644
index 0000000..282522d
--- /dev/null
+++ b/python/tests/.gitignore
@@ -0,0 +1,2 @@
+Makefile
+Makefile.in
diff --git a/qemud/.gitignore b/qemud/.gitignore
new file mode 100644
index 0000000..04fed54
--- /dev/null
+++ b/qemud/.gitignore
@@ -0,0 +1,11 @@
+Makefile
+Makefile.in
+.deps
+.libs
+*.lo
+*.la
+libvirt_qemud
+libvirtd
+libvirtd.init
+*.gcno
+*.gcda
diff --git a/src/.gitignore b/src/.gitignore
new file mode 100644
index 0000000..165a562
--- /dev/null
+++ b/src/.gitignore
@@ -0,0 +1,16 @@
+Makefile
+Makefile.in
+.deps
+.libs
+*.lo
+*.loT
+*.la
+virsh
+*.gcda
+*.gcno
+*.gcov
+*.cov
+libvirt_parthelper
+libvirt_lxc
+virsh-net-edit.c
+virsh-pool-edit.c
diff --git a/tests/.gitignore b/tests/.gitignore
new file mode 100644
index 0000000..f09e6bb
--- /dev/null
+++ b/tests/.gitignore
@@ -0,0 +1,20 @@
+Makefile
+Makefile.in
+.deps
+.libs
+xmlrpctest
+sexpr2xmltest
+xml2sexprtest
+virshtest
+conftest
+reconnect
+xmconfigtest
+xencapstest
+qemuxml2xmltest
+qemuxml2argvtest
+nodeinfotest
+statstest
+qparamtest
+*.gcda
+*.gcno
+
diff --git a/tests/confdata/.gitignore b/tests/confdata/.gitignore
new file mode 100644
index 0000000..282522d
--- /dev/null
+++ b/tests/confdata/.gitignore
@@ -0,0 +1,2 @@
+Makefile
+Makefile.in
diff --git a/tests/sexpr2xmldata/.gitignore b/tests/sexpr2xmldata/.gitignore
new file mode 100644
index 0000000..282522d
--- /dev/null
+++ b/tests/sexpr2xmldata/.gitignore
@@ -0,0 +1,2 @@
+Makefile
+Makefile.in
diff --git a/tests/virshdata/.gitignore b/tests/virshdata/.gitignore
new file mode 100644
index 0000000..282522d
--- /dev/null
+++ b/tests/virshdata/.gitignore
@@ -0,0 +1,2 @@
+Makefile
+Makefile.in
diff --git a/tests/xencapsdata/.gitignore b/tests/xencapsdata/.gitignore
new file mode 100644
index 0000000..282522d
--- /dev/null
+++ b/tests/xencapsdata/.gitignore
@@ -0,0 +1,2 @@
+Makefile
+Makefile.in
diff --git a/tests/xmconfigdata/.gitignore b/tests/xmconfigdata/.gitignore
new file mode 100644
index 0000000..282522d
--- /dev/null
+++ b/tests/xmconfigdata/.gitignore
@@ -0,0 +1,2 @@
+Makefile
+Makefile.in
diff --git a/tests/xml2sexprdata/.gitignore b/tests/xml2sexprdata/.gitignore
new file mode 100644
index 0000000..282522d
--- /dev/null
+++ b/tests/xml2sexprdata/.gitignore
@@ -0,0 +1,2 @@
+Makefile
+Makefile.in
16 years, 5 months
[libvirt] libvirt-qpid
by Ian Main
Howdy folks!
So I've been working on a qpid interface to libvirt. Here's the description
I've come up with:
libvirt-qpid provides an interface with libvirt using QMF (qpid modeling
framework) which utilizes the AMQP protocol. The Advanced Message Queuing
Protocol (AMQP) is an open standard application layer protocol providing
reliable transport of messages.
QMF provides a modeling framework layer on top of qpid. This interface
allows you to manage hosts, domains, pools etc. as a set of objects with
properties and methods.
The source code repo:
http://git.et.redhat.com/?p=libvirt-qpid.git;a=summary
So I'd like to hear any feedback you guys might have. This file in particular
describes the API that is used to interact with libvirt.
http://git.et.redhat.com/?p=libvirt-qpid.git;a=blob_plain;f=src/libvirt-s...
My TODO list looks like this:
- Not sure on camel case or underscores. Original libvirt API uses
camel case, I went with underscores as I was originally basing it off
the ruby bindings.
- Need rc scripts, daemonization, better reconnect/error handling for
both qpid and libvirt. I think it should attempt to reconnect until
successful whenever it gets disconnected. We may need an extra status
property for this state as well.
- Return libvirt error codes? (it's just text msgs right now with error
status bit).
- Make it less chatty, but log stuff
If you wish to try it out, I've made rpms for fedora 9 x86_64 and i386.
They are in the ovirt repo, which you can add to yum using:
rpm -ivh http://ovirt.org/repos/ovirt/9/ovirt-release-LATEST.fc9.noarch.rpm
Once you have that set up, 'yum install libvirt-qpid python-qpid', and then
run (each in their own terminals):
qpidd --auth no
libvirt-qpid (as root to auth with libvirt)
qpid-tool
qpid-tool provides an interface to qpid and allows you to view/manipulate the
qpid models/objects. Here is an example of how it looks using qpid-tool:
$ qpid-tool
Management Tool for QPID
qpid: list
Management Object Types:
ObjectType Active Deleted
============================================
com.redhat.libvirt:domain 2 0
com.redhat.libvirt:node 1 0
qpid: list node
Objects of type com.redhat.libvirt:node
ID Created Destroyed Index
=================================
101 00:02:00 -
qpid: show 101
Object of type com.redhat.libvirt:node: (last sample time: 17:47:54)
Type Element 101
==============================================
property hostname vpro.mains.net
property uri qemu:///system
property libvirt_version 0.4.5
property api_version 0.4.5
property hypervisor_version 0.9.1
property hypervisor_type QEMU
qpid: list domain
Objects of type com.redhat.libvirt:domain
ID Created Destroyed Index
=================================
102 00:02:05 - 101
103 00:02:05 - 101
qpid: show 102
Object of type com.redhat.libvirt:domain: (last sample time: 17:48:09)
Type Element 102
=================================================================
property uuid 662958f8-12c5-baad-2252-4d2126e0971f
property name ovirt-appliance
property node 101
property state shutoff
property num_vcpus 1
property active false
statistic maximum_memory 786432
statistic memory 786432
statistic cpu_time 0
qpid: call 102 create
Call Result: create 0 (OK) {}
qpid: show 102
Object of type com.redhat.libvirt:domain: (last sample time: 17:48:24)
Type Element 102
=================================================================
property uuid 662958f8-12c5-baad-2252-4d2126e0971f
property name ovirt-appliance
property node 101
property state running
property num_vcpus 1
property active true
statistic maximum_memory 786432
statistic memory 786432
statistic cpu_time 0
qpid:
16 years, 5 months
[libvirt] [PATCH] openvz: swap <source bridge=...> with <target dev=...>
by Anton Protopopov
2008/9/29 Evgeniy V. Sokolov <evg(a)parallels.com>
>
>
>> This behaviour contradicts with description found in docs (in which
>> <source> tag specify interface in host, not in container). I think,
>> the previous bridge must be specified as
>> <interface type='bridge'>
>> <mac address='00:16:3e:34:21:9e'/>
>> - <source bridge='eth10'/>
>> + <target dev='eth10'/>
>> </interface>
>>
>> You are right. It is bug.
>>
>> Well, here is the patch, that fixes that behaviour.
>>
>
> Your patch is half of fix. It require to fix openvzReadNetworkConf() in
> openvz_conf.c.
>
Here is a new one. Check it, please.
16 years, 5 months
[libvirt] [PATCH 0 of 2] [RFC] Add cgroup manipulation and LXC driver support
by Dan Smith
This patch set adds basic cgroup support to the LXC driver. It consists of
a small internal cgroup manipulation API, as well as changes to the driver
itself to utilize the support. Currently, we just set a memory limit
and the allowed devices list. The cgroup.{c,h} interface can be easily
redirected to libcgroup in the future if and when the decision to move in
that direction is made.
Some discussion on the following points is probably warranted, to help
determine how deep we want to go with this internal implementation, in terms'
of supporting complex system configurations, etc.
- What to do if controllers are mounted in multiple places
- What to do if memory and device controllers aren't present
- What to do if the root group is set for exclusive cpuset behavior
Some additional caveats are noted per-patch as well.
16 years, 6 months
[libvirt] [PATCH] Fix > 1 char device for qemu VM
by Cole Robinson
Trying to start a qemu guest with more than 1 character
device (serial or parallel, doesn't count for console)
always times out. There was an error in the code that
would strip the pty path qemu spits out, which
confused the parsing after being called more than twice.
The attached patch fixes this. I verified that guests
with 0, 1, and 2 serial devices all boot fine.
Thanks,
Cole
16 years, 6 months
[libvirt] Overriding vnetN with the <target> element in xml configuration not working
by Ahmed Medhat
Hello,
I've been trying to dedicated a vnet interface to each virtual machine
in order to be able to monitor their traffic, looking at
http://libvirt.org/formatdomain.html#elementsNICSBridge it says that a
virtual machine could have a specific vnetN specified in the xml
element <target>, like <target dev='vnet7'/> .
Unfortunately its not working and still it comes with vnet(current+1),
here's my configuration for a qemu-kvm guest.
<interface type='bridge'>
<source bridge='virbr0'/>
<target dev='vnet7'/>
<mac address='00:16:3e:6c:1f:9d'/>
</interface>
I'm running on F9 x86_64,
libvirt-0.4.4-2.fc9.x86_64
libvirt-python-0.4.4-2.fc9.x86_64
kvm-65-7.fc9.x86_64
qemu-0.9.1-6.fc9.x86_64
I haven't yet tested this with a RHEL box to know if it is version
specific issue to open a bugzilla report, any input is appreciated.
/*
|| Thanks, Ahmed Medhat
|| ultimatetux [at] gmail [dot] com
|| +2-012-4184768
|| In a world without walls and fences, who needs Windows and Gates?
*/
16 years, 6 months
