11:21 p.m.
.... 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.
11:57 p.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
1:11 a.m.
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.
1:18 a.m.
On 09/25/2012 10:41 PM, William A. Mahaffey III wrote:
--
/kashyap
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
1:33 a.m.
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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
4365
days inactive
4365
days old
4 comments
3 participants
participants (3)
-
Eric Blake -
Kashyap Chamarthy -
William A. Mahaffey III