[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.