Features request

[bodhi zazen]

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 ?

I would like to suggest adding some of the command line options to virt-manager, or at least a way to specify options manually.

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.

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.

3. Additional networking options would be nice. Host only , virtual private network.

4. Bridge wireless network cards.

Thank you.

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

[Michal Novotny]

Well, in my opinion you have to consider that virt-manager supports both KVM and Xen so you can't simply give KVM only stuff there. It's like the ac97 card request - Xen doesn't support this card so virt-manager doesn't have a choice to select it at all. In fact, there should be one way for already existing and maybe even domain creation - the information about connection type is stored when we have domain already setup but also, in creating new domain we know (due to virt-manager.log) what hv type will be used - whether kvm or xen so theoretically this should work to compensate the differences between KVM/Xen but I don't know whether it's a right way.

To your requested features:
1. Bridged networking - yeah, this could be good to be added there not to have to setup the bridge manually
2. Snapshots - like I said, you're referring to KVM so see above, Xen can save the machine to a checkpoint file while not running (ie. this shuts the domain down) or even when running (not shutting the domain down) and I think nothing else is there about that. I don't know about KVM options.
3. Additional networking options - what options do you mean? What would you like to have there?
4. Bridge wireless NIC cards - would this be useful?

Thanks,
Michal

On 06/17/2009 12:14 AM, 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 ?

I would like to suggest adding some of the command line options to virt-manager, or at least a way to specify options manually.

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.

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.

3. Additional networking options would be nice. Host only , virtual private network.

4. Bridge wireless network cards.

Thank you.

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

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

[Emre Erenoglu]

On Wed, Jun 17, 2009 at 8:28 AM, Michal Novotny <minovotn@...> wrote:

Well, in my opinion you have to consider that virt-manager supports both KVM and Xen so you can't simply give KVM only stuff there. It's like the ac97 card request - Xen doesn't support this card so virt-manager doesn't have a choice to select it at all. In fact, there should be one way for already existing and maybe even domain creation - the information about connection type is stored when we have domain already setup but also, in creating new domain we know (due to virt-manager.log) what hv type will be used - whether kvm or xen so theoretically this should work to compensate the differences between KVM/Xen but I don't know whether it's a right way.

Then why don't we just make an "advanced" field where a user can enter his own parameters to the qemu-kvm binary?

To your requested features:
1. Bridged networking - yeah, this could be good to be added there not to have to setup the bridge manually

+1 for this one, but with a normal user account in kvm group (not root). Adding to this:

2. Snapshots - like I said, you're referring to KVM so see above, Xen can save the machine to a checkpoint file while not running (ie. this shuts the domain down) or even when running (not shutting the domain down) and I think nothing else is there about that. I don't know about KVM options.
3. Additional networking options - what options do you mean? What would you like to have there?

I would like to open an already created TAP interface. I have a script running at boot time which creates the bridge and as many TAP interfaces as you want, owned by group kvm. Any user who is a member of kvm group can use these tap interfaces to have bridged networking in their virtual machines, without needing privilate escalation or running as root. Therefore:

3.1. Ability to choose a pre-defined TAP interface. (ie, if the OS provides pre-cooked tapX devices read/write by kvm group that one can assign to his VMs). A config, such as:

Example Config Proposal:

      <interface type='bridge'>
        <source bridge='br0'/>
        <target dev='your_precreated_tap_interface'/>

        <create dev='no'>
        <mac address="11:22:33:44:55:66"/>
      </interface>

This is more or less the same thing as bridged networking of libvirt/virt-manager, just skipping the tap device creation part and using an existing tap instead.

4. Bridge wireless NIC cards - would this be useful?

It would be, but I think there are technical limitations for bridging a wireless and a wireline card.

Best Regards,
--
Emre

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

[Michal Novotny]

On 06/17/2009 10:41 AM, Emre Erenoglu wrote:

On Wed, Jun 17, 2009 at 8:28 AM, Michal Novotny <minovotn@...> wrote:

Well, in my opinion you have to consider that virt-manager supports both KVM and Xen so you can't simply give KVM only stuff there. It's like the ac97 card request - Xen doesn't support this card so virt-manager doesn't have a choice to select it at all. In fact, there should be one way for already existing and maybe even domain creation - the information about connection type is stored when we have domain already setup but also, in creating new domain we know (due to virt-manager.log) what hv type will be used - whether kvm or xen so theoretically this should work to compensate the differences between KVM/Xen but I don't know whether it's a right way.

Then why don't we just make an "advanced" field where a user can enter his own parameters to the qemu-kvm binary?

Sounds good, if a user knows the virtualization tool well, he could pass any parameter supported by HV itself so this idea is not bad I think. But like you said, it's the "advanced" feature so that somewhere in virt-manager user should choose or check the advanced interface mode or something similar. I don't think some people don't knowing the HV would like to investigate this so that this should be a new entry in the menu that have to be enabled first. Some item like "Advanced mode" in "View" menu or so...

To your requested features:
1. Bridged networking - yeah, this could be good to be added there not to have to setup the bridge manually

+1 for this one, but with a normal user account in kvm group (not root). Adding to this:

2. Snapshots - like I said, you're referring to KVM so see above, Xen can save the machine to a checkpoint file while not running (ie. this shuts the domain down) or even when running (not shutting the domain down) and I think nothing else is there about that. I don't know about KVM options.
3. Additional networking options - what options do you mean? What would you like to have there?

I would like to open an already created TAP interface. I have a script running at boot time which creates the bridge and as many TAP interfaces as you want, owned by group kvm. Any user who is a member of kvm group can use these tap interfaces to have bridged networking in their virtual machines, without needing privilate escalation or running as root. Therefore:

