Description of problem:
When installing a guest using virt-install, the storage used for the guest, is not registered so that virt-manager knows about it.
Ie. after the install, when looking at it with virt-manager, it doesn't show up anywhere under managed storage, as it would do if one uses virt-manager to install the image.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Take a fresh install of RHEL60A3
2. Run virt-install --prompt and go through the process.
3. Launch virt-manager, right click on host->Details->Storage
Nothing is listed under managed storage
The image or the image directory should be listed.
I am now sure if this is a virt-install or virt-manager bug, so feel free to move it appropriately.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
If the user points to a directory that isn't a libvirt storage pool, we don't auto-poolify it (teach libvirt/virt-manager about it), we just provision one off storage on move along. I'm starting to think this isn't the way to do things though. Either way this is RHEL6.1 material since it would be a ripe for regressions.
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as an
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.
Isn't looking likely for 6.2, moving to 6.3
Fixing this is an important long term improvement for virtinst/virt-manager, but it will be invasive. And given that our capacity for virt-manager work is reduced for RHEL, I'm moving this to the upstream tracker.
Duping to virt-manager bug for autopoolifying storage, since it's all going to be the same fix.
*** This bug has been marked as a duplicate of bug 557107 ***