[libvirt] [PATCH 0/3] fix migration of paused vms
by Paolo Bonzini
From: Paolo Bonzini <pbonzini(a)gnu.org>
This is yet another try on fixing migration of paused vms. Since the
driver-only solution didn't work out, I'm now fixing it directly in
libvirt.c.
The first two patches are the same as for the previous series. The
first is a bugfix for failed migration for the QEMU driver; the second
adds a "virsh migrate --suspend" option to leave the VM not running
on the destination machine.
As in the previous version of the patch, --suspend/VIR_MIGRATE_PAUSED
is the bulk of implementing the new feature. I just query the domain
state and, if it is paused, I implicitly add the VIR_MIGRATE_PAUSED
flag to the migration. This is the third patch.
I thought about transmitting the state in the end (since it works well
if VIR_MIGRATE_PAUSED is passed only to MigrateFinish and not to
MigratePerform), but I don't think it's a good idea to commit it
now as it's basically untestable. It's in the fourth patch, but if
you want it now and think the approach is sound, tell me and I'll
test it more heavily.
15 years, 4 months
[libvirt] [PATCH 0/2] Xen: Add support for interface model='netfront'
by Jiri Denemark
Xen HVM guests with PV drivers end up with two network interfaces for
each configured interface. One of them being emulated by qemu and the
other one paravirtual. As this might not be desirable, the attached
patch provides a way for users to specify that only paravirtual network
interface should be presented to the guest.
The configuration was inspired by qemu/kvm driver, for which users can
specify model='virtio' to use paravirtual network interface.
The patch adds support for model='netfront' which results in
type=netfront instead of type=ioemu (or nothing for newer xen versions)
in guests native configuration. Xen's qemu ignores interfaces with
type != ioemu and only paravirtual network device will be seen in the
guest.
Four possible configuration scenarios follow:
- no model specified in domain's XML
- libvirt will behave like before this change; it will set
type=ioemu for HVM guests on xen host which is not newer than
XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU
- covered by existing tests
- PV guest, any model
- no functional change, model is passed as is (and ignored by the
hypervisor)
- covered by existing tests (e.g., *-net-e1000.*)
- HVM guest, model=netfront
- type is set to "netfront", model is not specified
- covered by new *-net-netfront.* tests
- HVM guest, model != netfront
- type is set to "ioemu", model is passed as is
- covered by new *-net-ioemu.* tests
The fourth scenario feels like a regression for xen newer than
XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU as users who had a model specified
in their guest's configuration won't see a paravirtual interface in
their guests any more. On the other hand, the reason for specifying a
model is most likely the fact that they want to use such model which
implies emulated interface. Users of older xen won't be affected at all
as their xen provides paravirtual interface regardless of the type used.
In previous version of this patch, I used "xenpv" instead of "netfront"
as it looked more like kvm/qemu's virtio. However, you can find several
tips how to force PV network interface for HVM guest by using
type="netfront" so I changed it to conform with those tips. It also
matches guest's driver name used for that device.
Jiri Denemark (2):
Support for interface model='netfront'
Tests for interface type/model configuration
src/xen/xend_internal.c | 32 +++++++++++----
src/xen/xm_internal.c | 38 +++++++++++++++--
tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr | 1 +
tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml | 42 +++++++++++++++++++
.../sexpr2xmldata/sexpr2xml-fv-net-netfront.sexpr | 1 +
tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml | 42 +++++++++++++++++++
tests/sexpr2xmltest.c | 3 +
tests/xmconfigdata/test-fullvirt-net-ioemu.cfg | 25 +++++++++++
tests/xmconfigdata/test-fullvirt-net-ioemu.xml | 43 ++++++++++++++++++++
tests/xmconfigdata/test-fullvirt-net-netfront.cfg | 25 +++++++++++
tests/xmconfigdata/test-fullvirt-net-netfront.xml | 43 ++++++++++++++++++++
tests/xmconfigtest.c | 3 +
tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr | 1 +
tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml | 31 ++++++++++++++
.../xml2sexprdata/xml2sexpr-fv-net-netfront.sexpr | 1 +
tests/xml2sexprdata/xml2sexpr-fv-net-netfront.xml | 31 ++++++++++++++
tests/xml2sexprtest.c | 3 +
17 files changed, 352 insertions(+), 13 deletions(-)
create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr
create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml
create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.sexpr
create mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml
create mode 100644 tests/xmconfigdata/test-fullvirt-net-ioemu.cfg
create mode 100644 tests/xmconfigdata/test-fullvirt-net-ioemu.xml
create mode 100644 tests/xmconfigdata/test-fullvirt-net-netfront.cfg
create mode 100644 tests/xmconfigdata/test-fullvirt-net-netfront.xml
create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr
create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml
create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-netfront.sexpr
create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-netfront.xml
15 years, 4 months
[libvirt] Move esxVMX_IndexToDiskName to util.c
by Matthias Bolte
I needed the inverse function to virDiskNameToIndex() for the ESX
driver and added it to esx_vmx.c. The pending VirtualBox 3.1 patch
needs disk index to disk name mapping too. So I want to move
esxVMX_IndexToDiskName() to util.c.
esxVMX_IndexToDiskName() handles indices up to 701. This limit comes
from a gap in the disk name to disk index mapping of
virDiskNameToIndex():
sdzy -> 700
sdzz -> 701
sdaaa -> 728
sdaab -> 729
This line in virDiskNameToIndex() causes this gap:
idx = (idx + i) * 26;
It can be fixed by altering this line to:
idx = (idx + (i < 1 ? 0 : 1)) * 26;
But this change breaks compatibility for indices > 701.
So, I made two patches for either option and ask you for comments.
Matthias
15 years, 4 months
[libvirt] Eventtest unit test failure
by Soren Hansen
Hi, guys.
I've changed the libvirt package in Ubuntu to run the test suite with
every build. However, on our build daemons, the eventtest unit test
seems to almost[1] consistently fail. You can see an example build log
here:
http://launchpadlibrarian.net/36196282/buildlog_ubuntu-lucid-amd64.libvir...
Does this look familiar to anyone? Any idea what might be causing this?
FWIW, I cannot reproduce it locally, so it's likely environmental, but
at this point, I don't really know where to begin to look.
[1]: It actually succeeds on sparc and armel :-/
--
Soren Hansen |
Lead virtualisation engineer | Ubuntu Server Team
Canonical Ltd. | http://www.ubuntu.com/
15 years, 4 months
[libvirt] how do I stop libvirt futzing with my network configuration?
by Nix
So I have an existing QEMU/KVM setup with networks connected to a bridge
which is routed/forwarded to the host's other interfaces. I'm trying
to switch to administering at least *some* of its VMs through libvirt
(probably not all as I use QEMU snapshots extensively for some of them
and libvirt doesn't support that yet, if ever). So libvirt has to be
able to start guests connected to a particular host bridge, and give them
appropriate IP addresses.
I thought it was easy to teach libvirt about this:
spindle:/etc/libvirt/qemu/networks# cat /etc/libvirt/qemu/networks/default.xml
<network>
<name>default</name>
<uuid>ee573497-1d74-473b-a2cb-9916229209b8</uuid>
<forward mode='route'/>
<bridge name='vm-net' stp='on' delay='0' />
<ip address='192.168.20.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.20.1' end='192.168.20.254' />
</dhcp>
</ip>
</network>
However, there appears to be no way to say 'this is what the network is
already like'. That network is considered 'inactive' and can't be used by
any guests, and if I try to make it active, I get this:
virsh # net-start default
error: Failed to start network default
error: cannot create bridge 'vm-net': File exists
Of course it bloody can't create that bridge: it's already there, has an
IP address on the host, and has the host routing packets to it. There
appears to be no option to allow libvirt to assign IPs on the host...
... should I fix that, 'net-start' tries to update iptables rules!
How should I put this: I do not *not not* want libvirt pissing with the
firewall in any way at all. If I want firewall rules, I'll create them.
But there's no way to tell it 'hands off! This network is already active,
don't try to *make* it active!'
... at least, there's none in the documentation, and there's none in the
code that I can see.
Or is there?
15 years, 4 months
Re: [libvirt] how do I stop libvirt futzing with my network configuration?
by Ian Woodstock
----- "Nix" <nix(a)esperi.org.uk> wrote:
> From: "Nix" <nix(a)esperi.org.uk>
> To: "Daniel P. Berrange" <berrange(a)redhat.com>
> Cc: libvir-list(a)redhat.com
> Sent: Saturday, November 28, 2009 4:10:28 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [libvirt] how do I stop libvirt futzing with my network configuration?
>
> On 26 Nov 2009, Daniel P. Berrange spake thusly:
>
> > On Thu, Nov 26, 2009 at 06:25:07PM +0000, Nix wrote:
> >> However, there appears to be no way to say 'this is what the network is
> >> already like'. That network is considered 'inactive' and can't be used by
> >> any guests, and if I try to make it active, I get this:
> >>
> >> virsh # net-start default
> >> error: Failed to start network default
> >> error: cannot create bridge 'vm-net': File exists
> >>
> >> Of course it bloody can't create that bridge: it's already there, has an
> >> IP address on the host, and has the host routing packets to it. There
> >> appears to be no option to allow libvirt to assign IPs on the host...
> >>
> >> ... should I fix that, 'net-start' tries to update iptables rules!
> >> How should I put this: I do not *not not* want libvirt pissing with the
> >> firewall in any way at all. If I want firewall rules, I'll create them.
> >> But there's no way to tell it 'hands off! This network is already active,
> >> don't try to *make* it active!'
> >
> > If you don't want libvirt to create the bridge + setup IPtables rules
> > then don't use the net-XXX commands / XML. That functionality is
> > not there for pointing libvirt to existing bridge devices.
> >
> > If you already have a bridge configured, then just point the guest
> > directly at that bridge by name.
>
> OK, I still can't make this work: it worked briefly but then stopped.
> As far as I can tell tools like virt-manager are unwilling to *let* you
> connect to a network considered 'inactive', and networks are only
> considered active if they have a configuration file under
> /var/run/libvirt/network. These files are only created if libvirt has
> created the bridge itself as well. If no networks are considerd active,
> virt-manager won't let you create a guest at all: it insists on trying
> to start the sodding network, and when that fails doesn't let you get
> any further.
>
I've been running with this configuration for many months on dozens of hosts.
- Created a bridge (the old fashion way) in /etc/sysconfig/network-scripts
Bridge called br0 with one device eth1.
- Created a VM in virt manager (or edit existing)
Picked "Shared Physical Device" Device "eth1 (Bridge br0)" in the GUI.
Or just add it to the VMs XML
<interface type='bridge'>
<mac address='52:54:00:4f:0a:76'/>
<source bridge='br0'/>
</interface>
Works like a charm and there's certainly no configuration in libvirt
for this interface, ie. nothing in /var/run/libvirt/network, and
*nothing* set up in Virt Manager under "Host Details->Virtual networks
You do need to make sure that you disable netfilter on the bridge or
setup the appropriate iptables rules ( see
http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shar...)
> So as far as I can tell, if you don't want libvirt creating all your
> bridges for you, you may as well give up hope of using virt-manager, or
> start hacking all this stuff out of the source.
>
> I hoped I could use libvirt in conjunction with raw qemu. So much for
> that, it seems :( it *really* wants to take over the world...
>
>
> (aside: ideally I should not have to spend half an hour crawling around
> the source to figure this out. The only other program I've ever seen
> that was this hard to set up was Oracle! Whole *Linux distros* take less
> work than this. I have half a dozen patches I'll send your way, but I
> wasn't going to send any of them until I'd actually managed to get a VM
> working. I got one up last night, somehow -- I no longer have any idea
> how, obviously one network had somehow got marked active -- whereupon
> KVM fell over. *sigh*)
>
> --
> Libvir-list mailing list
> Libvir-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
15 years, 4 months
[libvirt] [PATCH v2] Disk- and Controller Hotplug
by wolfgang.mauerer＠siemens.com
Hi,
this is the second revision of a patch series to improve disk
hotadd support for libvirt. It focuses on the qemu backend, but
is naturally designed to be compatible with other backends as
well. The objective is two-fold:
1.) Split off controller from disk handling. This is done by
introducing a new domain element <controller> that is used to
describe disk controllers. Support for hotplugging such
controllers is added. Support to reference controllers by
name is also included.
2.) <disk>s can now be associated with a specific controller;
this is done by means of a <controller> subelemnt for disks.
This patch addresses the questions that were raised during the
review of the initial submission, massages the code by fixing
some whitespace issues, gets static controller configurations to
work, and adds documentation. Notice that in contrast to the
first submission I did not include the patch that adds support
for disk- and controller hot_remove_. Since the qemu codebase is
still in bit of a flux wrt. the necessary patches required for
this functionality, it will reappear some time later as a
separate submission.
Best,
Wolfgang
daemon/libvirtd.c | 2 +-
docs/formatdomain.html.in | 38 +++++
docs/schemas/domain.rng | 158 ++++++++++++++++-----
src/conf/domain_conf.c | 314 +++++++++++++++++++++++++++++++++++++++++-
src/conf/domain_conf.h | 62 ++++++++-
src/libvirt_private.syms | 7 +-
src/qemu/qemu_driver.c | 184 +++++++++++++++++++++++--
src/qemu/qemu_monitor_text.c | 197 ++++++++++++++++++++++++++
src/qemu/qemu_monitor_text.h | 7 +
9 files changed, 910 insertions(+), 59 deletions(-)
--
Siemens AG, CT T DE
Corporate Competence Centre Embedded Linux
15 years, 4 months
[libvirt] questions on build qemu driver with non-root
by Shi Jin
Hi there,
I have been successful in building the latest libvirt code from the git repository. The options I used to build is
./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --without-xen --with-qemu --with-qemu-user=oneadmin --with-qemu-group=oneadmin --without-uml --without-vbox --without-openvz --without-lxc
Please note that I have specified qemu user and group to be non-root.
So far the libvirtd service and virsh both seem to work fine but I have a few issues
1. Before running "virsh create", the image belongs to user oneadmin. During the run, it still does. But the as soon as I shutdown/destroy the instance, the image ownership changes to
-rw-rw—— 1 root root
I don't understand why. Is this a bug?
2. From the documentation at http://libvirt.org/drvqemu.html, the directories /var/run/libvirt/qemu/, /var/lib/libvirt/qemu/ and /var/cache/libvirt/qemu/ must all have their ownership set to oneadmin:oneadmin. However, mine are still set to root:root and it does not seem to affect the running of libvirt/qemu/kvm. For example,
oneadmin@test2:~$ ls /var/run/libvirt/qemu -la
total 8
drwxr-xr-x 2 root root 80 2009-11-27 13:22 .
drwxr-xr-x 3 root root 100 2009-11-27 13:07 ..
-rw------- 1 root root 4 2009-11-27 13:22 client.pid
-rw------- 1 root root 1250 2009-11-27 13:22 client.xml
3. The libvirtd service still shows the warning message:
warning : qemudStartup:904 : Unable to create cgroup for driver: No such device or address
I read from earlier posts that the --without-lxc option should get rid of this message.
Thank you for your help.
--
Shi Jin, PhD
15 years, 4 months
