[Libvir] PATCH: Support NIC model selection for QEMU/KVM
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
Signed-off-by: Jim Paris <jim@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
Signed-off-by: Jim Paris <jim@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
Signed-off-by: Jim Paris <jim@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
Signed-off-by: Jim Paris <jim@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
Signed-off-by: Jim Paris <jim@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
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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 -=|
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
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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 -=|
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Jim Paris