Re: Making labels selectable in properties dialog

Rob James wrote:
> Ah, OK, that seems better. I've attached the bundle for the patch.
> Would you be able to review for me? i wasn't able to test against head
> though as when compiling the hg source here it won't show the details
> page ('NoneType' object is not iterable).
> 

Not sure why you were getting an error with upstream checkout, but I
applied your patch:

http://hg.et.redhat.com/cgi-bin/hg-virt.cgi/applications/virt-manager--devel/rev/b8b3bf2c628c

Thanks,
Cole

Heads up: new virtinst + virt-manager releases in coming weeks

Hi all,

Just a heads up that I'm planning on pushing a new virtinst release this
coming Tuesday, March 3rd. A new virt-manager release will be pushed out
a week later (March 9th, maybe a few days earlier). All in time for
Fedora 11 Beta :)

So if you have anything you'd like to get resolved, please raise (or
re-raise) it.

Thanks,
Cole

Re: Support for kvm/qemu cache mode

Ok, thanks for all the off-list help.

Here's my patch for adding cache support to virt-install.  I'm not super 
happy with the xml if/elif bits at VitualDisk.py:681, but that part of the 
code is a bit tricky anyway.

http://ben.nerp.net/virtinst/cache-support-v4.diff

There are some other logs and output examples in the dir:

http://ben.nerp.net/virtinst/

It would be great to get this in for the next release.

-ben

  "UNIX is user-friendly, it's just picky about its friends."

On Wed, 25 Feb 2009, Cole Robinson wrote:

> Ben Kochie wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Libvirt now supports an xml bit to select qemu cache types.
>>
>> <disk type='block' device='disk'>
>>   <driver name='qemu' cache='writethrough'/>
>>   <source dev='/path/to/dev'/>

[PATCH 0/3] virt-install: support host device assignment

The following patches add support for host device assignment to virtinst
and virt-install.

The patches aren't complete, since I'm not entirely sure how managed or
unmanaged devices coincide with HostDeviceDetach and HostDeviceReset,
and how this relates to PCI vs. USB. But it shouldn't be a big change
from what's posted.

The patches are:

01 - Support for parsing libvirt nodedev xml
02 - Support for building domain 'hostdev' device xml
03 - virt-install --host-device option

Thanks,
Cole

[PATCH 1/3]: Add NodeDeviceParser module

Add NodeDeviceParser module for parsing libvirt host device xml,
associated helper functions and tests.

Thanks,
Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[PATCH 2/3]: Add VirtualHostDevice classes

Add VirtualHostDevice classes for build domain 'hostdev' device xml,
along with associated tests.

This is currently incomplete: I'm not entirely clear on how a managed
vs. unmanaged device interacts with HostDeviceAttach/Reset, and if there
are differences in whats applicable for USB vs. PCI devices. The libvirt
API for all this hasn't officially landed yet either so this is blocked
until then.

Thanks,
Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[PATCH 3/3]: Add virt-install --host-device command

Add a --host-device command to virt-install. It takes a libvirt nodedev
name as it's only argument, and attaches the associated device to the
new VM.

Thanks,
Cole

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

Re: [PATCH 0/3] virt-install: support host device assignment

On Sun, Mar 01, 2009 at 11:41:11PM -0500, Cole Robinson wrote:
> The following patches add support for host device assignment to virtinst
> and virt-install.
> 
> The patches aren't complete, since I'm not entirely sure how managed or
> unmanaged devices coincide with HostDeviceDetach and HostDeviceReset,
> and how this relates to PCI vs. USB. But it shouldn't be a big change
> from what's posted.

If 'managed=yes' then libvirt will automatically detach the device
from the host driver. This is nice & simple, but also nice & easy
to shoot yourself in the foot - don't mix up the PCI id for the NIC
you want to pasthrough with your SATA controller 

If 'managed=no' then libvirt expects that the caller has already ensured
the device is detached from the host before *ALL* attempts to start the
guest, now & in the future. The app can use HostDeviceDetach todo this
but remember it has to be manually run every time, which probably is not
what you want. The more likely case for using managed=no, is if you have
statically assigned the PCI device ID to pcistub.ko in /etc/modprobe.conf
so that is guarenteed detached from the moment you boot.

I'd strongly recommend virt-install only use managed=yes, and don't make
the use pick PCI ids off the list, rather present them with the human
readable vendor and product names. When picking PCI devices you can
also use the node device APIs to query for any other devices which are
children of that PCI device - so if there are 2 identical NICs in the
machine, you can show the user that one is eth0 and the other is eth1
to help them pick the right one.

Re: RFC: virt-manager: Redesigned 'New VM' wizard

Cole Robinson wrote:
> Hi all,
>
> 
> Page 5: Summary and Advanced Options
> 
> http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg5-1.png
> http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg5-2.png
> http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg5-3.png
> 
> The summary section is pretty straight forward, no surprises here.
> The 'Advanced Options' section encompasses networking, hypervisor, and
> architecture options. The hypervisor and arch defaults were explained above.
> 
> For networking, the default is:
> 
> - A bridge device if any exist, else
> - Virtual Network 'default' (comes out of the box with libvirt), else
> - First available virtual network, else
> - no networking!

Networking being "hidden" seems a bit odd here. In a decent number of 
the cases I have used the tool in (not all) i wanted to select this. It 
it possible to show this information on the summary, and then have them 
click into advanced to set it?

-- bk

Re: RFC: virt-manager: Redesigned 'New VM' wizard

Bryan Kearney wrote:
> Cole Robinson wrote:
>> Hi all,
>>
>>
>> Page 5: Summary and Advanced Options
>>
>> http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg5-1.png
>> http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg5-2.png
>> http://fedorapeople.org/~crobinso/virt-manager/newvm2/newvm-pg5-3.png
>>
>> The summary section is pretty straight forward, no surprises here.
>> The 'Advanced Options' section encompasses networking, hypervisor, and
>> architecture options. The hypervisor and arch defaults were explained
>> above.
>>
>> For networking, the default is:
>>
>> - A bridge device if any exist, else
>> - Virtual Network 'default' (comes out of the box with libvirt), else
>> - First available virtual network, else
>> - no networking!
> 
> Networking being "hidden" seems a bit odd here. In a decent number of
> the cases I have used the tool in (not all) i wanted to select this. It
> it possible to show this information on the summary, and then have them
> click into advanced to set it?
> 

In the times you were changing the default network selection, what was