[Libguestfs] Issues with p2v & virt-v2v Windows

Jason A. Kates jason at kates.org
Thu Feb 7 17:21:25 UTC 2013


On Thu, 2013-02-07 at 08:59 +0000, Richard W.M. Jones wrote:
> On Wed, Feb 06, 2013 at 09:48:15AM -0500, Jason A. Kates wrote:
> > It looks to me that the windows 2008 image I am attempting to convert is
> > not being detected as windows but is being updated as a Linux system.
> > 
> > When PXE booted the server with the p2v image I ended up with this
> > error:
> > Failed to launch guestfs appliance. Try running again with
> > LIBGUESTFS_DEBUG=1 for more information
> > 
> > The system image transferred and I was able to create an XML file to
> > boot it under kvm with IDE disks.
> > 
> > I undefined it and attempted to convert the system into another storage
> > pool to help in the debugging and I ended up with the same error.
> > 
> > This is what I ran:
> > 
> > LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1 virt-v2v -i libvirtxml -os
> > external  --network default window2008_r1.xml 2>&1 | tee virt-v2v.log
> > 
> > 
> > This is the log file that was produced:
> > "
> > libguestfs: new guestfs handle 0x32df9a0
> > libguestfs: trace: add_drive_opts
> > "/run/media/jkates/WD-3TB-DSK-B/p2v/window2008_r1-cciss_c0d0"
> > "format:raw" "iface:ide" "name:hda"
> > libguestfs: trace: add_drive_opts = 0
> > libguestfs: trace: add_drive_opts "/tmp/JxIRaWzMVf" "readonly:true"
> > "format:raw" "iface:ide"
> > libguestfs: trace: add_drive_opts = 0
> > libguestfs: trace: set_network true
> > libguestfs: trace: set_network = 0
> > libguestfs: trace: launch
> > libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f checksum
> > '/usr/lib64/guestfs/supermin.d' x86_64
> > supermin helper [00000ms] whitelist = (not specified), host_cpu =
> > x86_64, kernel = (null), initrd = (null), appliance = (null)
> > supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d
> > checking modpath /lib/modules/3.6.11-5.fc17.x86_64 is a directory
> > picked vmlinuz-3.6.11-5.fc17.x86_64 because
> > modpath /lib/modules/3.6.11-5.fc17.x86_64 exists
> > checking modpath /lib/modules/3.7.3-101.fc17.x86_64 is a directory
> > picked vmlinuz-3.7.3-101.fc17.x86_64 because
> > modpath /lib/modules/3.7.3-101.fc17.x86_64 exists
> > checking modpath /lib/modules/3.7.5-101.fc17.x86_64 is a directory
> > picked vmlinuz-3.7.5-101.fc17.x86_64 because
> > modpath /lib/modules/3.7.5-101.fc17.x86_64 exists
> > supermin helper [00000ms] finished creating kernel
> > supermin helper [00000ms] visiting /usr/lib64/guestfs/supermin.d
> > supermin helper [00000ms]
> > visiting /usr/lib64/guestfs/supermin.d/base.img
> > supermin helper [00000ms]
> > visiting /usr/lib64/guestfs/supermin.d/daemon.img
> > supermin helper [00001ms]
> > visiting /usr/lib64/guestfs/supermin.d/hostfiles
> > supermin helper [00054ms]
> > visiting /usr/lib64/guestfs/supermin.d/init.img
> > supermin helper [00054ms]
> > visiting /usr/lib64/guestfs/supermin.d/ntfs.hostfiles
> > supermin helper [00055ms]
> > visiting /usr/lib64/guestfs/supermin.d/ntfs.img
> > supermin helper [00055ms] adding kernel modules
> > supermin helper [00134ms] finished creating appliance
> > libguestfs: [00146ms] begin building supermin appliance
> > libguestfs: [00146ms] run febootstrap-supermin-helper
> > libguestfs: [00146ms] febootstrap-supermin-helper --verbose -f
> > ext2 /usr/lib64/guestfs/supermin.d
> > x86_64 /var/tmp/guestfs.ohng6U/kernel /var/tmp/guestfs.ohng6U/initrd /var/tmp/guestfs.ohng6U/root
> > supermin helper [00000ms] whitelist = (not specified), host_cpu =
> > x86_64, kernel = /var/tmp/guestfs.ohng6U/kernel, initrd
> > = /var/tmp/guestfs.ohng6U/initrd, appliance
> > = /var/tmp/guestfs.ohng6U/root
> > supermin helper [00000ms] inputs[0] = /usr/lib64/guestfs/supermin.d
> > checking modpath /lib/modules/3.6.11-5.fc17.x86_64 is a directory
> > picked vmlinuz-3.6.11-5.fc17.x86_64 because
> > modpath /lib/modules/3.6.11-5.fc17.x86_64 exists
> > checking modpath /lib/modules/3.7.3-101.fc17.x86_64 is a directory
> > picked vmlinuz-3.7.3-101.fc17.x86_64 because
> > modpath /lib/modules/3.7.3-101.fc17.x86_64 exists
> > checking modpath /lib/modules/3.7.5-101.fc17.x86_64 is a directory
> > picked vmlinuz-3.7.5-101.fc17.x86_64 because
> > modpath /lib/modules/3.7.5-101.fc17.x86_64 exists
> > supermin helper [00000ms] finished creating kernel
> > supermin helper [00393ms] finished mke2fs
> > supermin helper [00394ms] visiting /usr/lib64/guestfs/supermin.d
> > supermin helper [00394ms]
> > visiting /usr/lib64/guestfs/supermin.d/base.img
> > supermin helper [03635ms]
> > visiting /usr/lib64/guestfs/supermin.d/daemon.img
> > supermin helper [03646ms]
> > visiting /usr/lib64/guestfs/supermin.d/hostfiles
> > supermin helper [08967ms]
> > visiting /usr/lib64/guestfs/supermin.d/init.img
> > supermin helper [08968ms]
> > visiting /usr/lib64/guestfs/supermin.d/ntfs.hostfiles
> > supermin helper [08973ms]
> > visiting /usr/lib64/guestfs/supermin.d/ntfs.img
> > febootstrap-supermin-helper: ext2fs_unlink_inode: Ext2 inode is not a
> > directory
> 
> This is the actual problem.  This is caused because your
> copy of libguestfs is broken.
> 
> > libguestfs: trace: launch = -1 (error)
> > virt-v2v: Failed to launch guestfs appliance. Try running again with
> > LIBGUESTFS_DEBUG=1 for more information
> > libguestfs: trace: close
> > libguestfs: closing guestfs handle 0x32df9a0 (state 0)
> > virt-v2v: Transferring storage volume window2008_r1-cciss_c0d0:
> > 72833679360 bytes
> > "
> > 
> > I redefined the guest and I ran this:
> > [root at W520 v2v]# virt-inspector window2008_r1
> > febootstrap-supermin-helper: ext2fs_unlink_inode: Ext2 inode is not a
> > directory
> > libguestfs: error: external command failed, see earlier error messages
> >
> > This is a list of the RPM files that I think might be relevant:
> > libguestfs-winsupport-1.0-7.el6.x86_64
> > libguestfs-tools-c-1.18.11-2.fc17.x86_64
> > libguestfs-1.18.11-2.fc17.x86_64
> > libguestfs-tools-1.18.11-2.fc17.x86_64
> 
> It's pretty strange that libguestfs-winsupport is installed.  That's a
> RHEL 6 package, and could break libguestfs if used on Fedora 17.  In
> any case, there is no need to use libguestfs-winsupport since NTFS
> support is provided in the base Fedora package.  'yum remove' it and
> try again.
> 
> > virtio-win-1.5.3-1.el6_3.noarch
> > virt-manager-0.9.4-3.fc17.noarch
> > libvirt-daemon-config-nwfilter-0.9.11.9-1.fc17.x86_64
> > libvirt-0.9.11.9-1.fc17.x86_64
> > libvirt-python-0.9.11.9-1.fc17.x86_64
> > virt-v2v-0.9.0-1.fc17.x86_64
> > libvirt-daemon-config-network-0.9.11.9-1.fc17.x86_64
> > virt-manager-common-0.9.4-3.fc17.noarch
> > libvirt-daemon-0.9.11.9-1.fc17.x86_64
> > libvirt-client-0.9.11.9-1.fc17.x86_64
> > python-virtinst-0.600.3-2.fc17.noarch
> > 
> > 
> > Any help or suggestions of what to attempt next would be appreciated.
> > 
> > 					-Jason
> 
> Rich.
> 