3.1. Ability to choose a pre-defined TAP interface. (ie, if the OS provides pre-cooked tapX devices read/write by kvm group that one can assign to his VMs). A config, such as:

Example Config Proposal:

      <interface type='bridge'>
        <source bridge='br0'/>
        <target dev='your_precreated_tap_interface'/>

        <create dev='no'>
        <mac address="11:22:33:44:55:66"/>
      </interface>
  

This is more or less the same thing as bridged networking of libvirt/virt-manager, just skipping the tap device creation part and using an existing tap instead.

Well, ability to use pre-defined TAP interface could be good, that's right.

4. Bridge wireless NIC cards - would this be useful?

It would be, but I think there are technical limitations for bridging a wireless and a wireline card.

I have never tried bridging the wireless cards so I don't know about that. This was just a thought...

Best Regards,
--
Emre

Best regards,
Michal

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

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

[Daniel P. Berrange-2]

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@...
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

[Cole Robinson]

On 06/17/2009 07:02 AM, Daniel P. Berrange wrote:

> 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.
>

Just a minor point, the existing snapshot support in libvirt isn't supported
in virt-manager (yet).

Thanks,
Cole

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

[Cole Robinson]

On 06/17/2009 02:28 AM, Michal Novotny wrote:
> Well, in my opinion you have to consider that virt-manager supports both
> KVM and Xen so you can't simply give KVM only stuff there. It's like the
> ac97 card request - Xen doesn't support this card so virt-manager
> doesn't have a choice to select it at all.

This isn't very clear. Because xen doesn't support ac97 (and neither does old
QEMU), we can't _unconditionally_ add an ac97 card. That doesn't mean we can't
support it, such as giving the user an option to install ac97 via the Add
Hardware wizard if they are using qemu or kvm.

Just because virt-manager supports N platforms doesn't mean we can't support
features that only work on M < N platforms, we just need to expose them in a
hypervisor independent way (but libvirt largely sets the stage for this).

Thanks,
Cole

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

[bodhi zazen]

Thank you all for listening to my request.

I think there are 3 "basic" types of virtualization users, each with slightly different needs.

1. Testing development. VM used as a sand box.

2. Testing an iso, taking rawhide for a spin.

3. Running servers in an isolated VM for any variety of reasons.

In the first two NAT is sufficient.

With the last, however, NAT is not the easiest of options.

In terms of networking, there are 3 types.

1. (most common) virtual machines have assess to external network.

2. (not unusaual) Host only. The virtual machines can talk with host only.

3. Isolated virtual network. The VM talk to each other and to host. Some may take to external networks and some may not .

These are broad categories I know, my point is IMO it would be nice if one could have such options in virt-manager. If you want a more detailed user case I for these options I can provide one =)

How about running a DMZ on virtual machines, with a proxy server to public net and isolated web / mysql servers, in the DMZ, isolated from both LAN and public access, but accessible by host and public proxy server.

FYI wireless cards can be bridged with parprouted . I am not an expert on this mind you. Virtualbox is able to bridge wireless cards and (I do not use VBox) I believe they use parprouted.

At any rate here is an example :

http://www.linux-kvm.org/page/Simple_shell_script_to_manage_your_virtual_machine_with_bridged_networking

sorry for the long url , lol

Scroll down to the "kvm-manager.sh for wireless interface " section.

I would also like to say I am not implying you should "break" or change the way virt-manager works or the xml file structure.

I would hope one could add in some "advanced" features of KVM as suggested by "Emre Erenoglu" <erenoglu@...> .

One such feature would be snapshot ;)

Again thank you.

----- Original Message -----
From: "Cole Robinson" <crobinso@...>
To: "Fedora/Linux Management Tools" <et-mgmt-tools@...>
Sent: Wednesday, June 17, 2009 6:28:43 AM GMT -07:00 US/Canada Mountain
Subject: Re: [et-mgmt-tools] Features request

On 06/17/2009 02:28 AM, Michal Novotny wrote:
> Well, in my opinion you have to consider that virt-manager supports both
> KVM and Xen so you can't simply give KVM only stuff there. It's like the
> ac97 card request - Xen doesn't support this card so virt-manager
> doesn't have a choice to select it at all.

This isn't very clear. Because xen doesn't support ac97 (and neither does old
QEMU), we can't _unconditionally_ add an ac97 card. That doesn't mean we can't
support it, such as giving the user an option to install ac97 via the Add
Hardware wizard if they are using qemu or kvm.

Just because virt-manager supports N platforms doesn't mean we can't support
features that only work on M < N platforms, we just need to expose them in a
hypervisor independent way (but libvirt largely sets the stage for this).

Thanks,
Cole

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

[bodhi zazen]

Just in follow up to my wireless request.

I would like to follow up and bring Proxy arp to your attention.

With proxy arp you can route traffic to your LAN via your wireless card (if you wish to access a samba or nfs share for example).

This is done with a few simple commands:

tunctl

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/wlan0/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp

ip link set tap0 up
route add -host 192.168.0.20 dev tap0

You can now use the tap0 on the guest (from the command line). In fedora you need to allow the traffic as the default settings in iptables will block the traffic)

The tap0 does not appear as an option in virt-manager, so you have to start kvm from the command line.

In the guest configure a static IP with the route ip as a gateway.

I hope this information is helpful and perhaps you could consider adding the option to virt manager.

I posted a blog on how I did this on Fedora 11 here :

http://blog.bodhizazen.net/linux/bridge-wireless-cards/

(Yes I know it is not technically a bridge, but it accomplishes what I need / want, ie the guest behaves as if it is on th eLAN and I can manage internet access via my router rather then the host and I can use samba and nfs with the guest and a wireless network card on the host).

HTH, thanks

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