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.