XenParavirtOps wiki page updates

XenParavirtOps wiki page updates

[Todd Deshane]

I've updated the wiki to reflect some more of the steps and
workarounds that are currently needed.

Please add your comments/updates/corrections:

http://wiki.xensource.com/xenwiki/XenParavirtOps

Cheers,
Todd

-- 
Todd Deshane
http://todddeshane.net
http://runningxen.com

Re: XenParavirtOps wiki page updates

[Ferenc Wagner]

"Todd Deshane" <deshantm@gmail.com> writes:

> I've updated the wiki to reflect some more of the steps and
> workarounds that are currently needed.
>
> Please add your comments/updates/corrections:
>
> http://wiki.xensource.com/xenwiki/XenParavirtOps

Thanks for collecting this very useful bunch of information!
Here is what I still miss:

 * Features in 2.6.26:
     Balloon (contraction only)

   It isn't clear whether this contraction is reversible or not.

 * If the domain crashes very early, before any output appears on the
   console, then booting with: should provide some useful information.

   Booting with what?

 * How to achieve time sync between the dom0 and the domUs?  Lots of
   people seem to have problem with domU clock drift, me included.
   Ntp doesn't work in domU, and apparently no clocksource guarantees
   such synchronization.

 * I couldn't find it documented anywhere that SysRq is available via
   Ctrl+O on the domU and more importantly on the dom0 serial console.

 * The idle count doubling I still experience happens with pvops
   guests only (http://lkml.org/lkml/2008/9/18/276).

Otherwise, Debian's pvops guest kernel works very good for me, already
in production.
-- 
Cheers,
Feri.

Re: Re: XenParavirtOps wiki page updates

[Ian Campbell]

On Mon, 2008-12-15 at 12:55 +0100, Ferenc Wagner wrote:
> "Todd Deshane" <deshantm@gmail.com> writes:
> 
> > I've updated the wiki to reflect some more of the steps and
> > workarounds that are currently needed.
> >
> > Please add your comments/updates/corrections:
> >
> > http://wiki.xensource.com/xenwiki/XenParavirtOps
> 
> Thanks for collecting this very useful bunch of information!
> Here is what I still miss:
> 
>  * Features in 2.6.26:
>      Balloon (contraction only)
> 
>    It isn't clear whether this contraction is reversible or not.

I believe you can balloon back up to the amount you had at boot so yes
it is reversible.

>  * If the domain crashes very early, before any output appears on the
>    console, then booting with: should provide some useful information.
> 
>    Booting with what?

Probably "earlyprintk=xen" ??

>  * I couldn't find it documented anywhere that SysRq is available via
>    Ctrl+O on the domU and more importantly on the dom0 serial console.

That's not new to the pvops kernel but it's probably worth mentioning
somewhere.

I can't answer the rest I'm afraid.

Ian.

Re: Re: XenParavirtOps wiki page updates

[William Dauchy]

On Mon, Dec 15, 2008 at 1:01 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>  * Features in 2.6.26:
>>      Balloon (contraction only)
>>
>>    It isn't clear whether this contraction is reversible or not.
>
> I believe you can balloon back up to the amount you had at boot so yes
> it is reversible.

Yes I can confirm that you can grow and shrink the amount of memory of
your domU relative to the amount of memory at boot (memory parameter
and not the maxmem parameter which is not yet used).
tested on a 2.6.27.9
-- 
William

Re: Re: XenParavirtOps wiki page updates

[Jeremy Fitzhardinge]

Ferenc Wagner wrote:
> Thanks for collecting this very useful bunch of information!
> Here is what I still miss:
>
>  * Features in 2.6.26:
>      Balloon (contraction only)
>
>    It isn't clear whether this contraction is reversible or not.
>   

It is, but only up to the original size.

>  * If the domain crashes very early, before any output appears on the
>    console, then booting with: should provide some useful information.
>
>    Booting with what?
>   

earlyprintk=xen

>  * How to achieve time sync between the dom0 and the domUs?  Lots of
>    people seem to have problem with domU clock drift, me included.
>    Ntp doesn't work in domU, and apparently no clocksource guarantees
>    such synchronization.
>   

Why doesn't ntp work?  As far as I know it should.

The 2.6.18-xen kernels have a mechanism to try and sync the domains to 
the hypervisor's time, but it doesn't fit well into the current kernel's 
timekeeping.  I think either ntp or a lightweight daemon should be able 
to do this from usermode.  (I was thinking of adding some /sys files to 
publish the hypervisor's current time, which a daemon could use to warp 
the domain's time to match.)

>  * I couldn't find it documented anywhere that SysRq is available via
>    Ctrl+O on the domU and more importantly on the dom0 serial console.
>
>  * The idle count doubling I still experience happens with pvops
>    guests only (http://lkml.org/lkml/2008/9/18/276).
>   

That is pretty strange.

> Otherwise, Debian's pvops guest kernel works very good for me, already
> in production.
>   

Good to hear.  32 or 64 bit?

    J

Re: Re: XenParavirtOps wiki page updates

[Ferenc Wagner]

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Ferenc Wagner wrote:
>
>>  * Features in 2.6.26:
>>      Balloon (contraction only)
>>
>>    It isn't clear whether this contraction is reversible or not.
>
> It is, but only up to the original size.
>
>>  * If the domain crashes very early, before any output appears on the
>>    console, then booting with: should provide some useful information.
>>
>>    Booting with what?
>
> earlyprintk=xen

Thanks both of you for the clarification.  I pretty much expected these
answers, but wasn't entirely sure on one hand, and wanted to make sure
that this information makes it into the Wiki (where Todd accidentally
the point :)

Speaking of debugging, the dom0 serial console is highly unreliable,
it often loses characters, making the boot (and oops) messages
unreadable.  Is this just me, or is it a known deficiency?  If I boot
the kernel on bare hardware, hardware flow control keeps the serial
output intact, but the hypervisor doesn't seem to play nicely.

>>  * How to achieve time sync between the dom0 and the domUs?  Lots of
>>    people seem to have problem with domU clock drift, me included.
>>    Ntp doesn't work in domU, and apparently no clocksource guarantees
>>    such synchronization.
>
> Why doesn't ntp work?  As far as I know it should.
>
> The 2.6.18-xen kernels have a mechanism to try and sync the domains to
> the hypervisor's time, but it doesn't fit well into the current
> kernel's timekeeping.  I think either ntp or a lightweight daemon
> should be able to do this from usermode.  (I was thinking of adding
> some /sys files to publish the hypervisor's current time, which a
> daemon could use to warp the domain's time to match.)

Hmm, my last data points are from the summer, but since people keep
constantly asking on the users' list how to do this, I assumed things
didn't change.  Back then ntpd was unable to change the domU clock, it
was constantly drifting away from the current time.  Also, when the
procfs settings (like independent_wallclock) disappeared I got the
impression that the system times are now unconditionally synced.
Probably I'm just confused and all is well now...  I'll set up and
test this again.  Thanks for the hint!

>>  * The idle count doubling I still experience happens with pvops
>>    guests only (http://lkml.org/lkml/2008/9/18/276).
>
> That is pretty strange.

Yes.  Fortunately, it doesn't seem to really hurt anything, only
uglifyes our CPU graphs.

>> Otherwise, Debian's pvops guest kernel works very good for me, already
>> in production.
>
> Good to hear.  32 or 64 bit?

Right now everything is 32 bit here, but a 64 bit host is already
powered up in the basement, so sooner or later we'll test that as well.
-- 
Regards,
Feri.

Re: Re: XenParavirtOps wiki page updates

[Jeremy Fitzhardinge]

Ferenc Wagner wrote:
> Hmm, my last data points are from the summer, but since people keep
> constantly asking on the users' list how to do this, I assumed things
> didn't change.  Back then ntpd was unable to change the domU clock, it
> was constantly drifting away from the current time.

Ah.  I've never tested it, but I've never got a bug report about it 
either.   The Xen clocksource's rate should be tuneable down to ~1ppm, 
which should be fine for ntp.

>   Also, when the
> procfs settings (like independent_wallclock) disappeared I got the
> impression that the system times are now unconditionally synced.
>   

No, the opposite - its never synced, except at domain boot.

> Probably I'm just confused and all is well now...  I'll set up and
> test this again.  Thanks for the hint!
>   

Please keep me informed.  RH has been shipping pvops kernels for a while 
now, and their stock install starts ntp.  I would have assumed that I'd 
have heard about any time sync problems by now...

    J

Re: XenParavirtOps wiki page updates

[Ferenc Wagner]

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Ferenc Wagner wrote:
>
>> Also, when the procfs settings (like independent_wallclock)
>> disappeared I got the impression that the system times are now
>> unconditionally synced.
>
> No, the opposite - its never synced, except at domain boot.

Heh, I probably had a look after boot, noticed that it was synced, and
drew the wrong conclusion.  And never revisited it.

>> Probably I'm just confused and all is well now...  I'll set up and
>> test this again.  Thanks for the hint!
>
> Please keep me informed.  RH has been shipping pvops kernels for a
> while now, and their stock install starts ntp.  I would have assumed
> that I'd have heard about any time sync problems by now...

Yes, things seem to be fine indeed.  I reinstalled ntp on several
domUs, and they have been keeping the time synced for a couple of
days now.  Thanks again for clearing it up, this problem is history.
-- 
Regards,
Feri.