On Tue, Jun 16, 2009 at 04:14:02PM -0600, bodhi zazen wrote: > I normally run KVM from the command line and it work well. > > I appreciate and am impressed with the work that has gone into virt-manager. > > I am wondering what the process is to put in requests for additional > features ? It depends what your request is for, but typically either this mailing list, or the libvirt mailing list, or file a bug report requesting the feature. If you have ability to create patches even better :-) > I would like to suggest adding some of the command line options to > virt-manager, or at least a way to specify options manually. This is an often requested feature, but afraid we explicitly do not allow for specifying extra KVM arguments. libvirt defines a XML config model that is idependant of any virtualization technology. So exposing KVM command line args in this would break our goal of compatability. If there are KVM command line args we don't currently support that you need, please mention them so we can come up with a generic way to represent them in libvirt XML. > Options / features I use on a regular basis on the command line not > available in virt-manager are : > > 1. Bridged networking. Yes I know this can be manually configured and once > configured works with virt-manager, still would be nice to see this > automated. This is coming real soon .... scheduled for Fedora 12 http://fedoraproject.org/wiki/Features/Shared_Network_Interface > 2. Snapshots. KVM has a rich set of options for snapshots. Boot a snapshot, > save changes, save the machine state, etc. Any consideration being given to > adding these options. Our storage APIs in libvirt allow for creating LVM snapshots, and creating qcow2 files with a backing file. We don't yet support internal qcow2 snapshots for snapshotting the whole VM state, but that is planned for the future. We don't have a target date yet though. > 3. Additional networking options would be nice. Host only , virtual private > network. Out of the box libvirt provids a virtual network called 'default' which gives guests NAT'd access to the LAN. You can add more virtual networks, and turn off the NAT ability thus giving you a 'host only' network. Not sure what you're wanting with 'virtual private network' - that terminology is quite overloaded with meaning.. > 4. Bridge wireless network cards. Wireless cards don't react well with bridging, becasue they'll typically drop all traffic with a non-matching MAC address. eg they'll drop all your guest traffic :-( In addition there is the issue that the guest will never see when your host switches wireless networks, so won't know it needs to run DHCP again. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
