[libvirt] [PATCH 0/4] Support for limiting guest coredumps
by Martin Kletzander
This series applies on the disable_s3/s4 series [1] and works with
qemu patch [2] (not applied yet), so it shouldn't be pushed before
the qemu part is.
Basically qemu supports marking guest memory as (not)dumpable using
madvise(2) system call and in case the guest memory is not desired the
option can reduce the coredump by a reasonable size.
Martin
[1] https://www.redhat.com/archives/libvir-list/2012-August/msg00572.html
[2] http://lists.nongnu.org/archive/html/qemu-devel/2012-08/msg00554.html
Martin Kletzander (4):
Add support for limiting guest coredump
qemu: add support for dump-guest-core option
tests: Add tests for dump-core option
docs: Document dump-core memory feature
docs/formatdomain.html.in | 13 ++-
docs/schemas/domaincommon.rng | 8 ++
src/conf/domain_conf.c | 19 ++++-
src/conf/domain_conf.h | 10 ++
src/libvirt_private.syms | 2 +
src/qemu/qemu_capabilities.c | 4 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 89 ++++++++++++++++++--
tests/qemuargv2xmltest.c | 2 +
.../qemuxml2argv-machine-core-off.args | 5 +
.../qemuxml2argv-machine-core-off.xml | 26 ++++++
.../qemuxml2argv-machine-core-on.args | 5 +
.../qemuxml2argv-machine-core-on.xml | 26 ++++++
tests/qemuxml2argvtest.c | 3 +
tests/qemuxml2xmltest.c | 2 +
15 files changed, 202 insertions(+), 13 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-core-off.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-core-off.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-core-on.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-core-on.xml
--
1.7.8.6
12 years, 3 months
[libvirt] [PATCHv2 0/4] Add LibSSH2 transport
by Peter Krempa
This is a second respin of the LibSSH2 transport patch series.
The most notable changes:
-------------------------
- Rebased on top of current upstream (virObject, new error codes)
- ported to use virObject stuff
- re-named all functions and other literals to contain the "2"
- implemented suggestions from Eric's review
- added symbol file and various other cleanups
The easiest way to test the actual implementation is to apply the patchset and
try connecting to a remote host using virsh and then trying some API's. The
most complex part of the code are the various authentication options that can
be selected in the connection URI.
Peter Krempa (4):
libssh2_transport: add main libssh2 transport implementation
libssh2_transport: add ssh context support to virNetSocket
libssh2_transport: Add libssh2 session support to net client code
libssh2_transport: Use libssh2 driver code in remote driver
configure.ac | 40 +-
include/libvirt/virterror.h | 2 +
po/POTFILES.in | 1 +
src/Makefile.am | 16 +-
src/libvirt_libssh2.syms | 18 +
src/libvirt_private.syms | 2 +
src/remote/remote_driver.c | 47 ++-
src/rpc/virnetclient.c | 117 ++++
src/rpc/virnetclient.h | 14 +-
src/rpc/virnetlibssh2session.c | 1464 ++++++++++++++++++++++++++++++++++++++++
src/rpc/virnetlibssh2session.h | 83 +++
src/rpc/virnetsocket.c | 178 +++++-
src/rpc/virnetsocket.h | 13 +
src/util/virterror.c | 8 +-
14 files changed, 1993 insertions(+), 10 deletions(-)
create mode 100644 src/libvirt_libssh2.syms
create mode 100644 src/rpc/virnetlibssh2session.c
create mode 100644 src/rpc/virnetlibssh2session.h
--
1.7.8.6
12 years, 3 months
[libvirt] [PATCH] Fix parsing of uid/gid on Mingw32
by Daniel P. Berrange
From: "Daniel P. Berrange" <berrange(a)redhat.com>
The DAC security driver uses the virStrToLong_ui function to
parse the uid/gid out of the seclabel string. This works on
Linux where 'uid_t' is an unsigned int, but on Mingw32 it is
just an 'int'. This causes compiler warnings about signed/
unsigned int pointer mis-match.
To avoid this, use explicit 'unsigned int ouruid' local
vars to pass into virStrToLong_ui, and then simply assign
to the 'uid_t' type after parsing
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
src/security/security_dac.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/security/security_dac.c b/src/security/security_dac.c
index e37b09e..925498f 100644
--- a/src/security/security_dac.c
+++ b/src/security/security_dac.c
@@ -68,25 +68,25 @@ void virSecurityDACSetDynamicOwnership(virSecurityManagerPtr mgr,
static
int parseIds(const char *label, uid_t *uidPtr, gid_t *gidPtr)
{
- uid_t uid;
- gid_t gid;
+ unsigned int theuid;
+ unsigned int thegid;
char *endptr = NULL;
if (label == NULL)
return -1;
- if (virStrToLong_ui(label, &endptr, 10, &uid) ||
+ if (virStrToLong_ui(label, &endptr, 10, &theuid) ||
endptr == NULL || *endptr != ':') {
return -1;
}
- if (virStrToLong_ui(endptr + 1, NULL, 10, &gid))
+ if (virStrToLong_ui(endptr + 1, NULL, 10, &thegid))
return -1;
if (uidPtr)
- *uidPtr = uid;
+ *uidPtr = theuid;
if (gidPtr)
- *gidPtr = gid;
+ *gidPtr = thegid;
return 0;
}
--
1.7.11.2
12 years, 3 months
[libvirt] [libguestfs] Options for hotplugging
by Richard W.M. Jones
libguestfs recently added support for virtio-scsi and libvirt, and
when these are both available this lets us relatively easily add
hotplugging of drives. This email is about how we would present that
through the libguestfs API.
(a) The current API
Currently you have to add drive(s) via guestfs_add_drive* and then
call guestfs_launch, ie. your program must look something like this:
guestfs_h *g = guestfs_create ();
guestfs_add_drive (g, "/tmp/disk1.img");
guestfs_add_drive (g, "/tmp/disk2.img");
guestfs_launch (g);
After guestfs_launch [the qemu backend is running] you are not allowed
to add more drives.
The API specifies that you refer to drives in other commands in one of
two ways. Either you're allowed to use names like "/dev/sda",
"/dev/sdb" etc to refer to the first, second etc drive you added, in
the same order that you added them. Or you can call
guestfs_list_devices which returns a list of device names, opaque
strings that you pass to other functions.
In the first case (using "/dev/sdX" names), some magic already happens
translating these to the real names underneath, but currently that
magic is just "/dev/sdX" -> "/dev/vdX" for the virtio case.
Note that we cannot change this API or break existing programs.
(b) The hidden appliance drive
The libguestfs appliance has to have its own root drive. Currently
this is added after the user-added drives. For example, if the user
adds two drives, then the appliance will appear as /dev/sdc (or
/dev/vdc or whatever). Some magic in the bootloader causes the last
drive to be used as the root filesystem.
This hidden drive doesn't appear in the API -- for example it is
suppressed when we generate the result of guestfs_list_devices.
(c) /dev/null drives
It's always been possible to add "/dev/null" as a drive via
guestfs_add_drive*. This is mainly useful for testing, or if you want
to access just those parts of the API which don't require a disk image
(for various reasons we force you to add one drive, so if you don't
have any drive to add, you can use "/dev/null"). Current libguestfs
treats "/dev/null" as a magic string and (because of bugs in qemu)
substitutes a non-zero sized temporary file.
(d) Maximum number of drives
With virtio-scsi, this maximum is pretty large -- currently 255 (256
targets less the hidden appliance), but if we used LUNs or even
multiple controllers then it'd be almost unlimited. We actually test
up to 255, and virt-df will use as many slots as it can.
(e) For libguestfs you can assume the latest of everything, qemu,
guest kernel, host kernel, libvirt, tools. Any suggestions based on
very new features are fine, even proposed features provided there's a
working implementation which is likely to go upstream.
- - - -
Here are some ideas about how we might add hotplugging without
breaking existing clients.
(1) The "raw libvirt" option
In this one we'd simply provide thin wrappers around
virDomainAttachDevice and virDomainDetactDevice, and leave it up to
the user to know what they're doing.
The problem with this is the hidden appliance disk. We certainly
don't want the user to accidentally detach that(!) It's also
undesirable for there to be a "hole" in the naming scheme so that
you'd have:
/dev/sda <- your normal drives
/dev/sdb <-
[/dev/sdc # sorry, you can't use this, we won't tell you why]
/dev/sdd <- your first hotplugged device
As far as I know, the kernel assigns /dev/sdX names on a first-free
basis, so there's no way to permanently put the appliance at
/dev/sdzzz (if there is, please let me know!)
(2) The "slots" option
In this option you'd have to use null devices to reserve the maximum
number of drive slots that you're going to use in the libguestfs
handle before launch. Then after launching you'd be allowed to
hotplug only those slots.
So for example:
guestfs_add_drive (g, "/dev/null"); # reserves /dev/sda
guestfs_add_drive (g, "/dev/null"); # reserves /dev/sdb
guestfs_add_drive (g, "/dev/null"); # reserves /dev/sdc
guestfs_launch (g);
guestfs_hotplug (g, 1, "/tmp/foo"); # replaces index 1 == /dev/sdb
guestfs_hotplug (g, 3, "/tmp/foo"); # error!
Although ugly, in some ways this is quite attractive. It maps easily
into guestfish scripts. You have contiguous device naming. You often
know how many drives you'll need in advance, and if you don't then you
can reserve up to max_disks-1.
(3) The "serial numbers" option
This was Dan's suggestion. Hotplugged drives are known only by their
serial number. ie. We hotplug them via libvirt using the <serial/>
field, and then they are accessed using /dev/disk/by-id/serial.
This is tempting, but unfortunately it doesn't quite work in stock
udev, because the actual name used is:
/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_SERIAL
We could add a custom udev rule to get the path we wanted.
(4) The "rewriting device names" option
Since we already have the infrastructure to rewrite device names, we
could do some complicated and hairy device name rewriting to make
names appear continguous, even though there's an hidden appliance
drive.
This is my least favourite option, mainly because of the complexity,
and complexity is bound to lead to bugs.
(5) Your idea here ...
As usual, comments and suggestions welcome.
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
12 years, 3 months
[libvirt] [PATCH v3 0/4] qemu: configurable port boundaries for remote displays
by Martin Kletzander
This series introduces a possibility to change default minimal and
maximal port numbers that are used to specify a remote display port
for both VNC and SPICE.
Because the code was a bit messy, PATCH 1/4 cleans up few things
needed to make a clean run of PATCH 2/4, that does the main change in
the code.
I also noticed two things that could be changed and it made sense for
me to do that, but these are nowhere near any importance, so feel free
to reject them if your heart feels that way.
PATCH 3/4 [optional] rewords three messages and applying it would mean
that they are not translated. Even though I think it makes more sense
this way, I'm not a good English speaker, so that's more like an RFC.
PATCH 4/4 [optional] makes more flexible port searching available, but
now it is used just on one place and it's not necessary to have it.
--
v3:
- rebase on current HEAD
v2:
- apply the change to both VNC and SPICE sessions
Martin Kletzander (4):
qemu: Unify port-wise SPICE and VNC behavior
qemu: configurable remote display port boundaries
qemu: modify 3 error messages
qemu: allow searching for all open ports
src/conf/domain_conf.c | 2 +-
src/qemu/libvirtd_qemu.aug | 4 ++
src/qemu/qemu.conf | 14 ++++++
src/qemu/qemu_command.h | 11 ++++-
src/qemu/qemu_conf.c | 48 +++++++++++++++++++++-
src/qemu/qemu_conf.h | 4 +-
src/qemu/qemu_driver.c | 19 ++++-----
src/qemu/qemu_process.c | 80 +++++++++++++++++++++--------------
src/qemu/test_libvirtd_qemu.aug.in | 2 +
9 files changed, 136 insertions(+), 48 deletions(-)
--
1.7.8.6
12 years, 3 months
[libvirt] [PATCH v2 00/17] Supports for emulator-pin and emulator-bandwidth
by Hu Tao
This series adds support of emulator-pin to pin emulator threads on
specified physical CPUs, and emulator-bandwidth to control physical
CPU bandwidth for emulator threads.
changes:
v2:
- rename hypervisor to emulator all through the series
- no Flags-suffix for new APIs
- reduce code duplication
- rollback to old vcpupin def if error
Hu Tao (9):
Introduce the function virCgroupMoveTask
add function bitmapFromBytemap() to convert bytemap to bitmap
refactor virDomainVcpuPinAdd()
updates of some vcpupin related functions
Enable cpuset cgroup and synchronous vcpupin info to cgroup.
Change virDomainVcpuPinDefParseXML to support parsing emulatorpin
qemu: support emulator pinning
Add a new function vshPrintPinInfo.
new command emulatorpin
Tang Chen (6):
Support simulatorpin xml parse.
qemu: synchronize emulatorpin info to cgroup
Add qemuProcessSetEmulatorAffinites and set emulator threads
affinities
Introduce virDomainPinEmulator and virDomainGetEmulatorPinInfo
functions.
Introduce virDomainEmulatorPinAdd and virDomainEmulatorPinDel
functions
remote: introduce emulator pinning RPCs
Wen Congyang (2):
Introduce the function virCgroupForEmulator
create a new cgroup and move all emulator threads to the new cgroup
daemon/remote.c | 91 +++++++
docs/formatdomain.html.in | 9 +
docs/schemas/domaincommon.rng | 7 +
include/libvirt/libvirt.h.in | 10 +
src/conf/domain_conf.c | 279 ++++++++++++++-----
src/conf/domain_conf.h | 15 +-
src/driver.h | 12 +
src/libvirt.c | 147 ++++++++++
src/libvirt_private.syms | 9 +
src/libvirt_public.syms | 2 +
src/libxl/libxl_driver.c | 13 +-
src/qemu/qemu_cgroup.c | 131 ++++++++-
src/qemu/qemu_cgroup.h | 7 +
src/qemu/qemu_driver.c | 325 ++++++++++++++++++++++-
src/qemu/qemu_process.c | 60 ++++-
src/remote/remote_driver.c | 99 +++++++
src/remote/remote_protocol.x | 21 +-
src/remote_protocol-structs | 22 ++
src/util/cgroup.c | 186 ++++++++++++-
src/util/cgroup.h | 15 ++
src/xen/xend_internal.c | 13 +-
tests/qemuxml2argvdata/qemuxml2argv-cputune.xml | 1 +
tools/virsh-domain.c | 253 ++++++++++++++++--
tools/virsh.pod | 16 ++
24 files changed, 1634 insertions(+), 109 deletions(-)
--
1.7.10.2
12 years, 3 months
[libvirt] [PATCH 0/5] network: define new API virNetworkDefineXMLFlags
by Laine Stump
I would like to enhance libvirt's network API to allow enacting any
changes in definition immediately, as an alternative to the current
behavior of saving the changes right away, but not using them until
the next time the network is destroyed and re-started.
This could easily be handled by a flag passed to
virNetworkDefineXML(). Unfortunately, virNetworkDefineXML() was added
to libvirt before we came up with the idea of adding a flags arg to
every new API (just for things like this). To remedy this, I've
effectively duplicated that API with a new API,
virNetworkDefineXMLFlags(), which currently behaves identically, but
has an extra "flags" argument.
At the end of this patch series, it's still not possible to call
virNetworkDefineXMLFlags() with anything other than 0 in flags, butt
this gets the API in place, and in use by virsh (although with no
extra functionality).
A later patchset will add a VIR_NETWORK_DEFINE_AFFECT_LIVE flag and
the network driver support behind it.
(It almost seems like overkill to split this into so many teeny tiny
patches, but this is the currently popular/accepted format for API
addition patches.)
12 years, 3 months
[libvirt] [PATCH 0/4] start cleaning up virsh split
by Eric Blake
Not complete, but this is what I got done in a couple hours after
complaining about Osier's series:
https://www.redhat.com/archives/libvir-list/2012-August/msg01247.html
There's more work to be done, but this should give an idea at the
sort of cleanups made possible when we cleanly split into different
.o files.
Eric Blake (4):
virsh: move vshWatchJob earlier
virsh: split out virsh.h
virsh: split out virsh-domain.c
virsh: kill some double underscores
tools/Makefile.am | 15 +-
tools/virsh-domain-monitor.c | 2 +-
tools/virsh-domain.c | 220 ++++++++++++---------
tools/virsh-domain.h | 33 ++++
tools/virsh.c | 460 ++++++-------------------------------------
tools/virsh.h | 384 ++++++++++++++++++++++++++++++++++++
6 files changed, 622 insertions(+), 492 deletions(-)
create mode 100644 tools/virsh-domain.h
create mode 100644 tools/virsh.h
--
1.7.11.2
12 years, 3 months
[libvirt] virsh vol-upload purpose question
by Li, Chun Wen
I use virsh vol-upload to upload some data in a volume and use
vol-download to download these data from the same volume, both these two
commands work well. However, when I first use these two commands, I
thought I can use vol-upload to upload some file, then attach this
volume to a vm, and access the upload file in this vm. I did this
experiment, bud it not success. Once I upload a file into a volume,
attach it to a vm, then the vm can not recognize the file type of this
vm, if I mkfs to the volume, the file I upload disappear.
So, my question is the purpose of the vol-upload is just to save some
data in the volume outside vm? I think it is more reasonable if we can
access upload data from vm.
Best Regards
Kimi Li
12 years, 3 months
[libvirt] [ANNOUNCE] libvirt-glib 0.1.2 release
by Daniel P. Berrange
I am pleased to announce that a new release of the libvirt-glib package,
version 0.1.2, is now available from
ftp://libvirt.org/libvirt/glib/
The packages are GPG signed with
Key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF (4096R)
New in this release:
- Add async binding for virDomainResume
- Fix deadlock in event loop handle/timer removal
libvirt-glib comprises three distinct libraries:
- libvirt-glib - Integrate with the GLib event loop and error handling
- libvirt-gconfig - Representation of libvirt XML documents as GObjects
- libvirt-gobject - Mapping of libvirt APIs into the GObject type system
NB: While libvirt aims to be API/ABI stable forever, with libvirt-glib
we are not yet guaranteeing that libvirt-glib libraries are API/ABI
permanently stable. As of the 0.0.8 release, we have tentatively frozen
the API/ABI with the intent of being longterm stable hereafter, but
there is still a small chance we might find flaws requiring an API/ABI
change. The likelihood of this is low, however, and we will strive to
avoid it.
Follow up comments about libvirt-glib should be directed to the regular
libvir-list redhat com development list.
Thanks to all the people involved in contributing to this release.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
12 years, 3 months
