[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH ] (type ioem) adding qemu nic configuration option in to libvirt (XEN)



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]