[PTLsim-devel] Problems with devices for domU

Fri Oct 12 14:37:50 EDT 2007

> > Hi,
> >   I've been playing around with the options for root-devices for a domU
> > in PTLsim/X and finally have found only the way with tap.aio usable,
> > using the ptlsim.img from the webpage.
> >
> > Ideally I'd like to have my domU's root mounted over NFS, but mounting a
> > physical partition would be nice too.
> >
> > If I use the attached xm-config file, (xm create ptlvm-smp.sda1 -c) the
> > domain will eventually time-out and just state
> >
> > # Error: Device 769 (vbd) could not be connected. Hotplug scripts not
> > working.
> >...
> >
> > I'm (still) using PTLsim's 219 revision, as I have heavily changed the
> > core models and have not yet found the time to do a merge. As a kernel I
> > use the provided 2.6.20.3-mtyrel-64bit-xen kernel sources and rebuilt
> > them myself. I have also rebuitl and reinstalled the xentools inside my
> > dom0.
>
> Are you sure you're using a matching version of the kernel 2.6.20.3, the
> Xen hypervisor and the Xen tools?
>
> It's very easy to get these mixed up, and the first problem you'll
> encounter is that disk images and networking will not work correctly.
> Specifically, the dom0 kernel and the Xen tools need to have matching
> versions (unfortunately, there's no "version number" that you can compare,
> but we try to make them match by testing them together).
>
> Here's a possible solution: first try using the Xen versions (hypervisor,
> kernel and Xen tools) provided with SuSE 10.2, since these obviously work
> together correctly. You should be able to just install the RPM packages to
> get all the required versions.
>
> If you can get your domains working under this configuration, then try
> booting everything under the PTLsim-modified Xen hypervisor (just use our
> "xen" binary in place of the SuSE-provided one), but leave all the other
> components (kernel and Xen tools) the same. The system should still boot
> since the hypervisor provides full backwards compatibility (i.e. new
> hypervisor will work with older kernels, but not vice versa). All of the
> disk and network features are provided by the dom0 kernel, not the
> hypervisor.
>
> Keep in mind that there are now two incompatible versions of the PTLsim
> hypervisor. The old version (that's compatible with rev 219) uses a
> different PTLCALL instruction format than the new version (rev 221 and
> later) we released on 9-Sep-2007. This change (which I explained in an
> earlier list post) was needed to offer better support for checkpointing and
> performance counter access.
>
> Since you're still using PTLsim r219, make sure you use the old version of
> the hypervisor (i.e. the one you're running now). We removed this from our
> web site, but I can put it back up if you don't have the source code
> anymore.
>
> I'm sorry you're having a problem with this - hopefully some day Xen will
> come up with a versioning scheme that lets different kernels work correctly
> with the Xen scripts and tools. This may happen soon now that Xen is built
> into the official 2.6.23 kernels - then they'll be forced to stop changing
> the kernel-to-tools protocols so often.
>

Thanks Matt for the heads up! I do remember from my days of Xen hacking that 
mixing the versions is quite painful. I have seen many requests for better 
compatibility of the APIs on many roadmap slides then. Let's hope that things 
will get better.

Unfortunatly, I'm pretty short on time for experiments and as the tap.aio 
solution with an image file works okay for me (thanks for providing the 
image!), I kind of have given up on this issue for _now_, it is just less 
comfortable than having direct access to network roots.

If I have more time at hands, I shall update my repo to the newest official 
version and upgrade everything in a clean fashion.

Thanks for all the patience and help, I was somehow (with actually knowing 
better ;-) )hoping for a 
yes-this-is-a-well-known-problem-tweak-this-and-you're-done solution.

Kind regards,
  Stephan
-- 
Stephan Diestelhorst, AMD Operating System Research Center
stephan.diestelhorst at amd.com, Tel.   (AMD: 8-4903)

AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, 
Deutschland
Registergericht Dresden: HRA 4896

vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, 
Delaware, USA)
Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy