Hide Forgot
Description of problem: Note that i only flagged this as high priority because it's breaking tests. feel free to adjust it . When virt-install is invoked in the nightly trees without --nodisks option, it no longer asks for image location. In 6.1, it would: # virt-install --name GuestOne_a --cdrom /var/lib/libvirt/images/GuestOne.iso --ram=1024 --vcpus=1 --file-size=20 --hvm --debug --prompt --accelerate --os-variant=virtio26 --network bridge:br0 --noreboot --vnc Wed, 10 Aug 2011 06:40:25 DEBUG Launched with command line: /usr/sbin/virt-install --name GuestOne_a --cdrom /var/lib/libvirt/images/GuestOne.iso --ram=1024 --vcpus=1 --file-size=20 --hvm --debug --prompt --accelerate --os-variant=virtio26 --network bridge:br0 --noreboot --vnc Wed, 10 Aug 2011 06:40:25 DEBUG Requesting libvirt URI default Wed, 10 Aug 2011 06:40:25 DEBUG Received libvirt URI qemu:///system Wed, 10 Aug 2011 06:40:25 DEBUG Requesting virt method 'hvm', hv type 'default'. Wed, 10 Aug 2011 06:40:25 DEBUG Received virt method 'hvm' Wed, 10 Aug 2011 06:40:25 DEBUG Hypervisor name is 'kvm' Wed, 10 Aug 2011 06:40:26 DEBUG Setting os type to 'linux' for variant 'virtio26' Please enter the path to the file you would like to use for storage. It will have size 20.0GB. In 6.2 nightly tree the installation goes on, to never-never land with no obvious errors, causing automated tests to fail when the tests are submitted without appropriate --disk options . Note that the tests rely on virt-install's prompting capability to answer the questions if the testers don't submit any. Version-Release number of selected component (if applicable): # rpm -qa | egrep "python-virtinst|libvirt" libvirt-client-0.9.4-1.el6.x86_64 libvirt-0.9.4-1.el6.x86_64 libvirt-python-0.9.4-1.el6.x86_64 libvirt-java-0.4.7-1.el6.noarch libvirt-java-devel-0.4.7-1.el6.noarch libvirt-devel-0.9.4-1.el6.x86_64 python-virtinst-0.600.0-2.el6.noarch How reproducible: Everytime Steps to Reproduce: 1. Invoke virt-install without --nodisks option with no disk image location. 2. 3. Actual results: It tries to go on with the installation. Expected results: It should gracefully fail with error. Additional info:
Hi, I see /distribution/virtinstall in cvs is updated these days. Now when running it, some errors happen and they look like relating to this bug. On Mon Aug 08 01:58:55 -0400 2011 https://errata.devel.redhat.com/errata/show/11298#c75 They all passed. These days: https://beaker.engineering.redhat.com/jobs/119842 https://beaker.engineering.redhat.com/jobs/119846 /distribution/virtinstall fails on x86_64 with the message: "Sun, 14 Aug 2011 22:49:33 ERROR Need to pass size for each disk somehow no diskspace is given. Report this as a bug for virtinstall test" Could you please have look at this? Thanks. Igor Kernel QE
Fixed upstream: http://git.fedorahosted.org/git?p=python-virtinst.git;a=commit;h=de8aaf09157a31aa8ca66036371751100b3d0edb But I really hope our QE tests aren't depending on interacting with virt-install's prompting mode? I can understand using it for an interactive test but if we are automating virt-install please don't use --prompt.
Fixed in python-virtinst-0.600.0-3.el6
Reproduced with the following components: libvirt-0.9.4-7.el6.x86_64 python-virtinst-0.600.0-2.el6.noarch Verified with the following components: libvirt-0.9.4-7.el6.x86_64 python-virtinst-0.600.0-3.el6.noarch kernel-2.6.32-191.el6.x86_64 qemu-kvm-0.12.1.2-2.184.el6.x86_64 virt-manager-0.9.0-6.el6.x86_64 Steps: 1. virt-install -n guest -c /var/lib/libvirt/images/RHEL6.2-20110823.1-Server-x86_64-DVD1.iso -r 1024 --vcpus=1 --file-size=5 --hvm --debug --prompt --accelerate --os-variant=virtio26 --noreboot --vnc ... Thu, 01 Sep 2011 20:03:04 DEBUG Setting os type to 'linux' for variant 'virtio26' Please enter the path to the file you would like to use for storage. It will have size 5.0GB. /var/lib/libvirt/images/guest.img Thu, 01 Sep 2011 20:10:19 DEBUG Path '/var/lib/libvirt/images' is target for pool 'default'. Creating volume 'guest.img ... (The guest could be installed successfully) So move the status of this bug to verified.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No description necessary
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. http://rhn.redhat.com/errata/RHBA-2011-1643.html