[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
2 weeks, 6 days
[libvirt] Supporting vhost-net and macvtap in libvirt for QEMU
by Anthony Liguori
Disclaimer: I am neither an SR-IOV nor a vhost-net expert, but I've CC'd
people that are who can throw tomatoes at me for getting bits wrong :-)
I wanted to start a discussion about supporting vhost-net in libvirt.
vhost-net has not yet been merged into qemu but I expect it will be soon
so it's a good time to start this discussion.
There are two modes worth supporting for vhost-net in libvirt. The
first mode is where vhost-net backs to a tun/tap device. This is
behaves in very much the same way that -net tap behaves in qemu today.
Basically, the difference is that the virtio backend is in the kernel
instead of in qemu so there should be some performance improvement.
Current, libvirt invokes qemu with -net tap,fd=X where X is an already
open fd to a tun/tap device. I suspect that after we merge vhost-net,
libvirt could support vhost-net in this mode by just doing -net
vhost,fd=X. I think the only real question for libvirt is whether to
provide a user visible switch to use vhost or to just always use vhost
when it's available and it makes sense. Personally, I think the later
makes sense.
The more interesting invocation of vhost-net though is one where the
vhost-net device backs directly to a physical network card. In this
mode, vhost should get considerably better performance than the current
implementation. I don't know the syntax yet, but I think it's
reasonable to assume that it will look something like -net
tap,dev=eth0. The effect will be that eth0 is dedicated to the guest.
On most modern systems, there is a small number of network devices so
this model is not all that useful except when dealing with SR-IOV
adapters. In that case, each physical device can be exposed as many
virtual devices (VFs). There are a few restrictions here though. The
biggest is that currently, you can only change the number of VFs by
reloading a kernel module so it's really a parameter that must be set at
startup time.
I think there are a few ways libvirt could support vhost-net in this
second mode. The simplest would be to introduce a new tag similar to
<source network='br0'>. In fact, if you probed the device type for the
network parameter, you could probably do something like <source
network='eth0'> and have it Just Work.
Another model would be to have libvirt see an SR-IOV adapter as a
network pool whereas it handled all of the VF management. Considering
how inflexible SR-IOV is today, I'm not sure whether this is the best model.
Has anyone put any more thought into this problem or how this should be
modeled in libvirt? Michael, could you share your current thinking for
-net syntax?
--
Regards,
Anthony Liguori
1 year, 5 months
[libvirt] process= support for 'qemu-kvm -name' [Bug 576950]
by John Morrissey
I wrote (attached here, and to the bug) a quick patch that sets the process
name to the same value as the window title.
I'm unsure where to go from here. Should I add support for converting
"native" QEMU command lines to libvirt XML? What would that look like, since
I'm not modifying the libvirt format? Should it just drop any ,process= from
the QEMU command line it's parsing? I also imagine the test cases will need
updating.
If someone could give me some high-level guidance, I'd be happy to keep
going on this.
john
--
John Morrissey _o /\ ---- __o
jwm(a)horde.net _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
14 years, 4 months
[libvirt] inability to open local read-only connection
by Tavares, John
I have been experimenting with using libvirt (0.3.3) on a variety of systems (RHEL, CentOS and Oracle VM). I have run into an issue when I try to open a local read-only connection to the hypervisor that is failing only on Oracle VM server release 2.2.0. I have created a root owned setuid executable that is effectively running as root, but even so, still cannot open the local read-only connection of the hypervisor. It only works if I run it directly as root. This is not an option. I do not understand why it works as is on my RHEL and CentOS machines, but not my Oracle machine. It would seem as thought it is not checking if the effective uid is root, just the uid.
Has anyone run into a similar issue or have any suggestions of what I might try to fix this issue or can tell me that this is a defect that needs (is) fixed??
Thanks.
14 years, 7 months
[libvirt] Don't add iptables rules when creating networks
by Felix Schwarz
Hi,
I just found out that libvirt always add some iptables rules if it creates a
natted (or routed) network. There were a couple of mailing list posts about
this so I'm pretty sure this is not news to you.
I don't want to go into the debate if your approach is sensible or not (I
guess there are some use cases where I kind of like it). However on my server
machine I really need full control over my (rather complicated) firewall
settings.
Currently the newly added rules really create a lot of problems for me. For
example if I manage to have a good configuration after startup and then start
a libvirt network afterwards, it will inject its rules at the start of the
FORWARD queue (even though the same parameters are already present at the
end!). On every net start there will be more duplicated rules and they will
take preference over my existing rules.
Besides that specific issue I think this is only one tiny problem compared to
others (central configuration of firewall rules, auditing requirements, ...).
Therefore I would like to have some kind 'power user' flag that prevents
libvirt from adding any filter rules. I'm fine with activating it manually as
long as I don't have to patch libvirt.
fs
14 years, 9 months
[libvirt] [PATCH 0/1] port profile id
by David Allan
The following proof of concept patch attempts to show how we might support the use of port profile IDs. The ID would be associated with an interface on a VM and provided to the network infrastructure at VM start time. Since the interfaces by which the id can be provided are still in flux, the use function is only a stub.
Dave
David Allan (1):
Initial POC of port profile id support
docs/schemas/domain.rng | 8 ++++++++
src/conf/domain_conf.c | 12 ++++++++++++
src/conf/domain_conf.h | 1 +
src/libvirt_private.syms | 3 +++
src/qemu/qemu_conf.c | 12 ++++++++++++
src/util/macvtap.c | 13 +++++++++++++
src/util/macvtap.h | 4 ++++
7 files changed, 53 insertions(+), 0 deletions(-)
14 years, 11 months
[libvirt] cannot start a qemu64 model on an Intel host
by Dan Kenigsberg
If I specify
<cpu match="exact">
<model>qemu64</model>
</cpu>
according to the new cpu schema, I get
error: internal error guest CPU is not compatible with host CPU
because qemu64 supports svm, and my host does not.
However, the error remains when I explicitly ask to disable svm with
<feature policy="disable" name="svm"/>
I am not sure if this is a bug or an intended feature, but I'd expect
cpu_disable taken into account when doing
x86ModelCompare(host_model, cpu_require)
Regards,
Dan.
14 years, 11 months
