[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, 1 month
[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, 6 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, 8 months
[libvirt] Two issues regarding TFTP support in virtual networks...
by Darryl L. Pierce
The first is just a wiki fix: the wiki says this functionality is
available as of 0.7.1 of libvirt. The code though is only in the 0.7.2
tag and later. So the wiki should say 0.7.2 instead.
The second regards how I'm using it and what I'm doing wrong. I'm
creating a virtual network and pointing it to a temporary directory
where I've run livecd-iso-to-pxeboot to setup an ISO file for PXE
booting. So the network XML looks like this:
(mcpierce@mcpierce-desktop:node-image)$ sudo virsh net-dumpxml testbr541
<network>
<name>testbr541</name>
<uuid>f389317f-8420-7516-df9d-756b7deb3d37</uuid>
<forward mode='nat'/>
<bridge name='testbr541' stp='on' delay='0' />
<ip address='192.168.31.1' netmask='255.255.255.0'>
<tftp root='/tmp/tmp.3B8opJfBXw/tftpboot/' />
<dhcp>
<range start='192.168.31.100' end='192.168.31.199' />
</dhcp>
</ip>
</network>
When I start up the VM, I see it get an IP address within the range
specified, but it never pxeboots the ISO image.
To what directory should the root attribute be pointed?
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
14 years, 9 months
[libvirt] [PATCH 1/3] Make sure that the vmx2xml test data files are shipped in the distribution.
by Diego Elio Pettenò
Without these files the tests will fail when ESX support is enabled.
---
tests/Makefile.am | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 63 insertions(+), 1 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 335b0e5..cf51162 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -47,6 +47,67 @@ qemuhelpdata = \
qemu-kvm-0.10.5 \
qemu-kvm-0.11.0-rc2
+vmx2xmldata = \
+ vmx2xml-cdrom-ide-device.vmx \
+ vmx2xml-cdrom-ide-device.xml \
+ vmx2xml-cdrom-ide-file.vmx \
+ vmx2xml-cdrom-ide-file.xml \
+ vmx2xml-cdrom-scsi-device.vmx \
+ vmx2xml-cdrom-scsi-device.xml \
+ vmx2xml-cdrom-scsi-file.vmx \
+ vmx2xml-cdrom-scsi-file.xml \
+ vmx2xml-esx-in-the-wild-1.vmx \
+ vmx2xml-esx-in-the-wild-1.xml \
+ vmx2xml-esx-in-the-wild-2.vmx \
+ vmx2xml-esx-in-the-wild-2.xml \
+ vmx2xml-esx-in-the-wild-3.vmx \
+ vmx2xml-esx-in-the-wild-3.xml \
+ vmx2xml-esx-in-the-wild-4.vmx \
+ vmx2xml-esx-in-the-wild-4.xml \
+ vmx2xml-ethernet-bridged.vmx \
+ vmx2xml-ethernet-bridged.xml \
+ vmx2xml-ethernet-custom.vmx \
+ vmx2xml-ethernet-custom.xml \
+ vmx2xml-ethernet-e1000.vmx \
+ vmx2xml-ethernet-e1000.xml \
+ vmx2xml-floppy-device.vmx \
+ vmx2xml-floppy-device.xml \
+ vmx2xml-floppy-file.vmx \
+ vmx2xml-floppy-file.xml \
+ vmx2xml-gsx-in-the-wild-1.vmx \
+ vmx2xml-gsx-in-the-wild-1.xml \
+ vmx2xml-gsx-in-the-wild-2.vmx \
+ vmx2xml-gsx-in-the-wild-2.xml \
+ vmx2xml-gsx-in-the-wild-3.vmx \
+ vmx2xml-gsx-in-the-wild-3.xml \
+ vmx2xml-gsx-in-the-wild-4.vmx \
+ vmx2xml-gsx-in-the-wild-4.xml \
+ vmx2xml-harddisk-ide-file.vmx \
+ vmx2xml-harddisk-ide-file.xml \
+ vmx2xml-harddisk-scsi-file.vmx \
+ vmx2xml-harddisk-scsi-file.xml \
+ vmx2xml-minimal-64bit.vmx \
+ vmx2xml-minimal-64bit.xml \
+ vmx2xml-minimal.vmx \
+ vmx2xml-minimal.xml \
+ vmx2xml-parallel-device.vmx \
+ vmx2xml-parallel-device.xml \
+ vmx2xml-parallel-file.vmx \
+ vmx2xml-parallel-file.xml \
+ vmx2xml-scsi-buslogic.vmx \
+ vmx2xml-scsi-buslogic.xml \
+ vmx2xml-scsi-writethrough.vmx \
+ vmx2xml-scsi-writethrough.xml \
+ vmx2xml-serial-device.vmx \
+ vmx2xml-serial-device.xml \
+ vmx2xml-serial-file.vmx \
+ vmx2xml-serial-file.xml \
+ vmx2xml-serial-pipe-client-app.vmx \
+ vmx2xml-serial-pipe-client-vm.vmx \
+ vmx2xml-serial-pipe-server-app.vmx \
+ vmx2xml-serial-pipe-server-vm.vmx \
+ vmx2xml-serial-pipe.xml
+
EXTRA_DIST = \
oomtrace.pl \
test-lib.sh \
@@ -69,7 +130,8 @@ EXTRA_DIST = \
storagevolxml2xmlin \
nodedevschematest \
nodedevschemadata \
- $(patsubst %,qemuhelpdata/%,$(qemuhelpdata))
+ $(patsubst %,qemuhelpdata/%,$(qemuhelpdata)) \
+ $(patsubst %,vmx2xmldata/%,$(vmx2xmldata))
noinst_PROGRAMS = virshtest conftest \
nodeinfotest statstest qparamtest
--
1.6.6.rc4
14 years, 11 months
[libvirt] [PATCH v2 0/2] Block assignment of PCI devices below non-ACS capable switch
by Jiri Denemark
This is a patchset for blocking assignment of PCI devices below non-ACS
capable switch. In case user still wants to assign such device even though it
might not be safe, she can specify 'relaxed_acs_check = 1' in qemu.conf
Special thanks to Chris L. who created a standalone program the PCI check.
This code is a port of that check to libvirt.
Changes in version 2:
- permissive attribute for <hostdev> was removed
- new 'relaxed_acs_check' config option in qemu.conf for relaxing the check
Jiri Denemark (2):
Tests for ACS in PCIe switches
Use pciDeviceIsAssignable in qemu driver
src/libvirt_private.syms | 1 +
src/qemu/libvirtd_qemu.aug | 1 +
src/qemu/qemu.conf | 6 ++
src/qemu/qemu_conf.c | 4 +
src/qemu/qemu_conf.h | 2 +
src/qemu/qemu_driver.c | 6 ++-
src/qemu/test_libvirtd_qemu.aug | 6 ++-
src/util/pci.c | 151 +++++++++++++++++++++++++++++++++++++++
src/util/pci.h | 4 +
9 files changed, 179 insertions(+), 2 deletions(-)
14 years, 11 months
[libvirt] Re: [virt-tools-list] Questions about virt-manager running on Arch of Itanium 64
by Cole Robinson
cc-ing libvirt-list
On 11/19/2009 10:35 PM, Dustin Xiong wrote:
>
>
>>> Hi everyone!
>>> I am a newer to the virt-manager and maillist. I sent the mail just want
>>> to ask some questions about virt-manager running on Arch of Itanium 64.
>>> My itanium 64 cpu actualy support the VT. I compiled the kvm85
>>> successful. Then I can use the binary /usr/local/bin/qemu-system-ia64 to
>>> create a vm and running. But in my /proc/cpuinfo , there doesn't have
>>> flags such as vmx or svm. So when I use the virt-manager to install a
>>> vm, the virt-manager will tell me my cpu doesn't support fully
>>> virtualization, then I can't install vm. In fact I can't get understand
>>> how the virt-manager find my cpu support the fully virtualization or
>>> not.In src, which file implements this.
>>>
>>
>> Just because qemu-kvm works doesn't mean virt is working on your box, since it
>> can fall back to full emulation mode. If you are trying to use kvm, is the kvm
>> module actually loaded? lsmod | grep kvm
>
> My kvm mod actually loaded.
>
> [root@kvm bin]# lsmod | grep kvm
>
> kvm_intel 306104 4294967281
>
> kvm 327544 1 kvm_intel
>
>
>
> [root@kvm bin]# modinfo kvm
>
> filename: /lib/modules/2.6.28.9hzp/extra/kvm.ko
>
> license: GPL
>
> author: Qumranet
>
> version: kvm-85
>
> srcversion: C399DD2D9B40BAAC05CD509
>
> depends:
>
> vermagic: 2.6.28.9hzp SMP mod_unload modversions ia64gcc-4.1
>
>> If so, libvirt may need to be fixed. What's the output of 'virsh --connect
>> qemu:///system capabilities'
>
> [root@kvm bin]# virsh --connect qemu:///system capabilities
> <capabilities>
>
> <host>
> <cpu>
> <arch>ia64</arch>
> </cpu>
> <topology>
> <cells num='1'>
> <cell id='0'>
> <cpus num='16'>
> <cpu id='0'/>
> <cpu id='1'/>
> <cpu id='2'/>
> <cpu id='3'/>
> <cpu id='4'/>
> <cpu id='5'/>
> <cpu id='6'/>
> <cpu id='7'/>
> <cpu id='8'/>
> <cpu id='9'/>
> <cpu id='10'/>
> <cpu id='11'/>
> <cpu id='12'/>
> <cpu id='13'/>
> <cpu id='14'/>
> <cpu id='15'/>
> </cpus>
> </cell>
> </cells>
> </topology>
> </host>
>
>
>>> My cpu is itanium 64, the OS is RHEL.The libvirt is 0.6.3, virt-manager
>>> is 0.6.1.
Ah, are you using the version of libvirt that comes with RHEL 5.4? That
version has been patched to only look for the qemu-kvm binary in one
spot: /usr/libexec/qemu-kvm IIRC. You could try to work with that, but
since you are already building upstream KVM, virt-manager, and virtinst,
might not be a bad idea to pull upstream libvirt as well.
>>> Once i tried to compile the virt-manager-0.8.0, but when i make check,
>>> it returns:
>>>
>>> PYTHONPATH=./..:../graphWidgets/.libs python addhardware.py && touch
>>> .tstamp.addhardware.py
>>> Traceback (mos! t recent call last):
>>> File "addhardware.py", line 32, in ?
>>> from virtinst import VirtualCharDevice, VirtualDevice,
>>> VirtualVideoDevice
>>>
>>> when i rpm -ivh virt-manager-0.6.1-8.el5.ia64.rpm, it could work.
>>>
>>> I don't know why this error occur. Can anyone be kind to tell me how?
>>> thanks a lot.
>>>
>>
>> You will also need to install the latest version of virtinst, found at:
>>
>> http://virt-manager.org/download.html
>
> I downloaded and compiled the latest version of virtinst: virtinst-0.500.0.tar.gz.
> then compile the virt-manager-0.8.0, error changed as below:
>
> [root@kvm virt-manager-0.8.0]# make check
> Making check in src
> make[1]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src'
> Making check in virtManager
> make[2]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager'
> make check-local
> make[3]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager'
> PYTHONPATH=./..:../graphWidgets/.libs python about.py && touch .tstamp.about.py
> PYTHONPATH=./..:../graphWidgets/.libs python addhardware.py && touch .tstamp.addhardware.py
> Traceback (most recent call last):
> File "addhardware.py", line 35, in ?
> from virtManager.asyncjob import vmmAsyncJob
> File "/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager/asyncjob.py", line 30, in ?
> class vmmAsyncJob(gobject.GObject):
> File "/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager/asyncjob.py", line 40, in vmmAsyncJob
> def __init__(self, config, callback, args=None,
> NameError: name '_' is not defined
>
> Thanks for help.If you need any further infos please dont't hesitate to tell me.
>
Ah, didn't notice the make check in the first mail. 'make check' doesn't
work in the virt-manager code base, never taken the time to fix it. You
should just be able to 'make && make install', or 'make' and python
src/virt-manager.py to run from the source dir. If running virt-manager
then throws an error, report here and Ill try to help.
- Cole
14 years, 11 months
[libvirt] Some questions about the libvirt ESX driver
by Richard W.M. Jones
I'm playing with VMWare ESX 4.0 and I decided to try driving it from
libvirt [git version]. Here are some random questions and issues I
encountered, in no particular order.
Listing domains works fine, but:
(a) I have to specify ?no_verify=1 to get it to ignore the lack of
valid https certificate. Is there some documentation on how to set up
certificates correctly? [vSphere gives exactly the same error]
(b) I have to type the root password (of the ESX server) each time.
Can I avoid that?
$ sudo ./tools/virsh -c 'esx://192.168.2.121/?no_verify=1' list --all
Enter username for 192.168.2.121 [root]:
Enter root password for 192.168.2.121:
Id Name State
----------------------------------
- TestLinux shut off
- TestWin shut off
(c) Starting domains doesn't seem to work, and the error message is
obscure:
$ sudo ./tools/virsh -c 'esx://192.168.2.121/?no_verify=1' start TestLinux
Enter username for 192.168.2.121 [root]:
Enter root password for 192.168.2.121:
error: Failed to start domain TestLinux
error: internal error HTTP response code 500 for call to 'PowerOnVM_Task'. Fault: ServerFaultCode - The operation is not allowed in the current state.
Is this to do with the "ask questions" API that was discussed on this
list before? Specifying auto_answer=0 or auto_answer=1 didn't make
any difference.
(d) dumpxml XML output looks very good, and consistent with the other
drivers. However it produces an odd <source file> attribute:
<disk type='file' device='disk'>
<driver name='lsilogic'/>
<source file='[Storage1] TestLinux/TestLinux.vmdk'/>
<target dev='sda' bus='scsi'/>
</disk>
<disk type='file' device='cdrom'>
<source file='[Storage1] Fedora-12-x86_64-Live.iso'/>
<target dev='hdc' bus='ide'/>
</disk>
(e) pool-list, net-list are not supported by the driver.
That's a particular problem for me because I was really hoping to use
the storage APIs from libvirt to access the VMDK files that contain
domains (eg. [Storage1] TestLinux/TestLinux.vmdk in the example
above). Is support for storage (particularly) and/or networks on the
horizon for this driver?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
14 years, 11 months
[libvirt] [Patch v0.5] iSCSI Multi-IQN (Libvirt Support)
by Shyam Iyer
This patch set realizes the multi-IQN concept discussed in an earlier thread http://www.mail-archive.com/libvir-list@redhat.com/msg16706.html
And here .. http://www.mail-archive.com/libvir-list@redhat.com/msg17499.html
The patch realizes an XML schema like the one below and allows libvirt to read through it to create storage pools.
These XMLs when created using a virtualization manager realize unique VM to storage LUN mappings through a single console and thus opening up possibilities for the following scenarios -
* possibility of multiple IQNs for a single Guest
* option for hypervisor's initiator to use these IQNs on behalf of the guest
Change Log from v0.4:
1) Set default tab space to 4(Hopefully this is corrected this time ;) )
2) Review comments from Dave Allan
a) Use output of "iscsiadm -m iface" to search for existing iqn names in the iface files.
3) Create new unique iface file names for user provided iqn names if the iqns are not present in the existing iface files.
Change Log from v0.3:
1) Set default tab space to 4
2) Use Case Description for Commit Log
3) Review comments from Dave Allan
a) No initiator iqn in the xml would mean use of the default initiator iqn name
b) Initiator iqn provided would mean a unique session to be created using the provided iqn name.
c) Single iSCSI session per pool
4) Added syntax in doc/schemas/storagepool.rng
There are no new errors introduced by this patch with "make check" and "make syntax-check" tests.
Signed-off-by: Sudhir Bellad <sudhir_bellad(a)dell.com>
Signed-off-by: Shyam Iyer <shyam_iyer(a)dell.com>
14 years, 11 months
