Re: problem with virt-manager

my previous message:
 >RunRunning virt-manager on  my Fedora 9 system
 >running kernel: 2.6.26-0.115.rc9.git2.fc10.x86_64 SMP
 >
 >I get the following error:
 >
 >gar xp]# virt-manager
 >Traceback (most recent call last):
 >  File "/usr/share/virt-manager/virt-manager.py", line 
310, >in <module>
 >    main()
 >  File "/usr/share/virt-manager/virt-manager.py", line 
239, >in main
 >    gtk.gdk.threads_init()
 >SystemError: error return without exception set

I downloaded the source and loaded the debuging info.
strace provide the following:

open("/usr/share/virt-manager/virt-manager.py", O_RDONLY) = 7
write(2, "  File \"/usr/share/virt-manager/v"..., 72  File 
"/usr/share/virt-manager/virt-manager.py", line 310, in <module>
) = 72
fstat(7, {st_mode=S_IFREG|0644, st_size=11835, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffddeb05000
read(7, "# -*- python -*-\n#\n# Copyright (C"..., 4096) = 4096
read(7, "level from gconf, or command line"..., 4096) = 4096
read(7, ", \"uuid\", value)        \n    s = "..., 4096) = 3643
write(2, "    "..., 4    )                  = 4

[PATCH] virt-manager: populate storage pools, vols

The attached patch adds some of the lower level plumbing for
libvirt storage api awareness in virt-manager.

Similar to the vmmNetwork and vmmDomain classes, I've added
a vmmStoragePool and vmmStorageVol to wrap the underlying
libvirt objects and provide convenience methods. The only
other changes in this patch are to the connection object
to poll for currently available pools and make this info
accessable.

I've been carrying this for a while so I think it's pretty
stable.

Thanks,
Cole

# HG changeset patch
# User "Cole Robinson <crobinso@...>"
# Date 1217535344 14400
# Node ID a3c5cd7b86ed627261054d1850c9b7646333553b
# Parent  66bddd644b8297ec78e958f547991e358e7e84ec
Add vmmStorage{Pool,Vol}, poll for these devices in connection tick function.

diff -r 66bddd644b82 -r a3c5cd7b86ed src/virtManager/connection.py
--- a/src/virtManager/connection.py	Thu Jul 24 16:42:43 2008 -0400
+++ b/src/virtManager/connection.py	Thu Jul 31 16:15:44 2008 -0400
@@ -36,6 +36,7 @@
 from virtManager.domain import vmmDomain
 from virtManager.network import vmmNetwork

[PATCH] virtinst: Remove most prompting from virt-* tools

The attached patch removes most parameter prompting from
the virt command line tools. I think any usefulness they
once had is largely gone, and they are becoming a maintainance
burden. This burden is even more apparent trying to
update this stuff to accommodate remote installs.

Currently, if not specified, we prompt for:

  vm name (will now fail if not specified)
  vm ram  (will now fail if not specified)
  install media (this is a real pain now. originally the
                 install type matrix was far simpler, so
                 abstracting what type of media the user
                 'really' means is actually impossible
                 in some cases from this prompt)
  pv vs. hvm (this was actually dropped in last release)
  enable vnc (should just default to vnc if display is set,
              nographics otherwise)
  disk path  (will now fail, and inform user they need to
              specify --nodisks if they don't want storage)
  disk size, if disk doesn't exist (will now fail)

There are also some yes/no prompts to keep users from
shooting themselves in the foot

  sparse disk max size exceeds physical disk capacity
  specified more vcpus than physical cpus

I say we leave these in. I think these are generally useful,
and any automated virt-install commands should use --force

[PATCH] report block size in add hardware summary

The way virt-manager is setup now is that it only reports sizes of file
backed images and a "-" with storage partitions.

This patch addresses that issue.

I'll be filing a bug for RHEL5 as soon as bugzilla comes out of
maintenance mode

Thanks

-- 
              _|-  |  _  _
             _\|_()|<(/__\
 .----------------------------------.
( astokes@... || 919.754.4187 )
 `----------------------------------'

diff -r 6815a5f94048 src/virtManager/addhardware.py
--- a/src/virtManager/addhardware.py	Thu Jul 31 16:02:39 2008 -0400
+++ b/src/virtManager/addhardware.py	Sat Aug 02 10:38:33 2008 -0400
@@ -277,6 +277,12 @@
             return self.window.get_widget("storage-file-address").get_text()

     def get_config_disk_size(self):
+        if self.window.get_widget("storage-partition").get_active():
+            partition_address = self.window.get_widget("storage-partition-address").get_text()
+            fd = open(partition_address,"rb")
+            fd.seek(0,2)
+            block_size = fd.tell() / 1024 / 1024

Re: [PATCH] report block size in add hardware summary

Adam Stokes wrote:
> The way virt-manager is setup now is that it only reports sizes of file
> backed images and a "-" with storage partitions.

I'm fine with the idea, however this patch needs a bit of work.

First this will need to be duplicated in create.py for the 
guest creation wizard. I'd recommend breaking it out into
it's own function as well so we don't start adding a lot
of logic to the relatively simple get_config_* functions.

Also, could you wrap this code in a try...except block, just
log an error if we can't detect the size, and return None.

> 
> This patch addresses that issue.
> 
> I'll be filing a bug for RHEL5 as soon as bugzilla comes out of
> maintenance mode
> 

Actually could you just bring this up in bz 453061? It's basically
covering the same issue.

Thanks,
Cole

Re: [PATCH] report block size in add hardware summary

> First this will need to be duplicated in create.py for the 
> guest creation wizard. I'd recommend breaking it out into
> it's own function as well so we don't start adding a lot
> of logic to the relatively simple get_config_* functions.
This is complete, though for the logic part im not really sure the best
way to handle the different varieties that can be seen here
> 
> Also, could you wrap this code in a try...except block, just
> log an error if we can't detect the size, and return None.
Complete as well 

> Actually could you just bring this up in bz 453061? It's basically
> covering the same issue.

Sure thing I've appended this issue to the above BZ.

Please let me know your thoughts on the latest patch

Thanks
--

-- 
              _|-  |  _  _
             _\|_()|<(/__\
 .----------------------------------.
( astokes@... || 919.754.4187 )
 `----------------------------------'

diff -r 6815a5f94048 src/virtManager/addhardware.py
--- a/src/virtManager/addhardware.py	Thu Jul 31 16:02:39 2008 -0400
+++ b/src/virtManager/addhardware.py	Mon Aug 04 06:45:00 2008 -0400

[PATCH] virt-manager: access keys collision in gui

When going through the add-hardware or create wizard there is a access
key collision in the network setup.

This addresses the access key collision by changing the label for
Setting the mac address to use _a rather than _f.

Thanks

-- 
              _|-  |  _  _
             _\|_()|<(/__\
 .----------------------------------.
( astokes@... || 919.754.4187 )
 `----------------------------------'

diff -r 6815a5f94048 src/vmm-add-hardware.glade
--- a/src/vmm-add-hardware.glade	Thu Jul 31 16:02:39 2008 -0400
+++ b/src/vmm-add-hardware.glade	Mon Aug 04 10:17:41 2008 -0400
@@ -965,7 +965,7 @@
                               <widget class="GtkCheckButton" id="mac-address">
                                 <property name="visible">True</property>
                                 <property name="can_focus">True</property>
-                                <property name="label" translatable="yes">Set _fixed MAC address for this NIC?</property>
+                                <property name="label" translatable="yes">Set fixed MAC _address for this NIC?</property>
                                 <property name="use_underline">True</property>
                                 <property name="response_id">0</property>
                                 <property name="draw_indicator">True</property>
diff -r 6815a5f94048 src/vmm-create.glade
--- a/src/vmm-create.glade	Thu Jul 31 16:02:39 2008 -0400

Re: [PATCH] report block size in add hardware summary

Adam Stokes wrote:
>> First this will need to be duplicated in create.py for the 
>> guest creation wizard. I'd recommend breaking it out into
>> it's own function as well so we don't start adding a lot
>> of logic to the relatively simple get_config_* functions.
> This is complete, though for the logic part im not really sure the best
> way to handle the different varieties that can be seen here
>> Also, could you wrap this code in a try...except block, just
>> log an error if we can't detect the size, and return None.
> Complete as well 
> 
>> Actually could you just bring this up in bz 453061? It's basically
>> covering the same issue.
> 
> Sure thing I've appended this issue to the above BZ.
> 
> Please let me know your thoughts on the latest patch
> 
> Thanks
> 

Thanks! I've committed this:

http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=7a0eb7f2ab10

- Cole

Re: [PATCH] virt-manager: access keys collision in gui

Adam Stokes wrote:
> When going through the add-hardware or create wizard there is a access
> key collision in the network setup.
> 
> This addresses the access key collision by changing the label for
> Setting the mac address to use _a rather than _f.
> 
> Thanks
> 

Yeah virt-manager really needs some love in the mnemonics/accelerators
department. I've committed this:

http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=f31200001da2

Thanks,
Cole

Re: problem with virt-manager

Gary Richardson wrote:
> my previous message:
>  >RunRunning virt-manager on  my Fedora 9 system
>  >running kernel: 2.6.26-0.115.rc9.git2.fc10.x86_64 SMP
>  >
>  >I get the following error:
>  >
>  >gar xp]# virt-manager
>  >Traceback (most recent call last):
>  >  File "/usr/share/virt-manager/virt-manager.py", line 
> 310, >in <module>
>  >    main()
>  >  File "/usr/share/virt-manager/virt-manager.py", line 
> 239, >in main
>  >    gtk.gdk.threads_init()
>  >SystemError: error return without exception set
> 
> 

I'm really not sure what could be causing this error. If
threads_init() is causing problems I'm inclined to say
it's not a virt-manager issue.

Have you only recently hit this problem? Or is this your
first time trying out the app?

- Cole