Bug 701814 - virt-win-reg fails on a libvirt guest that has no defined disk format: "format parameter is empty or contains disallowed characters"
virt-win-reg fails on a libvirt guest that has no defined disk format: "forma...
Status: CLOSED UPSTREAM
Product: Virtualization Tools
Classification: Community
Component: libguestfs (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard W.M. Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-03 19:40 EDT by Tom Horsley
Modified: 2012-05-03 11:48 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-03 11:48:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
virsh dumpxml winxppro (2.23 KB, text/plain)
2011-05-03 19:43 EDT, Tom Horsley
no flags Details
New fedora 15 modified winxppro.xml (2.57 KB, text/plain)
2011-05-08 19:16 EDT, Tom Horsley
no flags Details

  None (edit)
Description Tom Horsley 2011-05-03 19:40:40 EDT
Description of problem:

Wanted to check out the virt-win-reg tool, so I tried this example from
the web page I found:

[root@zooty ~]# cvkey='HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
[root@zooty ~]# virt-win-reg winxppro $cvkey ProductName
format parameter is empty or contains disallowed characters at /usr/lib64/perl5/Sys/Guestfs/Lib.pm line 256.

If I use the file image name it works:

[root@zooty ~]# cd /zooty/images/
[root@zooty images]# virt-win-reg winxppro.img "$cvkey" ProductName
Microsoft Windows XP

Version-Release number of selected component (if applicable):
libguestfs-1.8.6-1.fc14.x86_64


How reproducible:
Seems to be 100%

Steps to Reproduce:
1.see above
2.
3.
  
Actual results:
Funny perl error

Expected results:
Same as when I used the image name

Additional info:

Image file is qcow2 with a backing file in case that matters:

[root@zooty images]# pwd
/zooty/images
[root@zooty images]# qemu-img info winxppro.img
image: winxppro.img
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 92M
cluster_size: 65536
backing file: winxpsp3-acpi-base.img (actual path: winxpsp3-acpi-base.img)
Comment 1 Tom Horsley 2011-05-03 19:43:22 EDT
Created attachment 496666 [details]
virsh dumpxml winxppro

Here's the xml def of the winxppro machine. I do have two disks attached, as
well as a cd iso image. Don't know if the multiple disks might confuse it.
Comment 2 Richard W.M. Jones 2011-05-04 14:12:57 EDT
This is potentially a dupe of bug 672825 or bug 674130.

Tom, since we have made a lot of changes to the inspection
code and virt-win-reg in (eg) 1.10 and 1.11, can you try a
newer version?  In particular the newer version should behave
correctly when presented with a Windows VM that has multiple
disks (whereas it was definitely broken before).
Comment 3 Tom Horsley 2011-05-08 18:47:46 EDT
Well, I get different results with fedora 15 beta and
libguestfs-1.10.2-1.fc15.x86_64, in fact it does seem to work giving it
just the domain name:

[root@zooty ~]# cvkey='HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
[root@zooty ~]# virt-win-reg winxppro "$cvkey" ProductName
Microsoft Windows XP

The xml for winxppro is almost the same (but I now have it working with
spice directly under libvirt instead of with a silly wrapper script).
Comment 4 Richard W.M. Jones 2011-05-08 19:00:12 EDT
I think this is a bug, but it's got nothing to do with
having multiple disks.  It is because the libvirt <disk>
element isn't specifying the format of the disk.  From
your attachment:

    <disk type='file' device='disk'>
      <driver name='qemu'/>
      <source file='/zooty/images/winxppro.img'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>

Notice that <driver name='qemu'/> does not specify a type
attribute, eg. type='raw'.

The odd thing is that I cannot reproduce this configuration.

If I take an existing guest and try to remove the type
attribute, then libvirt insists on adding it back.
(CC'd to Dan Berrange to see if he's got any idea).

Nevertheless I suspect that if the type field *is* missing,
as it clearly is in your case, then virt-win-reg probably
does the wrong thing.
Comment 5 Tom Horsley 2011-05-08 19:16:32 EDT
Created attachment 497692 [details]
New fedora 15 modified winxppro.xml

So that may be the reason it worked in fedora 15. Since I was running with the
default qemu.conf that disables probing, I figured I'd better put the
type in as long as I was editing the xml to make the spice changes as well.
Here's the winxppro xml def I used in the f15 example which worked OK.
Comment 6 Richard W.M. Jones 2011-05-09 03:26:15 EDT
What was the old version of libvirt / version of Fedora that allowed
you to have a guest with no disk type?
Comment 7 Tom Horsley 2011-05-09 05:29:57 EDT
I'm on an f14 system I keep fully up to date, but perhaps libvirt
is influenced by my qemu.conf file in which I uncommented the setting
so as to allow disk probing: allow_disk_format_probing = 1. I also
uncommented the group and user to leave them "root".

Here's all the rpm versions that look to be "virt" related:

python-virtinst-0.500.6-1.fc14.noarch
libvirt-0.8.3-9.fc14.x86_64
python-virtkey-0.50-8.fc14.x86_64
virt-manager-0.8.7-2.fc14.noarch
libvirt-client-0.8.3-9.fc14.x86_64
virt-top-1.0.4-3.fc13.x86_64
libvirt-python-0.8.3-9.fc14.x86_64
virt-viewer-0.2.1-1.fc13.x86_64

This winxppro machine originated several releases ago, and I've be
copying it from release to release by using virsh dumpxml and
virsh define, but it has never been reluctant to add other
things too it (like the pci bus settings).
Comment 8 Richard W.M. Jones 2012-05-03 07:40:59 EDT
Patches posted upstream to fix this:

https://www.redhat.com/archives/libguestfs/2012-May/msg00012.html
Comment 9 Richard W.M. Jones 2012-05-03 11:48:57 EDT
Fixed in 1.17.39.

Note You need to log in before you can comment on or make changes to this bug.