WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Where does xen chache domUs grub.conf ?


Thanks Al, that's exactly the explanation I waited for.

Alain.

xen-users-bounces@xxxxxxxxxxxxxxxxxxx a écrit sur 29/01/2008 03:29:10 :

> On Dec 11, 2007 8:08 AM, John Madden <jmadden@xxxxxxxxxxx> wrote:
> > > By "reboot", I meant "shutdown/restart". Among others things, I tried
> > > to run pygrub on the dom0 on the LV that support the domU's virtual
> > > disk, while the domU is off. Without seeing any change.
> > > I also verified the grub.conf to be effectively updated by mounting
> > > the domU boot partition on the dom0, while the domU is off. The
> > > grub.conf was actually changed. That's why I suppose something to be
> > > cached somewhere on the dom0.
> >
> > dom0 can/will certainly cache the contents of the disk you're sharing to
> > the domU: I had another case where "grub wasn't getting installed inside
> > domU" when it certainly was; less -f /dev/disk from dom0 didn't show the
> > grub sectors on the disk when they were definitely there, a domU
> > shutdown "cleared the cache."  So again, my experience has been that
> > shutting it down completely fixed the problem, but perhaps it doesn't
> > for you.
>
> A domU shutdown will not necessarily clear the cache that is causing
> the pygrub problem.   In fact, the problem has nothing to do with Xen
> or pygrub at all.   It's the linux kernel that's caching the blocks in
> RAM and not noticing that they've changed on the disk.     I ran into
> this when editing the grub configuration by mounting a kpartx device
> then trying to boot the VM off the normal LVM device.    The kernel
> had no way of knowing that the pages containing grub.conf were dirty,
> so it just returned what it had cached in RAM.    I'll let a kernel
> hacker can explain this more thoroughly.
>
> Either of the following commands should clear the cache and let pygrub
> get the right information:
>
> echo 1 > /proc/sys/vm/drop_caches
> blockdev --flushbufs <device>
>
> See also:
> http://linux-mm.org/Drop_Caches
> blockdev(8)
> linux-2.6.xx/Documentation/filesystems/proc.txt (from the linux kernel source)
>
> -Al Tobey
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
<Prev in Thread] Current Thread [Next in Thread>