>> 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.
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list