similar to: New release 0.8.5 of virt-v2v and virt-p2v

On 01/19/2012 08:43 PM, Richard W.M. Jones wrote: > I don't remember this commit coming up for review, although it seems > to have been pushed upstream: Well spotted! I was just about to point out that you did review it, when I noticed I'd mixed this one up with a similar one. You reviewed the other one. I have pushed this one accidentally. > commit

I've attached v2v/STATUS. There's still a bit to do. I'm not yet proposing this for inclusion, just discussion. Apart from the tool itself, I think there's mileage in considering how the functionality of Sys::Guestfs::Lib could be given more structure. I think there's considerable mileage in moving much of Sys::Guestfs::Lib into Sys::Guestfs::GuestOS. I haven't tried

I'm trying to use guestmount to install some kernel modules in a guest: [mbooth at mbooth linux-2.6 (amit)]$ make modules_install INSTALL_MOD_PATH=~/etch ln: creating symbolic link `/home/mbooth/etch/lib/modules/2.6.32-rc6/source': No such file or directory make: *** [_modinst_] Error 1 I think something's screwy with symlinks. In the following, /tmp/source is a symlink, and I

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

I've attached a patch to generator.ml for the proposed new file apis. Note that hread, hpread, hwrite and hpwrite are slightly different to the apis I proposed previously. I've also added hallocate for good measure. 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 --------------

This is a snapshot of gobject bindings. This is literally mid-edit, and contains numerous known errors in its output! I'm posting it for review of the ocaml code. 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 -------------- next part -------------- An embedded and charset-unspecified

I've attached the generated gobject bindings for direct review. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: Guestfs-1.0.gir Type: text/xml Size: 435504 bytes Desc: not available URL:

Output from guestfish after upgrading to rawhide libguestfs, compiled with virtio: ><fs> add_drive "/dev/Guests/RHEL52PV32" ><fs> add_cdrom "/var/lib/virt-v2v/transfer.iso" ><fs> launch ><fs> list-devices /dev/sr0 /dev/vda Note that the order has swapped. If these aren't consistent we don't have a good way to determine which host

On Mon, Nov 10, 2014 at 04:52:35PM +0000, Matthew Booth wrote: > On 10/11/14 16:01, Richard W.M. Jones wrote: > > On Mon, Nov 10, 2014 at 04:12:35PM +0100, Nicolas Ecarnot wrote: > >> Hi, > >> > >> In a oVirt 3.4.4 environnement, and using a > >> virt-p2v-0.9.1-2.20130730.1.el6.centos, I'm trying to convert a > >> windows 2003 server 32

We've recently discovered that libguestfs can't handle guests which use md. There are (at least) 2 reasons for this: Firstly, the appliance doesn't include mdadm. Without this, md devices aren't detected during the boot process. Simply adding mdadm to the appliance package list fixes this. Secondly, md devices referenced in fstab as, e.g. /dev/md0, aren't handled

I hit the following weirdness in guestfish: ><fs> ll /../proc/modules -r--r--r-- 1 root root 0 Aug 18 10:37 /sysroot/../proc/modules ><fs> cat /../proc/modules libguestfs: error: open: /../proc/modules: No such file or directory The underlying reason for this seems to be that ll uses sysroot_path to establish a path before operating on it, whereas cat uses CHROOT_IN and

We've currently got a bug in libguestfs which means we can't inspect filesystems in btrfs subvolumes: https://bugzilla.redhat.com/show_bug.cgi?id=824021 This is the default configuration if you select btrfs in F17+. The issue is that it requires an api to fix it, as the return values of inspect_os, inspect_get_filesystems and inspect_get_mountpoints can't express a btrfs

I've attached my initial thoughts on the design for the v2v tool. -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: v2v-pseudo.txt URL:

On 10/11/14 16:01, Richard W.M. Jones wrote: > On Mon, Nov 10, 2014 at 04:12:35PM +0100, Nicolas Ecarnot wrote: >> Hi, >> >> In a oVirt 3.4.4 environnement, and using a >> virt-p2v-0.9.1-2.20130730.1.el6.centos, I'm trying to convert a >> windows 2003 server 32 bits into an oVirt KVM image. >> >> I already succeed doing that many times, but now,

I've summarised how the GObject bindings work below, which should hopefully help reviewing the generator/generated code. There are a couple of points in here I'm still not 100% happy with. Specifically the handling of FBuffer and the Cancellable flag. Both are explained below. I'm interested in suggestions. Return values: ************** All functions which can return an error

One of the things we would really like to be able to do for V2V is to install a new driver in a Windows guest. There are a couple of reasons for this: * The guest may not be bootable without the driver installed, for example because the underlying virtual hardware has changed from vmscsi to virtio. * If the guest can boot, the alternative is to modify the guest to run a script on next boot.

These are the current steps we followed to set up and run Windows P2V migrations. Note that development is proceeding rapidly and the versions of all pieces below will likely be obsolete soon. ************************************************************* Windows RHEV P2V Cookbook 2011-1122 1. Install 32 bit Fedora 14 as a virtual machine or physical host. You will use this system to build

The tests that depend on rhsrvany.exe being available, actually don't need it to be the real one: all they want is the file being present. So, instead of skipping the tests if the real rhsrvany.exe is not found, store a fake one in the repository, and point $VIRT_TOOLS_DATA_DIR at its location. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- p2v/test-virt-p2v-pxe.sh

We have phony tools for v2v tests, introduced with commit c1af1ba32f126b7be275bcc8cd4ea4e5af27a88e; make use of it also in tests related to v2v outside the v2v directory. --- p2v/test-virt-p2v.sh | 6 +----- tests/regressions/rhbz1232192.sh | 6 +----- 2 files changed, 2 insertions(+), 10 deletions(-) diff --git a/p2v/test-virt-p2v.sh b/p2v/test-virt-p2v.sh index 8c3731c..540d2fd

On Wed, Aug 31, 2011 at 12:56:50PM -0500, Greg Scott wrote: > OK, thanks. I just did a yum install virt-v2v on a Fedora 14 VM - but > the man pages don't have anything about how to do physical machines. I > already have a p2v CD built with virt-p2v-image-builder a while ago. I > boot my source server from that CD - what do I do on the Fedora 14 > conversion VM? How do I