[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.x / Linux 3.x (dom0 and HVM domU) and NIC handling
On 02.12.2011 11:41, Pasi Kärkkäinen wrote: > On Fri, Dec 02, 2011 at 11:11:38AM +0100, Stefan Bader wrote: >> On 01.12.2011 19:09, Pasi Kärkkäinen wrote: >>> On Thu, Dec 01, 2011 at 04:09:38PM +0100, Stefan Bader wrote: >>>> Moving to public discussion... >>>> >>>> This was found with Xen hypervisor version supporting device unplugging >>>> and the >>>> domU kernel having net-/blkfront and pci platform built-in (or as module). >>>> >>>> The block device is defined as hda and the NIC type=ioemu (so theoretically >>>> guests without pv support would work, too). >>>> >>>> Since both drivers are present, the kernel tries to unplug the emulated >>>> devices >>>> and succeeds. The blkfront driver detects the xvda device available in >>>> parallel >>>> and is working ok. >>>> >>>> However the network interface does not work. There are entries present >>>> under >>>> sysfs for the xenbus but trying to bring it up fails with errors. And also >>>> there >>>> seems to be no mac address set (all zeros in sysfs). >>>> When the type=ioemu is removed in the configuration, this works. >>>> >>>> I have not much more debugging information beyond that, yet. But it sounds >>>> a bit >>>> like NICs should behave the same as block devices. So if there is an >>>> emulated >>>> device defined there will be an alternate paravirt interface for it and >>>> after >>>> unplugging the emulated ones we end up with the pv ones. >>>> Is that something that can be seen with newer Xen versions, too (I am >>>> using 4.1.1)? >>>> >>> >>> Hey, >>> >>> Have you seen?: >>> http://wiki.xen.org/xenwiki/XenLinuxPVonHVMdrivers >>> >>> Especially the following note: >>> "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!)." >>> >>> "type=ioemu" is not needed, at least with xm/xend toolstack both HVM and >>> PVHVM guests work OK without it. >>> >>> -- Pasi >>> >> Thanks Pasi, >> >> hmm, so it is documented actually and thus sort of expected. Still it is >> confusing. For one driver it does not make a difference to use the form of an >> emulated device in the config, for the other it does. The xl stack works, >> the xm >> stack does not. >> And then, ok this is probably a quite naive approach, it seemed to make >> sense to >> go through the pain of always having potentially both interfaces available >> (emulated and pv) so in theory the same guest config can accommodate a guest >> os >> supporting one or the other (or easily switch from one to the other). >> Otherwise >> I would expect an emulated device only when I have hd? in the config and a pv >> device when I write xvd?. >> > > This works for both HVM and PVHVM (also mentioned on the wiki page): > vif = [ 'mac=00:16:5e:02:07:45, bridge=xenbr0, model=e1000' ] > > So there's no need for "type=ioemu" option with xm/xend. > > You can switch between HVM and PVHVM with: > xen_platform_pci=0|1 > > -- Pasi > It seems that this works (without the model, too) for xm and xl. So even without explicitly saying type=ioemu, there is an emulated device created. And if the platform device is enabled, the emulated devices are unplugged by default. So it sounds like "type=ioemu" is not only not needed but hurts in the one case of xm. Would it make sense to completely remove it from the example configs? -Stefan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |