Bug 585460

ok, I think my text got lost in my first attempt.

I pinpointed this in gentoo.  It's virt-manager.  In debian, a version selection narrows it down to virt-manager, not libvirt.

The options for cdrom should be on offer.  They are in place for kxm qemu.
Apparently virt-manager makes a default selection for full virt, leaving para virt out in the cold.
Previous versions got this right.

See the gentoo bug, all explained there.

Again an attempt to enter has got lost.

In gentoo, the version of virt-manager is 0.8.4  Fedora's is a 0.8.2.

Being older, it lacks a couple of options to the newer package.  The back door for virt-manager I described in the cited gentoo bug report.
In fedora, it lacks this luxury, lacking that option.  It's obliged to attempting a cdrom install without removing the offending device.  It never gets o enter the new vm into virt-manager, so rescue via libvirt is blocked.

I do wonder though how it could go unnoticed through a number of versions.  I need it tested on some other machines, the being vms I can't see hoe it could vary, the virtual software removing it  from the hardware layer.  Afterall, the fault occurs trying to create an emulated device, not plug into  a real one.

This bug is extremely unclear. Please lay out exactly what packages you are using, and what you are trying to do. For one thing, Fedora doesn't even have any xen host support, so I'm not sure how you are connecting to Xen in fedora.

What is the output of 'virsh --connect xen:/// capabilities'? 

Please provide ~/.virt-manager/virt-manager log after reproducing this issue.

Created attachment 417497 [details]
log of the failes attmpt to install via cdrom.

The log of virt-manager, as requested, which demos the fault in virt-manager installing from cdrom.

This bug is extremely unclear.

Well let's try to make it clear. 

'What is the output of 'virsh --connect xen:/// capabilities'?'

[idella@fedora12 ~]$ sudo virsh -c xen:/// capabilities
[sudo] password for idella: 
<capabilities>

  <host>
    <cpu>
      <arch>i686</arch>
      <features>
        <pae/>
      </features>
    </cpu>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>xenmigr</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='1'>
        <cell id='0'>
          <cpus num='2'>
            <cpu id='0'/>
            <cpu id='1'/>
          </cpus>
        </cell>
      </cells>
    </topology>
  </host>

  <guest>
    <os_type>xen</os_type>
    <arch name='i686'>
      <wordsize>32</wordsize>
      <emulator>/usr/lib/xen/bin/qemu-dm</emulator>
      <machine>xenpv</machine>
      <domain type='xen'>
      </domain>
    </arch>
    <features>
      <pae/>
    </features>
  </guest>

  <guest>
    <os_type>hvm</os_type>
    <arch name='i686'>
      <wordsize>32</wordsize>
      <emulator>/usr/lib/xen/bin/qemu-dm</emulator>
      <loader>/usr/lib/xen/boot/hvmloader</loader>
      <machine>xenfv</machine>
      <domain type='xen'>
      </domain>
    </arch>
    <features>
      <pae/>
      <nonpae/>
      <acpi default='on' toggle='yes'/>
      <apic default='on' toggle='yes'/>
    </features>
  </guest>

</capabilities>

Please lay out exactly what packages you are using,

python-virtinst-0.500.1-2.fc12
virt-mem-0.3.1-9.fc12(i686)
virt-manager-0.8.2-3.fc12(i686)
xen-3.4.2-1.fc12(i686)
xen-hypervisor-3.4.2-1.fc12(i686)
xen-libs-3.4.2-1.fc12(i686)

I shall re-summarise.

Steps to Reproduce:
1.Invoke virt-manager within xen.  select new vm
2.Choose any system on cdrom dvd.  Enter info.  Within xen, select new vm to install.  Select cdrom as the source.  Progress to the last screen.  Check the check-box of Advanced options, which summarises the config options.
The selection of which type of virtualisation is a list-box of two items.
For xen, para-virt or full-virt.  If it were qemu / kvm, it would be qemu / kvm.
3.  Select finish

