[PATCH] Enable virtio-serial in the daemon
by Matthew Booth
Update the daemon to recognise a guestfs_vmchannel argument of the form
"virtio-serial:<name>". The daemon will expect a virtio-serial device to be
available locally at /dev/virtio-ports/<name>.
---
daemon/guestfsd.c | 32 ++++++++++++++++++++++++++++++--
1 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/daemon/guestfsd.c b/daemon/guestfsd.c
index 49aca08..1417e50 100644
--- a/daemon/guestfsd.c
+++ b/daemon/guestfsd.c
@@ -345,10 +345,38 @@ main (int argc, char *argv[])
}
}
freeaddrinfo (res);
- } else {
+ }
+
+#define VSPREFIX "virtio-serial:"
+#define VSPREFIX_LEN sizeof(VSPREFIX)
+
+ else if (STREQLEN (vmchannel, VSPREFIX, VSPREFIX_LEN)) {
+ char *name;
+
+ if (asprintf(&name, "/dev/virtio-ports/%s", vmchannel + VSPREFIX_LEN) < 0)
+ {
+ perror ("malloc");
+ exit (EXIT_FAILURE);
+ }
+
+ fprintf (stderr, "Attempting to open virtio-serial device %s\n", name);
+ sock = open (name, O_RDWR);
+ if (sock == -1) {
+ fprintf (stderr, "open %s: %m\n", name);
+ }
+
+ free(name);
+ }
+
+#undef VSPREFIX
+#undef VSPREFIX_LEN
+
+ else {
fprintf (stderr,
"unknown vmchannel connection type: %s\n"
- "expecting \"tcp:<ip>:<port>\"\n",
+ "expecting one of:\n"
+ "\"tcp:<ip>:<port>\"\n"
+ "\"virtio-serial:<name>\"\n",
vmchannel);
exit (EXIT_FAILURE);
}
--
1.7.2.2
13 years, 9 months
[PATCH febootstrap 0/8] Add support for building an ext2-based appliance
by Richard W.M. Jones
This patch series adds support for outputing an ext2-based appliance
from febootstrap-supermin-helper. The usage is very simple, you just
add '-f ext2' flag and the name of the appliance file that you want to
write to.
The implementation uses libext2fs, which is a very low level way to
create ext2 filesystems from scratch. We'd like to use libguestfs,
but that's an obvious reason why we can't do that :-)
These patches are *not* finalized yet. However I doubt that patches
0001-0007 will change very much (and especially not 0001-0004), so
those can be reviewed.
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
13 years, 9 months
Proposed new libguestfs file APIS
by Matthew Booth
As part of a new virt-v2v feature, I've been thinking about how to write
data to an arbitrary block device in the appliance. I need to be able to
write arbitrary chunks of data to specific places on the device. This
will need a new API, as guestfs_pread can't open a block device. While
I'm at it, I'd like to create a new family of APIs which operate on a
file handle:
int guestfs_open_device(g, path);
Open a block device. Return a handle.
int guestfs_open_file(g, path);
Open a file from the guest's filesystem. Return a handle.
int guestfs_close_handle(g, handle);
Close a file handle.
ssize_t guestfs_hpread(g, handle, buf, size, offset);
ssize_t guestfs_hread(g, handle, buf, size);
ssize_t guestfs_hpwrite(g, handle, buf, size, offset);
ssize_t guestfs_hwrite(g, handle, buf, size);
Wrappers round pread(), read(), pwrite() and write() which operate on
a handle.
ssize_t guestfs_hseek(g, handle, offset, whence);
Wrapper round lseek().
int guestfs_htruncate(g, handle, length);
Wrapper round ftruncate().
In terms of the API, the handle would be an opaque int. In practise it
would be a file descriptor owned by guestfsd.
I believe these APIs could result in a performance improvement over
opening a file repeated. However, I have no data to back this up at present.
Aside from any potential performance improvement I believe these APIs
are a better interface for the developer when doing low level file
operations in the guest.
Comments before I code this up?
Thanks,
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
13 years, 9 months
Create virtual appliance + deployment + manage
by Saravanan S
Dear all,
I am working on a virtualization project that involves setting up virtual
appliances over cloud.
to implement the same, which tool is required to
1) create virtual appliances
2) deploy virtual appliances
3) manage virtual appliances/virtual machines
Could you please guide me with some pointers or resources to get started
with the implementation.
Thank you.
Saravanan Sundaramoorthy
Red Hat Certified Engineer
http://www.google.com/profiles/dearsaravanan#about
+91 99404 32545
13 years, 9 months
Whether libguestfs work only with 32bit processors
by Rajiv Rajaian
Hi
I have installed libguestfs in Fedora Core 13. Here's the packages I ve
installed.
[root@kvmcluster ~]# rpm -qa | grep guest
guestfish-1.2.2-1.fc13.i686
perl-libguestfs-1.2.2-1.fc13.i686
libguestfs-1.2.2-1.fc13.i686
libguestfs-tools-1.2.2-1.fc13.i686
And I have tried to resize the KVM guest image with virt-resize command. But
I'm getting the error as "virt-resize: sorry this program does not work on
a 32 bit host" since Im su
Whether libguest doesnt have any support fo 32 bit processors?? Or can u
please suggest me any other versions of libguestfs that would support 32 bit
processor.
Here the stpes I have tried for resizing the KVM guest
[root@kvmcluster images]# truncate -r redhat5_old.img redhat5.img
[root@kvmcluster images]# truncate -s +1G redhat5.img
[root@kvmcluster images]# virt-list-partitions -lh redhat5_old.img
/dev/sda1 ext3 101.9M
/dev/sda2 swap 1.0G
/dev/sda3 ext3 2.9G
[root@kvmcluster images]# virt-resize --expand /dev/sda3 redhat5_old.img
redhat5.img
virt-resize: sorry this program does not work on a 32 bit host
Thanks /Regards
Rajiv.R
Project Associate,
CARE,MIT,
Anna University Chennai.
13 years, 9 months
Generate coredumps of the guestfs appliance
by Matthew Booth
[PATCH 1/3] Add a core_pattern debug command
The first patch is just a rework of Rich's earlier core dump patch. It turns it
into a debug subcommand so it can be called at any time. This also has the
advantage of explicitly labelling an extremely untidy API as debug.
[PATCH 2/3] Call sync after guestfsd exits
The second patch seems to be required for cores to be dumped reliably. I was
able to generate cores without this patch, but not in the real scenario I was
actually interested in. I suspect that there was a race for the core to be
committed to disk before the appliance exited. With a larger core file and a
busier cache, perhaps it just wasn't winning.
[PATCH 3/3] Shut down the appliance cleanly
The third patch is opportunistic while I was looking at init. I'm pretty sure it
also fixes RHBZ#618556, although I haven't checked explicitly.
Matt
13 years, 9 months
[PATCH] Correctly detect the size of a block device over SSH
by Matthew Booth
When fetching a storage volume over SSH, we were detecting its size with a
simple 'stat -c %s'. While this works fine for files, it won't return the
correct size of a block device.
This patch uses the output of 'blockdev --getsize64' for block devices, and stat
as before for regular files.
Fixes RHBZ#620698
---
lib/Sys/VirtV2V/Transfer/SSH.pm | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/Sys/VirtV2V/Transfer/SSH.pm b/lib/Sys/VirtV2V/Transfer/SSH.pm
index 66ec294..5f54f0e 100644
--- a/lib/Sys/VirtV2V/Transfer/SSH.pm
+++ b/lib/Sys/VirtV2V/Transfer/SSH.pm
@@ -138,7 +138,21 @@ sub _connect
push(@command, 'ssh');
push(@command, '-l', $username) if (defined($username));
push(@command, $host);
- push(@command, "stat -c %s $path; cat $path");
+
+ # Return the size of the remote path on the first line, followed by its
+ # contents.
+ # The bit arithmetic with the output of stat is a translation into shell
+ # of the S_ISBLK macro. If the remote device is a block device, stat
+ # will simply return the size of the block device inode. In this case,
+ # we use the output of blockdev --getsize64 instead.
+ push(@command,
+ "dev=$path; ".
+ 'if [[ $(((0x$(stat -L -c %f $dev)&0170000)>>12)) == 6 ]]; then '.
+ 'blockdev --getsize64 $dev; '.
+ 'else '.
+ 'stat -L -c %s $dev; '.
+ 'fi; '.
+ 'cat $dev');
# Close the ends of the pipes we don't need
close($stdin_write);
--
1.7.2.1
13 years, 9 months
[PATCH] Send trace output to stderr
by Matthew Booth
Trace output sent to stdout can be lost in the event of a crash due to
buffering. This patch sends it to stderr instead.
---
src/generator.ml | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/generator.ml b/src/generator.ml
index 52e7aba..db674a6 100755
--- a/src/generator.ml
+++ b/src/generator.ml
@@ -6174,7 +6174,7 @@ check_state (guestfs_h *g, const char *caller)
pr "\n"
);
- pr " printf (\"%s\");\n" shortname;
+ pr " fprintf (stderr, \"%s\");\n" shortname;
List.iter (
function
| String n (* strings *)
@@ -6186,27 +6186,27 @@ check_state (guestfs_h *g, const char *caller)
| BufferIn n
| Key n ->
(* guestfish doesn't support string escaping, so neither do we *)
- pr " printf (\" \\\"%%s\\\"\", %s);\n" n
+ pr " fprintf (stderr, \" \\\"%%s\\\"\", %s);\n" n
| OptString n -> (* string option *)
- pr " if (%s) printf (\" \\\"%%s\\\"\", %s);\n" n n;
- pr " else printf (\" null\");\n"
+ pr " if (%s) fprintf (stderr, \" \\\"%%s\\\"\", %s);\n" n n;
+ pr " else fprintf (stderr, \" null\");\n"
| StringList n
| DeviceList n -> (* string list *)
- pr " putchar (' ');\n";
- pr " putchar ('\"');\n";
+ pr " fputc (' ', stderr);\n";
+ pr " fputc ('\"', stderr);\n";
pr " for (i = 0; %s[i]; ++i) {\n" n;
- pr " if (i > 0) putchar (' ');\n";
- pr " fputs (%s[i], stdout);\n" n;
+ pr " if (i > 0) fputc (' ', stderr);\n";
+ pr " fputs (%s[i], stderr);\n" n;
pr " }\n";
- pr " putchar ('\"');\n";
+ pr " fputc ('\"', stderr);\n";
| Bool n -> (* boolean *)
- pr " fputs (%s ? \" true\" : \" false\", stdout);\n" n
+ pr " fputs (%s ? \" true\" : \" false\", stderr);\n" n
| Int n -> (* int *)
- pr " printf (\" %%d\", %s);\n" n
+ pr " fprintf (stderr, \" %%d\", %s);\n" n
| Int64 n ->
- pr " printf (\" %%\" PRIi64, %s);\n" n
+ pr " fprintf (stderr, \" %%\" PRIi64, %s);\n" n
) (snd style);
- pr " putchar ('\\n');\n";
+ pr " fputc ('\\n', stderr);\n";
pr " }\n";
pr "\n";
in
--
1.7.2
13 years, 9 months
[PATCH] Fix mkinitrd detection of LVM root on RHEL 4
by Matthew Booth
RHEL 4's mkinitrd will fail to recognise that root is on LVM when running on a
recent kernel/udev due to changes in naming. This patch detects LVM root for
RHEL 4, and uses a dirty hack to frig mkinitrd if required.
Fixes RHBZ#580461
---
lib/Sys/VirtV2V/GuestOS/RedHat.pm | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/lib/Sys/VirtV2V/GuestOS/RedHat.pm b/lib/Sys/VirtV2V/GuestOS/RedHat.pm
index 101a64b..74b9de1 100644
--- a/lib/Sys/VirtV2V/GuestOS/RedHat.pm
+++ b/lib/Sys/VirtV2V/GuestOS/RedHat.pm
@@ -1639,13 +1639,14 @@ sub prepare_bootable
my @modules = @_;
my $g = $self->{g};
+ my $desc = $self->{desc};
# Find the grub entry for the given kernel
my $initrd;
my $found = 0;
eval {
my $prefix;
- if ($self->{desc}->{boot}->{grub_fs} eq "/boot") {
+ if ($desc->{boot}->{grub_fs} eq "/boot") {
$prefix = '';
} else {
$prefix = '/boot';
@@ -1720,7 +1721,23 @@ sub prepare_bootable
$g->modprobe('loop');
};
- $g->command(['/sbin/mkinitrd', @module_args, $initrd, $version]);
+ my @env;
+
+ # RHEL 4 mkinitrd determines if the root filesystem is on LVM by
+ # checking if the device name (after following symlinks) starts with
+ # /dev/mapper. However, on recent kernels/udevs, /dev/mapper/foo is
+ # just a symlink to /dev/dm-X. This means that RHEL 4 mkinitrd
+ # running in the appliance fails to detect root on LVM. We check
+ # ourselves if root is on LVM, and frig RHEL 4's mkinitrd if it is
+ # by setting root_lvm=1 in its environment. This overrides an
+ # internal variable in mkinitrd, and is therefore extremely nasty
+ # and applicable only to a particular version of mkinitrd.
+ if ($desc->{distro} eq 'rhel' && $desc->{major_version} eq '4') {
+ push(@env, 'root_lvm=1') if ($g->is_lv($desc->{root_device}));
+ }
+
+ $g->sh(join(' ', @env).' /sbin/mkinitrd '.join(' ', @module_args).
+ " $initrd $version");
}
else {
--
1.7.2
13 years, 9 months
