<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 06/17/2009 10:41 AM, Emre Erenoglu wrote:
<blockquote
cite="mid:fe9771a80906170141o7ac55050lff42502043813b02@mail.gmail.com"
type="cite">
<div class="gmail_quote">On Wed, Jun 17, 2009 at 8:28 AM, Michal
Novotny <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:minovotn@redhat.com">minovotn@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">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.</div>
</blockquote>
<div><br>
Then why don't we just make an "advanced" field where a user can enter
his own parameters to the qemu-kvm binary?<br>
</div>
</div>
</blockquote>
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... <br>
<blockquote
cite="mid:fe9771a80906170141o7ac55050lff42502043813b02@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">To your requested features:<br>
1. Bridged networking - yeah, this could be good to be added there not
to have to setup the bridge manually</div>
</blockquote>
<div><br>
+1 for this one, but with a normal user account in kvm group (not
root). Adding to this:<br>
<br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">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.<br>
3. Additional networking options - what options do you mean? What would
you like to have there?</div>
</blockquote>
<div><br>
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:<br>
<br>
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:<br>
<br>
Example Config Proposal:<br
style="font-family: arial,helvetica,sans-serif;">
<pre style="font-family: arial,helvetica,sans-serif;"> <interface type='bridge'>
<source bridge='br0'/>
<b> <target dev='your_precreated_tap_interface'/>
<create dev='no'>
</b> <mac address="11:22:33:44:55:66"/>
</interface>
</pre>
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.<br>
</div>
</div>
</blockquote>
Well, ability to use pre-defined TAP interface could be good, that's
right.<br>
<blockquote
cite="mid:fe9771a80906170141o7ac55050lff42502043813b02@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">4. Bridge wireless NIC cards
- would this be useful?</div>
</blockquote>
<div><br>
It would be, but I think there are technical limitations for bridging a
wireless and a wireline card.<br>
</div>
</div>
</blockquote>
I have never tried bridging the wireless cards so I don't know about
that. This was just a thought...<br>
<blockquote
cite="mid:fe9771a80906170141o7ac55050lff42502043813b02@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
</div>
Best Regards,<br>
-- <br>
Emre<br>
</blockquote>
Best regards,<br>
Michal<br>
<blockquote
cite="mid:fe9771a80906170141o7ac55050lff42502043813b02@mail.gmail.com"
type="cite">
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
et-mgmt-tools mailing list
<a class="moz-txt-link-abbreviated" href="mailto:et-mgmt-tools@redhat.com">et-mgmt-tools@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/et-mgmt-tools">https://www.redhat.com/mailman/listinfo/et-mgmt-tools</a></pre>
</blockquote>
<br>
</body>
</html>