I've already described this in the linked report.  From it;

  
"The problem is that the options at the very last step are greyed out.  This gave me the impression that the options were with-held, shouldn't be so, and made the choice of a cdrom dvd install unworkable.  If you click return and let it attempt, it does return an erroneous error and stops from installing."


I must admit , I relied upon the results from gentoo to apply to fedora, and they do.  All my descriptions pertain to fedora, except that fedora's virt-manager is 0.8.2, older than gentoo's.  But sure enough, it's reproduced.  In tying it now, fedora firstly put up an error couldn't find domain name, then retying, it just hangs and freezes.  I have however the same key cause.  I do have the virt-manager log, see the attached log above.

Once again I was expecting one thing to be the cause, but found something else.  It appears that the two options being greyed out are not the cause of it pulling up.  From the log, it's apparent that the choice of full-virt has been made.  So then there are two separate faults;  The first, the options being greyed out when they should be 'live', and second the cause of this bug, the included virtual sound device.


"I ran virt-manager through a console debugger and also cross-referenced the
cdrom install with a direct install to virt-install and pinpointed the error it
produces.  Now it may perhaps be specific to my hardware but the same mistake
occured in squeeze and fedora.

I acquired xml dumps from libvirt of the faulty virt-manager install and did a
direct comparison with the xml dump of an effective cdrom install from libvirt
directly.  combined with the debug output, I narrowed it down to a simple
virtual hardware selection made by the virt-manager / virt-install duo.

No need to include the dumps, but it  came down to this line

    <sound model='es1370'/>                                                    

I transposed every other element of the healthy into the faulty xml definition
of the vm, and this was the cause of it.  The sound choice didn't work, got
hald associated errors everywhere pointing the finger at a virtual hardware
device.  Remove the sound hardware selection, compromise and do without it, and
it becomes an effective install.
"

The log done now in fedora, the attachment, also creates that line.

Keeping to fedora's version, the user can't recover from this via virt-manager because it doesn't yet have the option to review and alter the options in the vnc console the last thing before executing the install.  To recover, you can take the xml file, edit and remove the sound device and re define the new vm from virsh, and it will be viable.

Now I've provided alot of technical backup for this.  I am 'new' at submitting bugs, but I've done a bit of it now.  The question is whether it's clear to you.
As  said, I find it strange it go unrecorded through a few versions, so I'm open to it being something in my system, but it's consistent and repeatable in three separate distros.  It worked fine a number of versions ago.

From gentoo, 

"> I would strongly suggest you report these as bugs to the virtinst and
> virt-manager maintainers then.
> 
> http://www.virt-manager.org/page/BugReporting
> 
" 

which leads to here.  So, fedora doesn't support xen as a host. Not surprisingly, I just imported another xen kernel

[idella@fedora12 ~]$ uname -a
Linux fedora12.homenetwork 2.6.31-xen-r10 #27 SMP Wed Apr 21 06:38:59 WST 2010 i686 i686 i386 GNU/Linux

This is where you can tell me how the systems work.  I just found that bugzilla.redhat is cited as the 'home base' for dealing with these virtual software bugs, libvirt, virtinst virt-manager.

I have submitted a couple which proved erroneous, but this one has been persistent in the cited distros.

I hope this is clear and look forward to a response.

p.s.

a couple of supporting examples

[idella@fedora12 ~]$ sudo tail /var/log/xen/xend-debug.log
cat: /sys/bus/scsi/devices/target10:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target10:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target10:0:0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target11:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target11:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target11:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target11:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target11:0:0/scsi_level: No such file or directory
/usr/lib/python2.6/site-packages/xen/xend/XendAPI.py:544: DeprecationWarning: object.__new__() takes no parameters
  return object.__new__(cls, *args, **kwds)


and 


[idella@fedora12 ~]$ sudo cat /var/log/xen/qemu-dm-karmic.log.2
domid: 1
qemu: the number of cpus is 2
/usr/lib/xen/bin/qemu-dm: invalid option -- '-soundhw'

