Observations on compiling on Mac OS X 10.5 (Leopard)
by Richard W.M. Jones
I started with:
- Mac OS X 10.5.8
- Xcode installed
- OCaml from GODI
- qemu from git
autoconf is really ancient (2.61). It doesn't have AM_SILENT_RULES
and although we tried to make things work when autoconf lacks this by
having:
m4_ifndef([AM_SILENT_RULES], [m4_define([AM_SILENT_RULES],[])])
AM_SILENT_RULES([yes]) # make --enable-silent-rules the default.
this nevertheless doesn't work. I had to comment out these two lines
in both configure.ac and daemon/configure.ac.
There is no libtoolize. I had to manually link build-aux/ltmain.sh ->
/usr/share/libtool/ltmain.sh
There is no autopoint. I think this is the reason I had to manually
remove references to the po/ subdirectory.
There is no mkisofs. I commented out the test for this in
configure.ac, but eventually I'll have to find out if this is
available for Mac OS X because it is relatively important (used by
libguestfs-test-tool amongst other things).
There is no qemu, but I was able to compile and use qemu from git.
There is an additional problem which is that 'qemu --help' opens (very
briefly) a toplevel window. We run 'qemu --help' and 'qemu --version'
at configure time and at run time in order to determine qemu features
and version, so we'll need to add the '-nographic' option [patch
coming up].
I have added --disable-daemon and --disable-appliance options to
'configure' [patch coming up].
No pkgconfig, therefore no PKG_CHECK_MODULES. I commented out these
two tests temporarily.
The shell which runs configure is not bash, and so it doesn't
understand the 'echo -n' flag that we use in the configure script.
For example:
echo -n "OCaml bindings ...................... "
if test "x$HAVE_OCAML_TRUE" = "x"; then echo "yes"; else echo "no"; fi
produces the output:
-n OCaml bindings ......................
yes
I was able to get all the way through
./configure --disable-appliance --disable-daemon
with the following results:
Daemon .............................. no
Appliance ........................... no
QEMU ................................ /Users/rich/bin/qemu
OCaml bindings ...................... yes
Perl bindings ....................... no
Python bindings ..................... no
Ruby bindings ....................... yes
Java bindings ....................... no
Haskell bindings .................... no
virt-inspector ...................... no
virt-* tools ........................ no
supermin appliance .................. no
FUSE filesystem ..................... no
GODI has a strange layout for OCaml packages; a small OS X-specific
hack was required to src/generator.ml to cope with this.
OS X version of XDR doesn't support 64 bit / hyper type. Known
problem and PortableXDR should be able to supply a replacement. I
copied src/guestfs_protocol.[ch] from a Fedora machine temporarily,
but the complete solution is to use PortableXDR.
There's a few other portability problems in the code which I have
fixed [patches coming up].
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
14 years, 8 months
[PATCH] ESX: Enable verification of SSL certificates
by Matthew Booth
Fix a bug which would have prevented an SSL certification from ever being
verified.
---
lib/Sys/VirtV2V/Transfer/ESX.pm | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/lib/Sys/VirtV2V/Transfer/ESX.pm b/lib/Sys/VirtV2V/Transfer/ESX.pm
index 1da382a..66ba515 100644
--- a/lib/Sys/VirtV2V/Transfer/ESX.pm
+++ b/lib/Sys/VirtV2V/Transfer/ESX.pm
@@ -53,7 +53,7 @@ our %handles;
sub new {
my $class = shift;
- my ($server, $username, $password, $pool, $verify) = @_;
+ my ($server, $username, $password, $target, $noverify) = @_;
my $self = $class->SUPER::new(
agent => 'virt-v2v/'.$Sys::VirtV2V::VERSION,
@@ -65,7 +65,7 @@ sub new {
my ($response, $self, $h) = @_;
if ($response->is_success) {
- $self->verify_certificate($response) if ($verify);
+ $self->verify_certificate($response) unless ($noverify);
$self->create_volume($response);
}
});
@@ -75,14 +75,14 @@ sub new {
$self->{_v2v_username} = $username;
$self->{_v2v_password} = $password;
- if ($verify) {
+ if ($noverify) {
+ # Unset HTTPS_CA_DIR if it is already set
+ delete($ENV{HTTPS_CA_DIR});
+ } else {
# Leave HTTPS_CA_DIR alone if it is already set
# Setting HTTPS_CA_DIR to the empty string results in it using the
# compiled-in default paths
$ENV{HTTPS_CA_DIR} = "" unless (exists($ENV{HTTPS_CA_DIR}));
- } else {
- # Unset HTTPS_CA_DIR if it is already set
- delete($ENV{HTTPS_CA_DIR});
}
die("Invalid configuration of Net::HTTPS")
@@ -330,7 +330,8 @@ sub transfer
my $ua = Sys::VirtV2V::Transfer::ESX::UA->new($conn->{hostname},
$username,
$password,
- $pool);
+ $pool,
+ $noverify);
return $ua->get_volume($path);
}
--
1.6.6.1
14 years, 8 months
Re: [Libguestfs] [RFC] Unify KVM kernel-space and user-space code into a single project
by Richard W.M. Jones
On Mon, Mar 22, 2010 at 02:56:47PM +0100, Ingo Molnar wrote:
> Just curious: any plans to extend this to include live read/write access as
> well?
>
> I.e. to have the 'agent' (guestfsd) running universally, so that
> tools such as perf and by users could rely on the VFS integration as
> well, not just disaster recovery tools?
Totally. That's not to say there is a definite plan, but we're very
open to doing this. We already wrote the daemon in such a way that it
doesn't require the appliance part, but could run inside any existing
guest (we've even ported bits of it to Windoze ...).
The only remaining issue is how access control would be handled. You
obviously wouldn't want anything in the host that can get access to
the vmchannel socket to start sending destructive write commands into
guests.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
14 years, 8 months
Gnulib setenv on Mac OS X bug?
by Richard W.M. Jones
There seems to be a bug in Gnulib's setenv module on Mac OS X. At
configure time it says:
checking whether setenv validates arguments ... no
(The test program it is running is:
| int
| main ()
| {
|
| if (setenv ("", "", 0) != -1) return 1;
| if (errno != EINVAL) return 2;
| if (setenv ("a", "=", 1) != 0) return 3;
| if (strcmp (getenv ("a"), "=") != 0) return 4;
|
| ;
| return 0;
| }
and this returns status code 4)
As a result, in stdlib.h, this:
#if @GNULIB_SETENV@
# if @REPLACE_SETENV@
# undef setenv
# define setenv rpl_setenv
is replaced by:
#if 1
# if 1
# undef setenv
# define setenv rpl_setenv
However, no rpl_setenv function is getting generated in libgnu.a, so
of course the program fails to link.
Any ideas?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
14 years, 8 months