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