[ANNOUNCE] libguestfs 1.16 released - tools for managing virtual machines and disk images
by Richard W.M. Jones
libguestfs is a library and a set of tools for reading, writing,
managing, inspecting, rescuing, resizing and aligning disk images, and
offline and live virtual machines.
I'm pleased to announce the release of libguestfs 1.16, the next
stable release of libguestfs. See the release notes below for the
full list of changes.
You can get source and binaries from the website:
http://libguestfs.org/
Source: http://libguestfs.org/download/1.14-stable/
Fedora: http://koji.fedoraproject.org/koji/packageinfo?packageID=8391
Debian/Ubuntu: (packages available soon)
Release notes for libguestfs 1.16.0
-----------------------------------
These release notes only cover the differences from the previous
stable/dev branch split (1.14.0). For detailed changelogs, please see
the git repository, or the ChangeLog file distributed in the tarball.
New features
libguestfs:
- allow XFS filesystems to be created over an existing filesystem
(Wanlong Gao)
- the (unspecified) default alignment for part-disk has been
changed to 64K for better support of high-end network-attached
storage
- new guestfs-testing(1) man page
- list-filesystems returns MD devices containing filesystems
(Matthew Booth)
- support for GCC >= 4.7 (Jim Meyering)
- check user does not add the same drive twice (Wanlong Gao).
language bindings:
- Experimental GObject bindings, with support for GObject
Introspection. You can now use libguestfs from Javascript.
Please note these are not stable and final in this release.
(Matthew Booth).
- support for Ruby >= 1.9
- Ruby bindings can be disabled individually (Hilko Bengen)
- support for Python 2.6, 3.x (Richard Jones, Hilko Bengen)
- support for PHP >= 5.4
- new %guestfs_introspection hash is available in Perl bindings so
you can query which optional arguments are available
inspection:
- guests with MD devices can be inspected (Matthew Booth)
- support for GNU/Hurd guests
guestfish:
- libguestfs events (such as progress bar events and log messages) can
be trapped and processed by user-defined shell scripts.
- MD devices are tab-completed (Matthew Booth)
virt tools:
- New tool virt-format for erasing and making blank disks
- virt-sparsify new --compress and -o options to allow for compressed
and different format output
- virt-sparsify can now detect and sparsify .vdi files
- virt-sysprep no longer requires xmlstarlet; a new virt-inspector --xpath
option has been added to replace this functionality
- virt-rescue has a new --suggest option which suggests mount commands
for the guest
- virt-resize no longer requires OCaml pcre library
libguestfs live:
- daemon will no longer try to edit your live /etc/lvm configuration
- fix a potential security problem with predictable /tmp names (Steve Kemp)
Security
CVE-2011-4127, RHBZ#757071
Mitigate possible privilege escalation via SG_IO ioctl
For more information, see: https://github.com/libguestfs/libguestfs/commit/9a5f784d511a8f00a8386f316...
New APIs
blkid: print all attributes of a device known to blkid (Wanlong Gao)
e2fsck: access to more features of e2fsck (Wanlong Gao)
list-md-devices: list of Linux MD devices (Matthew Booth)
md-create: create an MD device
md-detail: returns metadata for an MD device (Matthew Booth)
md-stop: stop an MD device (Wanlong Gao)
tune2fs: allow ext2/3/4 filesystems to be tuned
Internals
Git hosting has moved to http://github.com/libguestfs
The various test directories have been rearranged logically, and now
all appear under 'tests/'.
There is a 'make extra-tests' rule which runs ordinary tests and
additional tests, using valgrind to check for memory problems.
Multiple memory leaks and other problems found by valgrind and fixed.
Support for optional arguments in the generator has been rewritten
to provide more features and safety (Matthew Booth).
With gcc -fvisibility=hidden is used for internal symbols, avoiding
call indirection via the PLT.
RHashtable functions can be tested in the generator.
ADD_ARG macro in daemon allows arg lists to be constructed without
risk of stack smashing.
Fix generation of OCaml functions that have more than 10 arguments.
psmisc has been added to the appliance, allowing use of 'fuser',
'killall' and 'pstree' for debugging.
bindtests now cover RBufferOut and optional arguments (Matthew Booth).
Bugs fixed
- 769680 temporary directories created during appliance builds are not cleaned up on error
- 761460 guestfs_utimens hangs on named pipes
- 761451 guestfs_utimens cannot set times on a directory
- 760775 "guestfish: multi-boot operating systems are not supported by the -i option" should be more explanatory
- 760669 guestfish copy-in and <! (inline execution) don't mix well: pclose: No child processes
- 760000 libguestfs fails to compile with Ruby >= 1.9
- 755729 Error message for resize2fs-M needs tweaking
- 750889 Python code incompatible with Python v3.
- 596761 Ctrl-\ causes guestfish to abort
----------------------------------------------------------------------
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
12 years, 3 months
What to Backup for Rebuild?
by Frank Murphy
Due to the failure of a HD.
Am taking the opportunity to rebuild my host.
Besides the images and config*xml.
is there anything else from the host that should be mandatory re guests.
--
Regards,
Frank Murphy
UTF_8 Encoded
12 years, 3 months
Virtual machine => Physical machine - fix screen resolution?
by Philip Rhoades
People,
I installed a Fedora 16 x86_64 virtual machine on a Fedora 14 x86_64
server but used a physical disk (/dev/sdb = /dev/vda) so I could get the
new server going almost completely in virtual mode and then when it was
ready to go, reboot the machine on the new drive. This process went
extremely well (thanks to all the Fedora developers!) but there were a
few glitches left to sort out - one of which was the screen resolution
for both the console and in X. It seems the default virtual screen is
1024x768 but I need 1280x1024. I tried adding a vga parameter to the
linux line in the grub.cfg file but that only temporarily changed the
resolution during bootup. xorg.conf doesn't get used much anymore - do
I need to create it for this case? Is there some way to tell Fedora to
rediscover the maximum screen resolution somehow?
Thanks,
Phil.
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil(a)pricom.com.au
12 years, 3 months
Re: [fedora-virt] virt Digest, Vol 37, Issue 15
by Anthony Vanover
So, just to verify, you're saying that you ping the virtual machine when
just after boot, stop the ping, wait a few hours, and ping again? But
this time the ping is slower? And you're using F16 as the virtual?
On Wed, 2012-01-18 at 12:00 +0000, virt-request(a)lists.fedoraproject.org
wrote:
> Message: 1
> Date: Wed, 18 Jan 2012 10:36:30 +0100
> From: Andrés García <andres(a)verot.com>
> To: virt(a)lists.fedoraproject.org
> Subject: Re: [fedora-virt] Slow virtual ping
> Message-ID: <4F16929E.6020209(a)verot.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi,
>
> I only pinged the guest long enough to get enough responses to show you
> what is happening,
> the first ping and the second one are completely independent from each
> other, it is not that
> I kept it half an hour going.
>
> If you look at the first ping of the second series you will see: icmp_seq=1
>
> Andrés
--
Sending sensitive information? Use PGP?
Then grab my public key available @
anthonyvanover.tk/public.asc
12 years, 3 months
live migration from CentOS 6.2 to 6.1 fails
by Gianluca Cecchi
Hello,
posting here as it could have occurred in Fedora too, during crossing
versions of components...
hope anyone could drive me some hints..
Also because I test qemu/kvm ibvirt in Fedora too...
I have 3 nodes with CentOS, two with 6.1 version + some updates (but below 6.2)
and one with 6.2.
I have a vm on 6.1 hypervisor and I'm able to live migrate it to the
6.2 host, but then I am not able to migrate from 6.2 to either one of
the 6.1....
relevant components:
6.1 hosts
qemu-kvm-0.12.1.2-2.160.el6_1.8.x86_64
libvirt-0.8.7-18.el6_1.1.x86_64
kernel-2.6.32-131.17.1.el6.x86_64
6.2 hosts
qemu-kvm-0.12.1.2-2.209.el6_2.1.x86_64
libvirt-0.9.4-23.el6_2.1.x86_64
kernel-2.6.32-220.2.1.el6.x86_64
guest is named dacsmaster and it is rh el 5.4
the migration from 6.2 to 6.1 fails with
# clusvcadm -M vm:dacsmaster -m intrarhev2
Trying to migrate vm:dacsmaster to intrarhev2...Failed; service
running on original owner
/var/log/messages information:
on source hypervisor:
Jan 12 15:45:17 rhev1 rgmanager[9267]: Migrating vm:dacsmaster to intrarhev2
Jan 12 15:45:18 rhev1 rgmanager[22193]: [vm] Migrate dacsmaster to
intrarhev2 failed:
Jan 12 15:45:18 rhev1 rgmanager[22215]: [vm] error: internal error
missing hostuuid element in migration data
Jan 12 15:45:18 rhev1 rgmanager[9267]: migrate on vm "dacsmaster"
returned 150 (unspecified)
Jan 12 15:45:18 rhev1 rgmanager[9267]: Migration of vm:dacsmaster to
intrarhev2 failed; return code 150
on target hypervisor:
Jan 12 15:45:18 rhev2 kernel: device vnet4 entered promiscuous mode
Jan 12 15:45:18 rhev2 kernel: brvlan65: topology change detected, propagating
Jan 12 15:45:18 rhev2 kernel: brvlan65: port 3(vnet4) entering forwarding state
Jan 12 15:45:18 rhev2 libvirtd: 15:45:18.113: 31182: warning :
qemudStartVMDaemon:3336 : Executing /usr/libexec/qemu-kvm
Jan 12 15:45:18 rhev2 libvirtd: 15:45:18.119: 31182: warning :
qemudStartVMDaemon:3346 : Executing done /usr/libexec/qemu-kvm
Jan 12 15:45:18 rhev2 qemu-kvm: Could not find keytab file:
/etc/qemu/krb5.tab: No such file or directory
Jan 12 15:45:18 rhev2 libvirtd: 15:45:18.332: 8787: error :
virCgroupRemoveRecursively:679 : Unable to remove
/cgroup/cpu/libvirt/qemu/dacsmaster/ (16)
Jan 12 15:45:18 rhev2 libvirtd: 15:45:18.332: 8787: error :
virCgroupRemoveRecursively:679 : Unable to remove
/cgroup/cpuacct/libvirt/qemu/dacsmaster/ (16)
Jan 12 15:45:18 rhev2 libvirtd: 15:45:18.332: 8787: error :
virCgroupRemoveRecursively:679 : Unable to remove
/cgroup/cpuset/libvirt/qemu/dacsmaster/ (16)
Jan 12 15:45:18 rhev2 libvirtd: 15:45:18.332: 8787: error :
virCgroupRemoveRecursively:679 : Unable to remove
/cgroup/memory/libvirt/qemu/dacsmaster/ (16)
Jan 12 15:45:18 rhev2 libvirtd: 15:45:18.332: 8787: error :
virCgroupRemoveRecursively:679 : Unable to remove
/cgroup/devices/libvirt/qemu/dacsmaster/ (16)
Jan 12 15:45:18 rhev2 libvirtd: 15:45:18.332: 8787: error :
virCgroupRemoveRecursively:679 : Unable to remove
/cgroup/freezer/libvirt/qemu/dacsmaster/ (16)
Jan 12 15:45:18 rhev2 libvirtd: 15:45:18.332: 8787: error :
virCgroupRemoveRecursively:679 : Unable to remove
/cgroup/blkio/libvirt/qemu/dacsmaster/ (16)
Jan 12 15:45:18 rhev2 kernel: brvlan65: port 3(vnet4) entering disabled state
Jan 12 15:45:18 rhev2 kernel: device vnet4 left promiscuous mode
Jan 12 15:45:18 rhev2 kernel: brvlan65: port 3(vnet4) entering disabled state
powering off the guest (through "disable" action of the related rhcs
service) and powering it on on 6.1 host, I'm able to live migrate it
either to the other 6.1 host and to the 6.2 one...
/etc/libvirt/libvirtd.conf doesn't contain anything for the host_uuid
part as I find in messages of source 6.2 hypervisor.....
and dmidecode command succeeds on all the three systems.
they are identical servers from an hw point of view and for example
output on one of them gives:
# dmidecode -s system-uuid
34353439-3036-435A-4A38-303330393332
Some additional notes:
If I freeze the vm related cluster service and on source 6.2 host I
manually run the virsh command that took place in 6.1 successfully, it
fails (as expected). This let me keep away considering the different
release versions of cluster related components between 6.1 and 6.2,
concentrating on different releaases of kernel/libvirt/qemu-kvm (at
least I
think so...)
intrarhevN is the host name on custer lan that is also used for migration
(the migration fails also using the service network, the only
difference being it asks a password as
on service network there is no ssh host equivalence)
# virsh migrate --live dacsmaster qemu+ssh://intrarhev2/system tcp:intrarhev2
error: internal error missing hostuuid element in migration data
It seems I'm able to connect through virsh from rhev1 (6.2) to rhev2
(6.1) as I can run
rhev1 prompt-- # virsh
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # connect qemu+ssh://intrarhev2/system
virsh # list
and this command shows me the domains currently running on rhev2 as expected
So I presume there is something related to migration itself and
possibly different needed parameters in 6.2 shipped version of libvirt
(0.9.4 vs 0.8.7).
Any hint on these and/or possible debug options?
The error seems quite obscure, to me at least
Gianluca
12 years, 3 months
Re: [fedora-virt] Slow virtual ping
by Anthony Vanover
Yeah, you're sending a ping flood to your virtual host. Be sure to
terminate ping after a few replies with Ctrl+C. Anyways, a ping flood is
a DDoS attack which overwhelms the victim with ICMP Echo Requests or
"Ping Packets". An attacker hopes that the victim will respond with ICMP
Echo Reply packets so that both incoming and outgoing traffic bandwidth
is consumed. Eventually, the target host's CPU cycles will be filled and
the system will notice a major slowdown. Obviously, this attack is most
successful when the attacker's bandwidth is greater than the hosts. In
your case, your host is virtual. So, it's fair to say that the virtual
host has either equal or less than your physical bandwidth. In short,
that's normal to see such a slowdown (either from consumed CPU cycles or
policy of the host being set not to send ICMP Echo Reply). Why would you
want to ping for several hours anyways?
On Tue, 2012-01-17 at 12:00 +0000, virt-request(a)lists.fedoraproject.org
wrote:
> Message: 2
> Date: Mon, 16 Jan 2012 18:56:38 +0100
> From: Andrés García <andres(a)verot.com>
> To: virt(a)lists.fedoraproject.org
> Subject: [fedora-virt] Slow virtual ping
> Message-ID: <4F1464D6.7000702(a)verot.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello,
>
> I am having a problem trying to setup a F16 machine as a virtual host.
>
> For example, I have another F16 installed as a virtual guest. If I ping it
> just after the host boots I get something like:
>
> PING 192.168.0.158 (192.168.0.158) 56(84) bytes of data.
> 64 bytes from 192.168.0.158: icmp_seq=1 ttl=64 time=0.358 ms
> 64 bytes from 192.168.0.158: icmp_seq=2 ttl=64 time=0.377 ms
> 64 bytes from 192.168.0.158: icmp_seq=3 ttl=64 time=0.317 ms
> 64 bytes from 192.168.0.158: icmp_seq=4 ttl=64 time=0.336 ms
> 64 bytes from 192.168.0.158: icmp_seq=5 ttl=64 time=0.293 ms
> 64 bytes from 192.168.0.158: icmp_seq=6 ttl=64 time=0.334 ms
> 64 bytes from 192.168.0.158: icmp_seq=7 ttl=64 time=0.353 ms
> 64 bytes from 192.168.0.158: icmp_seq=8 ttl=64 time=0.350 ms
> 64 bytes from 192.168.0.158: icmp_seq=9 ttl=64 time=0.291 ms
> [...]
>
> Which is very reasonable, but after some time, I can't tell you
> how much exactly, maybe half an hour, I get:
>
> PING 192.168.0.158 (192.168.0.158) 56(84) bytes of data.
> 64 bytes from 192.168.0.158: icmp_seq=1 ttl=64 time=22.5 ms
> 64 bytes from 192.168.0.158: icmp_seq=2 ttl=64 time=20.8 ms
> 64 bytes from 192.168.0.158: icmp_seq=3 ttl=64 time=19.1 ms
> 64 bytes from 192.168.0.158: icmp_seq=4 ttl=64 time=17.9 ms
> 64 bytes from 192.168.0.158: icmp_seq=5 ttl=64 time=16.8 ms
> 64 bytes from 192.168.0.158: icmp_seq=6 ttl=64 time=15.2 ms
> 64 bytes from 192.168.0.158: icmp_seq=7 ttl=64 time=14.1 ms
> 64 bytes from 192.168.0.158: icmp_seq=8 ttl=64 time=13.2 ms
> 64 bytes from 192.168.0.158: icmp_seq=9 ttl=64 time=11.7 ms
> 64 bytes from 192.168.0.158: icmp_seq=10 ttl=64 time=9.76 ms
> 64 bytes from 192.168.0.158: icmp_seq=11 ttl=64 time=7.86 ms
> 64 bytes from 192.168.0.158: icmp_seq=12 ttl=64 time=6.63 ms
> 64 bytes from 192.168.0.158: icmp_seq=13 ttl=64 time=5.27 ms
> 64 bytes from 192.168.0.158: icmp_seq=14 ttl=64 time=3.79 ms
> 64 bytes from 192.168.0.158: icmp_seq=15 ttl=64 time=1.83 ms
> 64 bytes from 192.168.0.158: icmp_seq=16 ttl=64 time=99.8 ms
> 64 bytes from 192.168.0.158: icmp_seq=17 ttl=64 time=97.9 ms
> 64 bytes from 192.168.0.158: icmp_seq=18 ttl=64 time=96.8 ms
> 64 bytes from 192.168.0.158: icmp_seq=19 ttl=64 time=95.2 ms
> 64 bytes from 192.168.0.158: icmp_seq=20 ttl=64 time=94.5 ms
> 64 bytes from 192.168.0.158: icmp_seq=21 ttl=64 time=92.9 ms
> 64 bytes from 192.168.0.158: icmp_seq=22 ttl=64 time=91.9 ms
> 64 bytes from 192.168.0.158: icmp_seq=23 ttl=64 time=90.7 ms
> 64 bytes from 192.168.0.158: icmp_seq=24 ttl=64 time=88.9 ms
> 64 bytes from 192.168.0.158: icmp_seq=25 ttl=64 time=87.9 ms
> 64 bytes from 192.168.0.158: icmp_seq=26 ttl=64 time=87.7 ms
> 64 bytes from 192.168.0.158: icmp_seq=27 ttl=64 time=85.9 ms
> 64 bytes from 192.168.0.158: icmp_seq=28 ttl=64 time=84.8 ms
> [...]
>
> Now ping answers are much slower for no reason I can see and
> they don't get back to 'normal' unless I reboot the host.
>
> I have two network interfaces, the one in the motherboard for the
> host to use and another one (PCI) which is bridged for the guests.
>
> The host keeps answering pings in less than 1ms without a problem.
>
> The guest has a virtio network interface.
>
> During these tests the F16 guests is the only guest running, I have also
> tried them with a Win7 guest and pretty much the same thing happens.
>
> Do you have any idea what could be the problem?
>
> Thanks,
> Andres
>
--
Sending sensitive information? Use PGP?
Then grab my public key available @
anthonyvanover.tk/public.asc
12 years, 3 months
Re: [fedora-virt] Unable to complete install
by Anthony Vanover
I keep receiving this error in Virtual Machine Manager when adding a new
disk and I'm not sure why. Also says something about KVM not being
installed during step 1, but it appears that I do have it installed (at
least, I think anyways).
Unable to complete install: 'internal error process exited while
connecting to monitor: char device redirected to /dev/pts/0
Could not allocate dynamic translator buffer
'
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line
44, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/create.py", line
1899, in do_install
guest.start_install(False, meter=meter)
File "/usr/lib/python2.7/site-packages/virtinst/Guest.py",
line 1223, in start_install
noboot)
File "/usr/lib/python2.7/site-packages/virtinst/Guest.py",
line 1291, in _create_guest
dom = self.conn.createLinux(start_xml or final_xml, 0)
File "/usr/lib/python2.7/site-packages/libvirt.py", line 2077,
in createLinux
if ret is None:raise libvirtError('virDomainCreateLinux()
failed', conn=self)
libvirtError: internal error process exited while connecting to
monitor: char device redirected to /dev/pts/0
Could not allocate dynamic translator buffer
On Fri, 2012-01-13 at 12:00 +0000, virt-request(a)lists.fedoraproject.org
wrote:
> Send virt mailing list submissions to
> virt(a)lists.fedoraproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://admin.fedoraproject.org/mailman/listinfo/virt
> or, via email, send a message with subject or body 'help' to
> virt-request(a)lists.fedoraproject.org
>
> You can reach the person managing the list at
> virt-owner(a)lists.fedoraproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of virt digest..."
>
>
> Today's Topics:
>
> 1. virtual mashines (Андрей Сафонов)
> 2. Re: virtual mashines (Łukasz Redynk)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 13 Jan 2012 11:57:01 +0400
> From: Андрей Сафонов <safonovandrei(a)gmail.com>
> To: virt(a)lists.fedoraproject.org
> Subject: [fedora-virt] virtual mashines
> Message-ID:
> <CALRAc9FwtFaSYd_UzvsxVb+3T087kKFiVv9Oxt=Xj-_ko8-hfw(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello
> Is it possible to manage vitualnymi machines from a text console?
> Interested in starting, reboot, shut down. I do not know how to put
> Android graphical console for Linux.
> --
> best regards,
> AS
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 13 Jan 2012 09:10:14 +0100
> From: Łukasz Redynk <mr.erdk(a)gmail.com>
> To: virt(a)lists.fedoraproject.org
> Subject: Re: [fedora-virt] virtual mashines
> Message-ID: <1723877.bCnIlVIpJU@lightstar>
> Content-Type: text/plain; charset="utf-8"
>
> Dnia piątek, 13 stycznia 2012 11:57:01 Андрей Сафонов pisze:
> > Hello
> > Is it possible to manage vitualnymi machines from a text console?
> > Interested in starting, reboot, shut down. I do not know how to put
> > Android graphical console for Linux.
>
> You mean kvm/xen VMM managed by libvirtd?
>
> If so then yes, it's possible, you can make ssh connection to target host and
> then run 'virsh', e.g. 'virsh -c qemu:///system' - this will connect to
> libvirtd manager for qemu virtual machines (this will depend on your
> connection string). This command opens shell in which you could start, stop,
> suspend, reboot domains (VMs), manage networks, torage pools etc.
>
--
Sending sensitive information? Use PGP?
Then grab my public key available @
anthonyvanover.tk/public.asc
12 years, 3 months
Slow virtual ping
by Andrés García
Hello,
I am having a problem trying to setup a F16 machine as a virtual host.
For example, I have another F16 installed as a virtual guest. If I ping it
just after the host boots I get something like:
PING 192.168.0.158 (192.168.0.158) 56(84) bytes of data.
64 bytes from 192.168.0.158: icmp_seq=1 ttl=64 time=0.358 ms
64 bytes from 192.168.0.158: icmp_seq=2 ttl=64 time=0.377 ms
64 bytes from 192.168.0.158: icmp_seq=3 ttl=64 time=0.317 ms
64 bytes from 192.168.0.158: icmp_seq=4 ttl=64 time=0.336 ms
64 bytes from 192.168.0.158: icmp_seq=5 ttl=64 time=0.293 ms
64 bytes from 192.168.0.158: icmp_seq=6 ttl=64 time=0.334 ms
64 bytes from 192.168.0.158: icmp_seq=7 ttl=64 time=0.353 ms
64 bytes from 192.168.0.158: icmp_seq=8 ttl=64 time=0.350 ms
64 bytes from 192.168.0.158: icmp_seq=9 ttl=64 time=0.291 ms
[...]
Which is very reasonable, but after some time, I can't tell you
how much exactly, maybe half an hour, I get:
PING 192.168.0.158 (192.168.0.158) 56(84) bytes of data.
64 bytes from 192.168.0.158: icmp_seq=1 ttl=64 time=22.5 ms
64 bytes from 192.168.0.158: icmp_seq=2 ttl=64 time=20.8 ms
64 bytes from 192.168.0.158: icmp_seq=3 ttl=64 time=19.1 ms
64 bytes from 192.168.0.158: icmp_seq=4 ttl=64 time=17.9 ms
64 bytes from 192.168.0.158: icmp_seq=5 ttl=64 time=16.8 ms
64 bytes from 192.168.0.158: icmp_seq=6 ttl=64 time=15.2 ms
64 bytes from 192.168.0.158: icmp_seq=7 ttl=64 time=14.1 ms
64 bytes from 192.168.0.158: icmp_seq=8 ttl=64 time=13.2 ms
64 bytes from 192.168.0.158: icmp_seq=9 ttl=64 time=11.7 ms
64 bytes from 192.168.0.158: icmp_seq=10 ttl=64 time=9.76 ms
64 bytes from 192.168.0.158: icmp_seq=11 ttl=64 time=7.86 ms
64 bytes from 192.168.0.158: icmp_seq=12 ttl=64 time=6.63 ms
64 bytes from 192.168.0.158: icmp_seq=13 ttl=64 time=5.27 ms
64 bytes from 192.168.0.158: icmp_seq=14 ttl=64 time=3.79 ms
64 bytes from 192.168.0.158: icmp_seq=15 ttl=64 time=1.83 ms
64 bytes from 192.168.0.158: icmp_seq=16 ttl=64 time=99.8 ms
64 bytes from 192.168.0.158: icmp_seq=17 ttl=64 time=97.9 ms
64 bytes from 192.168.0.158: icmp_seq=18 ttl=64 time=96.8 ms
64 bytes from 192.168.0.158: icmp_seq=19 ttl=64 time=95.2 ms
64 bytes from 192.168.0.158: icmp_seq=20 ttl=64 time=94.5 ms
64 bytes from 192.168.0.158: icmp_seq=21 ttl=64 time=92.9 ms
64 bytes from 192.168.0.158: icmp_seq=22 ttl=64 time=91.9 ms
64 bytes from 192.168.0.158: icmp_seq=23 ttl=64 time=90.7 ms
64 bytes from 192.168.0.158: icmp_seq=24 ttl=64 time=88.9 ms
64 bytes from 192.168.0.158: icmp_seq=25 ttl=64 time=87.9 ms
64 bytes from 192.168.0.158: icmp_seq=26 ttl=64 time=87.7 ms
64 bytes from 192.168.0.158: icmp_seq=27 ttl=64 time=85.9 ms
64 bytes from 192.168.0.158: icmp_seq=28 ttl=64 time=84.8 ms
[...]
Now ping answers are much slower for no reason I can see and
they don't get back to 'normal' unless I reboot the host.
I have two network interfaces, the one in the motherboard for the
host to use and another one (PCI) which is bridged for the guests.
The host keeps answering pings in less than 1ms without a problem.
The guest has a virtio network interface.
During these tests the F16 guests is the only guest running, I have also
tried them with a Win7 guest and pretty much the same thing happens.
Do you have any idea what could be the problem?
Thanks,
Andres
12 years, 3 months
