[libvirt] FileSystem Creation for Logical Storage Volume
by Martin Gajdos
Hi there
As I haven't found this information anywhere else, I'm trying this
mailing list.
I would like to know if it's possible to create a filesystem (ext3 for
e.g.) along with a storage volume with libvirt. The volumes are
located on a remote system.
So is there function in libvirt for this? and if not, what would be
the way to go?
Thanks
Martin Gajdos
15 years, 9 months
[libvirt] Libvirt audio xml format
by Simon Lambourn
Hi, excuse the possible dumb question from a new KVM/Libvirt user - I'm
very impressed overall but struggling to work out how to define an audio
device in the libvirt xml. I have a virtualised windows XP up &
running, now want to add an audio device. I can see how to do it in
kvm and I believe audio devices are now supported in libvirt, but could
not find documentation on how to write the xml.
System is Ubuntu 8.10 on AMD64.
Thanks in anticipation.
15 years, 9 months
[libvirt] PATCH: Fix crash after deleting storage vol fails
by Daniel P. Berrange
After a little debugging on IRC we discovered a problem in the deletion
of storage volumes. We were mistakenly calling virStorageVolFree(vol)
even if the delete call failed. So the pool got left with a NULL storage
volume, and later use of that pool could crash on this.
Daniel
Index: src/storage_driver.c
===================================================================
RCS file: /data/cvs/libvirt/src/storage_driver.c,v
retrieving revision 1.32
diff -u -p -r1.32 storage_driver.c
--- src/storage_driver.c 5 Feb 2009 16:28:30 -0000 1.32
+++ src/storage_driver.c 6 Mar 2009 12:56:20 -0000
@@ -1296,7 +1296,6 @@ storageVolumeDelete(virStorageVolPtr obj
ret = 0;
cleanup:
- virStorageVolDefFree(vol);
if (pool)
virStoragePoolObjUnlock(pool);
return ret;
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
15 years, 9 months
[libvirt] [RFC]: Secure migration
by Chris Lalancette
All,
I've been looking at implementing secure migration for libvirt. I've taken
a look at two approaches; I'll outline them, and then tell you which one I think
we should do, and why. Note that in the discussion below, I'm talking mostly
about the qemu migration protocol; I believe both of the approaches will lend
themselves to, say, Xen, but the details will be different. For the sake of the
outlines, I'm using three specific terms: "src" is used to refer to the source
of the migration, that is, where the VM is running *before* migration begins;
"dst" is used to refer to the destination of the migration, that is, where we
want the VM to be at the end; and "controller" refers to the controlling program
(usually virsh), which can be run on an entirely separate machine.
--------------------------------------------------------------------------------
1) virsh on the controller connects to the src, and initiates the migration
command. In turn, this causes the controller to also connect to the dst. Now,
during the "Prepare" step on the dst, we setup a qemu container to listen to
some port on localhost. Next, the "Perform" step is called on
the src machine. This causes an external program to be forked on the src; this
external program connects to the dst (using virConnectOpen), then waits for
migration data from the qemu instance. As the migration data comes in, it uses
a new RPC call (something like "writeMigrationData") to pass the data to the
dst. The dst then takes that data, and writes it out to the waiting qemu container.
Pros: Uses existing RPC mechanism, so you don't have to open a new port on the
destination
Cons: There is a "hidden" dependency between the src and dst, which may be
difficult for users to get right (more on this below).
2) virsh on the controller connects to the src, and initiates the migration
command. In turn, this causes the controller to also connect to the dst. Now,
during the "Prepare" step on the dst, we setup a qemu container to listen to
some port (call it 1234) on localhost. It also forks an external program (or a
thread) to listen for an incoming gnutls connection. Next, the "Perform" step
is call on the src machine. This forks an external program (or thread) to
listen for incoming data from a localhost migration, do the gnutls handshake
with the dst, and dump the data over the gnutls connection to the dst.
Pros: Works mostly transparently; the user doesn't have to set anything up
different than they do today for "unsecure" migration
Cons: Requires opening a new (but still well-known) port in the firewall on the
dst side.
--------------------------------------------------------------------------------
More about the "hidden" dependencies for 1). There are quite a few examples of
where the controller might have access to both machines, but the src
libvirtd does not. A few examples below:
a) libvirtd is using TLS + the "tls_allowed_dn_list" in
/etc/libvirt/libvirtd.conf on the dst machine. They have it configured so that
they can access the machine via TLS on the controller machine, but not from the
src machine.
b) libvirtd is using SASL digest-md5 on the dst machine. When the src machine
tries to connect, it needs a name and password to do so, which it doesn't have.
(technically, I guess we could proxy that response back to the controller, and
have the user fill it there, and then return back to the src, and then the dst,
but it seems roundabout)
c) libvirtd is using SASL gssapi on the dst machine. When the src machine tries
to connect to the dst, it needs to have the right configuration (i.e.
/etc/krb5.conf and /etc/sasl2/libvirt.conf need to work), and it also has to get
some kind of principal from the kerberos server (but which principal?).
Because of the hidden dependency problem, I think solution 2) is actually more
viable; yes, it also has a dependency (opening a hole in the firewall), but that
can be documented and will work no matter what other authentication you are
doing between the controller and src and dst machines. However, I am open to
being convinced otherwise. Thoughts?
--
Chris Lalancette
15 years, 9 months
[libvirt] Release of libvirt-0.6.1
by Daniel Veillard
I originaly though that this release would just include a set of bug
fixes from 0.6.0, but a couple feature are includd as well as a number
of local improvement.
Available as usual from
ftp://libvirt.org/libvirt/
+ New features:
- new APIs for Node device detach reattach and reset (Mark McLoughlin)
- sVirt mandatory access control support (James Morris and Dan Walsh)
+ Portability:
- non gcc toolchain (John Levon)
- gcc-4.4 warnings fixes (Mark McLoughlin)
- fix build without LXC and QEmu (Jim Meyering)
+ Documentation:
- man page bugzilla URL (Mark McLoughlin)
- typo in domain format (Jesse Farinacci)
- clock offset fix (Mark McLoughlin)
- hostdev description typo (Mark McLoughlin)
- static host IP (Charles Duffy)
- new example program (David Allan)
+ Bug fixes:
- NULL dereference in LXC (Jim Meyering)
- fix domain error reporting (John Levon)
- fix loop of libvirtd --timeout (Daniel Berrange)
- limit history to 500 to restrict virsh memory (Daniel Berrange)
- wrong lvm volume format check (Cole Robinson)
- I/O error in daemon and associated remote acces crash (Daniel
Berrange)
- fix autostart of session daemon (Daniel Berrange)
- restart guest on qemu migration failures (Chris Lalancette)
- config parsing leaks (Ryota Ozaki)
- DBus multithreading activation to avoid crashes (Daniel Berrange)
- mark defined network descriptions as persistent (Cole Robinson)
- qemu+tls handshake negotiation hang (Chris Lalancette)
+ Improvements:
- don't hardcode ssh port (Guido Gunther)
- new test cases and testing infrastructure (Jim Meyering)
- improve the SExpr parser (John Levon)
- proper error reporting on xend shutdown command (John Levon)
- proper handling of errors when saving QEmu domains state (Guido
Gunther)
- revamp of the internal error memory APIs (John Levon)
- better virsh error reporting (John Levon)
- more daemon options to allow running multiple daemons (Jim Meyering)
- error handling when creating a QEmu domain (Guido Gunther)
- fix timeouts in QEmu log reading (Guido Gunther)
- migration with xend 3.3 fixes (John Levon)
- virsh XML dump flags cleanup (Cole Robinson)
- fix build with loadable drivers (Maximilian Wilhelm)
- internal XML APIs to read long long and hexa values (Mark McLoughlin)
- function to parse node device XML descriptions and associated test
(Mark McLoughlin)
- generate network bridge names if not provided (Cole Robinson)
- recognize ejectable media in hostdev hal driver (Cole Robinson)
- integration of sVirt (Daniel Berrange)
+ Cleanups:
- printf NULL string checks (John Levon)
- remove uses of strerror and use virStrerror (Jim Meyering)
- remove redundant NULL assignments (Jim Meyering)
- QEmu driver logging and exec cleanups (Jim Meyering)
- many error handling cleanups (Jim Meyering)
- XML module cleanups (Mark McLoughlin)
- compiler warning (Maximilian Wilhelm)
- daemon TCP listen cleanup (Cole Robinson)
- size_t type cleanup (Guido Gunther)
- parallel make fix (Michael Marineau)
- storage error diagnostic fix (Ryota Ozaki)
- remove redundant monitor watch variable (Cole Robinson)
- qemu AttachDevice error report improvement (Cole Robinson)
- virsh output cleanup (Jim Meyering)
- various tests cleanups and improvements (Jim Meyering)
- fix the internal export list with new APIs (Daniel Berrange)
- cleanups on new APIs for Node device (Daniel Berrange)
So quite a bit of changes happened in one month of development,
so it's getting clear we aren't really slowing down and keeping a
relatively fast release cycle is needed. So expect 0.6.2 in a month
or so.
Thanks to everybody who contributed to the release !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
15 years, 9 months
[libvirt] [PATCH 0/1] Merge DanPB's SCSI HBA pool code
by David Allan
This patch contains the implementation Daniel Berrange did of storage pools using SCSI HBAs. I have updated it for the current tree in preparation for implementing NPIV support. Let me know what you think.
I would also like feedback on the integration into the build system, particularly where POLKIT_CFLAGS should go.
Dave
15 years, 9 months
[libvirt] [PATCH] Use posix_fallocate() to allocate disk space
by Amit Shah
Hi,
This is an untested patch to make disk allocations faster and
non-fragmented. I'm using posix_fallocate() now but relying on glibc
really calling fallocate() if it exists for the file system to be the
fastest.
- This fails build because libutil needs to be added as a dependency?
../src/.libs/libvirt_driver_storage.a(storage_backend_fs.o): In function
`virStorageBackendFileSystemVolCreate':
/home/amit/src/libvirt/src/storage_backend_fs.c:1023: undefined
reference to `safezero'
- What's vol->capacity? Why is ftruncate() needed after the call to
(current) safewrite()? My assumption is that the user can specify some
max. capacity and wish to allocate only a chunk off it at create-time.
Is that correct?
The best case to get a non-fragmented VM image is to have it allocated
completely at create-time with fallocate().
Currently xfs and ext4 support the fallocate() syscall (btrfs will, too,
when it's ready).
Comments?
Amit
>From dfe4780f5990571f026e02e6187cb64505c982c1 Mon Sep 17 00:00:00 2001
From: Amit Shah <amit.shah(a)redhat.com>
Date: Tue, 24 Feb 2009 16:55:58 +0530
Subject: [PATCH] Use posix_fallocate() to allocate disk space
Using posix_fallocate() to allocate disk space and fill it with zeros is faster
than writing the zeros block-by-block.
Also, for backing file systems that support the fallocate() syscall, this
operation will give us a big speed boost.
The biggest advantage of using this is the file will not be fragmented for the
allocated chunks.
Signed-off-by: Amit Shah <amit.shah(a)redhat.com>
---
src/storage_backend_fs.c | 23 ++++++++---------------
src/util.c | 5 +++++
src/util.h | 1 +
3 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/src/storage_backend_fs.c b/src/storage_backend_fs.c
index 240de96..74b0fda 100644
--- a/src/storage_backend_fs.c
+++ b/src/storage_backend_fs.c
@@ -1019,21 +1019,14 @@ virStorageBackendFileSystemVolCreate(virConnectPtr conn,
/* XXX slooooooooooooooooow.
* Need to add in progress bars & bg thread somehow */
if (vol->allocation) {
- unsigned long long remain = vol->allocation;
- static char const zeros[4096];
- while (remain) {
- int bytes = sizeof(zeros);
- if (bytes > remain)
- bytes = remain;
- if ((bytes = safewrite(fd, zeros, bytes)) < 0) {
- virReportSystemError(conn, errno,
- _("cannot fill file '%s'"),
- vol->target.path);
- unlink(vol->target.path);
- close(fd);
- return -1;
- }
- remain -= bytes;
+ int r;
+ if ((r = safezero(fd, 0, 0, vol->allocation)) < 0) {
+ virReportSystemError(conn, r,
+ _("cannot fill file '%s'"),
+ vol->target.path);
+ unlink(vol->target.path);
+ close(fd);
+ return -1;
}
}
diff --git a/src/util.c b/src/util.c
index 990433a..1bee7f0 100644
--- a/src/util.c
+++ b/src/util.c
@@ -117,6 +117,11 @@ ssize_t safewrite(int fd, const void *buf, size_t count)
return nwritten;
}
+int safezero(int fd, int flags, off_t offset, off_t len)
+{
+ return posix_fallocate(fd, offset, len);
+}
+
#ifndef PROXY
int virFileStripSuffix(char *str,
diff --git a/src/util.h b/src/util.h
index a79cfa7..acaabb1 100644
--- a/src/util.h
+++ b/src/util.h
@@ -31,6 +31,7 @@
int saferead(int fd, void *buf, size_t count);
ssize_t safewrite(int fd, const void *buf, size_t count);
+int safezero(int fd, int flags, off_t offset, off_t len);
enum {
VIR_EXEC_NONE = 0,
--
1.6.0.6
15 years, 9 months
[libvirt] selinux
by Michael Kress
Hi! What do I have to do to get qemu-kvm to run with selinux running
with enforcing policy?
I get these messages when I enable this policy:
Mar 3 20:56:23 matrix kernel: [ 8972.482746] device vnet0 entered
promiscuous mode
Mar 3 20:56:23 matrix kernel: [ 8972.898943] br0: port 2(vnet0)
entering learning state
Mar 3 20:56:23 matrix kernel: [ 8972.901957] type=1400
audit(1236110183.820:20): avc: denied { execmem } for pid=6376
comm="kvm" scontext=system_u:system_r:initrc_t:s0
tcontext=system_u:system_r:initrc_t:s0 tclass=process
Mar 3 20:56:23 matrix kernel: [ 8973.161318] type=1400
audit(1236110183.832:21): avc: denied { append } for pid=6379
comm="ifup" name="ifstate" dev=sda1 ino=1376380
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
Mar 3 20:56:23 matrix kernel: [ 8973.188371] br0: port 2(vnet0)
entering disabled state
Mar 3 20:56:23 matrix kernel: [ 8973.203666] device vnet0 left
promiscuous mode
Mar 3 20:56:23 matrix kernel: [ 8973.203675] br0: port 2(vnet0)
entering disabled state
Mar 3 20:56:23 matrix libvirtd: Received signal 17, dispatching to drivers
Mar 3 20:56:23 matrix libvirtd: Received signal 17, dispatching to drivers
Mar 3 20:56:23 matrix kernel: [ 8973.216362] type=1400
audit(1236110183.880:22): avc: denied { append } for pid=6387
comm="ifdown" name="ifstate" dev=sda1 ino=1376380
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
I've tried to set the type:
chcon -t virt_image_t a01.img
but all I got was:
chcon: failed to change context of `a01.img' to
`system_u:object_r:virt_image_t:s0': Invalid argument
The host is a debian 5.0 machine.
TIA
Regards
Michael
15 years, 9 months
