[Pkg-libvirt-maintainers] Bug#578173: other lenny

[IAN DELANEY]

Guido,

some more sobering info.  I have two instances of lenny.  One installed from a dvd, the other installed from a xen live cd.
The first is a 64 bit lenny, standard debian, the second is a hard drive install derived from the live xen cd.
As my other report indicated, I installed this live cd onto its own partition onto the hard drive.  That done, I tried installing,
That said, I had tried installing on the first some months ago, only to find all these troubles.

The reports just submitted were done on the second.  I've switched over to the first and repeated an install.
What I expected was to have the vnc console come up and hopefully trigger the reported bug.
This first closely matches the second.  I've installed the same backport versions of libvirt0 and libvirt-bin, and also two dnsmasq packages to match.  So It's almost identical, at least re the key packages.

xen is 3.2-1, the same.
virt-manager is 0.6.0-6
libvirto and libvirt-bin are the same backported packages.
python-libvirt is 0.4.6-10

The outcome is troublesome;

the failure to contact the vnc console is still in place, that's awkward.  The backorted packages didn't remove the issue.
Selecting the hardware tab of the console of the new install, the Serial o entry is in fact blank.  That is different.
The virt-manager also differs; it lists the current vms, xen and qemu, but offers no data detail in columns to the right of the listed vms.

So which lenny is the genuine article??

I removed /var/lib/dmesg and /var/lib/syslog and ~/.virt-manager.log to procure new clean data.  The fault pulling up so early has removed the luxury of any logs.  They are all empty.

What I can provide is an xml dump.

virsh # dumpxml Gentoo-2006
<domain type='xen' id='13'>
  <name>Gentoo-2006</name>
  <uuid>1d287949-ef4e-ed05-2513-bf813e7e4fe6</uuid>
  <memory>263168</memory>
  <currentMemory>263168</currentMemory>
  <vcpu>2</vcpu>
  <os>
    <type>hvm</type>
    <loader>/usr/lib/xen-default/boot/hvmloader</loader>
    <boot dev='cdrom'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>destroy</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/lib64/xen/bin/qemu-dm</emulator>
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/mnt/images/xen/images/gentoo/Gentoo-2006.img'/>
      <target dev='hda' bus='ide'/>
    </disk>
    <disk type='block' device='cdrom'>
      <driver name='phy'/>
      <source dev='/dev/sr0'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>
    <interface type='bridge'>
      <mac address='00:16:36:6d:5e:4d'/>
      <source bridge='eth0'/>
      <script path='vif-bridge'/>
      <target dev='vif13.0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
    <sound model='es1370'/>
  </devices>
</domain>

This dumpxml feature caused me much grief.  I tried to take the xml file and edit it to a workable form, but libvirt kept annuling and blocking my changes to the file to make a more healthy state.


 		 	   		  
_________________________________________________________________
Need a new place to live? Find it on Domain.com.au
http://clk.atdmt.com/NMN/go/157631292/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-libvirt-maintainers/attachments/20100418/3f3b3460/attachment-0001.htm>