[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v6 10/13] libxl: set nic type to VIF by default
Ian Campbell wrote:
On Tue, 2012-06-26 at 17:58 +0100, Pasi KÃrkkÃinen wrote:
On Tue, Jun 26, 2012 at 05:20:35PM +0100, Roger Pau Monne wrote:
Ian Jackson wrote:
Roger Pau Monne writes ("[PATCH v6 10/13] libxl: set nic type to VIF by
default"):
Set the default value for nic interfaces to VIF, since it used to be
IOEMU, even for PV guests.
If your renaming of IOEMU to VIF_IOEMU is correct, does this not stop
HVM guests getting emulated network interfaces by default ?
Yes, if you want emulated interfaces with HVM guests you should use
'type=ioemu', that's how it has always been right?
With Xen 4.1 you don't have to use "type=ioemu". Emulated interfaces seem to work OK
without "type=ioemu".
(at least with xm/xend). And if you actually do add "type=ioemu" it will break
PVHVM for Linux guests..
Quote from: http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers
"NOTE! If you have "type=ioemu" specified for the "vif"-line, PVHVM
drivers WILL NOT work! Don't specify "type" parameter for the vif.
(with type=ioemu the pvhvm nic in the VM will have mac address full of
zeroes - and thus won't work!). "
mac=00:00:00:00:00 is certainly a bug, if (lib)xl behaves this way too
then we should fix it.
But surely type=ioemu is supposed to mean "only emulated"? In which case
the actual xend bug is that it created a PV VIF at all.
Currently there's no network type that means "emulated only", we have
VIF and VIF_IOEMU.
What are the options here? I think they are, with their (lib)xl
behaviour:
PV HVM
type=ioemu meaningless / an error emulated device + paravirt VIF*
type=vif paravirt VIF device*& paravirt VIF device only&
You are missing a row, the default one when user doesn't specify
anything, this currently is:
PV HVM
default nic type is set to IEOMU nic type is set to IOEMU
In the past this was not a problem, since when the guest is PV, we
didn't launch Qemu, and thus the tap device was never created and the
hotplug scripts were not launched. Now that we launch hotplug scripts
from libxl this is a problem, because when we call libxl_device_nic_add,
libxl has no idea if the domain is a PV or HVM guest, and only sees the
network type, which is set to IOEMU by default.
This is the main problem, I think it should be ok to leave the default
type as IOEMU in libxl__device_nic_setdefault and set the type manually
to VIF for PV guests in
libxl_create.c:libxl__domain_build_info_setdefault, does this sound ok?
Where * == current lib(xl) default and& == proposed default after this change.
and:
type=ioemu => LIBXL_NIC_TYPE_IOEMU to be renamed
LIBXL_NIC_TYPE_VIF_IOEMU.
type=vif => LIBXL_NIV_TYPE_VIF, no renaming proposed.
But if my table is correct then LIBXL_NIC_TYPE_VIF_IOEMU is the right
default and shouldn't be changed. Roger can you either confirm or
correct my table.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|