On Fri, Oct 05, 2007 at 01:38:40AM +0100, Daniel P. Berrange wrote:
> On Fri, Oct 05, 2007 at 01:21:24AM +0100, John Levon wrote:
> > On Thu, Oct 04, 2007 at 08:40:16AM -0700, Xen patchbot-3.1-testing wrote:
> >
> > > xend: fix server/netif.py so that it respects type=None.
> > > Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>
> > > xen-unstable changeset: 15972:3a799196ff69d3a3d5e4a891c13434aa61ce60a9
> > > xen-unstable date: Thu Sep 27 17:44:03 2007 +0100
> > >
> > > - if not typ:
> > > - typ = xoptions.netback_type
> > > -
> >
> > Grumble, this makes xoptions.netback_type now clearly unused. I'm not
> > sure whether this breaks us yet, but certainly there's either cleanup
> > needed or it needs fixing.
>
> It shouldn't break anything unless it was already broken.
>
> Basically with type=None, then the in-memory VM would be booted with type
> of None, but at the same time the VM config would be written out to disk
> with type of 'netfront'. You could stop & start the HVM guest many times
> and XenD would always use a type of None when configuring qemu/netback.
> The moment you restarted XenD (or rebooted the machine), then it would read
> the config in from disk & now see type=netfront. So your config which had
> been working fine, suddenly changes when XenD is restarted & your qemu
> NICs disappear. So if this breaks anything for Solaris, then it must have
> been broken all along, because this only changes the config written to disk,
> not the in-memory one XenD is actuall using to start off with.
Actually if your Dom0/DomU drivers are working differently to the Linux ones
it could conceivably cause an issue. To explain what goes on in XenD when
starting a VM:
1 The netif.getDeviceDetails() method is called to get the dict for
front and backend devices. If type == 'ioemu' then, frontend dict is an
empty stub (ie no handle/mac fields present).
2 DevController.createDevice() writes the front & back dicts into xenstore
- frontend VIF info is written into /local/[DOMID]/device/vif/[DEVID]
- backend VIF info is written info /local/0/backends/device/vif/[DEVID]
3 netback sees the info in /local/0/backends/device/vif/[DEVID] and sets up
the backend devices.
4 if the frontend dict was a stub (ie no handle/mac fields present) then it
doesn't do anything, otherwise it connects to backend.
5 in image.py if type is None or 'ioemu' then qemu is given a -nic arg to
add an rtl8139 nic.
6 VM config is saved, by calling DevController.configurations(), which
calls configuration() on netif, which reads info out of xenstore in the
backend/frontend paths.
So, when in Step 1, the getDeviceDetails() was converting a type of 'None'
into 'netfront', when we get to step 6 it reads the type of 'netfront' out of
xenstore and writes it to disk. So next time XenD restarts, the type is fixed
to be 'netfront', and not None. This means that in step '5', qemu nevers sets
up a -nic arg.
So the one place where Solaris could in theory find trouble is if the kernel
modules for back/front actually look at the 'type' field in xenstore. In the
Linux impl, neither the back/front drivers ever look at the 'type' field - it
is only ever interpreted by XenD.
> > What does type=None do?
>
> The behaviour is
>
> - type == netfront -> setup netback only
> - type == ioemu -> setup qemu-dm only
> - type is None -> setup netback & qemu-dm
>
> The latter is the preferred behavour because it means the same VM config works
> whether the guest is using the RTL8139 emulated NIC, or PV drivers.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home