Bug 507202

Summary: libvirt fails to install a guest using an ISO on a NFS mount
Product: [Fedora] Fedora Reporter: Braden McDaniel <braden>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 11CC: berrange, clalance, crobinso, hbrock, itamar, markmc, nphilipp, veillard, virt-maint
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-23 04:00:52 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 480594    
Attachments:
Description Flags
~/.virt-manager/virt-manager.log
none
/home/braden/bolt-vista-x64.log
none
~/.virt-manager/virt-manager.log using libvirt-0.6.2-13.fc11
none
/var/log/libvirt/qemu/bolt-vista-x64.log using libvirt-0.6.2-13.fc11 none

Description Braden McDaniel 2009-06-21 11:47:34 EDT
Description of problem:
I get this error message when attempting to create a virtual machine:

Unable to complete install '<class 'libvirt.libvirtError'> internal error Domain bolt-vista-x64 didn't show up

Version-Release number of selected component (if applicable):
0.7.0-5.fc11

How reproducible:
Consistently.

Additional info:

This appears in the "Details" box:

Unable to complete install '<class 'libvirt.libvirtError'> internal error Domain bolt-vista-x64 didn't show up

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 1501, in do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 541, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 633, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 974, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error Domain bolt-vista-x64 didn't show up

'
Comment 1 Mark McLoughlin 2009-06-22 12:33:29 EDT
See also https://fedoraproject.org/wiki/Reporting virtualization bugs

What versions of python-virtinst, libvirt and qemu-system-x86?

