Hide Forgot
Description of problem: When you create a new guest using virt-manager and select to create new disk virt-manager will pickup the name for you automatically. If a file with this name exists it will pick another one. This will break when adding a second disk to the guest before the 1st disk image has been created. Version-Release number of selected component (if applicable): virt-manager-0.8.6-2.el6.noarch How reproducible: Always Steps to Reproduce: 1. Create new guest (my name is t4) and select to create a disk image of 8GB. 2. At the end select to customize the guest before installation. 3. Notice that disk 1 has a path of /var/lib/libvirt/images/t4.img 4. Add a second disk and select to create new disk image. Actual results: The second disk also uses the file path /var/lib/libvirt/images/t4.img. When you continue with the install you have 2 disks backed up by the same disk image. Expected results: The second disk image will be created with a filename such as /var/lib/libvirt/images/t4-1.img Additional info:
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Good catch, though deferring to 6.2 since it isn't a trivial fix
*** Bug 720969 has been marked as a duplicate of this bug. ***
Upstream now: http://git.fedorahosted.org/git?p=virt-manager.git;a=commit;h=d692ea652dc17e15a90ea2ae7dff517b2db43f14
Fixed in virt-manager-0.9.0-2.el6
verified with the following components: libvirt-0.9.4-1.el6.x86_64 virt-manager-0.9.0-5.el6.x86_64 Steps: 1. Create new guest (my name is demo) and select to create a disk image of 8GB. 2. At the end select to customize the guest before installation. 3. Notice that disk 1 has a path of /var/lib/libvirt/images/demo.img 4. Add a second disk and select to create new disk image. and its source path is "/var/lib/libvirt/images/demo-1.img"; 5. Add a third disk and select to create new disk image again, and its source path is "/var/lib/libvirt/images/demo-2.img";
Hi folks, i'm not sure if this is desired behavior or I'm hitting another issue. Please let me know: 1) I already have a disk named t1.img 2) I create new guest named t2 and assign the t1.img as it's first disk (name is important, it is different from guest name) 3) Then I select to customize the configuration and start adding additional disks 4) Select to create a new virtio disk image. It will be named t2.img 5) Add one more disk. Again create new one. Actual Results: Upon adding the 3rd disk I already have t1.img and t2.img created. virt-manager tells me that t2.img storage already exists but is not in use by any virtual machine. It will ask the user if they want to use the existing disk image or not. If you select No then a new image file called t2-1.img will be created. If you select Yes then the 3rd disk will be assigned the same path as the second disk. Expected results: I expect that since t2.img is already assigned virt-manager will not ask me about it and create the t2-1.img, t2-2.img and so on. I suspect the cause for this is that when checking if disk images are in use virt-manager will check only for existing guests but not for guests which are about to be created.
Created attachment 518247 [details] screenshot of dialog
I can reproduce comment 8's issue,i thought this bug not fixed completely. step same with comment 8 with :virt-manager-0.9.0-5.el6 Hi Cole: Reopen this bug or file new bug? please help confirm. thanks in advance.
Thanks for the additional report, that issume in comment #8 will need additional dev work, so another bug should be opened.
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-1642.html