[libvirt-users] minor swap issue ....
.... I have a CentOS 5.n VM running on a Fedora 14 server/host, installed using virt-manager, pretty plain vanilla. I use it to compile binaries to run under RHEL/CentOS 5.n OS. I occasionally notice that when the VM gets paged out by the server, it takes several minutes to get it back in :-/ (see below). On the host, logged in to a shell through a terminal window, this A.M.: [wam@Q6600, test, 10:09:08am] 3384 % /sbin/swapon -s ; free -m ; uname -a ; /sbin/hwclock -r ; date Filename Type Size Used Priority /dev/md2 partition 16773116 1967524 -1 total used free shared buffers cached Mem: 7993 7932 61 0 11 7176 -/+ buffers/cache: 744 7249 Swap: 16379 1921 14458 Linux Q6600 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Tue Sep 25 10:09:11 2012 -0.890900 seconds Tue Sep 25 10:09:11 CDT 2012 [wam@Q6600, test, 10:09:11am] 3385 % /sbin/swapon -s ; free -m ; uname -a ; /sbin/hwclock -r ; date Filename Type Size Used Priority /dev/md2 partition 16773116 1415136 -1 total used free shared buffers cached Mem: 7993 7939 54 0 12 6358 -/+ buffers/cache: 1568 6425 Swap: 16379 1381 14998 Linux Q6600 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Tue Sep 25 10:14:09 2012 -0.281487 seconds Tue Sep 25 10:14:09 CDT 2012 [wam@Q6600, test, 10:14:09am] 3385 % on the VM, logged in through a different terminal window: [wam@centos-5, CFD, 10:09:14am] 6507 % [wam@centos-5, CFD, 10:09:14am] 6507 % ( cd ../Utils/ ; make extra ) ; cd . make[1]: Entering directory `/home/wam/dev/CFD/Utils' make[2]: Entering directory `/home/wam/dev/CFD/Utils' /home/wam/dev/CFD/Utils/../lib/R4/SSE2/libutils.a up to date. make[2]: Leaving directory `/home/wam/dev/CFD/Utils' make[2]: Entering directory `/home/wam/dev/CFD/Utils' /home/wam/dev/CFD/Utils/../lib/R8/SSE2/libutils.a up to date. make[2]: Leaving directory `/home/wam/dev/CFD/Utils' make[1]: Leaving directory `/home/wam/dev/CFD/Utils' cd /net/cube/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/utils; icc -c -DNDEBUG -DUNDER_SCORE_SYS -DLOSE_GAMMAL -gcc-version=340 -gcc-name=gcc34 -fabi-version=2 -I /net/cube/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/include -wd138,167,186,266,279,880,1418,1419,2330,2331 -O3 -ip -opt-prefetch -parallel -opt-multi-version-aggressive -xSSE2 -DP64_BIT test.cpp cd /net/cube/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/utils; icc -o /home/wam/bin/checkout -parallel -mkl=parallel -Wl,-s test.o -L /home/wam/dev/CFD/Utils/../lib/R4/SSE2 -Wl,--start-group -lutils -lMemIO -Wl,--end-group && \rm -f test.o Done with extra. [wam@centos-5, CFD, 10:12:36am] 6508 % i.e. it took 3+ min. to get back to the prompt for this command (usually about 5 sec.) .... This isn't a show-stopped by any means, but it is irritating. From the timestamps & data from the host & guest, apparently all of that was used up swapping the guest back in. Is there any way to either prioritize the VM to not get swapped out, or preferentially swapped back in :-) ? TIA for any pointers .... -- William A. Mahaffey III ---------------------------------------------------------------------- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr.
On 09/25/2012 09:21 AM, William A. Mahaffey III wrote:
.... I have a CentOS 5.n VM running on a Fedora 14 server/host,
You do realize that Fedora 14 is no longer supported upstream, right? The Fedora folks won't support anything older than Fedora 16 at the moment.
i.e. it took 3+ min. to get back to the prompt for this command (usually about 5 sec.) .... This isn't a show-stopped by any means, but it is irritating. From the timestamps & data from the host & guest, apparently all of that was used up swapping the guest back in. Is there any way to either prioritize the VM to not get swapped out, or preferentially swapped back in :-) ? TIA for any pointers ....
I have no idea if this problem exists using modern kernels, or even if you can use recent cgroup scheduling tunables (exposed via domain XML here: http://libvirt.org/formatdomain.html#elementsCPUTuning) to resolve your problem. But you are unlikely to get much assistance unless you can reproduce the tests using more up-to-date software. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 09/25/12 10:57, Eric Blake wrote:
On 09/25/2012 09:21 AM, William A. Mahaffey III wrote:
.... I have a CentOS 5.n VM running on a Fedora 14 server/host,
You do realize that Fedora 14 is no longer supported upstream, right? The Fedora folks won't support anything older than Fedora 16 at the moment.
Yes, thanks. I am planning to upgrade this server to CentOS 6.n when I get a chance, but right now, it is serving many purposes, including across-the-LAN backups, singly since another server crashed a HDD a while back. I'll get around to it eventually ....
i.e. it took 3+ min. to get back to the prompt for this command (usually about 5 sec.) .... This isn't a show-stopped by any means, but it is irritating. From the timestamps& data from the host& guest, apparently all of that was used up swapping the guest back in. Is there any way to either prioritize the VM to not get swapped out, or preferentially swapped back in :-) ? TIA for any pointers .... I have no idea if this problem exists using modern kernels, or even if you can use recent cgroup scheduling tunables (exposed via domain XML here: http://libvirt.org/formatdomain.html#elementsCPUTuning) to resolve your problem. But you are unlikely to get much assistance unless you can reproduce the tests using more up-to-date software.
Fedora 12-14 are inputs/basis for RHEL/CentOS 6.n, so I am not clear on why they are not 'modern' or 'up-to-date' .... -- William A. Mahaffey III ---------------------------------------------------------------------- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr.
On 09/25/2012 10:41 PM, William A. Mahaffey III wrote:
On 09/25/12 10:57, Eric Blake wrote:
On 09/25/2012 09:21 AM, William A. Mahaffey III wrote:
.... I have a CentOS 5.n VM running on a Fedora 14 server/host,
You do realize that Fedora 14 is no longer supported upstream, right? The Fedora folks won't support anything older than Fedora 16 at the moment.
Yes, thanks. I am planning to upgrade this server to CentOS 6.n when I get a chance, but right now, it is serving many purposes, including across-the-LAN backups, singly since another server crashed a HDD a while back. I'll get around to it eventually ....
i.e. it took 3+ min. to get back to the prompt for this command (usually about 5 sec.) .... This isn't a show-stopped by any means, but it is irritating. From the timestamps& data from the host& guest, apparently all of that was used up swapping the guest back in. Is there any way to either prioritize the VM to not get swapped out, or preferentially swapped back in :-) ? TIA for any pointers .... I have no idea if this problem exists using modern kernels, or even if you can use recent cgroup scheduling tunables (exposed via domain XML here: http://libvirt.org/formatdomain.html#elementsCPUTuning) to resolve your problem. But you are unlikely to get much assistance unless you can reproduce the tests using more up-to-date software.
Fedora 12-14 are inputs/basis for RHEL/CentOS 6.n, so I am not clear on why they are not 'modern' or 'up-to-date' ....
Fedora release cycle and maintenance is independent of RHEL. In short: There's a new Fedora release every 6 months. And each release is maintained/supported for 13 months. (Also note: Even Fedora-16 will go End-of-Life once Fedora-18 releases, which is just around the corder) You can read about Fedora release life-cycle here (specifically 'Maintenance Schedule') - http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
-- /kashyap
On 09/25/2012 11:11 AM, William A. Mahaffey III wrote:
On 09/25/12 10:57, Eric Blake wrote:
On 09/25/2012 09:21 AM, William A. Mahaffey III wrote:
.... I have a CentOS 5.n VM running on a Fedora 14 server/host,
You do realize that Fedora 14 is no longer supported upstream, right? The Fedora folks won't support anything older than Fedora 16 at the moment.
Yes, thanks. I am planning to upgrade this server to CentOS 6.n when I get a chance, but right now, it is serving many purposes, including across-the-LAN backups, singly since another server crashed a HDD a while back. I'll get around to it eventually ....
I hope you also realize that all versions of CentOS are more or less unsupported - you are getting what you paid for :)
Fedora 12-14 are inputs/basis for RHEL/CentOS 6.n, so I am not clear on why they are not 'modern' or 'up-to-date' ....
There's a crucial difference between Fedora 14 and RHEL 6 - critical bug fixes are still being backported to RHEL 6 by Red Hat folks, as driven by the development dollars of paid support, while Fedora 14 is frozen in time with no more patches being backported. If you want long term support, you need to use a release that promises long term support, like RHEL, and not one that promises to abandon that release in 13 months, like Fedora. Likewise, there's a difference between RHEL and CentOS - with the former, you have paid for a support contract, and therefore Red Hat is obligated to help you for as long as they maintain that release (which is for quite a few years), but CentOS is just the software bits with no support, so you are on your own. As for 'modern' or 'up-to-date', this list tends to focus on issues that are reproducible in the latest libvirt.git or current libvirt release (now 0.10.2); anything older is deemed a problem relevant to your distributor, for them to determine whether there is a newer upstream patch to backport to their stable release, or to even drive some upstream development to fix the issue. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (3)
-
Eric Blake -
Kashyap Chamarthy -
William A. Mahaffey III