I'm learning about bridged networking and how it is applied to virtual
environments (bypassing all the automation provided by libvirtd etc) .
I have a question regarding ip configuration for the virtual bridge.
Let's say I have a host (my machine) where I want to run 3 VMs bridged
to my home network (thru eth0). I have a DHCP server running on my DSL
router, and I have dhcp enabled on my 3 VMs so they all should get a
lease from the DHCP.
As far as a I know these are the raw steps needed to accomplish this:
1- create br0
2- remove current ip address from eth0
3- enslave eth0 to br0
4- create tap devices
5- attach tap devices to br0
6- assign tap devices to every VM
As you can see I haven't assigned an ip address to the virtual bridge
(br0). Why is it that (on almost any site that I visit with this setup)
they always end up assigning an ip address to br0?
Thanks in advance!
My syslog is getting flooded with messages like this:
Nov 19 15:27:16 ian libvirtd: 15:27:16.949: 2725: error :
virInterfaceDefParseXML:807 : XML description for vlan interface misses
the vlan element is not well formed or invalid
I do have tagged VLAN interfaces on the host (br0.1, br0.4, and
br0.251), but none of my VMs are using them. I am not using any
libvirt-managed networks at all:
[pilcher@ian ~]$ sudo virsh net-list --all
Name State Autostart
default inactive no
I am running libvirt-0.8.8-7.fc15.x86_64.
Ian Pilcher arequipeno(a)gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
I'm having a problem with multiple VMs and virt-manager on a Fedora 16
x86_64 machine. When I have multiple VMs running and shut one down,
frequently virt-manager loses its connection. All of my VM windows
disappear, and I'm left looking at a dialog box that says (after
expanding the "Details" tab):
Error polling connection 'qemu:///system': Unable
to read from monitor: Connection reset by peer
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/engine.py", line 440, in _tick
File "/usr/share/virt-manager/virtManager/connection.py", line 1507, in tick
File "/usr/share/virt-manager/virtManager/domain.py", line 1531, in tick
info = self._backend.info()
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1411, in info
if ret is None: raise libvirtError ('virDomainGetInfo() failed', dom=self)
libvirtError: Unable to read from monitor: Connection reset by peer
Simply reconnecting in virt-manager usually works, and then I can
reopen windows for the VMs that are still running. HOWEVER, yesterday
I had this happen and one of my running VMs was NOT listed. I just
about panicked, thinking it had been deleted somehow. However,
restarting libvirtd made it show up again.
Is this a known problem? If not, what component should I file a bug
the xml files are in:
Usually I have to start as root.
If I try as user:
cd /etc/libvirt/qemu && virsh start 02-64-Bit-Old && virsh console
bash: cd: /etc/libvirt/qemu: Permission denied
I would like to be able to do this as user,
I was thinking chown user:user /etc/libvirt/qemu
but am worried about any security issues.
Frank Murphy, friend of fedoraproject
Havn't found much on this a la search engines..
Normally you would do a seriel console to grap a dodgy guest bootup.
ttywatch --name myhost --port /dev/ttyS0
How could this be adapted to start the guest from the host
non-interactive. (cronjob on host, do whatever on guest),
then poweroff guest.
Frank Murphy, friend of fedoraproject
perhaps it is unrelated but yestareday I ran update on my F16 system
and got this
Jan 25 10:19:13 Updated: glib2-2.30.2-1.fc16.x86_64
Jan 25 10:19:14 Updated: openssl-1.0.0g-1.fc16.x86_64
Jan 25 10:19:14 Updated: chkconfig-1.3.57-2.fc16.x86_64
Jan 25 10:19:14 Updated: gtk3-3.2.3-1.fc16.x86_64
Jan 25 10:19:15 Updated: libva-1.0.15-1.fc16.x86_64
Jan 25 10:19:15 Updated: ffmpeg-libs-0.8.8-1.fc16.x86_64
Jan 25 10:19:16 Updated: 1:qt-4.8.0-7.fc16.x86_64
Jan 25 10:19:16 Updated: postgresql-libs-9.1.2-2.fc16.x86_64
Jan 25 10:19:16 Updated: orc-0.4.16-5.fc16.x86_64
Jan 25 10:19:16 Updated: foomatic-db-filesystem-4.0-30.20120103.fc16.noarch
Jan 25 10:19:16 Updated: 12:dhcp-libs-4.2.3-5.P2.fc16.x86_64
Jan 25 10:19:16 Updated: 12:dhcp-common-4.2.3-5.P2.fc16.x86_64
Jan 25 10:19:21 Updated: foomatic-db-ppds-4.0-30.20120103.fc16.noarch
Jan 25 10:19:21 Updated: orc-compiler-0.4.16-5.fc16.x86_64
Jan 25 10:19:23 Updated: postgresql-9.1.2-2.fc16.x86_64
Jan 25 10:19:25 Updated: 1:qt-x11-4.8.0-7.fc16.x86_64
Jan 25 10:19:26 Updated: gnome-keyring-3.2.1-3.fc16.x86_64
Jan 25 10:19:26 Updated: glusterfs-3.2.5-6.fc16.x86_64
Jan 25 10:19:27 Updated: git-188.8.131.52-1.fc16.x86_64
Jan 25 10:19:27 Updated: perl-Git-184.108.40.206-1.fc16.noarch
Jan 25 10:19:38 Updated: selinux-policy-3.10.0-72.fc16.noarch
Jan 25 10:19:38 Updated: mplayer-common-1.0-0.128.20110816svn.fc16.x86_64
Jan 25 10:19:39 Updated: augeas-libs-0.10.0-3.fc16.x86_64
Jan 25 10:19:39 Updated: mplayer-1.0-0.128.20110816svn.fc16.x86_64
Jan 25 10:19:41 Updated: selinux-policy-targeted-3.10.0-72.fc16.noarch
Jan 25 10:19:41 Updated: glusterfs-fuse-3.2.5-6.fc16.x86_64
Jan 25 10:19:42 Updated: gnome-keyring-pam-3.2.1-3.fc16.x86_64
Jan 25 10:19:45 Updated: 1:qt-devel-4.8.0-7.fc16.x86_64
Jan 25 10:19:46 Updated: postgresql-server-9.1.2-2.fc16.x86_64
Jan 25 10:19:46 Updated: orc-devel-0.4.16-5.fc16.x86_64
Jan 25 10:19:50 Updated: foomatic-db-4.0-30.20120103.fc16.noarch
Jan 25 10:19:50 Updated: 12:dhclient-4.2.3-5.P2.fc16.x86_64
Jan 25 10:19:51 Updated: ffmpeg-devel-0.8.8-1.fc16.x86_64
Jan 25 10:19:51 Updated: ffmpeg-0.8.8-1.fc16.x86_64
Jan 25 10:19:51 Updated: libva-devel-1.0.15-1.fc16.x86_64
Jan 25 10:19:51 Updated: libva-utils-1.0.15-1.fc16.x86_64
Jan 25 10:19:51 Updated: gtk3-immodule-xim-3.2.3-1.fc16.x86_64
Jan 25 10:19:51 Updated: gnome-color-manager-3.2.2-1.fc16.x86_64
Jan 25 10:19:52 Updated: ntsysv-1.3.57-2.fc16.x86_64
Jan 25 10:19:52 Updated: 1:nfs-utils-1.2.5-4.fc16.x86_64
Jan 25 10:19:52 Updated: mysql-libs-5.5.19-1.fc16.x86_64
Jan 25 10:19:52 Updated: ibus-hangul-1.4.0-1.fc16.x86_64
Jan 25 10:19:53 Updated: glib2-devel-2.30.2-1.fc16.x86_64
Jan 25 10:19:54 Updated: gjs-1.30.1-1.fc16.x86_64
Jan 25 10:19:54 Updated: espeak-1.46.02-1.fc16.x86_64
Jan 25 10:19:55 Updated: libicu-4.6-4.fc16.x86_64
Jan 25 10:19:55 Updated: kernel-headers-3.2.1-3.fc16.x86_64
Jan 25 10:20:03 Installed: kernel-devel-3.2.1-3.fc16.x86_64
Jan 25 10:20:04 Updated: iso-codes-3.32-1.fc16.noarch
Jan 25 10:20:04 Updated: xkeyboard-config-2.3-3.fc16.noarch
Jan 25 10:20:04 Updated: alsa-plugins-pulseaudio-1.0.24-3.fc16.x86_64
Jan 25 10:20:04 Updated: os-prober-1.48-2.fc16.x86_64
Jan 25 10:20:05 Updated: kernel-tools-3.2.1-3.fc16.x86_64
Jan 25 10:20:05 Updated: 1:emacs-filesystem-23.3-9.fc16.x86_64
Jan 25 10:20:05 Updated: procmail-3.22-29.fc16.x86_64
Jan 25 10:20:05 Updated: gnome-tweak-tool-3.2.2-1.fc16.noarch
Jan 25 10:20:05 Updated: pptp-1.7.2-14.fc16.x86_64
Jan 25 10:20:06 Updated: rubygem-treetop-1.4.10-1.fc16.noarch
Jan 25 10:20:15 Updated: kernel-doc-3.2.1-3.fc16.noarch
Jan 25 10:20:19 Installed: kernel-3.2.1-3.fc16.x86_64
Jan 25 10:20:19 Updated: 1:libguestfs-1.14.9-1.fc16.x86_64
Jan 25 10:20:19 Updated: 1:libguestfs-tools-c-1.14.9-1.fc16.x86_64
I continued runnign previous kernel (3.1.9...) and a w7 spiced guest.
This morning after reboot it seems w7 guest doesn't start anymore.
It remains in the black screen with w7 logo that flash a little and
remains there with 100% cpu consumption...
ALso trying to rstart with old kernel after this the w7 guest blocks
Any suggestion or other guys encountering such a problem?
What is the "best" way to setup a Windows XP KVM mouse
(especially what matching gibberish should go in the xml
definition of the XP virtual machine :-)?
I'm currently using an old version of the XP agent and serial
driver, and when I experimented with updating, my XP mouse
stopped working, so I'm wondering what the correct combination
is supposed to be for latest and greatest most wonderful
Any example of a specific setup on the web somewhere?
I had a couple original F16 guests (un-updated) that I had originally
installed under a F13 host months ago. I installed a new copy (not
upgraded) of F16 on the host and imported the guests with their
original storage. This all worked fine until I did "yum update" on
the F16 guests (these guests are used for off-net testing, so they
were never updated until today--500+ entries in the update
transaction). Now the mouse pointers don't show up in the guests in
virt-manager, and "xev" on the guests shows no mouse activity at all.
I'm using cirrus for the video hardware and VNC for the remote display
protocol. I've tried rebooting host & guests with no improvement.
How can I troubleshoot/fix this?
I can't say for sure, but I think you may have too many virtual CPU's
set. Sometimes, it takes longer with more CPUs because the more there
are, the longer the latency of scheduled tasks. Set it to 1, if not
already, and see if that makes a difference. Poke around in your NIC
settings too, something may be off there...
On Sat, 2012-01-21 at 12:00 +0000, virt-request(a)lists.fedoraproject.org
> Date: Fri, 20 Jan 2012 17:22:46 +0100
> From: Andrés García <andres(a)verot.com>
> Cc: virt(a)lists.fedoraproject.org
> Subject: Re: [fedora-virt] virt Digest, Vol 37, Issue 15
> Message-ID: <4F1994D6.6040502(a)verot.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> > 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?
> That's right
> > And you're using F16 as the virtual?
> Both as host and guest.
Sending sensitive information? Use PGP?
Then grab my public key available @