virt-manager create disk image with LVM hangs for ever

workaround: in virt-manager, create storage _BEFORE_ creating guest.

and BTW, I'm not sure this relates to LVM.

If I use default storage pool (disk images in /var/lib/libvirt/images), virt-manager also hangs.

Did anyone take a look to this?

Can I enable debug? What should I look for?

I cannot reproduce this problem, it works fine for me.

Are you using "localhost (QEMU Usermode)" or "localhost (QEMU)" in virt-manager?

Hello Marc,

I'm using "localhost (QEMU)".

Thanks!

Do you get any error messages if you try doing it with "virt-manager --debug" ?

Nothing useful (to me.)

zoolook@venkman:~$ virt-manager --debug
2011-02-25 21:02:01,927 (virt-manager:161): Application startup
2011-02-25 21:02:02,070 (keyring:31): No support for gnome-keyring
2011-02-25 21:02:02,190 (engine:344): About to connect to uris ['qemu+ssh://norberto@kvm0/system', 'qemu:///system']
2011-02-25 21:02:02,245 (engine:634): window counter incremented to 1
2011-02-25 21:02:02,326 (connection:861): Scheduling background open thread for qemu:///system
2011-02-25 21:02:02,327 (connection:1006): Background thread is running
2011-02-25 21:02:02,328 (connection:1044): Background open thread complete, scheduling notify
2011-02-25 21:02:02,465 (connection:1049): Notifying open result
2011-02-25 21:02:02,487 (connection:1057): qemu:///system capabilities:
<capabilities>

  <host>
    <uuid>e0be0011-d800-0165-c331-001bfcfb8208</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>core2duo</model>
      <vendor>Intel</vendor>
      <topology sockets='1' cores='4' threads='1'/>
      <feature name='lahf_lm'/>
      <feature name='xtpr'/>
      <feature name='cx16'/>
      <feature name='tm2'/>
      <feature name='est'/>
      <feature name='vmx'/>
      <feature name='ds_cpl'/>
      <feature name='pbe'/>
      <feature name='tm'/>
      <feature name='ht'/>
      <feature name='ss'/>
      <feature name='acpi'/>
      <feature name='ds'/>
    </cpu>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <secmodel>
      <model>apparmor</model>
      <doi>0</doi>
    </secmodel>
  </host>

  <guest>
    <os_type>hvm</os_type>
    <arch name='i686'>
      <wordsize>32</wordsize>
      <emulator>/usr/bin/qemu</emulator>
      <machine>pc-0.12</machine>
      <machine canonical='pc-0.12'>pc</machine>
      <machine>pc-0.11</machine>
      <machine>pc-0.10</machine>
      <machine>isapc</machine>
      <domain type='qemu'>
      </domain>
      <domain type='kvm'>
        <emulator>/usr/bin/kvm</emulator>
        <machine>pc-0.12</machine>
        <machine canonical='pc-0.12'>pc</machine>
        <machine>pc-0.11</machine>
        <machine>pc-0.10</machine>
        <machine>isapc</machine>
      </domain>
    </arch>
    <features>
      <cpuselection/>
      <pae/>
      <nonpae/>
      <acpi default='on' toggle='yes'/>
      <apic default='on' toggle='no'/>
    </features>
  </guest>

  <guest>
    <os_type>hvm</os_type>
    <arch name='x86_64'>
      <wordsize>64</wordsize>
      <emulator>/usr/bin/qemu-system-x86_64</emulator>
      <machine>pc-0.12</machine>
      <machine canonical='pc-0.12'>pc</machine>
      <machine>pc-0.11</machine>
      <machine>pc-0.10</machine>
      <machine>isapc</machine>
      <domain type='qemu'>
      </domain>
      <domain type='kvm'>
        <emulator>/usr/bin/kvm</emulator>
        <machine>pc-0.12</machine>
        <machine canonical='pc-0.12'>pc</machine>
        <machine>pc-0.11</machine>
        <machine>pc-0.10</machine>
        <machine>isapc</machine>
      </domain>
    </arch>
    <features>
      <cpuselection/>
      <acpi default='on' toggle='yes'/>
      <apic default='on' to...

[Expired for virt-manager (Ubuntu) because there has been no activity for 60 days.]

Reopening and confirming because:
  1) The original reporter had replied after it had been marked incomplete.
  2) I'm now seeing the same thing on my Oneiric box

I'm running as my normal user (that is a member of libvirtd), one observation is that the storage pools are listed as 'cryptvms' - Filesystem Directory, 'default' Filesystem Directory and 'main' LVM Volume Group. main is shown as being 0% which I'm fairly sure is wrong, and there are no volumes listed in the right pane of the 'Locate or create storage volume' pane.

The last output from virt-manager --debug occurs on the page selecting the ISO and is:

2011-08-24 01:22:08,780 (DistroInstaller:208): DistroInstaller location is a local file/path: /media/more/isos/ubuntu-11.04-desktop-amd64.iso

Dave

