Re: [libvirt] PATCH: Be more flexible in emulator choice on x86 archs
Hi Dan,
I'd like to ask about qemu-0.10.0: it already contains KVM support,
BUT in contrary to std kvm userspace package, KVM support needs to be enabled
by switch (while in kvm shipped userspace it's enabled by default and can by
disabled by switch).
How can I enable it when I want to use new qemu + with KVM enabled from libvirt?
thanks a lot in advance...
BR
nik
On Mon, Mar 16, 2009 at 06:03:59PM +, Daniel P. Berrange wrote:
Currently we are pretty strict about what emulator binary we allow for
QEMU guests on x86 arches. In particular, for arch+domain type combos:
- i686+qemu must use 'qemu' binary
- x86_64+qemu must use 'qemu-system-x86_64' binary
- kvm must use 'qemu-kvm' or 'kvm' binaries
- i686+kvm on x86_64 host is not allowed
These restrictions are overkill because
- i686+qemu could use 'qemu-system-x86_64' if '-cpu qemu32' is added
- i686+qemu could use 'qemu-kvm' if '-cpu qemu32 -no-kvm' is added
- x86_64+qemu could use 'qemu-kvm' if '-no-kvm' is added
- i686+kvm on x86_64 host can be used if '-cpu qemu32' is added
This patch makes QEMU driver more flexible in this way when setting up
its capabilities information. It also makes it aware of the -no-kvm
and -cpu flag, using them where required by the os type + arch + emulator
combinations specified in the guest XML.
This should finally remove the confusion where a user in virt-manager
selectrs 'i686' and then wonders why we've disallowed choice of 'kvm'.
It also fixes 'virsh version' when only qemu-kvm is installed.
The matrix should now work thus:
1. qemu, qemu-system-x86_64, qemu-kvm all available
qemu+i686 = qemu
qemu+x86_64 = qemu-system-x86_64
kvm+i686= qemu-kvm -cpu qemu32
kvm+x86_64 = qemu-kvm
2. qemu, qemu-kvm available
qemu+i686 = qemu
qemu+x86_64 = qemu-kvm -no-kvm
kvm+i686= qemu-kvm -cpu qemu32
kvm+x86_64 = qemu-kvm
3. qemu-system-x86_64, qemu-kvm available
qemu+i686 = qemu-system-x86_64 -cpu qemu32
qemu+x86_64 = qemu-system-x86_64
kvm+i686= qemu-kvm -cpu qemu32
kvm+x86_64 = qemu-kvm
4. qemu-kvm available
qemu+i686 = qemu-kvm -no-kvm -cpu qemu32
qemu+x86_64 = qemu-kvm -no-kvm
kvm+i686= qemu-kvm -cpu qemu32
kvm+x86_64 = qemu-kvm
The only real remaining problem is that we don't cope with scenario
where the KVM enabled binary is called 'qemu-system-x64_64' instead
of 'qemu-kvm' or 'kvm'.
Regards,
Daniel
Index: src/qemu_conf.c
===
RCS file: /data/cvs/libvirt/src/qemu_conf.c,v
retrieving revision 1.138
diff -u -p -r1.138 qemu_conf.c
--- src/qemu_conf.c 16 Mar 2009 13:54:26 - 1.138
+++ src/qemu_conf.c 16 Mar 2009 17:53:20 -
@@ -211,6 +211,7 @@ struct qemu_arch_info {
const char *const *machines;
int nmachines;
const char *binary;
+const char *altbinary;
const struct qemu_feature_flags *flags;
int nflags;
};
@@ -231,24 +232,24 @@ static const struct qemu_feature_flags c
/* The archicture tables for supported QEMU archs */
static const struct qemu_arch_info const arch_info_hvm[] = {
{ i686, 32, arch_info_hvm_x86_machines, 2,
- /usr/bin/qemu, arch_info_i686_flags, 4 },
+ /usr/bin/qemu, /usr/bin/qemu-system-x86_64, arch_info_i686_flags,
4 },
{ x86_64, 64, arch_info_hvm_x86_machines, 2,
- /usr/bin/qemu-system-x86_64, arch_info_x86_64_flags, 2 },
+ /usr/bin/qemu-system-x86_64, NULL, arch_info_x86_64_flags, 2 },
{ mips, 32, arch_info_hvm_mips_machines, 1,
- /usr/bin/qemu-system-mips, NULL, 0 },
+ /usr/bin/qemu-system-mips, NULL, NULL, 0 },
{ mipsel, 32, arch_info_hvm_mips_machines, 1,
- /usr/bin/qemu-system-mipsel, NULL, 0 },
+ /usr/bin/qemu-system-mipsel, NULL, NULL, 0 },
{ sparc, 32, arch_info_hvm_sparc_machines, 1,
- /usr/bin/qemu-system-sparc, NULL, 0 },
+ /usr/bin/qemu-system-sparc, NULL, NULL, 0 },
{ ppc, 32, arch_info_hvm_ppc_machines, 3,
- /usr/bin/qemu-system-ppc, NULL, 0 },
+ /usr/bin/qemu-system-ppc, NULL, NULL, 0 },
};
static const struct qemu_arch_info const arch_info_xen[] = {
{ i686, 32, arch_info_xen_x86_machines, 1,
- /usr/bin/xenner, arch_info_i686_flags, 4 },
+ /usr/bin/xenner, NULL, arch_info_i686_flags, 4 },
{ x86_64, 64, arch_info_xen_x86_machines, 1,
- /usr/bin/xenner, arch_info_x86_64_flags, 2 },
+ /usr/bin/xenner, NULL, arch_info_x86_64_flags, 2 },
};
static int
@@ -257,43 +258,62 @@ qemudCapsInitGuest(virCapsPtr caps,
const struct qemu_arch_info *info,
int hvm) {
virCapsGuestPtr guest;
-int i, haskvm, hasbase, samearch;
+int i;
+int hasbase = 0;
+int hasaltbase = 0;
+int haskvm = 0;
+int haskqemu = 0;
const char *kvmbin = NULL;
-
Re: [libvirt] TLS for libvirt remote access
Zvi Dubitzky wrote: After generating TLS certificates for Libvirt remote access , I test the certificates by running pki_check.sh and get the following message : The CA certificate and the client certificate do not match What can cause this message ? I guess this is a problem as I am trying to access remotely the host machine and fail with a message of :libvir: Remote error : Connection refused That happens even if I use a client and server on the same machine and try : sudo virsh -c qemu://localhost/defualt. I am using libvirt 0.6. You have quite a few problems in your configuration here, including using the wrong URI, and most probably an iptables problem. However, let's start simply... can I get first a connection with no certificate/encryption by using URI = qemu+tcp://...by making the needed change on the libvirtd.conf file on the server side ? that did not work either To begin with, I would start with just getting tcp going. It's totally insecure, but it's a good initial test of getting everything up and running. To do that, you have to enable listen_tcp in libvirtd.conf. You *also* have to change auth_tcp to none in libvirtd.conf; otherwise, it automatically tries to use SASL for authentication, which you don't want at this point. Then you need to start up libvirtd --verbose --listen. At this point, you should be able to do: virsh -c qemu+tcp://hostname/system list --all, and get at least empty output from the virsh list command. If you get a connection refused, you most likely have a firewall blocking the port that libvirtd is listening on; you'll have to open up that part. Assuming you get the above working, go back into libvirtd.conf and disable TCP (like I said, it opens up a security issue). Then go back to the instructions on the website for generating and using TLS, and make sure you've followed the directions exactly. I've used those instructions many times, and they work just fine. Once you think you have it configured, then you can try: virsh -c qemu+tls://hostname/system list --all, and see if that works. Again, if you get connection refused, it probably means your firewall is in the way; libvirtd uses a different port for listen_tcp and listen_tls. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Be more flexible in emulator choice on x86 archs
On Fri, Mar 20, 2009 at 08:23:46AM +0100, Nikola Ciprich wrote: Hi Dan, I'd like to ask about qemu-0.10.0: it already contains KVM support, BUT in contrary to std kvm userspace package, KVM support needs to be enabled by switch (while in kvm shipped userspace it's enabled by default and can by disabled by switch). How can I enable it when I want to use new qemu + with KVM enabled from libvirt? thanks a lot in advance... We don't have support for that yet - its one of the next things we need to sort out. To be honest you are still far better off using the separate KVM releases because they have better performance and functionality. The built-in KVM support in QEMU is still very much work in progress. Daniel -- |: 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC][PATCH]: Secure migration
On Mon, Mar 16, 2009 at 04:26:58PM +0100, Chris Lalancette wrote: All, Attached is a *very* rough first draft of the secure migration code I'm working on. This is in no way ready for merge. That being said, this demonstrates the basic idea that I'm pursuing, and I've actually been able to perform a KVM secure live migrate using this. Before I go and finish polishing it up, though, I wanted to make sure there wasn't anything fundamentally wrong with the approach. So, in that vein, comments are appreciated. diff --git a/qemud/remote_protocol.h b/qemud/remote_protocol.h index 75def5e..d97a18b 100644 --- a/qemud/remote_protocol.h +++ b/qemud/remote_protocol.h @@ -41,6 +41,8 @@ typedef remote_nonnull_string *remote_string; #define REMOTE_SECURITY_MODEL_MAX VIR_SECURITY_MODEL_BUFLEN #define REMOTE_SECURITY_LABEL_MAX VIR_SECURITY_LABEL_BUFLEN #define REMOTE_SECURITY_DOI_MAX VIR_SECURITY_DOI_BUFLEN +#define REMOTE_CONNECT_SECURE_MIGRATION_DATA_MAX 65536 +#define REMOTE_CONNECT_SECURE_MIGRATION_COOKIE_MAX 65536 typedef char remote_uuid[VIR_UUID_BUFLEN]; Okay I have tried to think again about this, from the code fragment before and discussions on IRC while performances are tolerable, there is a lot of costs related to the 64KB chunking imposed by the XML-RPC. It is probably acceptable for a class of users who really want encryption of their data but I would like to make sure we don't close the door for a possibly more performant implementation. Trying to reopen a bit the discussion we had before on opening a separate encrypted connection, this would have a number of potential improvements over the XML-RPC: - no chunking, far less context-switching (it would be good to know how much of excess time spent in the secure migration is data encoding, how much is overall system burden) - seems to me a more standard encrypted TCP/IP connection would be more likely to be able to reuse crypto hardware if/when they get available. My main concern is keeping a port open in the firewall for the incoming connection of the encrypted data, and I wonder if it's really necessary, basically since the receiver and the sender can both communicate already via the XML-RPC maybe something like STUN (for UDP) where both end open simultaneously a new connection to the other side might work, and that can be coordinated via the XML-RPC (passing the new port opened etc). The point being that usually firewall block only incoming connections to non-registered port but outcoming connections are allowed to go, I have no idea if this can be made to work though. In general I would like to make sure we have room in the initial phase to add such a negociation where an optimal solution may be attempted, possibly falling back to a normal XML-RPC solution like this. Basically, make sure we can try to be as efficient as possible, and allow the protocol to evolve, but fallback to XML-RPC encapsulation if that initial round fails. any though ? Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] v3: Use posix_fallocate() on supported systems to allocate diskspace
On Thu, Mar 19, 2009 at 08:17:52PM +0530, Amit Shah wrote: This patchset makes use of the posix_fallocate() call to allocate chunks of files whenever needed if it's available. We fallback to using safewrite() if it's not available. mmap() could be used instead of safewrite too; I have a patch in case someone is interested in seeing it. 1 + 2 + 3 looks fine to me, ACK, thanks a lot ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC][PATCH]: Secure migration
On Fri, Mar 20, 2009 at 11:45:06AM +0100, Daniel Veillard wrote:
Okay I have tried to think again about this, from the code fragment
before and discussions on IRC while performances are tolerable, there
is a lot of costs related to the 64KB chunking imposed by the XML-RPC.
This isn't XML-RPC. This is our own binary protocol using XDR encoding,
which has very little metadata overhead - just a single 24 byte header
per 64kb of data. The payload is the raw binary encoding.
The biggest problem is that this is using our REMOTE_CALL message type.
Thus every 64 kb sent, the client has to wait for an empty REMOTE_REPLY
message to be returned before it can send another 64kb. This synchronous
round trip will really kill latency and throughput.
It is probably acceptable for a class of users who really want
encryption of their data but I would like to make sure we don't close
the door for a possibly more performant implementation.
Trying to reopen a bit the discussion we had before on opening a
separate encrypted connection, this would have a number of potential
improvements over the XML-RPC:
- no chunking, far less context-switching (it would be good to know
how much of excess time spent in the secure migration is data
encoding, how much is overall system burden)
The chunking imposed by our RPC layer isn't really a problem IMHO,
because you have chunking in the encryption APIs too - GNUTLS and
SASL will both encrypt in blocks. There is probably some tuning we
can do to optimize the size of chunks we encrypt, but ultimately
we will always have chunking of the data no matter what protocol
we're sending over.
The context switching between threads is a bit of a annoyance.
We could adapt the libvirtd daemon, so that when it gets a migration
message, the worker thread takes over all responsibility for I/O in
that connection, instead of delegates back to the main thread. THat
probably would not be all that hard - we'd just never re-enable the
'rx' queue for that 'struct qemud_client', so the main thread will
ignore that client forever more.
- seems to me a more standard encrypted TCP/IP connection would be
more likely to be able to reuse crypto hardware if/when they get
available.
Use of crypto hardware is something that's a hidden impl detail in
the TLS/SASL libraries, so that shouldn't be any problem for us.
I think it is pratical to use our existing RPC channel, but work
on eliminating the round-trip. Our protocol already allows for a
fire-and-forget message type with no roundtrip reply. This is the
REMOTE_MESSAGE type. Currently that is only used for messages
sent from the server back to the client. This type of message from
the client to the server is rejected.
One idea is to allow for a generic 'data stream' over the RPC
channel.
- Source libvirtd connects to dest libvirtd and sends
a message 'MIGRATION_INCOMING' message. This is a normal
REMOTE_CALL + REMOTE_REPLY synchronous call. The intent
of this is to let the source tell the destionation that
it wants to start a migration operation. Upon receving
this mesage, the remote libvirtd would decide whether it
wants to allow this. If so, then it can switch the TCP
channel to 'data stream' mode.
- Source libvirtd now sends a series of MIGRATION_DATA
messages. These are REMOTE_MESSAGE type, fire forget
message types with no reply. The source sends this as
fast as it likes, until complete. They are all processed
directly by the worker thread in libvirtd, and not the
main I/O thread.
This avoids any round trip delays, avoids context switches between
threads, and has only a few bytes overhead per 64kb of data sent
and avoids the need to open more ports.
Or we could generalize this a little more and instead of calling the
message MIGRATION_DATA, just have a STREAM_DATA message type, as
a generic efficient way of sending huge chunks of data over the
RPC service. You could imagine it being useful for some of our other
APIs, such virDomain{Memory,Block}Peek.
Daniel
--
|: 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 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] Introduce posix_fallocate() to allocate disk space
On Thu, Mar 19, 2009 at 08:17:53PM +0530, Amit Shah wrote: 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 extents and the fallocate() syscall, this operation will give us a big speed boost. This also brings us the advantage of very less fragmentation for the chunk being allocated. For systems that don't support posix_fallocate(), fall back to safewrite(). ACK, looks good now. Daniel -- |: 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] Use posix_fallocate() to allocate disk space on supported systems
On Thu, Mar 19, 2009 at 08:17:54PM +0530, Amit Shah wrote: Make use of the safezero() function to allocate disk space instead of safewrite() to write zeros. The safezero() function will use posix_fallocate() on supported systems. If progress activity is not requested (current behaviour), the new safezero() function will allocate the file in one go. If progress activity is requested, allocate in 512MiB chunks. Signed-off-by: Amit Shah amit.s...@redhat.com ACK Daniel -- |: 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] v3: Use posix_fallocate() on supported systems to allocate diskspace
On Thu, Mar 19, 2009 at 09:47:12PM +0530, Amit Shah wrote: On (Thu) Mar 19 2009 [20:17:52], Amit Shah wrote: This patchset makes use of the posix_fallocate() call to allocate chunks of files whenever needed if it's available. We fallback to using safewrite() if it's not available. mmap() could be used instead of safewrite too; I have a patch in case someone is interested in seeing it. Something like this: From d33b843b381ea6a25c6e8efb6b248965a40e5f84 Mon Sep 17 00:00:00 2001 From: Amit Shah amit.s...@redhat.com Date: Thu, 19 Mar 2009 21:43:50 +0530 Subject: [PATCH] Use mmap() and memset() for safezero If available, use mmap to allocate zeroed chunks for files. This should be faster than allocating small chunks using safewrite. Signed-off-by: Amit Shah amit.s...@redhat.com ACK, looks like a good extension. Daniel -- |: 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Be more flexible in emulator choice on x86 archs
On Fri, Mar 20, 2009 at 11:57:24AM +0100, Daniel Veillard wrote: On Mon, Mar 16, 2009 at 06:03:59PM +, Daniel P. Berrange wrote: Currently we are pretty strict about what emulator binary we allow for QEMU guests on x86 arches. In particular, for arch+domain type combos: - i686+qemu must use 'qemu' binary - x86_64+qemu must use 'qemu-system-x86_64' binary - kvm must use 'qemu-kvm' or 'kvm' binaries - i686+kvm on x86_64 host is not allowed These restrictions are overkill because - i686+qemu could use 'qemu-system-x86_64' if '-cpu qemu32' is added - i686+qemu could use 'qemu-kvm' if '-cpu qemu32 -no-kvm' is added - x86_64+qemu could use 'qemu-kvm' if '-no-kvm' is added - i686+kvm on x86_64 host can be used if '-cpu qemu32' is added This patch makes QEMU driver more flexible in this way when setting up its capabilities information. It also makes it aware of the -no-kvm and -cpu flag, using them where required by the os type + arch + emulator combinations specified in the guest XML. This should finally remove the confusion where a user in virt-manager selectrs 'i686' and then wonders why we've disallowed choice of 'kvm'. It also fixes 'virsh version' when only qemu-kvm is installed. The matrix should now work thus: 1. qemu, qemu-system-x86_64, qemu-kvm all available qemu+i686 = qemu qemu+x86_64 = qemu-system-x86_64 kvm+i686= qemu-kvm -cpu qemu32 kvm+x86_64 = qemu-kvm 2. qemu, qemu-kvm available qemu+i686 = qemu qemu+x86_64 = qemu-kvm -no-kvm kvm+i686= qemu-kvm -cpu qemu32 kvm+x86_64 = qemu-kvm 3. qemu-system-x86_64, qemu-kvm available qemu+i686 = qemu-system-x86_64 -cpu qemu32 qemu+x86_64 = qemu-system-x86_64 kvm+i686= qemu-kvm -cpu qemu32 kvm+x86_64 = qemu-kvm 4. qemu-kvm available qemu+i686 = qemu-kvm -no-kvm -cpu qemu32 qemu+x86_64 = qemu-kvm -no-kvm kvm+i686= qemu-kvm -cpu qemu32 kvm+x86_64 = qemu-kvm The only real remaining problem is that we don't cope with scenario where the KVM enabled binary is called 'qemu-system-x64_64' instead of 'qemu-kvm' or 'kvm'. The confusion around this deserve a patch, and that sounds one way to get this solved ... but I find the approach here is a hard coded path, then oh we finally need to add a second hardcoded path a bit worrying. This also doesn't cope with the occasional troubles where people have a binary outside of /usr/bin. Maybe some of this logic could be reduced and relying on configuration data would allow a fully flexible system (where the user can bite himself too, but heh), by suggesting architecture emulation binary names (with the above as the default) and a separate path list to lookup those binaries. Or we could just allow symlinks to be set in /usr/local/bin pointing to whatever the binaries names may be on that system or something approaching. I agree, this approach we're currently using has pretty much reached the end of its practicality. In particular it is impossible to solve the problem of figuring out whether a plain 'qemu' binary supports kvm natively. To adress that, we'd actually need to run the binary and probe its output. This would require pretty much re-writing this entire capabilities setup logic from scratch. Similarly coping with varying path locations is another problem we can't easily solve with this current code. To address this I think we'd need to completely change the logic to do something like - For each directory in $PATH For each emulator name in (qemu, qemu-system-x864, etc) If emulator exists run $emulator -help So this lets us build up a list of all available emulators and their capabilities (eg, whether each supports qemu, kqemu, kvm). From that list, we can then populate the list of supported combinations of guest, arch, domain type. If we honour $PATH, then it probably wouldn't be neccessary to add config params for it. But ACK, as is this solves the problem, Ok, will commit it shortly. Daniel -- |: 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 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Be more flexible in emulator choice on x86 archs
On Fri, Mar 20, 2009 at 11:18:57AM +, Daniel P. Berrange wrote: To address this I think we'd need to completely change the logic to do something like - For each directory in $PATH For each emulator name in (qemu, qemu-system-x864, etc) If emulator exists run $emulator -help So this lets us build up a list of all available emulators and their capabilities (eg, whether each supports qemu, kqemu, kvm). yes far more flexible, and introspection is the right way to assess capabilities. Agreed this sounds the way to go. From that list, we can then populate the list of supported combinations of guest, arch, domain type. If we honour $PATH, then it probably wouldn't be neccessary to add config params for it. yes that would probably be sufficient, unless the admin did something really weird like using /usr/lib/libexec or something ... Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Openvz: how to use a nondefault config
2009/3/16 Anton Protopopov asp...@gmail.com Hi all. When libvirt creates an OpenVZ machine, it does smth like # vzctl create $ctid --ostemplate `ostemplate` And we can't specify an --config `config` argument. In this case vzctl chooses a default config file (a value of CONFIG variable from /etc/vz/vz.conf). But there are cases when we want to specify a config file directly, as in # vzctl create $ctid --ostemplate `ostemplate` --config `config` I think, that we can try to use the same `ostemplate` name as --config value, if corresponding template exists, i.e., if there is a file /etc/vz/conf/ve-`ostemplate`.conf-sample, libvirt will run a command # vzctl create $ctid --ostemplate `ostemplate` --config `ostemplate` Otherwise, it will run it's default command # vzctl create $ctid --ostemplate `ostemplate` (the same arguments.) --- Example of creating a machine with nondefault config: 1. Create /etc/vz/conf/ve-altlinux-test.conf-sample 2. Create /var/lib/vz/template/cache/altlinux-test.tar 3. Use libvirt with (hypothetical) XML: domain type=openvz name100/name memory1/memory ostypeexe/type/os devices filesystem type=template source name=altlinux-test/ target dir=// /filesystem /devices /domain --- Example of creating a machine with default config: 1. Ensure there is no /etc/vz/conf/ve-altlinux-test.conf-sample 2. Create /var/lib/vz/template/cache/altlinux-test.tar 3. Use libvirt with (the same as above) XML file --- ping? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] v3: Use posix_fallocate() on supported systems to allocate diskspace
On Fri, Mar 20, 2009 at 12:06:25PM +0100, Daniel Veillard wrote: On Thu, Mar 19, 2009 at 08:17:52PM +0530, Amit Shah wrote: This patchset makes use of the posix_fallocate() call to allocate chunks of files whenever needed if it's available. We fallback to using safewrite() if it's not available. mmap() could be used instead of safewrite too; I have a patch in case someone is interested in seeing it. 1 + 2 + 3 looks fine to me, ACK, Applied and commited :-) thanks again ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC][PATCH]: Secure migration
Daniel Veillard wrote: On Mon, Mar 16, 2009 at 04:26:58PM +0100, Chris Lalancette wrote: All, Attached is a *very* rough first draft of the secure migration code I'm working on. This is in no way ready for merge. That being said, this demonstrates the basic idea that I'm pursuing, and I've actually been able to perform a KVM secure live migrate using this. Before I go and finish polishing it up, though, I wanted to make sure there wasn't anything fundamentally wrong with the approach. So, in that vein, comments are appreciated. diff --git a/qemud/remote_protocol.h b/qemud/remote_protocol.h index 75def5e..d97a18b 100644 --- a/qemud/remote_protocol.h +++ b/qemud/remote_protocol.h @@ -41,6 +41,8 @@ typedef remote_nonnull_string *remote_string; #define REMOTE_SECURITY_MODEL_MAX VIR_SECURITY_MODEL_BUFLEN #define REMOTE_SECURITY_LABEL_MAX VIR_SECURITY_LABEL_BUFLEN #define REMOTE_SECURITY_DOI_MAX VIR_SECURITY_DOI_BUFLEN +#define REMOTE_CONNECT_SECURE_MIGRATION_DATA_MAX 65536 +#define REMOTE_CONNECT_SECURE_MIGRATION_COOKIE_MAX 65536 typedef char remote_uuid[VIR_UUID_BUFLEN]; Okay I have tried to think again about this, from the code fragment before and discussions on IRC while performances are tolerable, there is a lot of costs related to the 64KB chunking imposed by the XML-RPC. Just so others are clear on what this means: After doing a little bugfixing on the version of the code I posted, I did some performance measurements with a guest using 3.4GB of memory. A standard migration, direct qemu-qemu, took somewhere between 30 seconds and a minute to complete this. The encrypted version took anywhere between 1 minute and 3 minutes to complete the migration, a slowdown of between 1.5 and 3 times. I'll have to do some more testing to get more solid numbers. It is probably acceptable for a class of users who really want encryption of their data but I would like to make sure we don't close the door for a possibly more performant implementation. Yes, that's a good point. Trying to reopen a bit the discussion we had before on opening a separate encrypted connection, this would have a number of potential improvements over the XML-RPC: - no chunking, far less context-switching (it would be good to know how much of excess time spent in the secure migration is data encoding, how much is overall system burden) Well, as DanB points out later, there is still chunking, but we get rid of the RPC overhead of a reply to every packet. My main concern is keeping a port open in the firewall for the incoming connection of the encrypted data, and I wonder if it's really necessary, basically since the receiver and the sender can both communicate already via the XML-RPC maybe something like STUN (for UDP) where both end open simultaneously a new connection to the other side might work, and that can be coordinated via the XML-RPC (passing the new port opened etc). The point being that usually firewall block only incoming connections to non-registered port but outcoming connections are allowed to go, I have no idea if this can be made to work though. In general I would like to make sure we have room in the initial phase to add such a negociation where an optimal solution may be attempted, possibly falling back to a normal XML-RPC solution like this. Basically, make sure we can try to be as efficient as possible, and allow the protocol to evolve, but fallback to XML-RPC encapsulation if that initial round fails. I'm not so sure I agree with this. If we have a reasonably generic solution, I think the admin would prefer to know up-front that the most performant solution is misconfigured somehow, rather than libvirt silently falling back to a less optimal solution. I think we should work on finding a solution that provides the encryption and has reasonably good performance, and just stick with one solution. What I'm going to do early next week is do some additional work to try to get DanB's suggestion of the STREAM_DATA RPC working. Then I'll try benchmarking (both for duration, and CPU usage): 1) Original, unencrypted migration as a baseline 2) Direct TLS-TLS stream migration; this requires a new port in the firewall, but will be another good data point, and I already have the code for this sitting around 3) The solution I posted here 4) The STREAM_DATA solution Assuming I can get some stable numbers out of those tests, it should at least give us the information we need to make a good decision. -- Chris Lalancette -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC][PATCH]: Secure migration
On Fri, Mar 20, 2009 at 02:43:40PM +0100, Chris Lalancette wrote: Daniel Veillard wrote: On Mon, Mar 16, 2009 at 04:26:58PM +0100, Chris Lalancette wrote: All, Attached is a *very* rough first draft of the secure migration code I'm working on. This is in no way ready for merge. That being said, this demonstrates the basic idea that I'm pursuing, and I've actually been able to perform a KVM secure live migrate using this. Before I go and finish polishing it up, though, I wanted to make sure there wasn't anything fundamentally wrong with the approach. So, in that vein, comments are appreciated. diff --git a/qemud/remote_protocol.h b/qemud/remote_protocol.h index 75def5e..d97a18b 100644 --- a/qemud/remote_protocol.h +++ b/qemud/remote_protocol.h @@ -41,6 +41,8 @@ typedef remote_nonnull_string *remote_string; #define REMOTE_SECURITY_MODEL_MAX VIR_SECURITY_MODEL_BUFLEN #define REMOTE_SECURITY_LABEL_MAX VIR_SECURITY_LABEL_BUFLEN #define REMOTE_SECURITY_DOI_MAX VIR_SECURITY_DOI_BUFLEN +#define REMOTE_CONNECT_SECURE_MIGRATION_DATA_MAX 65536 +#define REMOTE_CONNECT_SECURE_MIGRATION_COOKIE_MAX 65536 typedef char remote_uuid[VIR_UUID_BUFLEN]; Okay I have tried to think again about this, from the code fragment before and discussions on IRC while performances are tolerable, there is a lot of costs related to the 64KB chunking imposed by the XML-RPC. Just so others are clear on what this means: After doing a little bugfixing on the version of the code I posted, I did some performance measurements with a guest using 3.4GB of memory. A standard migration, direct qemu-qemu, took somewhere between 30 seconds and a minute to complete this. The encrypted version took anywhere between 1 minute and 3 minutes to complete the migration, a slowdown of between 1.5 and 3 times. I'll have to do some more testing to get more solid numbers. It is probably acceptable for a class of users who really want encryption of their data but I would like to make sure we don't close the door for a possibly more performant implementation. Yes, that's a good point. Trying to reopen a bit the discussion we had before on opening a separate encrypted connection, this would have a number of potential improvements over the XML-RPC: - no chunking, far less context-switching (it would be good to know how much of excess time spent in the secure migration is data encoding, how much is overall system burden) Well, as DanB points out later, there is still chunking, but we get rid of the RPC overhead of a reply to every packet. My main concern is keeping a port open in the firewall for the incoming connection of the encrypted data, and I wonder if it's really necessary, basically since the receiver and the sender can both communicate already via the XML-RPC maybe something like STUN (for UDP) where both end open simultaneously a new connection to the other side might work, and that can be coordinated via the XML-RPC (passing the new port opened etc). The point being that usually firewall block only incoming connections to non-registered port but outcoming connections are allowed to go, I have no idea if this can be made to work though. In general I would like to make sure we have room in the initial phase to add such a negociation where an optimal solution may be attempted, possibly falling back to a normal XML-RPC solution like this. Basically, make sure we can try to be as efficient as possible, and allow the protocol to evolve, but fallback to XML-RPC encapsulation if that initial round fails. I'm not so sure I agree with this. If we have a reasonably generic solution, I think the admin would prefer to know up-front that the most performant solution is misconfigured somehow, rather than libvirt silently falling back to a less optimal solution. I think we should work on finding a solution that provides the encryption and has reasonably good performance, and just stick with one solution. What I'm going to do early next week is do some additional work to try to get DanB's suggestion of the STREAM_DATA RPC working. Then I'll try benchmarking (both for duration, and CPU usage): 1) Original, unencrypted migration as a baseline 2) Direct TLS-TLS stream migration; this requires a new port in the firewall, but will be another good data point, and I already have the code for this sitting around 3) The solution I posted here 4) The STREAM_DATA solution FWIW, I'd consider it a bug in libvirtd impl if option 4) could not match the performance of option 2) Daniel -- |: 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
[libvirt] Improve heuristic for default guest architecture
In libvirt 0.6.1, if you create a domain description of type 'kvm'
without an arch set on an x86-64 host, you would get an i686 qemu guest
rather than the expected x86-64 kvm guest.
This is because virCapabilitiesDefaultGuestArch doesn't take the domain
type into consideration, so it just returned the first hvm architecutre
that has been registered, which is i686.
After applying Dan P's patch,
http://www.redhat.com/archives/libvir-list/2009-March/msg00281.html,
I now get a i686 kvm guest, since kvm now can do i686 guests from
libvirt. This is certainly an improvement, but I think a more reasonable
default is to attempt to match the host's architecture.
This patch makes virCapabilitiesDefaultGuestArch also check the domain
type, and also gives preference to a guest architecture that matches the
host's architecture.
Index: libvirt-0.6.1/src/capabilities.c
===
--- libvirt-0.6.1.orig/src/capabilities.c 2009-03-19 15:18:09.483317579
+0100
+++ libvirt-0.6.1/src/capabilities.c2009-03-19 15:42:31.027341187 +0100
@@ -468,14 +468,26 @@
*/
extern const char *
virCapabilitiesDefaultGuestArch(virCapsPtr caps,
-const char *ostype)
+const char *ostype,
+const char *domain)
{
-int i;
+int i, j;
+const char *arch = NULL;
for (i = 0 ; i caps-nguests ; i++) {
-if (STREQ(caps-guests[i]-ostype, ostype))
-return caps-guests[i]-arch.name;
+if (STREQ(caps-guests[i]-ostype, ostype)) {
+for (j = 0 ; j caps-guests[i]-arch.ndomains ; j++) {
+if (STREQ(caps-guests[i]-arch.domains[j]-type, domain)) {
+/* Use the first match... */
+if (!arch)
+arch = caps-guests[i]-arch.name;
+/* ...unless we can match the host's architecture. */
+if (STREQ(caps-guests[i]-arch.name, caps-host.arch))
+return caps-guests[i]-arch.name;
+}
+}
+}
}
-return NULL;
+return arch;
}
/**
Index: libvirt-0.6.1/src/capabilities.h
===
--- libvirt-0.6.1.orig/src/capabilities.h 2009-03-19 15:18:09.507338228
+0100
+++ libvirt-0.6.1/src/capabilities.h2009-03-19 15:42:31.027341187 +0100
@@ -177,7 +177,8 @@
extern const char *
virCapabilitiesDefaultGuestArch(virCapsPtr caps,
-const char *ostype);
+const char *ostype,
+const char *domain);
extern const char *
virCapabilitiesDefaultGuestMachine(virCapsPtr caps,
const char *ostype,
Index: libvirt-0.6.1/src/domain_conf.c
===
--- libvirt-0.6.1.orig/src/domain_conf.c2009-03-19 15:18:09.531341976
+0100
+++ libvirt-0.6.1/src/domain_conf.c 2009-03-19 15:42:31.031345327 +0100
@@ -2146,7 +2146,7 @@
goto error;
}
} else {
-const char *defaultArch = virCapabilitiesDefaultGuestArch(caps,
def-os.type);
+const char *defaultArch = virCapabilitiesDefaultGuestArch(caps,
def-os.type, virDomainVirtTypeToString(def-virtType));
if (defaultArch == NULL) {
virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
_(no supported architecture for os type
'%s'),
Index: libvirt-0.6.1/src/xm_internal.c
===
--- libvirt-0.6.1.orig/src/xm_internal.c2009-03-19 15:18:09.559316828
+0100
+++ libvirt-0.6.1/src/xm_internal.c 2009-03-19 15:42:45.807318313 +0100
@@ -695,7 +695,7 @@
if (!(def-os.type = strdup(hvm ? hvm : xen)))
goto no_memory;
-defaultArch = virCapabilitiesDefaultGuestArch(priv-caps, def-os.type);
+defaultArch = virCapabilitiesDefaultGuestArch(priv-caps, def-os.type,
virDomainVirtTypeToString(def-virtType));
if (defaultArch == NULL) {
xenXMError(conn, VIR_ERR_INTERNAL_ERROR,
_(no supported architecture for os type '%s'),
--
Soren Hansen |
Lead Virtualisation Engineer | Ubuntu Server Team
Canonical Ltd. | http://www.ubuntu.com/
signature.asc
Description: Digital signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt authorization
Is there any authorization mechanism in libvirt? I've got TLS going so that only those with a cert signed by my CA are allowed in, but there appears to be no way for me to only allow them access to certain VMs. Can I limit folks to specific VMs or VNC ports? Ideally I can allow access only to those VMs which they own. This is really not _that_ big of a deal because I'm advising all my admins to log out of their systems but it would give me and them peace of mind. Thoughts? Scott -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] (no subject)
Hello all,
I've been working on a libvirt extension to manage IBM's Power VMs
(LPARs). The Power systems are managed through management console
referred to as the HMC or using a management partition (IVM). Both HMC
and IVM runs an SSH, then you can reach it via command line, and an HTTP
server, then you can reach it via web browser.
The protocol between the console and the partition (LPAR) is not
disclosed, therefore I propose the driver to execute commands remoetly
over an SSH connection to the consoles to manage IBM LPARs.
The patch attached is the first scratch of the driver that will interact
with HMC over a SSH connection. The URI model that is
used in virsh command line is:
virsh --conect phyp://$u...@$server
Some known issues are:
* Next step is to make the URI like this: phyp://$user@
$HMC/@managed_system. Almost finished. What it takes now is
$server = $HMC = $managed_system.
* Next features in my TODO list are resume, stop and reboot the
LPAR.
Any comments are welcome.
Thanks,
--
Eduardo Otubo
Software Engineer
Linux Technology Center
IBM Systems Technology Group
Mobile: +55 19 8135 0885
ot...@linux.vnet.ibm.com
diff --git a/configure.in b/configure.in
index 6b2bb5e..201a7dc 100644
--- a/configure.in
+++ b/configure.in
@@ -182,6 +182,8 @@ AC_ARG_WITH([uml],
[ --with-uml add UML support (on)],[],[with_uml=yes])
AC_ARG_WITH([openvz],
[ --with-openvz add OpenVZ support (on)],[],[with_openvz=yes])
+AC_ARG_WITH([phyp],
+[ --with-phyp add IBM HMC/IVM support (on)],[],[with_phyp=yes])
AC_ARG_WITH([lxc],
[ --with-lxc add Linux Container support (on)],[],[with_lxc=yes])
AC_ARG_WITH([test],
@@ -714,6 +716,21 @@ AM_CONDITIONAL([HAVE_NUMACTL], [test $with_numactl != no])
AC_SUBST([NUMACTL_CFLAGS])
AC_SUBST([NUMACTL_LIBS])
+if test $with_phyp = yes; then
+ AC_CHECK_LIB([ssh],[ssh_new],[
+LIBSSH_LIBS=$LIBSSH_LIBS -lssh -L/usr/local/lib/
+AC_SUBST([LIBSSH_LIBS])],[
+AC_MSG_ERROR([You must install the libssh to compile Phype driver.])])
+
+ AC_CHECK_HEADERS([libssh/libssh.h],[
+LIBSSH_CFLAGS=-I/usr/local/include/libssh
+AC_SUBST([LIBSSH_CFLAGS])],[
+AC_MSG_ERROR([Cannot find libssh headers.Is libssh installed ?])],[])
+ AC_DEFINE_UNQUOTED([WITH_PHYP], 1,
+[whether IBM HMC / IVM driver is enabled])
+fi
+AM_CONDITIONAL([WITH_PHYP],[test $with_phyp = yes])
+
dnl virsh libraries
AC_CHECK_HEADERS([readline/readline.h])
@@ -1345,6 +1362,7 @@ AC_MSG_NOTICE([QEMU: $with_qemu])
AC_MSG_NOTICE([ UML: $with_uml])
AC_MSG_NOTICE([ OpenVZ: $with_openvz])
AC_MSG_NOTICE([ LXC: $with_lxc])
+AC_MSG_NOTICE([ IBM HMC/IVM: $with_phyp])
AC_MSG_NOTICE([Test: $with_test])
AC_MSG_NOTICE([ Remote: $with_remote])
AC_MSG_NOTICE([ Network: $with_network])
@@ -1373,6 +1391,7 @@ fi
AC_MSG_NOTICE([])
AC_MSG_NOTICE([Libraries])
AC_MSG_NOTICE([])
+AC_MSG_NOTICE([ libssh: $LIBSSH_CFLAGS $LIBSSH_LIBS])
AC_MSG_NOTICE([ libxml: $LIBXML_CFLAGS $LIBXML_LIBS])
AC_MSG_NOTICE([ gnutls: $GNUTLS_CFLAGS $GNUTLS_LIBS])
if test $with_sasl != no ; then
diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h
index 2c3777d..a61e2f3 100644
--- a/include/libvirt/virterror.h
+++ b/include/libvirt/virterror.h
@@ -61,6 +61,7 @@ typedef enum {
VIR_FROM_UML, /* Error at the UML driver */
VIR_FROM_NODEDEV, /* Error from node device monitor */
VIR_FROM_XEN_INOTIFY, /* Error from xen inotify layer */
+VIR_FROM_PHYP, /* Error from IBM power hypervisor */
VIR_FROM_SECURITY, /* Error from security framework */
} virErrorDomain;
diff --git a/src/Makefile.am b/src/Makefile.am
index d5aac11..787dc37 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -5,6 +5,7 @@ INCLUDES = \
-I../include \
-...@top_srcdir@/include \
-...@top_srcdir@/qemud \
+ $(LIBSSH_CFLAGS) \
$(LIBXML_CFLAGS) \
$(XEN_CFLAGS) \
$(SELINUX_CFLAGS) \
@@ -125,6 +126,10 @@ LXC_CONTROLLER_SOURCES = \
veth.c veth.h \
cgroup.c cgroup.h
+PHYP_DRIVER_SOURCES = \
+ phyp_conf.c phyp_conf.h \
+ phyp_driver.c phyp_driver.h
+
OPENVZ_DRIVER_SOURCES = \
openvz_conf.c openvz_conf.h \
openvz_driver.c openvz_driver.h
@@ -255,6 +260,18 @@ endif
libvirt_driver_xen_la_SOURCES = $(XEN_DRIVER_SOURCES)
endif
+if WITH_PHYP
+if WITH_DRIVER_MODULES
+mod_LTLIBRARIES += libvirt_driver_phyp.la
+else
+noinst_LTLIBRARIES += libvirt_driver_phyp.la
+libvirt_la_LIBADD += libvirt_driver_phyp.la
+endif
+libvirt_driver_phyp_la_LDFLAGS = $(LIBSSH_LIBS)
+libvirt_driver_phyp_la_CFLAGS = $(LIBSSH_CFLAGS)
+libvirt_driver_phyp_la_SOURCES = $(PHYP_DRIVER_SOURCES)
+endif
+
if WITH_OPENVZ
if WITH_DRIVER_MODULES
mod_LTLIBRARIES += libvirt_driver_openvz.la
@@ -403,6 +420,7 @@ EXTRA_DIST += \
$(LXC_DRIVER_SOURCES)\
$(UML_DRIVER_SOURCES)\
$(OPENVZ_DRIVER_SOURCES) \
+ $(PHYP_DRIVER_SOURCES) \
Re: [libvirt] [RFC] Power Hypervisor Libvirt support
Sorry all about my last email, the subject should be [RFC] Power Hypervisor Libvirt support. There should be an error here. Thanks again, Em Sex, 2009-03-20 às 13:58 -0300, Eduardo Otubo escreveu: Hello all, I've been working on a libvirt extension to manage IBM's Power VMs (LPARs). The Power systems are managed through management console referred to as the HMC or using a management partition (IVM). Both HMC and IVM runs an SSH, then you can reach it via command line, and an HTTP server, then you can reach it via web browser. The protocol between the console and the partition (LPAR) is not disclosed, therefore I propose the driver to execute commands remoetly over an SSH connection to the consoles to manage IBM LPARs. The patch attached is the first scratch of the driver that will interact with HMC over a SSH connection. The URI model that is used in virsh command line is: virsh --conect phyp://$u...@$server Some known issues are: * Next step is to make the URI like this: phyp://$user@ $HMC/@managed_system. Almost finished. What it takes now is $server = $HMC = $managed_system. * Next features in my TODO list are resume, stop and reboot the LPAR. Any comments are welcome. Thanks, -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems Technology Group Mobile: +55 19 8135 0885 ot...@linux.vnet.ibm.com -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Fix compile errors in 'safezero()' functions in util.c
Hi!
Fix compile errors in 'safezero()' functions in util.c
Commit 70e7672184ff639856d5f2f3bf7849464031dff9 introduced some
compile errors because of the unsued 'flags' parameter in all three
version of the 'safezero()' function.
Signed-Off-By: Maximilian Wilhelm m...@rfc2324.org
The attached patch fixes this.
Ciao
Max
--
Follow the white penguin.
diff --git a/src/util.c b/src/util.c
index 93d2937..a40ff17 100644
--- a/src/util.c
+++ b/src/util.c
@@ -121,14 +121,14 @@ ssize_t safewrite(int fd, const void *buf, size_t count)
}
#ifdef HAVE_POSIX_FALLOCATE
-int safezero(int fd, int flags, off_t offset, off_t len)
+int safezero(int fd, int flags ATTRIBUTE_UNUSED, off_t offset, off_t len)
{
return posix_fallocate(fd, offset, len);
}
#else
#ifdef HAVE_MMAP
-int safezero(int fd, int flags, off_t offset, off_t len)
+int safezero(int fd, int flags ATTRIBUTE_UNUSED, off_t offset, off_t len)
{
int r;
char *buf;
@@ -152,7 +152,7 @@ int safezero(int fd, int flags, off_t offset, off_t len)
#else /* HAVE_MMAP */
-int safezero(int fd, int flags, off_t offset, off_t len)
+int safezero(int fd, int flags ATTRIBUTE_UNUSED, off_t offset, off_t len)
{
int r;
char *buf;
signature.asc
Description: Digital signature
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Fix compile errors in 'safezero()' functions in util.c
On Fri, Mar 20, 2009 at 05:31:32PM +0100, Maximilian Wilhelm wrote: Hi! Fix compile errors in 'safezero()' functions in util.c Commit 70e7672184ff639856d5f2f3bf7849464031dff9 introduced some compile errors because of the unsued 'flags' parameter in all three version of the 'safezero()' function. Ah right, those should be warnings actually, but I didn't spot the problem ! Applied and commited, thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Fix compile errors in 'safezero()' functions in util.c
Anno domini 2009 Daniel Veillard scripsit: Hi! Fix compile errors in 'safezero()' functions in util.c Commit 70e7672184ff639856d5f2f3bf7849464031dff9 introduced some compile errors because of the unsued 'flags' parameter in all three version of the 'safezero()' function. Ah right, those should be warnings actually, but I didn't spot the problem ! Oh, right. I'm compiling libvirt with --enable-compile-warnings=error Nearby, I'm running a libvirt-buildd with builds upstream GIT head once a hour, to see whats happening in the codebase, so I can safely pull it into our local development GIT. Stay tuned for patches for a new driver these days :) Ciao Max -- Follow the white penguin. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
