[libvirt] [PATCH ] (type ioem) adding qemu nic configuration option in to libvirt (XEN)
Guys I have added a new attribute with with in <interface > tag called "qemu" which can be either true or false.. Indicating if the user wants XEN to create qeum net device or not.. This will fix the problem with PV net drivers with XEN.. Check the following examples e.g 1) Interface tag with qemu attribute set to false <interface type='bridge' qemu='false'> <mac address='00:16:3e:00:a5:01'/> <source bridge='eth0'/> <target dev='vif1.0'/> </interface> qemu-dm output --------------------- /usr/lib64/xen/bin/qemu-dm -d 60 -domain-name benchmark1 -k en-gb -vnc 0.0.0.0:1 -vcpus 2 -boot c -serial pty -acpi -usb -net none -M xenfv XEND has configured the hvm guest not to have network card via qemu e.g 2) Interface tag with qemu attribute set to true with qemu supported nic model <interface type='bridge' qemu='true'> <mac address='00:16:3e:00:a5:01'/> <source bridge='eth0'/> <target dev='vif1.0'/> <model type='e1000'/> </interface> qemu-dm output --------------------- /usr/lib64/xen/bin/qemu-dm -d 61 -domain-name benchmark1 -k en-gb -vnc 0.0.0.0:1 -vcpus 2 -boot c -serial pty -acpi -usb -net nic,vlan=1,macaddr=00:16:3e:00:a5:01,model=e1000 -net tap,vlan=1,ifname=tap61.0,bridge=eth0 -M xenfv Now XEND have configured the hvm guest to have emulated nic of the model "e1000" Therefore now, via libvirt configuration I have the ability ask xen to either to configure qemu network card or not (when I have pv divers installed with in my VM ) I have attached the patch files, Let me know what you guys think. Thanks Gihan -- Gihan Munasinghe R&D Team Leader XCalibre Communications Ltd. www.flexiscale.com --- domain_conf.h.back 2008-12-04 15:31:38.000000000 +0000 +++ domain_conf.h 2008-12-04 20:28:16.000000000 +0000 @@ -127,9 +127,17 @@ VIR_DOMAIN_NET_TYPE_NETWORK, VIR_DOMAIN_NET_TYPE_BRIDGE, - VIR_DOMAIN_NET_TYPE_LAST, + VIR_DOMAIN_NET_TYPE_LAST }; +/*Holds the values that can be passed as qemu attribute in <inteface >*/ +enum virDomainNetQemuAllocateType{ + VIR_DOMAIN_NET_QEMU_ALLOC_TRUE, + VIR_DOMAIN_NET_QEMU_ALLOC_FALSE, + + VIR_DOMAIN_NET_QEMU_ALLOC_LAST + +}; /* Stores the virtual network interface configuration */ typedef struct _virDomainNetDef virDomainNetDef; @@ -156,6 +164,8 @@ } bridge; } data; char *ifname; + int qemu_allocate;/* This is set so that the users can ask xen not give vm's a network card + maily to with the (type none)/(type ieoum) tags wchi will be send to xend*/ }; enum virDomainChrSrcType { @@ -608,5 +618,5 @@ VIR_ENUM_DECL(virDomainInput) VIR_ENUM_DECL(virDomainInputBus) VIR_ENUM_DECL(virDomainGraphics) - +VIR_ENUM_DECL(virDomainNetQemuAllocate) #endif /* __DOMAIN_CONF_H */ --- domain_conf.c.back 2008-12-04 15:31:40.000000000 +0000 +++ domain_conf.c 2008-12-04 20:30:31.000000000 +0000 @@ -142,6 +142,10 @@ "usb", "pci") +VIR_ENUM_IMPL(virDomainNetQemuAllocate, VIR_DOMAIN_NET_QEMU_ALLOC_LAST, + "true", + "false") + #define virDomainReportError(conn, code, fmt...) \ virReportErrorHelper(conn, VIR_FROM_DOMAIN, code, __FILE__, \ __FUNCTION__, __LINE__, fmt) @@ -787,6 +791,7 @@ char *address = NULL; char *port = NULL; char *model = NULL; + char *qemu_alloc = NULL; if (VIR_ALLOC(def) < 0) { virDomainReportError(conn, VIR_ERR_NO_MEMORY, NULL); @@ -800,6 +805,17 @@ _("unknown interface type '%s'"), type); goto error; } + qemu_alloc = virXMLPropString(node, "qemu"); + if( qemu_alloc!=NULL){ + if ((def->qemu_allocate = virDomainNetQemuAllocateTypeFromString(qemu_alloc)) < 0) { + virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR, + _("unknown qemu alloc '%s'"), qemu_alloc); + goto error; + } + + }else{ + def->qemu_allocate = VIR_DOMAIN_NET_QEMU_ALLOC_TRUE; // by default the aloocation will be true + } } else { def->type = VIR_DOMAIN_NET_TYPE_USER; } @@ -818,6 +834,7 @@ (def->type == VIR_DOMAIN_NET_TYPE_BRIDGE) && (xmlStrEqual(cur->name, BAD_CAST "source"))) { bridge = virXMLPropString(cur, "bridge"); + } else if ((dev == NULL) && (def->type == VIR_DOMAIN_NET_TYPE_ETHERNET) && xmlStrEqual(cur->name, BAD_CAST "source")) { --- xend_internal.c.back 2008-12-04 15:31:38.000000000 +0000 +++ xend_internal.c 2008-12-04 21:05:49.000000000 +0000 @@ -1773,10 +1773,9 @@ if (VIR_ALLOC(net) < 0) goto no_memory; - if ((tmp2 && strstr(tmp2, "bridge")) || tmp) { - net->type = VIR_DOMAIN_NET_TYPE_BRIDGE; - /* XXX virtual network reverse resolve */ - + if ((tmp2 && (strstr(tmp2, "bridge") )) || tmp) { + net->type = VIR_DOMAIN_NET_TYPE_BRIDGE; + /* XXX virtual network reverse resolve */ if (tmp && !(net->data.bridge.brname = strdup(tmp))) goto no_memory; @@ -5153,10 +5152,15 @@ /* * apparently (type ioemu) breaks paravirt drivers on HVM so skip this - * from Xen 3.1.0 + * from Xen 3.1.0 This happence as XEN try to allocate a network card via qemu */ - if ((hvm) && (xendConfigVersion < 4)) - virBufferAddLit(buf, "(type ioemu)"); +// if ((hvm) && (xendConfigVersion < 4) ) + if ((hvm) && (def->qemu_allocate==VIR_DOMAIN_NET_QEMU_ALLOC_FALSE)){ /* If we have asked the qemu not to allocte a net work for hvm guest. + This way you would not have a problem with PV drivers on HVM guests*/ + virBufferAddLit(buf, "(type none)"); + }else { + virBufferAddLit(buf, "(type ioemu)"); + } if (!isAttach) virBufferAddLit(buf, ")");
On Thu, Dec 04, 2008 at 09:50:01PM +0000, Gihan Munasinghe wrote:
<interface type='bridge' qemu='false'>
This is not suitable because it is adding attributes that are specific to the Xen hypervisor.
<mac address='00:16:3e:00:a5:01'/> <source bridge='eth0'/> <target dev='vif1.0'/> </interface>
As I mentioned before this should be handled with the existing XML <model> element. ...no model element... -> Default QEMU nic + Paravirt Driver backend <model type='e1000'/> -> Only QEMU's e1000 nic <model type='rtl8139'/> -> Only QEMU's rtl8139 nic <model type='ne2k_pci'/> -> Only QEMU's ne2k nic <model type='xen'/> -> Only Paravirt driver backend This doesn't allow us to have the PV driver + an explicit choice of QEMU nics, but I don't think that's important. If you're enabling PV drivers, you don't care about specific QEMU nic types. 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 :|
Daniel P. Berrange wrote:
On Thu, Dec 04, 2008 at 09:50:01PM +0000, Gihan Munasinghe wrote:
<interface type='bridge' qemu='false'>
This is not suitable because it is adding attributes that are specific to the Xen hypervisor.
Why can not this be used with any other hypervisor. The situation that I am concerned here is I want my network to be configured but I don't want qemu not to have a emulated nic. That is a user level requirement rather than a hypervisor specific requirement.. If name qemu is the problem. We can name it to be "emulate = false" be more generic, so this way regardless of the hypervisor we are asking not to emulate a nic. and if "emulate = true" with a < model type='whatever model type wanted '> tag . we are asking the whatever hypervisor to emulate a nic with a given model.
<mac address='00:16:3e:00:a5:01'/> <source bridge='eth0'/> <target dev='vif1.0'/> </interface>
As I mentioned before this should be handled with the existing XML <model> element.
...no model element... -> Default QEMU nic + Paravirt Driver backend <model type='e1000'/> -> Only QEMU's e1000 nic <model type='rtl8139'/> -> Only QEMU's rtl8139 nic <model type='ne2k_pci'/> -> Only QEMU's ne2k nic <model type='xen'/> -> Only Paravirt driver backend
The problem with using the model tag is in xend, level (type ioem) is different from (model e1000). In any case the (model e1000) to work with in XEN you have to send (type ioem) tag asking it to emulate the nic model What we need to send not to configure a qemu -net bock is something called ( type none) not ( model none ) or (model xen) xend. So what you are suggesting is that if we see a < model type='xen' > treat it a different way so that it will send (type none) to XEND. ?
This doesn't allow us to have the PV driver + an explicit choice of QEMU nics, but I don't think that's important.
If you're enabling PV drivers, you don't care about specific QEMU nic types.
Thats the situation for now. Gihan
Daniel
-- Gihan Munasinghe R&D Team Leader XCalibre Communications Ltd. www.flexiscale.com
On Thu, Dec 04, 2008 at 10:33:28PM +0000, Gihan Munasinghe wrote:
Daniel P. Berrange wrote:
<mac address='00:16:3e:00:a5:01'/> <source bridge='eth0'/> <target dev='vif1.0'/> </interface>
As I mentioned before this should be handled with the existing XML <model> element.
...no model element... -> Default QEMU nic + Paravirt Driver backend <model type='e1000'/> -> Only QEMU's e1000 nic <model type='rtl8139'/> -> Only QEMU's rtl8139 nic <model type='ne2k_pci'/> -> Only QEMU's ne2k nic <model type='xen'/> -> Only Paravirt driver backend
The problem with using the model tag is in xend, level (type ioem) is different from (model e1000). In any case the (model e1000) to work with in XEN you have to send (type ioem) tag asking it to emulate the nic model
This isn't a problem as there is no requirement to have a 1-to-1 mapping from XML elements to Xen config elements
What we need to send not to configure a qemu -net bock is something called ( type none) not ( model none ) or (model xen) xend. So what you are suggesting is that if we see a < model type='xen' > treat it a different way so that it will send (type none) to XEND. ?
Not quite - we'd not set model for the PV only case. What XenD's logic is keyed off is the value of the (type ) element. If it is 'ioemu' then only QEMU is configured. If it is left out completely, both both QEMU and PV are enabled. If it is any other value, then PV only is configure. (model) only matters when QEMU is enabled. So I was thinking we'd have the following as the mapping ...no model element... -> No (type) or (model) element at all QEMU + PV <model type='e1000'/> -> (type ioemu) (model e1000) QEMU only <model type='rtl8139'/> -> (type ioemu) (model rtl8139) QEMU only <model type='ne2k_pci'/> -> (type ioemu) (model ne2k_pci) QEMU only <model type='netback'/> -> (type netback) no (model) PV only 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 :|
What we need to send not to configure a qemu -net bock is something called ( type none) not ( model none ) or (model xen) xend. So what you are suggesting is that if we see a < model type='xen' > treat it a different way so that it will send (type none) to XEND. ?
Not quite - we'd not set model for the PV only case. What XenD's logic is keyed off is the value of the (type ) element. If it is 'ioemu' then only QEMU is configured. If it is left out completely, both both QEMU and PV are enabled. If it is any other value, then PV only is configure. (model) only matters when QEMU is enabled. So I was thinking we'd have the following as the mapping
...no model element... -> No (type) or (model) element at all QEMU + PV <model type='e1000'/> -> (type ioemu) (model e1000) QEMU only <model type='rtl8139'/> -> (type ioemu) (model rtl8139) QEMU only <model type='ne2k_pci'/> -> (type ioemu) (model ne2k_pci) QEMU only <model type='netback'/> -> (type netback) no (model) PV only
Daniel
Are we going to put a check on available or supported model types, by adding a new ENUM virDomainNetModel in domain_config.c/.h level. Like the way we have done to other types if so the xend_internal.c level we can put the check like if(def->model==NULL){ // do nothing }else if(NULL && def->model == VIR_DOMAIN_NET_MODEL_NETBACK){ (type netback) }else{ (type ioemu) (model %s) call the emum to sting function } Other way is to make sure each driver holds a list of supported nic models with in the driver code, enum virXENDomainNetModelType. (I would personally prefer this way of checking). So each driver would only have to hold a set of nic models that it will support. or else are we just going to do a string check on xend_internal.c level for "netback" string.
From what I have seen is that if we send a model that is not supported by qemu to xend. qemu-dm configuration will fail.. but the vm will be still running. xend will see it as a running vm.
So checking for a supported "model type", is it up to the libvirt or are we going to think that user will always configure with the correct model type.
Daniel P. Berrange wrote:
On Thu, Dec 04, 2008 at 10:33:28PM +0000, Gihan Munasinghe wrote:
Daniel P. Berrange wrote:
<mac address='00:16:3e:00:a5:01'/> <source bridge='eth0'/> <target dev='vif1.0'/> </interface>
As I mentioned before this should be handled with the existing XML <model> element.
...no model element... -> Default QEMU nic + Paravirt Driver backend <model type='e1000'/> -> Only QEMU's e1000 nic <model type='rtl8139'/> -> Only QEMU's rtl8139 nic <model type='ne2k_pci'/> -> Only QEMU's ne2k nic <model type='xen'/> -> Only Paravirt driver backend
Supporting pv net drives in XEN patch. If you define the interface model type as pvxen (<model type ="pvxen">). XEN will not load emulated network card Let me know what you think of the patch
--- xend_internal.c.back 2009-02-02 10:53:31.000000000 +0000 +++ xend_internal.c 2009-02-03 10:02:54.000000000 +0000 @@ -75,6 +75,8 @@ #define XEND_CONFIG_MIN_VERS_PVFB_NEWCONF 3 #endif +#define XEN_PV_NETWORK "pvxen" + #ifndef PROXY static int @@ -5198,12 +5200,25 @@ if (def->model != NULL) virBufferVSprintf(buf, "(model '%s')", def->model); + /*Fixing up the model to support XEN pv drivers + , if the user XML is defined as <model type="pvxen" > this means that + there is a PV driver for network is alredy installed. So xen should not + emulate the network card */ + + if(hvm && (def->model!=NULL) && (strcmp(def->model,XEN_PV_NETWORK)==0) ){ + virBufferAddLit(buf, "(type none)"); + }else if(hvm){// For any other hvm guest ask XEN to emulate the card + virBufferAddLit(buf, "(type ioemu)"); + if (def->model != NULL) + virBufferVSprintf(buf, "(model '%s')", def->model); + } + /* * apparently (type ioemu) breaks paravirt drivers on HVM so skip this * from Xen 3.1.0 - */ + if (hvm && xendConfigVersion <= XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU) - virBufferAddLit(buf, "(type ioemu)"); + virBufferAddLit(buf, "(type ioemu)");*/ if (!isAttach) virBufferAddLit(buf, ")"); @@ -5566,3 +5581,4 @@ } #endif /* ! PROXY */ + Thanks -- Gihan Munasinghe R&D Team Leader XCalibre Communications Ltd. www.flexiscale.com
It's a bit hard to follow this patch. Can you indent it according to the file "HACKING" (also read the rest of this file and fix things like strcmp). Also post it as an attachment. Maybe better to start a new thread as well, since this thread is months back. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
On Tue, Feb 03, 2009 at 01:56:31PM +0000, Gihan Munasinghe wrote:
- virBufferAddLit(buf, "(type ioemu)"); + virBufferAddLit(buf, "(type ioemu)");*/
The other thing I was going to say is don't comment out code. If the code is no longer used, remove it. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
Richard W.M. Jones wrote:
On Tue, Feb 03, 2009 at 01:56:31PM +0000, Gihan Munasinghe wrote:
- virBufferAddLit(buf, "(type ioemu)"); + virBufferAddLit(buf, "(type ioemu)");*/
The other thing I was going to say is don't comment out code. If the code is no longer used, remove it.
Thanks for the feedback.. I'll do the change and post the updated patch -- Gihan Munasinghe Development Team Leader XCalibre Communications Ltd. www.flexiscale.com
participants (5)
-
Daniel P. Berrange -
Gihan Munasinghe -
Gihan Munasinghe
-
gmunasin＠xcalibre.co.uk -
Richard W.M. Jones