I scattered some debug in, and I can see that /usr/share/virt-manager/virtManager/storageBrowse.py new_volume is getting called:

    def new_volume(self, src_ignore):
        logging.debug("DAG: new_volume 1")
        pool = self.current_pool()
        logging.debug("DAG: new_volume 2")
        if pool is None:
            return

        logging.debug("DAG: new_volume 3")
        try:
            if self.addvol is None:
                logging.debug("DAG: new_volume 4")
                self.addvol = vmmCreateVolume(self.conn, pool)
                logging.debug("DAG: new_volume 5")
                self.addvol.connect("vol-created", self.refresh_current_pool)
                logging.debug("DAG: new_volume 6")
            else:
                logging.debug("DAG: new_volume 7")
                self.addvol.set_parent_pool(pool)
                logging.debug("DAG: new_volume 8")
            self.addvol.set_modal(True)
            logging.debug("DAG: new_volume 9")
            self.addvol.set_name_hint(self.vm_name)
            logging.debug("DAG: new_volume 10")
            self.addvol.show(self.topwin)
            logging.debug("DAG: new_volume 11")
        except Exception, e:
            self.show_err(_("Error launching volume wizard: %s") % str(e))

and from those it's executing 1-6, 9-11

so I added debug to createvol.py's vmmCreateVolume __init__ and show
both are getting called and seem to complete. So to me the problem seems to be
that it's marked modal and so nothing else responds, and shown - but the show
never actually makes anything appear for me.

Dave (who knows almost exactly nothing about python)

xwininfo shows the window is created but not mapped:

xwininfo: Window id: 0x8e082c6 "Add a Storage Volume"

  Absolute upper-left X: 708
  Absolute upper-left Y: 349
  Relative upper-left X: 708
  Relative upper-left Y: 349
  Width: 500
  Height: 320
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnMapped
  Override Redirect State: no
  Corners: +708+349 -712+349 -712-411 +708-411
  -geometry 500x320+708+349

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here.

I did not attempt to reproduce this issue on my own machine. There are several debug logs included in this report.

Thanks for taking the time to make Ubuntu better!

Dave,

As your regular user, could you please launch "virsh pool-list", and then "virsh pool-dumpxml name" for each of the pools? (For example: "virsh pool-dumpxml default".

Please paste the result of those commands here.

Does this issue happen no matter what pool you select?

dg@major:~$ virsh pool-dumpxml cryptvms
<pool type='dir'>
  <name>cryptvms</name>
  <uuid>b2cfd50d-3937-9077-7386-42ab7b808ad3</uuid>
  <capacity>10568388608</capacity>
  <allocation>5730799616</allocation>
  <available>4837588992</available>
  <source>
  </source>
  <target>
    <path>/discs/crypt/vms</path>
    <permissions>
      <mode>0700</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

dg@major:~$ virsh pool-dumpxml default
<pool type='dir'>
  <name>default</name>
  <uuid>9613778f-4249-4816-e938-b10277ebe211</uuid>
  <capacity>100789669888</capacity>
  <allocation>37852254208</allocation>
  <available>62937415680</available>
  <source>
  </source>
  <target>
    <path>/var/lib/libvirt/images</path>
    <permissions>
      <mode>0700</mode>
      <owner>0</owner>
      <group>0</group>
    </permissions>
  </target>
</pool>

dg@major:~$ virsh pool-dumpxml main
<pool type='logical'>
  <name>main</name>
  <uuid>507fc133-c479-ec69-fb3e-1a2693ce27c3</uuid>
  <capacity>0</capacity>
  <allocation>0</allocation>
  <available>0</available>
  <source>
    <name>main</name>
    <format type='lvm2'/>
  </source>
  <target>
    <path>/dev/main</path>
    <permissions>
      <mode>0700</mode>
      <owner>0</owner>
      <group>0</gr...

What exactly is the "main" pool that you've got defined as /dev/main?

I think virt-manager is confused by data libvirt is returning regarding lvm disks.
Command line tool parsing in libvirt's storage_backend_logical.c needs to be checked to see if it can correctly parse oneiric's tools.

I can confirm Marc's issue where trying to create the storage pool on the remote server that has LVM causes virt-manager to totally lock up.

I am running kubuntu 11.10 64bit on local host and on remote server ubuntu 11.10 64bit

Please let me know if there is anything else you would like me to provide.

I have been doing some testing now and what i cannot comprehend is that when running virt-manager --debug i am able to create a new volume no issue. The problem seems to arise if you are not in debug mode. When in debug mode and choose new volume it seems like nothing is logged by the debugger.

Also tested this on an ubuntu 11.10 virtual machine running on virtual-box the application runs perfectly fine and doesn't lock up when selecting new volume, but on a non virtualized install unless in debug mode the application locks, nothing gets outputted to debug on the console.

NEW WORK AROUND FOR THOSE NOT RUNNING IN A VIRTUAL MACHINE.

If you must create a new volume run virt-manager with the --debug switch

This lock up is not just specific to Ubuntu. My OpenSUSE machine has this exact problem, expect the --debug switch doesnt solve the problem. If i manually specify the location of the ISO file in the USE ISO image box it goes through smoothly. Just a problem when i try to browse. It locks up the program.

Also affects me - OpenSUSE.

Click Browse either to add storage pool, or to add ISO and virt-manager hangs.

Work around for me:

Create storage pool by typing in path (not clicking browse)

Create a storage pool to ISO folders

This is no longer reproducible. I always create volumes this way and it works. The latest version tested with Jammy Jellyfish: 1:4.0.0-1