Please attach ~/.virt-manager/virt-manager.log and /var/log/libvirt/qemu/$guest.log
Comment 2 Nils Philippsen 2009-06-29 07:49:22 EDT
Just FYI, I got a similar error when I tried to install a VM with 2048MB of RAM on a 32-bit machine. There was an error message in the log file that only 2047MB are supported (which didn't make it through to the GUI). After adjusting the RAM size to that, it worked.
Comment 3 Braden McDaniel 2009-07-03 01:59:46 EDT
Created attachment 350375 [details]
~/.virt-manager/virt-manager.log

I get the error even when I use the default settings of 512 MB RAM and one CPU.

$ rpm -q python-virtinst libvirt qemu-system-x86
python-virtinst-0.400.3-8.fc11.noarch
libvirt-0.6.2-12.fc11.x86_64
qemu-system-x86-0.10.5-3.fc11.x86_64
Comment 4 Braden McDaniel 2009-07-03 02:02:30 EDT
Created attachment 350376 [details]
/home/braden/bolt-vista-x64.log
Comment 5 Mark McLoughlin 2009-07-03 09:28:47 EDT
libvir: Security Labeling error : SELinuxSetFilecon: unable to set security context 'system_u:object_r:virt_content_t:s0' on /share/en_windows_vista_sp2_x64_dvd_342267.iso: Operation not supported.
libvir: QEMU error : internal error Failed to set security label

Braden: could you try with libvirt-0.6.2-13.fc11 from updates-testing? It looks like this is a dup of bug #507555
Comment 6 Braden McDaniel 2009-07-30 00:41:19 EDT
Using libvirt-0.6.2-13.fc11 doesn't appear to change anything.

I'll attach updated log files.
Comment 7 Braden McDaniel 2009-07-30 00:42:39 EDT
Created attachment 355638 [details]
~/.virt-manager/virt-manager.log using libvirt-0.6.2-13.fc11
Comment 8 Braden McDaniel 2009-07-30 00:47:27 EDT
Created attachment 355639 [details]
/var/log/libvirt/qemu/bolt-vista-x64.log using libvirt-0.6.2-13.fc11
Comment 9 Mark McLoughlin 2009-08-10 09:05:58 EDT
libvir: Security Labeling error : SELinuxSetFilecon: unable to set security context 'system_u:object_r:virt_content_t:s0' on /share/en_windows_vista_sp2_x64_dvd_342267.iso: No such file or directory.
libvir: QEMU error : internal error Failed to set security label

Okay, the problem here seems to be that you've deleted the iso which is still referenced in the XML configuration for the guest. You can fix that by using the 'Disconnect' button in virt-manager's Details->disk hdc

We should fix libvirt not to fail in this case because we're also going to fix qemu to not fail in this case - see bug #473154
Comment 10 Daniel Berrange 2009-08-10 09:42:56 EDT
I don't see why we should ignore this error - it is a clearly broken configuration. Ignoring the failure to relabel a disk because the operation is not supported is reasonable. Ignoring an error due to the file path not even existing is just going to silently hide problems from users.

bug 473154 is a different problem to the one reported here. The reason /dev/sr0 opening failed is because that was a physical CDROM device with no media present - the path itself still exists. In this bug the report is about a path to an ISO image, not a CDROM device.
Comment 11 Mark McLoughlin 2009-08-10 10:30:02 EDT
Okay, looks like you're right about bug #473154 - even with Cole's patch, qemu will still fail if the ISO has been deleted

Bear in mind, though, that we leave the cdrom connected to the ISO for window's installs and users will fairly naturally just delete the ISO at some point after the install has finished.
Comment 12 Braden McDaniel 2009-08-10 12:46:02 EDT
No, I have not deleted the iso.  It is still there as I type this.  Unless the process of creating the virtual machine removes and replaces that file, that error message is inaccurate.

Now, /share is an NFS mount.  Could that be the problem?
Comment 13 Braden McDaniel 2009-08-10 18:10:14 EDT
And Mark, as stated in the original description of this bug, this is happening during virtual machine creation. There is thus no opportunity to disconnect the iso.
Comment 14 Mark McLoughlin 2009-08-11 07:33:00 EDT
(In reply to comment #9)
> libvir: Security Labeling error : SELinuxSetFilecon: unable to set security
> context 'system_u:object_r:virt_content_t:s0' on
> /share/en_windows_vista_sp2_x64_dvd_342267.iso: No such file or directory.

It's the "No such file or directory" that lead me to believe the ISO had been deleted. But, as I discovered in bug #515547, this error message is bogus

(In reply to comment #12)

> Now, /share is an NFS mount.  Could that be the problem?

Yep, that's the problem.

In order to use ISOs on an NFS mount for installing guests, you need to mount it using the virt_content_t label e.g.

  $> mount -o context="system_u:object_r:virt_content_t:s0" ....

Hopefully that sorts it out for you, sorry it took so long to diagnose

I've updated:

  https://fedoraproject.org/wiki/Reporting_virtualization_bugs#SELinux

Thanks
Comment 15 Mark McLoughlin 2009-08-21 07:15:21 EDT
Actually, the alternative to mounting it with a specific context is to set the 'virt_use_nfs' sebool:

  $> sebool virt_use_nfs on

However, libvirt currently has a bug that prevents the from working. See bug #517157

*** This bug has been marked as a duplicate of bug 517157 ***
Comment 16 Braden McDaniel 2009-09-23 03:17:36 EDT
Reopening.  libvirt-0.7.1 doesn't appear to fix this problem.  The error message has changed a bit, though:


Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: bind(unix:/var/lib/libvirt/qemu/bolt-vista-x64.monitor): Permission denied
qemu: could not open monitor device 'unix:/var/lib/libvirt/qemu/bolt-vista-x64.monitor,server,nowait'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 1489, in do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 628, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 726, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1077, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error unable to start guest: bind(unix:/var/lib/libvirt/qemu/bolt-vista-x64.monitor): Permission denied
qemu: could not open monitor device 'unix:/var/lib/libvirt/qemu/bolt-vista-x64.monitor,server,nowait'

'
Comment 17 Mark McLoughlin 2009-09-23 04:00:52 EDT
Thanks for trying

That's a different issue to the NFS issue, so I'm going to close it again

The "could not open monitor device" issue was fixed by an selinux-policy update AFAIR. Please open a new bug if it persists

*** This bug has been marked as a duplicate of bug 517157 ***