On Wed, Mar 22, 2017 at 4:04 AM, Michal Privoznik <mprivozn@redhat.com> wrote:

On 03/21/2017 07:04 PM, D L wrote:
> Yes, I compiled, installed, and used the binaries successfully.
> Could you confirm the location of bug list is the following, please?
>
> https://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Virtualization%20Tools

This will fetch all bug there are/ever were for upstream libvirt, regardless of their state. You want just opened ones. Thus this should be:

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&component=libvirt&product=Virtualization%20Tools&query_format=advanced

> https://bugzilla.redhat.com/enter_bug.cgi?product=Virtualization%20Tools&component=libvirt

This is for entering a new bug. Unless you've found one, you don't need this.

Michal

Hi Michal,

To keep the thread consistent, I am writing now about two Bugs here which probably

have been mentioned in other thread. So I am watching two bugs, and trying to decide

one to fix. They are 1431652 and 1434550.

For 1434550, I am reading ./src/nodeinfo.c and several other related files for a bug

about possible incorrect number of socket when executing 'virsh capabilities' on a host.

It seems this totally depends on design decision. When showing cell number = 2 and

socket = 1 in the XML CPU topology in a 2 CPU sockets machine indeed kinda of

confusing, if one does not read the XML carefully, or is not familiar with the notion of

"cell". Would people want it to be changed or leave it in the current state?

For 1431652, I am able to reproduce the error. And I also tried to use absolute path

which resulted in different output and behavior as the following from 'history' command

513 truncate -s 100M test-backing.img

514 pwd

515 qemu-img create /var/tmp/test-overlay.img -f qcow2 -b 'json:{"driver":"raw","file":

{"driver":"file","filename":"/var/tmp/test-backing.img"}}'

516 ls -lh

517 history

root@<host> :/var/tmp# !507

qemu-img info test-overlay.img

image: test-overlay.img

file format: qcow2

virtual size: 100M (104857600 bytes)

disk size: 196K

cluster_size: 65536

backing file: json:{"driver":"raw","file":{"driver":"file","filename":"/var/tmp/test-backing.img"}}

Format specific information:

compat: 1.1

lazy refcounts: false

refcount bits: 16

corrupt: false

root@<host> :/var/tmp# !508

virt-install --import --name tmp-relpaths --memory 1024 --disk /var/tmp/test-overlay.img

WARNING No operating system detected, VM performance may suffer. Specify an OS

with --os-variant for optimal results.

WARNING Graphics requested but DISPLAY is not set. Not running virt-viewer.

WARNING No console to launch for the guest, defaulting to --wait -1

Starting install...

Creating domain... | 0 B 00:00:00

Domain installation still in progress. Waiting for installation to complete.

At the end, it hanged and I had to terminated the 'virsh install' by ctrl + C. So I guess

the expected behavior when using 'virsh install' with relative path should be the same.

Is that right?

I may want to try both of the bugs and maybe

one of them can be solved in a timely manner. Or would you recommend one, or other

one than those two? (I did attempt to search something like xml parser or cmd generation

bugs which could be closer to the fuzzing project)

Dan