Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1049855

Summary: '/var/lib/libvirt/boot' is not managed on the remote host.' during remote install
Product: Red Hat Enterprise Linux 7 Reporter: Dr. David Alan Gilbert <dgilbert>
Component: virt-managerAssignee: Giuseppe Scrivano <gscrivan>
Status: CLOSED UPSTREAM QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: berrange, crobinso, dyuan, lcui, mkletzan, mzhan, tzheng, virt-maint, vyasevic
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1049852 Environment:
Last Closed: 2014-01-28 17:55:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1049852    
Bug Blocks:    

Description Dr. David Alan Gilbert 2014-01-08 11:25:47 UTC
+++ This bug was initially created as a clone of Bug #1049852 +++

Description of problem:

F20 laptop running virt-manager -> RHEL7 ~beta host via ssh (with key)

I'm trying to do an install of RHEL7 onto the RHEL7 host, controlled from my laptop.
I tried to create a new VM using a URL as an installation source, it downloaded the initrd/vmlinuz but then failed with the error 

ValueError: Cannot use storage '/var/lib/libvirt/boot/virtinst-vmlinuz.OLwdRQ': '/var/lib/libvirt/boot' is not managed on the remote host.
(full backtrace below)

I can see that a boot-scratch storage pool in /var/lib/libvirt/boot has been created on the host.
This is the 1st VM creation I've tried on this host.

Version-Release number of selected component (if applicable):

F20 client:
libvirt-client-1.1.3.2-1.fc20.x86_64
libvirt-daemon-driver-qemu-1.1.3.2-1.fc20.x86_64
libvirt-daemon-driver-secret-1.1.3.2-1.fc20.x86_64
libvirt-daemon-config-network-1.1.3.2-1.fc20.x86_64
libvirt-daemon-1.1.3.2-1.fc20.x86_64
libvirt-daemon-driver-nwfilter-1.1.3.2-1.fc20.x86_64
libvirt-daemon-driver-storage-1.1.3.2-1.fc20.x86_64
libvirt-python-1.1.3.2-1.fc20.x86_64
libvirt-daemon-driver-network-1.1.3.2-1.fc20.x86_64
libvirt-daemon-kvm-1.1.3.2-1.fc20.x86_64
libvirt-daemon-driver-interface-1.1.3.2-1.fc20.x86_64
libvirt-daemon-driver-nodedev-1.1.3.2-1.fc20.x86_64
libvirt-glib-0.1.7-2.fc20.x86_64
virt-manager-common-0.10.0-5.git1ffcc0cc.fc20.noarch
virt-manager-0.10.0-5.git1ffcc0cc.fc20.noarch
libvirt-daemon-driver-storage-1.1.3.2-1.fc20.x86_64

RHEL7 host:
libvirt-glib-0.1.7-1.el7.x86_64
libvirt-daemon-driver-nwfilter-1.1.1-16.el7.x86_64
libvirt-client-1.1.1-16.el7.x86_64
libvirt-daemon-driver-nodedev-1.1.1-16.el7.x86_64
libvirt-daemon-driver-storage-1.1.1-16.el7.x86_64
libvirt-daemon-driver-interface-1.1.1-16.el7.x86_64
libvirt-daemon-driver-network-1.1.1-16.el7.x86_64
libvirt-daemon-kvm-1.1.1-16.el7.x86_64
libvirt-python-1.1.1-16.el7.x86_64
libvirt-daemon-1.1.1-16.el7.x86_64
libvirt-daemon-driver-secret-1.1.1-16.el7.x86_64
libvirt-daemon-driver-qemu-1.1.1-16.el7.x86_64
qemu-kvm-common-1.5.3-30.el7.x86_64
qemu-kvm-1.5.3-30.el7.x86_64
qemu-img-1.5.3-30.el7.x86_64


How reproducible:
It succeeded trying a second time - so I suspect this is a race involving the creation of the boot-scratch storage storage, where it's not quite ready when it comes to use it.