[idella@fedora12 ~]$ sudo cat /var/log/xen/qemu-dm-karmic.log
domid: 3
qemu: the number of cpus is 2
/usr/lib/xen/bin/qemu-dm: invalid option -- '-soundhw'
[idella@fedora12 ~]$ 


and


[idella@fedora12 ~]$ sudo tail /var/log/xen/xend.log
    return op_method(op, req)
  File "/usr/lib/python2.6/site-packages/xen/xend/server/SrvDomain.py", line 85, in op_wait_for_devices
    return self.dom.waitForDevices()
  File "/usr/lib/python2.6/site-packages/xen/xend/XendDomainInfo.py", line 1068, in waitForDevices
    self.getDeviceController(devclass).waitForDevices()
  File "/usr/lib/python2.6/site-packages/xen/xend/server/DevController.py", line 140, in waitForDevices
    return map(self.waitForDevice, self.deviceIDs())
  File "/usr/lib/python2.6/site-packages/xen/xend/server/DevController.py", line 169, in waitForDevice
    "Device not found." % (devid, self.deviceClass))
VmError: Device 5632 (vbd) could not be connected. Device not found.

If you want more, can spark up the python debugger.  But I think this is pinpointed.

Okay, the sound device issue is separate. You can work around that in virt-manager with Edit->Preferences, Uncheck 'Sound devices for new local VM' or whatever the option is called. Not sure why xen is suddenly erroring out from sound devices though.

virt-manager was incorrectly disabling the 'Xen (fullvirt)' option in the dropdown, as your screenshot shows. I've fixed this upstream now:

http://hg.fedorahosted.org/hg/virt-manager/rev/490caf506693

Xen (Paravirt) option is correctly disabled though: CDROM installs are not supported for paravirt. The tooltip on the icon next to the box should inform you of that.

However that issue didn't prevent me from actually creating the VM, so it's not a major problem. That sound device issue sounds like the only thing getting in your way.

One question though, what are you using for a xen kernel? Fedora doesn't ship one, were you getting it from somewhere else?

Cole, thanks for the quick reply, a pleasing outcome.