Rich,
Thanks for the help,  I had installed
libguestfs-winsupport-1.0-7.el6.x86_64 & virtio-win-1.5.3-1.el6_3.noarch
as a hope that it would fix this issues.  

I have now removed the two RHEL6 packages and attempted the P2V.  Attached is a screen shot of the result.

When I ran this:
LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1 virt-v2v -i libvirtxml -os iso  --network default window2008_r1.xml 2>&1 | tee virt-v2v-5.log
I received much different results than last time..

This is the tail of the log:
libguestfs: trace: inspect_get_minor_version "/dev/sda1"
libguestfs: trace: inspect_get_minor_version = 0
libguestfs: trace: umount "/transfer3MLStM"
libguestfs: send_to_daemon: 64 bytes: 00 00 00 3c | 20 00 f5 f5 | 00 00 00 04 | 00 00 00 2d | 00 00 00 00 | ...
guestfsd: main_loop: proc 73 (mount_ro) took 0.02 seconds
guestfsd: main_loop: new request, len 0x3c
umount /sysroot/transfer3MLStM
guestfsd: main_loop: proc 45 (umount) took 0.00 seconds
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 00 2d | 00 00 00 01 | 00 12 34 56 | ...
libguestfs: trace: umount = 0
libguestfs: trace: rmdir "/transfer3MLStM"
libguestfs: send_to_daemon: 64 bytes: 00 00 00 3c | 20 00 f5 f5 | 00 00 00 04 | 00 00 00 1e | 00 00 00 00 | ...
guestfsd: main_loop: new request, len 0x3c
guestfsd: main_loop: proc 30 (rmdir) took 0.00 seconds
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 00 1e | 00 00 00 01 | 00 12 34 57 | ...
libguestfs: trace: rmdir = 0
libguestfs: trace: close
libguestfs: closing guestfs handle 0x4265bf0 (state 2)
libguestfs: trace: shutdown
libguestfs: trace: internal_autosync
libguestfs: send_to_daemon: 44 bytes: 00 00 00 28 | 20 00 f5 f5 | 00 00 00 04 | 00 00 01 1a | 00 00 00 00 | ...
guestfsd: main_loop: new request, len 0x28
umount /sysroot
fsync /dev/sda
fsync /dev/sdb
libguestfs: recv_from_daemon: 40 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 01 1a | 00 00 00 01 | 00 12 34 58 | ...
libguestfs: trace: internal_autosync = 0
libguestfs: sending SIGTERM to process 13720
libguestfs: trace: shutdown = 0
virt-v2v: No app in config matches os='windows' name='virtio' distro='windows' major='6' minor='0' arch='i386'
virt-v2v: Transferring storage volume windows2008_r1-cciss_c0d0: 72833679360 bytes

The full log can be found at http://www.kates.org/tmp/virt-v2v-5.log


As for the status of  libguestfs-test-tool  I ran it and it seems OK.

I have also posted the full output of the test tool to http://www.kates.org/tmp/libguestfs-test-tool-output.txt

				-Jason



-- 
----------------------------------------------------------------------------
Jason A. Kates (jason at kates.org) 
Fax:    208-975-1514
Phone:  660-960-0070
============================================================================

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2013-02-07 11:50:16.png
Type: image/png
Size: 63829 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20130207/01933f7a/attachment.png>


More information about the Libguestfs mailing list