Steps to Reproduce:
1. Take one F20 machine with a GUI, and a remote RHEL7 machine
2. Start virt-manager, add RHEL7 machine as a connection (I'm using an ssh key)
3. Add a new machine, giving an installation URL for the OS (in this case a RHEL7 install)

Actual results:

'/var/lib/libvirt/boot' is not managed on the remote host.' during remote install

Expected results:
A nice fresh running RHEL7 guest

Additional info:
Unable to complete install: 'Cannot use storage '/var/lib/libvirt/boot/virtinst-vmlinuz.OLwdRQ': '/var/lib/libvirt/boot' is not managed on the remote host.'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 1959, in do_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 370, in start_install
    self._prepare_install(meter, dry)
  File "/usr/share/virt-manager/virtinst/guest.py", line 263, in _prepare_install
    util.make_scratchdir(self.conn, self.type))
  File "/usr/share/virt-manager/virtinst/installer.py", line 212, in prepare
    self._prepare(guest, meter, scratchdir)
  File "/usr/share/virt-manager/virtinst/distroinstaller.py", line 422, in _prepare
    self._prepare_kernel_url(guest, fetcher)
  File "/usr/share/virt-manager/virtinst/distroinstaller.py", line 346, in _prepare_kernel_url
    fetcher.meter, kernel, initrd)
  File "/usr/share/virt-manager/virtinst/distroinstaller.py", line 289, in _upload_media
    kvol = _upload_file(conn, meter, pool, kernel)
  File "/usr/share/virt-manager/virtinst/distroinstaller.py", line 119, in _upload_file
    disk.path = os.path.join(poolpath, name)
  File "/usr/share/virt-manager/virtinst/devicedisk.py", line 457, in _set_path
    self._change_backend(val, None)
  File "/usr/share/virt-manager/virtinst/devicedisk.py", line 644, in _change_backend
    path, vol_object, None, None, None)
  File "/usr/share/virt-manager/virtinst/devicedisk.py", line 118, in _distill_storage
    conn, path)
  File "/usr/share/virt-manager/virtinst/diskbackend.py", line 129, in check_if_path_managed
    raise ValueError(err)
ValueError: Cannot use storage '/var/lib/libvirt/boot/virtinst-vmlinuz.OLwdRQ': '/var/lib/libvirt/boot' is not managed on the remote host.

Comment 2 tingting zheng 2014-01-10 07:29:04 UTC
I tested on F20 desktop and try to install guest on remote rhel7 host using http,I didn't hit the issue in description of the bug,but hit errors described in bug 1044742.

Comment 3 Dr. David Alan Gilbert 2014-01-10 20:13:47 UTC
Hi Tingting,
  The RHEL7 host you tried it on, was that a fresh install or had it had guests installed on it already?

Dave

Comment 4 tingting zheng 2014-01-13 02:29:21 UTC
(In reply to Dr. David Alan Gilbert from comment #3)
> Hi Tingting,
>   The RHEL7 host you tried it on, was that a fresh install or had it had
> guests installed on it already?
> 
> Dave

The rhel7 host I've tried has already installed some guests.

Comment 5 Dr. David Alan Gilbert 2014-01-13 09:31:26 UTC
(In reply to tingting zheng from comment #4)
> (In reply to Dr. David Alan Gilbert from comment #3)
> > Hi Tingting,
> >   The RHEL7 host you tried it on, was that a fresh install or had it had
> > guests installed on it already?
> > 
> > Dave
> 
> The rhel7 host I've tried has already installed some guests.

OK; my suspicion from the bug is that it would probably only happen on the first install but I don't know for sure.

Comment 6 Dr. David Alan Gilbert 2014-01-16 16:05:17 UTC
Triggered this again today doing the same sequence; so it's certainly repeatable for me (this was on a different beaker host running RHEL7 - I think using the build from the 10th)

Comment 7 Vlad Yasevich 2014-01-16 18:27:35 UTC
Happened to me today when trying to install a VM on a newly provisioned beaker machine.  Seems to be caused by the fact that /var/lib/libvirt/boot was not
in the libvirt pool list.  After the failed provision, the boot director shows
up in the pool list and subsequent install gets past this problem.

-vlad

Comment 8 Giuseppe Scrivano 2014-01-28 17:55:53 UTC
fixed upstream by:

commit 7f669267217528396d89c4f9f559ad4324571cb1
Author: Cole Robinson <crobinso>
Date:   Sat Jan 18 14:57:39 2014 -0500

    Fix first time remote URL installs from virt-manager (bz 1049852)
    
    On first run, the remote URL install handling creates a storage pool
    for /var/lib/libvirt/boot on the remote host. After this, it clears
    the VirtualConnection's object cache, so the next time all pools are
    fetched, it returns an accurate list.
    
    However that clear_cache call wasn't propagated up to virt-manager's
    cache. Add a new cb to fix it.

Comment 9 Cole Robinson 2014-01-28 18:10:30 UTC
To be clear, the root issue was in virt-manager upstream and the version in fedora. So there's not anything in RHEL to fix here. There's a fedora bug in POST that's tracking when the fix hits fedora;

https://bugzilla.redhat.com/show_bug.cgi?id=1049852