On Wed, Mar 22, 2017 at 4:04 AM, Michal Privoznik <mprivozn@xxxxxxxxxx> 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
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