(In reply to comment #7)
> Okay, the sound device issue is separate. You can work around that in
> virt-manager with Edit->Preferences, Uncheck 'Sound devices for new local VM'
> or whatever the option is called. 

Yes, with you.

Not sure why xen is suddenly erroring out
> from sound devices though.
> 

This was the problem I was encountering.  It hijacked virt-manager's capacity to install from the dvd cdrom.  I would like it if you could tell me if this is the first you've seen or heard of it.  It is consistent in my systems.


> virt-manager was incorrectly disabling the 'Xen (fullvirt)' option in the
> dropdown, as your screenshot shows. I've fixed this upstream now:
> 
> http://hg.fedorahosted.org/hg/virt-manager/rev/490caf506693
> 

Excellent, well done.

> Xen (Paravirt) option is correctly disabled though: CDROM installs are not
> supported for paravirt. The tooltip on the icon next to the box should inform
> you of that.
> 

This is curious.  In Suse (11), I finally got virt-manager to install and manage vms.  Its version DID offer this option.  Mind you, it offered it but it constantly refused to use it, except upon itself.

A linux magazine article I have uses centos (5.3) to install and manage xen.  It actually cites using the cdrom or .iso image as a source and uses them as a network install source, and does para-virt installs.  So this is curious.  You're the redhat reference on this!  And. centos 5.3 is way old.

Anyway, that means that cdrom .iso images in xen are only usable for full virt.
Right.  And the tool tip in virt-manager needs a tool tip.

> However that issue didn't prevent me from actually creating the VM, so it's not a major problem. 

Yes, agreed.

That sound device issue sounds like the only thing getting in
> your way.
> 

Yes, it was.  When I first found it, it just stopped me in my tracks.  It's taken me months to pin it down, a steep learning curve to tackle these intricate packages.    Once discovered, it was easy to work around it.


> One question though, what are you using for a xen kernel? Fedora doesn't ship
> one, were you getting it from somewhere else?    

Nor does ubuntu.  I've run lenny and karmic and gentoo and now fedora with this gentoo xen kernel.  If it wasn't apparent. I'm an established gentoo user.
Building kernels goes with the territory.  I did have some help with it.
I'm not a gentoo kernel guru but I've had lots of practice.
My gentoo kernel is a good host kernel.  Ubuntu made a good guest kernel, 2.6.31.6 which i use.  I copied and edited it and cloned it for gentoo 64.

Do you mind me running fedora as a xen host and testing virt-manager?
The ubuntu developers did.

> Not sure why xen is suddenly erroring out
> > from sound devices though.
> > 
> 
> This was the problem I was encountering.  It hijacked virt-manager's capacity
> to install from the dvd cdrom.  I would like it if you could tell me if this is
> the first you've seen or heard of it.  It is consistent in my systems.
> 

Yes, it is the first I've heard of it. Most likely because 99% of virt-manager users in fedora aren't using xen, since we don't ship a dom0 kernel.

...

> 
> > Xen (Paravirt) option is correctly disabled though: CDROM installs are not
> > supported for paravirt. The tooltip on the icon next to the box should inform
> > you of that.
> > 
> 
> This is curious.  In Suse (11), I finally got virt-manager to install and
> manage vms.  Its version DID offer this option.  Mind you, it offered it but it
> constantly refused to use it, except upon itself.
> 

There are ways around it, if you are using an install DVD, try mounting it an exporting it as a URL: for most distros, virt-manager will be able to install from it. Maybe SUSE does something like that automatically for paravirt, but we don't.

...
 
> > One question though, what are you using for a xen kernel? Fedora doesn't ship
> > one, were you getting it from somewhere else?    
> 
> Nor does ubuntu.  I've run lenny and karmic and gentoo and now fedora with this
> gentoo xen kernel.  If it wasn't apparent. I'm an established gentoo user.
> Building kernels goes with the territory.  I did have some help with it.
> I'm not a gentoo kernel guru but I've had lots of practice.
> My gentoo kernel is a good host kernel.  Ubuntu made a good guest kernel,
> 2.6.31.6 which i use.  I copied and edited it and cloned it for gentoo 64.
> 
> Do you mind me running fedora as a xen host and testing virt-manager?
> The ubuntu developers did.    

I can't say it's high priority for fedora, but as virt-manager upstream I'm interested in any issues you hit, so it might be a good idea to track fedora rawhide or possible virt-manager upstream.

There is also a fedora guy who builds upstream dom0 kernel RPMs, info here;

http://fedorapeople.org/~myoung/dom0/

(In reply to comment #9   
> 
> I can't say it's high priority for fedora, but as virt-manager upstream I'm
> interested in any issues you hit, so it might be a good idea to track fedora
> rawhide or possible virt-manager upstream.
> 
> There is also a fedora guy who builds upstream dom0 kernel RPMs, info here;
> 
> http://fedorapeople.org/~myoung/dom0/    

Cole, thanks, it was a long time coming, but your response is very good.  It actually validates my findings, a pleasant change to some other reports.

I'm a gentoo follower.  What is fedora rawhide?  I'm in unfamiliar territory.

I'll certainly look at that link.

I have a number of other findings; debian has born the brunt of them.
The bug reporting for virt-manager points to redhat, i.e. you.  So this is how I've ended up on redhat bugzilla, remembering that gentoo bugzilla pointed me here too.  Please treat me as a new comer unfamiliar with redhat and fedora.
I'm mostly practiced in gentoo, which also had gaps in its packaging of things virt.  (My gentoo and xen is now in tip top shape

Cole, 
I looked for fedora rawhide in google, so never mind about that.
Do you mind if I put some virt related questions to you to your redhat email site?

Sure.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Not backporting to F12 at this point, so closing against F13 where this is
currently fixed.