/var/lib/xenstored & Xen4CentOS

Home » CentOS-Virt » /var/lib/xenstored & Xen4CentOS
CentOS-Virt 3 Comments

By default, /var/lib/xenstored is mounted tmpfs in CentOS 5 but this doesn’t appear to be true for Xen4CentOS. This can cause performance issues as mentioned in https://bugzilla.redhat.com/show_bug.cgi?idD6089

I’m not sure if this should be part of xencommons, but if not, adding a tmpfs mount should probably be documented on the quick start wiki page.

Thanks, Sarah

3 thoughts on - /var/lib/xenstored & Xen4CentOS

  • Sarah,

    Thanks for looking into this.

    Adding a tmpfs mount to xencommons, if using the C xenstored, might be a good idea — I’ll float that with upstream and see what they say.

    As an alternate, can you try using the ocaml-based oxenstored (which doesn’t use the filesystem as its atomicity mechanism)?

    To use oxenstored:
    * Install the xen-ocaml package
    * Reboot dom0
    * Verify that oxenstored is running:
    # ps ax | grep xenstore
    654 ? S 0:00 /usr/sbin/oxenstored –pid-file

    (On my to-do list is to get oxenstored into the core xen-runtime package, which would also resolve this situation, I believe.)


  • FWIW, I used the following shell snippet to create 80 VMs (which crash immediately without an initrd but still take up space in xenstore):

    for i in {1..80} ; do xl create null.cfg name=\”t$i\”
    kernel=\”/boot/vmlinuz-3.18.12-11.el7.x86_64\” memory=\”40\”
    on_crash=\”preserve\” ; done

    And then used the shell snippet from the bug report to generate load:

    while true; do xl list &> /dev/null; usleep 5000;done

    With xenstored normally the CPU load was about 30%. Mounted under tmpfs, it was slightly smaller, around 20%, but swung around wildly. With oxenstored it was about 15%.

    This is with xfs as the filesystem.

    That doesn’t seem big enough to warrant a lot of effort: if you can reproduce the 75% numbers from the bug report I’ll pursue it further, otherwise I’ll probably just leave it.


  • I’m actually more concerned about I/O wait than CPU usage. When shutting down or starting a lot of guests the wait time could be significantly increased.

    I only started to look into this because I was doing load testing and it was taking much longer to shut everything down then it seemed like it should. Running multiple versions of xl in parallel (especially xl destroy) can make many, many backups of tdb such that there’s hundreds of MB of backup copies.