2:44 p.m.
Hi,
Sometime between kvm-36 and kvm-46 I ran into problems with the
default QEMU network card (ne2k-pci). Switching it fixed the
problems, but libvirt doesn't support changing the NIC model.
These patches add support for:
<interface>
<nic model="rtl8139"/>
</interface>
which becomes
qemu -net nic,model=rtl8139,mac=...
By default, no model is appended to the qemu command line, as before.
Documentation update & some fixes are included too.
-jim
2:44 p.m.
New subject: [Libvir] [PATCH 1/5] qemu: Add nic model to XML format.
Signed-off-by: Jim Paris <jim(a)jtan.com>
---
src/qemu_conf.c | 21 +++++++++++++++++++++
src/qemu_conf.h | 2 ++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index f3b8f4e..c463ffb 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -644,6 +644,7 @@ static struct qemud_vm_net_def *qemudParseInterfaceXML(virConnectPtr
conn,
struct qemud_vm_net_def *net = calloc(1, sizeof(struct qemud_vm_net_def));
xmlNodePtr cur;
xmlChar *macaddr = NULL;
+ xmlChar *model = NULL;
xmlChar *type = NULL;
xmlChar *network = NULL;
xmlChar *bridge = NULL;
@@ -687,6 +688,9 @@ static struct qemud_vm_net_def *qemudParseInterfaceXML(virConnectPtr
conn,
if ((macaddr == NULL) &&
(xmlStrEqual(cur->name, BAD_CAST "mac"))) {
macaddr = xmlGetProp(cur, BAD_CAST "address");
+ } else if ((model == NULL) &&
+ (xmlStrEqual(cur->name, BAD_CAST "nic"))) {
+ model = xmlGetProp(cur, BAD_CAST "model");
} else if ((network == NULL) &&
(net->type == QEMUD_NET_NETWORK) &&
(xmlStrEqual(cur->name, BAD_CAST "source"))) {
@@ -739,6 +743,21 @@ static struct qemud_vm_net_def *qemudParseInterfaceXML(virConnectPtr
conn,
qemudRandomMAC(net);
}
+ if (model) {
+ int len;
+
+ if ((len = xmlStrlen(model)) >= (QEMUD_MAX_MODEL_LEN-1)) {
+ qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR,
+ "NIC model type '%s' is too long",
model);
+ goto error;
+ } else {
+ strncpy(net->model, (char *)model, len);
+ net->model[len] = '\0';
+ }
+ xmlFree(model);
+ model = NULL;
+ }
+
if (net->type == QEMUD_NET_NETWORK) {
int len;
@@ -872,6 +891,8 @@ static struct qemud_vm_net_def *qemudParseInterfaceXML(virConnectPtr
conn,
return net;
error:
+ if (model)
+ xmlFree(model);
if (network)
xmlFree(network);
if (address)
diff --git a/src/qemu_conf.h b/src/qemu_conf.h
index e1844da..d95871e 100644
--- a/src/qemu_conf.h
+++ b/src/qemu_conf.h
@@ -79,6 +79,7 @@ enum qemud_vm_net_type {
};
#define QEMUD_MAX_NAME_LEN 50
+#define QEMUD_MAX_MODEL_LEN 16
#define QEMUD_MAX_XML_LEN 4096
#define QEMUD_MAX_ERROR_LEN 1024
@@ -86,6 +87,7 @@ enum qemud_vm_net_type {
struct qemud_vm_net_def {
int type;
unsigned char mac[QEMUD_MAC_ADDRESS_LEN];
+ char model[QEMUD_MAX_MODEL_LEN];
union {
struct {
char ifname[BR_IFNAME_MAXLEN];
--
1.5.3.4
2:44 p.m.
New subject: [Libvir] [PATCH 2/5] qemu: specify nic model when invoking qemu
Signed-off-by: Jim Paris <jim(a)jtan.com>
---
src/qemu_conf.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/qemu_conf.c b/src/qemu_conf.c
index c463ffb..c1260ed 100644
--- a/src/qemu_conf.c
+++ b/src/qemu_conf.c
@@ -1738,7 +1738,8 @@ int qemudBuildCommandLine(virConnectPtr conn,
while (net) {
char nic[100];
- if (snprintf(nic, sizeof(nic),
"nic,macaddr=%02x:%02x:%02x:%02x:%02x:%02x,vlan=%d",
+ if (snprintf(nic, sizeof(nic),
"nic%s%s,macaddr=%02x:%02x:%02x:%02x:%02x:%02x,vlan=%d",
+ (net->model[0] ? ",model=" : ""),
net->model,
net->mac[0], net->mac[1],
net->mac[2], net->mac[3],
net->mac[4], net->mac[5],
--
1.5.3.4
2:44 p.m.
New subject: [Libvir] [PATCH 3/5] docs: Fix typo in QEMU network examples
Signed-off-by: Jim Paris <jim(a)jtan.com>
---
docs/format.html | 8 ++++----
docs/libvir.html | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/docs/format.html b/docs/format.html
index efdbcde..8a519af 100644
--- a/docs/format.html
+++ b/docs/format.html
@@ -230,7 +230,7 @@ support a variety of options:</p><ol><li>Userspace
SLIRP stack
<pre><interface type='user'/></pre>
<pre>
<interface type='user'>
- <mac address="11:22:33:44:55:66:/>
+ <mac address="11:22:33:44:55:66"/>
</interface>
</pre>
</li>
@@ -253,7 +253,7 @@ support a variety of options:</p><ol><li>Userspace
SLIRP stack
<interface type='network'>
<source network='default'/>
<target dev='vnet7'/>
- <mac address="11:22:33:44:55:66:/>
+ <mac address="11:22:33:44:55:66"/>
</interface>
</pre>
</li>
@@ -273,11 +273,11 @@ support a variety of options:</p><ol><li>Userspace
SLIRP stack
<interface type='bridge'>
<source dev='br0'/>
<target dev='vnet7'/>
- <mac address="11:22:33:44:55:66:/>
+ <mac address="11:22:33:44:55:66"/>
</interface> <interface type='bridge'>
<source dev='br0'/>
<target dev='vnet7'/>
- <mac address="11:22:33:44:55:66:/>
+ <mac address="11:22:33:44:55:66"/>
</interface></pre>
</li>
<li>Generic connection to LAN
diff --git a/docs/libvir.html b/docs/libvir.html
index 22bb168..be6f9bb 100644
--- a/docs/libvir.html
+++ b/docs/libvir.html
@@ -964,7 +964,7 @@ support a variety of options:</p>
<pre><interface type='user'/></pre>
<pre>
<interface type='user'>
- <mac address="11:22:33:44:55:66:/>
+ <mac address="11:22:33:44:55:66"/>
</interface>
</pre>
</li>
@@ -987,7 +987,7 @@ support a variety of options:</p>
<interface type='network'>
<source network='default'/>
<target dev='vnet7'/>
- <mac address="11:22:33:44:55:66:/>
+ <mac address="11:22:33:44:55:66"/>
</interface>
</pre>
</li>
@@ -1007,11 +1007,11 @@ support a variety of options:</p>
<interface type='bridge'>
<source dev='br0'/>
<target dev='vnet7'/>
- <mac address="11:22:33:44:55:66:/>
+ <mac address="11:22:33:44:55:66"/>
</interface> <interface type='bridge'>
<source dev='br0'/>
<target dev='vnet7'/>
- <mac address="11:22:33:44:55:66:/>
+ <mac address="11:22:33:44:55:66"/>
</interface></pre>
</li>
<li>Generic connection to LAN
--
1.5.3.4
2:44 p.m.
New subject: [Libvir] [PATCH 4/5] docs: Remove duplicated qemu bridge example
Signed-off-by: Jim Paris <jim(a)jtan.com>
---
docs/format.html | 6 +-----
docs/libvir.html | 6 +-----
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/docs/format.html b/docs/format.html
index 8a519af..5553d10 100644
--- a/docs/format.html
+++ b/docs/format.html
@@ -274,11 +274,7 @@ support a variety of options:</p><ol><li>Userspace
SLIRP stack
<source dev='br0'/>
<target dev='vnet7'/>
<mac address="11:22:33:44:55:66"/>
-</interface> <interface type='bridge'>
- <source dev='br0'/>
- <target dev='vnet7'/>
- <mac address="11:22:33:44:55:66"/>
- </interface></pre>
+</interface></pre>
</li>
<li>Generic connection to LAN
<p>Provides a means for the administrator to execute an arbitrary script
diff --git a/docs/libvir.html b/docs/libvir.html
index be6f9bb..7eb8a5b 100644
--- a/docs/libvir.html
+++ b/docs/libvir.html
@@ -1008,11 +1008,7 @@ support a variety of options:</p>
<source dev='br0'/>
<target dev='vnet7'/>
<mac address="11:22:33:44:55:66"/>
-</interface> <interface type='bridge'>
- <source dev='br0'/>
- <target dev='vnet7'/>
- <mac address="11:22:33:44:55:66"/>
- </interface></pre>
+</interface></pre>
</li>
<li>Generic connection to LAN
<p>Provides a means for the administrator to execute an arbitrary script
--
1.5.3.4
2:44 p.m.
New subject: [Libvir] [PATCH 5/5] docs: Document nic model options for qemu
Signed-off-by: Jim Paris <jim(a)jtan.com>
---
docs/format.html | 9 +++++++--
docs/libvir.html | 13 +++++++++++--
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/docs/format.html b/docs/format.html
index 5553d10..d73adb1 100644
--- a/docs/format.html
+++ b/docs/format.html
@@ -219,8 +219,13 @@ XML description is quite similar, here is a simple
example:</p><pre><domain <
<li>networking interface definitions definitions are somewhat different due
to a different model from Xen see below</li>
</ul><p>except those points the options should be quite similar to Xen HVM
-ones.</p><h3><a name="Net1" id="Net1">Networking
options for QEmu and KVM (added in 0.2.0)</a></h3><p>The networking
support in the QEmu and KVM case is more flexible, and
-support a variety of options:</p><ol><li>Userspace SLIRP stack
+ones.</p><h3><a name="Net1" id="Net1">Networking
options for QEmu and KVM (added in 0.2.0)</a></h3><p>The networking
support in the QEmu and KVM case is more flexible.
+Common options control how the interface is presented to the VM. For
example:</p><pre>
+<interface type='user'>
+ <span style="color: #0000E5; background-color: #FFFFFF"><mac
address="11:22:33:44:55:66"/></span>
+ <span style="color: #0000E5; background-color: #FFFFFF"><nic
model="rtl8139"/></span>
+</interface></pre><p>Supported models for <code>nic
model</code> (added in ?.?.?) depend
+on the architecture and can be found in the QEmu documentation.</p><p>On the
host side, the network interface can be connected in a number of
ways:</p><ol><li>Userspace SLIRP stack
<p>Provides a virtual LAN with NAT to the outside world. The virtual
network has DHCP & DNS services and will give the guest VM addresses
starting from <code>10.0.2.15</code>. The default router will be
diff --git a/docs/libvir.html b/docs/libvir.html
index 7eb8a5b..7113b4a 100644
--- a/docs/libvir.html
+++ b/docs/libvir.html
@@ -951,8 +951,17 @@ ones.</p>
<h3><a name="Net1">Networking options for QEmu and KVM (added in
0.2.0)</a></h3>
-<p>The networking support in the QEmu and KVM case is more flexible, and
-support a variety of options:</p>
+<p>The networking support in the QEmu and KVM case is more flexible.
+Common options control how the interface is presented to the VM. For example:</p>
+ <pre>
+<interface type='user'>
+ <span style="color: #0000E5; background-color: #FFFFFF"><mac
address="11:22:33:44:55:66"/></span>
+ <span style="color: #0000E5; background-color: #FFFFFF"><nic
model="rtl8139"/></span>
+</interface></pre>
+<p>Supported models for <code>nic model</code> (added in ?.?.?) depend
+on the architecture and can be found in the QEmu documentation.</p>
+
+<p>On the host side, the network interface can be connected in a number of
ways:</p>
<ol>
<li>Userspace SLIRP stack
<p>Provides a virtual LAN with NAT to the outside world. The virtual
--
1.5.3.4
3:33 p.m.
On Mon, Oct 22, 2007 at 03:44:38PM -0400, Jim Paris wrote:
Hi,
Sometime between kvm-36 and kvm-46 I ran into problems with the
default QEMU network card (ne2k-pci). Switching it fixed the
problems, but libvirt doesn't support changing the NIC model.
These patches add support for:
<interface>
<nic model="rtl8139"/>
</interface>
which becomes
qemu -net nic,model=rtl8139,mac=...
By default, no model is appended to the qemu command line, as before.
Documentation update & some fixes are included too.
Hum,
I would really prefer if we were able to identify the issue and
fix it transparently for the user (for example by detecting the
kvm version if possible) rather than add an option in the permanent
data file just to make stuff work. I hope this is possible, but
can't really tell.
Patch 2 & 4 are obviously documentation errors and not related so
I pushed them to CVS, thanks a lot !
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
3:35 p.m.
On Mon, Oct 22, 2007 at 04:33:40PM -0400, Daniel Veillard wrote:
On Mon, Oct 22, 2007 at 03:44:38PM -0400, Jim Paris wrote:
> Hi,
>
> Sometime between kvm-36 and kvm-46 I ran into problems with the
> default QEMU network card (ne2k-pci). Switching it fixed the
> problems, but libvirt doesn't support changing the NIC model.
> These patches add support for:
>
> <interface>
> <nic model="rtl8139"/>
> </interface>
>
> which becomes
>
> qemu -net nic,model=rtl8139,mac=...
>
> By default, no model is appended to the qemu command line, as before.
> Documentation update & some fixes are included too.
Hum,
I would really prefer if we were able to identify the issue and
fix it transparently for the user (for example by detecting the
kvm version if possible) rather than add an option in the permanent
data file just to make stuff work. I hope this is possible, but
can't really tell.
In Fedora/RHEL we simply switched Xen, QEMU and KVM to all use rtl8139 by
defualt since ne2k is crap.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
4:23 p.m.
Daniel P. Berrange wrote:
On Mon, Oct 22, 2007 at 04:33:40PM -0400, Daniel Veillard wrote:
> On Mon, Oct 22, 2007 at 03:44:38PM -0400, Jim Paris wrote:
> > Hi,
> >
> > Sometime between kvm-36 and kvm-46 I ran into problems with the
> > default QEMU network card (ne2k-pci). Switching it fixed the
> > problems, but libvirt doesn't support changing the NIC model.
> > These patches add support for:
> >
> > <interface>
> > <nic model="rtl8139"/>
> > </interface>
> >
> > which becomes
> >
> > qemu -net nic,model=rtl8139,mac=...
> >
> > By default, no model is appended to the qemu command line, as before.
> > Documentation update & some fixes are included too.
>
> Hum,
>
> I would really prefer if we were able to identify the issue and
> fix it transparently for the user (for example by detecting the
> kvm version if possible) rather than add an option in the permanent
> data file just to make stuff work. I hope this is possible, but
> can't really tell.
In Fedora/RHEL we simply switched Xen, QEMU and KVM to all use rtl8139 by
defualt since ne2k is crap.
Getting it fixed upstream might be best. We could also just have
libvirt always append "model=rtl8139", but I'd be concerned that we
could break existing VMs for some users if we swap out the network
card unexpectedly. An upstream change would have the same problem.
Regardless of what the defaults are, I don't think exposing a knob
that lets you control what NIC the guest sees is that much of a hack;
describing the guest hardware is what the config xml is mostly for.
-jim
8:34 a.m.
On Mon, Oct 22, 2007 at 05:23:47PM -0400, Jim Paris wrote:
Daniel P. Berrange wrote:
> On Mon, Oct 22, 2007 at 04:33:40PM -0400, Daniel Veillard wrote:
> > On Mon, Oct 22, 2007 at 03:44:38PM -0400, Jim Paris wrote:
> > > Hi,
> > >
> > > Sometime between kvm-36 and kvm-46 I ran into problems with the
> > > default QEMU network card (ne2k-pci). Switching it fixed the
> > > problems, but libvirt doesn't support changing the NIC model.
> > > These patches add support for:
> > >
> > > <interface>
> > > <nic model="rtl8139"/>
> > > </interface>
> > >
> > > which becomes
> > >
> > > qemu -net nic,model=rtl8139,mac=...
> > >
> > > By default, no model is appended to the qemu command line, as before.
> > > Documentation update & some fixes are included too.
> >
> > Hum,
> >
> > I would really prefer if we were able to identify the issue and
> > fix it transparently for the user (for example by detecting the
> > kvm version if possible) rather than add an option in the permanent
> > data file just to make stuff work. I hope this is possible, but
> > can't really tell.
>
> In Fedora/RHEL we simply switched Xen, QEMU and KVM to all use rtl8139 by
> defualt since ne2k is crap.
Getting it fixed upstream might be best. We could also just have
libvirt always append "model=rtl8139", but I'd be concerned that we
could break existing VMs for some users if we swap out the network
card unexpectedly. An upstream change would have the same problem.
Regardless of what the defaults are, I don't think exposing a knob
that lets you control what NIC the guest sees is that much of a hack;
describing the guest hardware is what the config xml is mostly for.
Agreed. The specifics of the hardware configuration emulated for the
domain have their place in the XML file. But I'm not sure what other
compatibility issues may arise if we applied such a patch.
Also I hate seeing a patch rot in the list archive without proper process
but I don't feel like I understand all the issues at stake here to really
try to apply it myself ...
What would we beak by applying this patch, and can this be fixed ?
Daniel, wondering ...
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
10:05 a.m.
On Wed, Oct 31, 2007 at 09:34:33AM -0400, Daniel Veillard wrote:
On Mon, Oct 22, 2007 at 05:23:47PM -0400, Jim Paris wrote:
> Daniel P. Berrange wrote:
> > On Mon, Oct 22, 2007 at 04:33:40PM -0400, Daniel Veillard wrote:
> > > On Mon, Oct 22, 2007 at 03:44:38PM -0400, Jim Paris wrote:
> > > > Hi,
> > > >
> > > > Sometime between kvm-36 and kvm-46 I ran into problems with the
> > > > default QEMU network card (ne2k-pci). Switching it fixed the
> > > > problems, but libvirt doesn't support changing the NIC model.
> > > > These patches add support for:
> > > >
> > > > <interface>
> > > > <nic model="rtl8139"/>
> > > > </interface>
> > > >
> > > > which becomes
> > > >
> > > > qemu -net nic,model=rtl8139,mac=...
> > > >
> > > > By default, no model is appended to the qemu command line, as
before.
> > > > Documentation update & some fixes are included too.
> > >
> > > Hum,
> > >
> > > I would really prefer if we were able to identify the issue and
> > > fix it transparently for the user (for example by detecting the
> > > kvm version if possible) rather than add an option in the permanent
> > > data file just to make stuff work. I hope this is possible, but
> > > can't really tell.
> >
> > In Fedora/RHEL we simply switched Xen, QEMU and KVM to all use rtl8139 by
> > defualt since ne2k is crap.
>
> Getting it fixed upstream might be best. We could also just have
> libvirt always append "model=rtl8139", but I'd be concerned that we
> could break existing VMs for some users if we swap out the network
> card unexpectedly. An upstream change would have the same problem.
>
> Regardless of what the defaults are, I don't think exposing a knob
> that lets you control what NIC the guest sees is that much of a hack;
> describing the guest hardware is what the config xml is mostly for.
Agreed. The specifics of the hardware configuration emulated for the
domain have their place in the XML file. But I'm not sure what other
compatibility issues may arise if we applied such a patch.
Also I hate seeing a patch rot in the list archive without proper process
but I don't feel like I understand all the issues at stake here to really
try to apply it myself ...
Having thought about it, I think its reasonable to aply some variant of
this patch. Guest a question of how we want to present it as XML. Just to
present some variants...
<interface type="bridge">
<nic model="rtl8139"/>
<source bridge="xenbr0"/>
<target dev="vif1.0"/>
</interface>
<interface type="bridge" model="rtl8139">
<source bridge="xenbr0"/>
<target dev="vif1.0"/>
</interface>
<interface type="bridge">
<model>rtl8139</model>
<source bridge="xenbr0"/>
<target dev="vif1.0"/>
</interface>
<interface type="bridge">
<source bridge="xenbr0"/>
<target dev="vif1.0" model="rtl8139"/>
</interface>
I guess I'd lean towards the first variant, which was Jim's original
suggestion.
Of course for any of this to solve Jim's problem, we need virt-install
and / or virt-manager to explicitly ask for the RTL8139 nic when
creating new guests, otherwise you're still at the mercy of the underlying
default NIC choice in QEMU/KVM/XEn which may or may not be RTL8139.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
10:21 a.m.
On Wed, Oct 31, 2007 at 03:05:07PM +0000, Daniel P. Berrange wrote:
On Wed, Oct 31, 2007 at 09:34:33AM -0400, Daniel Veillard wrote:
> > Getting it fixed upstream might be best. We could also just have
> > libvirt always append "model=rtl8139", but I'd be concerned that
we
> > could break existing VMs for some users if we swap out the network
> > card unexpectedly. An upstream change would have the same problem.
> >
> > Regardless of what the defaults are, I don't think exposing a knob
> > that lets you control what NIC the guest sees is that much of a hack;
> > describing the guest hardware is what the config xml is mostly for.
>
> Agreed. The specifics of the hardware configuration emulated for the
> domain have their place in the XML file. But I'm not sure what other
> compatibility issues may arise if we applied such a patch.
> Also I hate seeing a patch rot in the list archive without proper process
> but I don't feel like I understand all the issues at stake here to really
> try to apply it myself ...
Having thought about it, I think its reasonable to aply some variant of
this patch. Guest a question of how we want to present it as XML. Just to
present some variants...
<interface type="bridge">
<nic model="rtl8139"/>
<source bridge="xenbr0"/>
<target dev="vif1.0"/>
</interface>
[...]
I guess I'd lean towards the first variant, which was Jim's
original
suggestion.
yes, I prefer that one too
Of course for any of this to solve Jim's problem, we need
virt-install
and / or virt-manager to explicitly ask for the RTL8139 nic when
creating new guests, otherwise you're still at the mercy of the underlying
default NIC choice in QEMU/KVM/XEn which may or may not be RTL8139.
Well at least <nic .../> can be added after creation to guarantee the
profile won't change if the default gets eventually changed.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6045
days inactive
6054
days old
11 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Jim Paris