RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1146017 - virt-v2v -v -x during windows guest conversion will hang at hivex: hivex_open: used block id ……
Summary: virt-v2v -v -x during windows guest conversion will hang at hivex: hivex_open...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard: V2V
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-24 10:01 UTC by tingting zheng
Modified: 2015-03-05 13:45 UTC (History)
7 users (show)

Fixed In Version: libguestfs-1.27.55-1.1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 13:45:38 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0303 0 normal SHIPPED_LIVE libguestfs bug fix and enhancement update 2015-03-05 17:34:44 UTC

Description tingting zheng 2014-09-24 10:01:56 UTC 
Description
virt-v2v -v -x during windows guest conversion will hang at hivex: hivex_open: used block id ……

Version:
virt-v2v-1.27.53-1.1.el7.x86_64
libguestfs-winsupport-7.1-4.el7.x86_64
libguestfs-1.27.53-1.1.el7.x86_64
virtio-win-1.7.2-1.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1.Use virt-v2v -v -x to convert a windows guest,from esx server or xen server.
# virt-v2v -ic vpx://administrator.7.125/tzheng-test/10.66.71.84/?no_verify=1 esx5.1-win7-i386 -v -x |& tee /tmp/v2v-esx-win7-hang.log

The conversion will always hang at some place as below:
hivex: hivex_open: used block id -64,9 at 0x581db8 size 16
hivex: hivex_open: used block id 110,107 at 0x581dc8 size 120
hivex: hivex_open: used block id 118,107 at 0x581e40 size 40
hivex: hivex_open: used block id 67,0 at 0x581e68 size 72
hivex: hivex_open: used block id 118,107 at 0x581eb0 size 32
hivex: hivex_open: used block id 82,0 at 0x581ed0 size 40
hivex: hivex_open: used block id 64,14 at 0x581ef8 size 16
hivex: hivex_open: used block id 110,107 at 0x581f08 size 120
hivex: hivex_open: used block id 118,107 at 0x581f80 size 40
hivex: hivex_open: used block id 67,0 at 0x581fa8 size 72
hivex: hivex_open: used block id -128,15 at 0x581ff

Actual results：
As decribed.

Expected results:
virt-v2v -v -x during windows guest conversion will not hang and the conversion will finish.

Additional info:
If I don't use -v -x option,then conversion will finish.
Attached the log file.
Comment 3 tingting zheng 2014-09-25 02:49:18 UTC 
When converting windows guests from xen server using -v -x option,virt-v2v will also hang.
Comment 5 Richard W.M. Jones 2014-09-25 13:34:46 UTC 
I wonder if /tmp is running out of disk space.  That causes qemu
to hang (see bug 745576).

The root cause of this is that we shouldn't be putting the overlay
on /tmp.  It should go on /var/tmp (or even better, guestfs_get_cachedir).
So I have added this patch:

https://github.com/libguestfs/libguestfs/commit/9a9d10d2a0388f84ace3454c56071c544a3b923f

(Will appear in virt-v2v >= 1.27.55)
Comment 6 zhoujunqin 2014-09-26 03:42:22 UTC 
(In reply to Richard W.M. Jones from comment #5)
> I wonder if /tmp is running out of disk space.  That causes qemu
> to hang (see bug 745576).

I rerun command (for details see this link:https://bugzilla.redhat.com/show_bug.cgi?id=1145916#c10 )

# virt-v2v -ic xen+ssh://10.66.106.64 -os default xen-hvm-win7-x86_64 -of qcow2 -v -x |& tee xen-hvm-win7-x86_64.log

virt-v2v command hangs at:
hivex: hivex_open: used block id 76,0 (L.) at 0x1966fc0 size 48
hivex: hivex_open: used block id 168,95 (._) at 0x1966ff0 size 16
hivex: hive

file xen-hvm-win7-x86_64.log locates in /root, while hanging check the /root space, enough left.
# df -h /root/
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda6        98G   77G   22G  79% /
Comment 7 Richard W.M. Jones 2014-09-26 07:34:21 UTC 
Right, but specifically I need to know if */tmp* is running out
of space.  That is where the overlay is stored (or was in < 1.27.55,
in >= 1.27.55 it has moved to /var/tmp).
Comment 8 zhoujunqin 2014-09-26 08:45:27 UTC 
(In reply to Richard W.M. Jones from comment #7)
> Right, but specifically I need to know if */tmp* is running out
> of space.  That is where the overlay is stored (or was in < 1.27.55,
> in >= 1.27.55 it has moved to /var/tmp).

while hanging, check host:

# df -h /tmp/
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda6        98G   77G   21G  79% /

# df -h 
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda6        98G   77G   21G  79% /
devtmpfs        3.8G     0  3.8G   0% /dev
tmpfs           3.9G  140K  3.9G   1% /dev/shm
tmpfs           3.9G  9.0M  3.8G   1% /run
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
Comment 9 Richard W.M. Jones 2014-09-26 16:51:15 UTC 
I don't think it will necessarily help, but please try
libguestfs-1.27.55-1.1.el7
Comment 11 zhoujunqin 2014-09-28 05:14:57 UTC 
I can reproduce it as bug description.
Then try to verify it with new build:
libguestfs-1.27.55-1.1.el7.x86_64
virt-v2v-1.27.55-1.1.el7.x86_64
qemu-kvm-rhev-2.1.2-1.rwmj1.el7.x86_64

steps:
#  virt-v2v -ic xen+ssh://10.66.106.64 -os default   xen-hvm-win7-x86_64 -of qcow2  -on xen-hvm-win7-x86_64-third  -v -x |& tee /tmp/newtracing.log
[   0.0] Opening the source -i libvirt -ic xen+ssh://10.66.106.64 xen-hvm-win7-x86_64
libvirt xml is:
<domain type='xen'>
  <name>xen-hvm-win7-x86_64</name>
  <uuid>a0e13e6b-96a2-ba79-b290-88dfd7d64306</uuid>
  <memory>524288</memory>
  <currentMemory>524288</currentMemory>
  <vcpu>1</vcpu>
  <os>
....
qemu-img convert -p -n -f qcow2 -O 'qcow2' '/var/tmp/v2vovlb8a132.qcow2' '/var/lib/libvirt/images/xen-hvm-win7-x86_64-third-sda'
    (100.00/100%)
[ 384.0] Creating output metadata
Pool default refreshed

Domain xen-hvm-win7-x86_64-third defined from /tmp/v2vlibvirt9a7300.xml

[ 384.0] Finishing off

Result: conversion finished successfully and without hanging，so move this bug to VERIFIED.
Comment 13 errata-xmlrpc 2015-03-05 13:45:38 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0303.html
Note You need to log in before you can comment on or make changes to this bug.