|
On Fri February 17 2012, 10:22:12 AM, Ian Campbell wrote:
> On Thu, 2012-02-16 at 10:11 +0000, jim burns wrote:
> [...]
>
> > 1) After my winxp hvm domu, started with a stubdom, got some windows
> > updates yesterday, I restarted (not shutdown), and the new domain hung
> > in pause:
> [..]
>
> I tried this with win7 on xen-unstable and it worked ok. This may be a
> bug specific to 4.1.
Good to know! Thank you very much for taking the time to look at this.
> [...]
>
> > xl create /etc/xen/winxp-dm target=8 memory=32 extra=" -d 8"
> >
> > and only got a syntax error on the '-d'.
>
> I don't think this approach is advised but FWIW the error here is
> probably lack of quoting of the " against the shell. You would have
> needed
> ... extra=\" -d 8\"
Ouch! I was trying to quote the '-' in -d!
> > So my question is: is this a bug, and is it fixed in xen 4.2?
>
> The failure to restart the stub DM when rebooting a VM is a bug, AFAICT
> it is fixed in unstable and therefore will be fixed in 4.2.
>
> I've not been able to spot a specific changeset with the fix, but there
> was quite a lot to wade through.
>
> > 2) I'm having a strange problem right after I get a xen update from
> > rawhide: stubdoms stop working for a day after wards. It happened with
> > fedora xen 4.1.2-7 and -8. The next time it happens, I'll look at
> > whether something in /var/lib/xen* changed.
>
> Stop working for a day and then magically starts working? Or stops
> working for a day until the next update?
As it turns out, both, the two times it happened to me. Stubdoms stop working until the next yum update, but nothing installed the next day has any relationship to xen or a kernel. Whether or not it would have worked 1/2 hour before the yum update is not something I have had an opportunity to explore yet. Of course, a yum update is frequently accompanied by a systemd restart, which could have an effect.
Whenever I get a rawhide xen or kernel update, I usually reboot to test the update for regressions/bugs, then reboot back to the highest version kernel I have w/o debug options turned off (before the next yum update). Thus, a full reboot, twice, doesn't fix the problem. So I would think that a simple systemd restart wouldn't, either. That's why the next thing I intend to look at would be whether anything got damaged/not regenerated in /var/lib/xen*. Another possibility is that xend is still running. I usually take care not to mix xm and xl commands in one boot session. If I do mix them, I usually stop any domus, and do an 'xm mem-set 0 ...' back to the boot value in my system, and then use only one of the xm / xl commands thereafter. (It is really disconcerting to see xm list, xl list report differing dom0 memory amounts!) Anyway, stopping xend and trying stubdoms again is something else I will try.
> > 3) Specifying vncviewer=1 will automatically start a vnc viewer for
> > you
>
> [...]
>
> > 4) The 'localtime=1' option in your config is ignored by xl. This
> > works with
>
> [...]
>
> > The answer given to the two above problems at the time was essentially
> > that they had not been implemented. Have they been implemented in xen
> > 4.2 yet?
>
> Not as far as I can tell with grep. Patches would be greatly
> appreciated, these should be relatively simple issues for a newcomer to
> tackle with only basic C required I think, I'd be glad to advise etc.
>
> I'll add these as "nice to have" in the 4.2 TODO thread.
That is greatly appreciated. While I was a programmer awhile back, I have not read the xen code, and the learning curve there, and in learning how to write *acceptable* patches is more than my time constraints currently allow. I confine my time to administrative duties, and looking for bugs / regressions to report, and helping the occasional user on Xen-users with what I *have* learned.
[...]
> > Also, while device_model_args does indeed add '-localtime' to the end
> >
> > of the qemu-dm args, it's still ineffective.
>
> I'm not 100% sure of this but I don't think xm's "localtime" corresponds
> to solely passing "-localtime" to the DM (although it may also do that
> also).
>
> I think it needs to turn into a hypercall to tell the hypervisor about
> the guests time offset, e.g. a call to xc_domain_set_time_offset. The
> rtc_timeoffset option relates to this call as well.
That makes sense. Thanx.
> In a Xen system the RTC is emulated by the hypervisor not by qemu (it
> used to be done by qemu many moons ago, which might explain the
> vestigial passing of -localtime to qemu).
And I've been with xen since the 3.0 days, so features start merging in my head! Thanx for the clarity!.
> > And 2) If you have GPLPV installed in your domain, it completely takes
> > over. Booting with GPLPV enabled is no faster with stubdoms as
> > without. Booting with /nogplpv is just as slow as if you booted
> > without stubdoms. I suspect xenpci.sys is overriding what stubdoms is
> > doing.
>
> If you are using PV devices then you won't be hitting the emulated
> devices (which is what is in the stubdom) all that much after the very
> early boot stages IOW after anything which uses BIOS int13 hook e.g. the
> bootloader. If you aren't hitting the emulated devices then putting them
> in stubdom vs dom0 won't make much odds to the performance.
>
> Ian.
Makes sense. The main thing that I was disappointed in was that even booting with /nogplpv didn't result in a speed increase. xenpci.sys seems to take over completely, even in that case.
Thanx again for your time and interest. | 
