Log filling with bogus(?) VLAN-related error message
by Ian Pilcher
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.
Any ideas?
Thanks!
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================
11 years, 11 months
Close a VM, virt-manager loses connection
by Jerry James
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
conn.tick()
File "/usr/share/virt-manager/virtManager/connection.py", line 1507, in tick
vm.tick(now)
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
against? Thanks,
--
Jerry James
http://www.jamezone.org/
12 years, 2 months
Re: [fedora-virt] Routing to guests
by Robert Thiem
> From: Philip Rhoades
> I can ssh from/to the host/guest OK but how do I set up a route (or
> whatever is necessary) so that another machine:
> eth0: 192.168.0.12
> can ssh to the guest? - "ssh 192.168.122.68" gives "no route to host" -
> http://docs.fedoraproject.org/virtualization-guide/f12/en-US/html/ but
> the problem does not seem to be covered there.
Alexander is correct in saying that bridging would allow you to do that.
There are two networking discussed in the guide.
The first is a NAT (network address translation), in which the guests are
given "private" ip addresses and any outbound traffic appears to be coming
from the host machine's IP address. This is the same as the setup on your
ADSL router where the internal network machines get addresses of
192.168.x.x but the internet sees your requests as coming from the IP
address of your router.
There should be lots of documentation in linux firewalling guides under
sections on NAT (or possibly called IP Masquerading in some). Have a look
at these for information on port forwarding to reveal services
inside the virtual (such as ssh).
The other option is bridging. This shares the physical network interface
of the host with the guest. In this case the VM acts as though it's a
machine plugged into the same subnet as the host, its services are
accessible like those of the host and it's as vulnerable to attack as the
host.
Robert
12 years, 3 months
Virtual CD-ROM & floppy problems in F16
by Ian Pilcher
I am trying to set up a (32-bit) Windows 7 guest on Fedora 16, and I've
run into a couple of irritating problems.
1. The guest does not seem to recognize the virtual floppy drive at
all. I've used virt-manager to create a virtual floppy drive (and
controller), confirmed that it appears in the XML, and attached the
VirtIO driver VFD, but the guest is acting as if it doesn't have a
floppy drive at all -- both during installation and after I install
to an emulated IDE disk.
2. I am unable to attach an ISO file to the virtual CD-ROM. Clicking
on the "Attach" button in virt-manager has no effect. The only way
I've been able to achieve this is to shut down the guest and delete
and recreate the CD-ROM.
Is anyone seeing anything like this? Any ideas what could be going on?
Thanks!
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================
12 years, 3 months
Dissapearing Cursor F17 guests
by Frank Murphy
I have a dissapearing cursor in some F17\Rawhide guests.
Happens with both spice\vnc.
differents video qxl,cirrus etc.
F15\16 guests are fine.
Have removed tablet in case that was the problem,
still there with ps\2 emu.
I cannot remove ps2 to test the other way around.
Any ideas.
F16 host, with F17 libvirt + deps.
(to fix the losing connectiion problem)
--
Regards,
Frank Murphy
UTF_8 Encoded
Friend of fedoraproject.org
12 years, 3 months
EFI (UEFI)
by Frank Murphy
What is the best way to create a fake EFI\UEFI
setup as a guest vm? (Current host F15+ virt-preview)
--
Regards,
Frank Murphy
UTF_8 Encoded
Friend of fedoraproject.org
12 years, 4 months
[fedora-specific libvirt PATCH] qemu: replace deprecated fedora-13 machine type with pc-0.13
by Laine Stump
(I'm thinking of appying this patch to libvirt in the F15 and F16
branches, as well as Rawhide. The intent is to prepare everyone for
qemu's removal of support for the "fedora-13" machine type, which will
happen in F17 (already done in Rawhide)).
This addresses https://bugzilla.redhat.com/show_bug.cgi?id=754772 .
It should only be applied to Fedora builds of libvirt (it seems
appropriate to apply it to all versions currently in support).
Background:
During the lifetime of Fedora 13, some features were
backported into the F13 build of qemu-kvm from upstream. These
features were part of the functionality of machine type "pc-0.13" in
upstream qemu-kvm, so a special "fedora-13" machine type was created
for the F13 qemu-kvm. Since this fedora-13 became the new "canonical
machine type", all new domains created with F13 libvirt tools by
default contained that machine type in their configuration file.
With the release of Fedora 16, qemu-kvm initially removed support for
this machine type, which caused failure of many guest configurations
to start. qemu-kvm subsequently re-added the patch to support
fedora-13, but with the promise that they could remove it with the
release of Fedora 17. (see
https://bugzilla.redhat.com/show_bug.cgi?id=748218 ).
Solution:
In order to create a repeat of the recent problems, prior to F17
existing guest configurations need to be updated to change fedora-13
to pc-0.13 (which has been determined to be equivalent for all
practical purposes). That's what this patch does:
Each time libvirtd is started, it calls virDomainLoadAllConfigs()
which calls virDomainLoadConfig(); this function has been modified to
check for os.machine == "fedora-13", and change it to "pc-0.13" then
write the updated config back to disk.
Also, any other time a domain definition is parsed, the parsed version
in memory is changed to turn "fedora-13" into "pc-0.13". This handles
domains that had been saved to disk prior to the upgrade, and are
subsequently restarted.
Finally, whenever a domain definition is formatted into a string, any
occurence of fedora-13 is replaced with pc-0.13. This should deal with
those cases where a domain was running at the time of upgrade, and is
later saved/snapshotted.
I had considered doing this with some sed commands in the specfile,
but that wouldn't do anything to help the xml saved in image files.
(Also, one of the xml tests was using the machine type "fedora-13", and
since that machine type is treated specially by the rest of this
patch, it was failing. It has been changed to use machine type pc-0.13
instead.)
---
src/conf/domain_conf.c | 52 ++++++++++++++++++-
.../qemuxml2argv-encrypted-disk.args | 2 +-
.../qemuxml2argv-encrypted-disk.xml | 2 +-
3 files changed, 51 insertions(+), 5 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 75e51a0..bf3dd88 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -8061,7 +8061,25 @@ virDomainDefPtr virDomainDefParseString(virCapsPtr caps,
unsigned int expectedVirtTypes,
unsigned int flags)
{
- return virDomainDefParse(xmlStr, NULL, caps, expectedVirtTypes, flags);
+ virDomainDefPtr def
+ = virDomainDefParse(xmlStr, NULL, caps, expectedVirtTypes, flags);
+
+ /* Fedora-specific HACK - treat fedora-13 and pc-0.13 as equivalent.
+ * This handles the case of domains that had been saved to an image file
+ * prior to upgrade (save or snapshot), then restarted/reverted.
+ */
+ if (def && STREQ_NULLABLE(def->os.machine, "fedora-13")) {
+ VIR_FREE(def->os.machine);
+ if (!(def->os.machine = strdup("pc-0.13"))) {
+ virReportOOMError();
+ virDomainDefFree(def);
+ def = NULL;
+ } else {
+ VIR_WARN("Replacing deprecated 'fedora-13' machine type "
+ "with equivalent 'pc-0.13' in domain %s xml", def->name);
+ }
+ }
+ return def;
}
virDomainDefPtr virDomainDefParseFile(virCapsPtr caps,
@@ -11343,8 +11361,20 @@ virDomainDefFormatInternal(virDomainDefPtr def,
virBufferAddLit(buf, " <type");
if (def->os.arch)
virBufferAsprintf(buf, " arch='%s'", def->os.arch);
- if (def->os.machine)
- virBufferAsprintf(buf, " machine='%s'", def->os.machine);
+ if (def->os.machine) {
+ /* Fedora-specific HACK - replace "fedora-13" with "pc-0.13".
+ * This will catch XML being written to save/migration images
+ * of domains that were running when libvirtd was restarted at
+ * the time of upgrade.
+ */
+ if (STREQ_NULLABLE(def->os.machine, "fedora-13")) {
+ virBufferAddLit(buf, " machine='pc-0.13'");
+ VIR_WARN("substituting machine type 'fedora-13' with 'pc-0.13' "
+ "in domain %s", def->name);
+ } else {
+ virBufferAsprintf(buf, " machine='%s'", def->os.machine);
+ }
+ }
/*
* HACK: For xen driver we previously used bogus 'linux' as the
* os type for paravirt, whereas capabilities declare it to
@@ -11779,6 +11809,22 @@ static virDomainObjPtr virDomainLoadConfig(virCapsPtr caps,
VIR_DOMAIN_XML_INACTIVE)))
goto error;
+ /* Fedora-specific HACK - replace "fedora-13" with "pc-0.13".
+ * This updates all config files at the first restart of libvirt
+ * after upgrade.
+ */
+ if (STREQ_NULLABLE(def->os.machine, "fedora-13")) {
+ VIR_FREE(def->os.machine);
+ if (!(def->os.machine = strdup("pc-0.13"))) {
+ virReportOOMError();
+ goto error;
+ }
+ VIR_WARN("Replacing deprecated 'fedora-13' machine type "
+ "with equivalent 'pc-0.13' in domain %s configuration file", name);
+ if (virDomainSaveConfig(configDir, def) < 0)
+ goto error;
+ }
+
if ((autostartLink = virDomainConfigFile(autostartDir, name)) == NULL)
goto error;
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args
index 1da0073..c6634fd 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args
+++ b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.args
@@ -1,5 +1,5 @@
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root \
-/usr/bin/qemu -S -M fedora-13 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name \
+/usr/bin/qemu -S -M pc-0.13 -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name \
encryptdisk -uuid 496898a6-e6ff-f7c8-5dc2-3cf410945ee9 -nographic -nodefconfig \
-nodefaults -chardev socket,id=monitor,\
path=//var/lib/libvirt/qemu/encryptdisk.monitor,server,nowait -mon \
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml
index f5e5d74..fdcf624 100644
--- a/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml
+++ b/tests/qemuxml2argvdata/qemuxml2argv-encrypted-disk.xml
@@ -5,7 +5,7 @@
<currentMemory>524288</currentMemory>
<vcpu>1</vcpu>
<os>
- <type arch='i686' machine='fedora-13'>hvm</type>
+ <type arch='i686' machine='pc-0.13'>hvm</type>
<boot dev='hd'/>
</os>
<clock offset='utc'/>
--
1.7.7.3
12 years, 4 months
Suggestions for NFS mount options?
by Scott Baker
I have a virt frontend that runs the VMs, and another server that stores
the VM images/configs and shares via NFS.
On the frontend I mount /mnt/nfs/virt-stuff and then symlink
/var/lib/libvirt/images and /etc/libvirt/ from the NFS mount point. Are
there any "best practices" for NFS mount options? Do I need to worry
about the filesystem on the VM store? Right now I'm just using EXT3 to
store the images.
Any advice on the best way to share/store the VM images would be
appreciated.
--
Scott Baker - Canby Telcom
System Administrator - RHCE - 503.266.8253
12 years, 4 months
Re: [fedora-virt] P2P Packaging/Koji Cloud
by Denis Arnaud
> Date: Thu, 8 Dec 2011 12:33:38 -0500
> From: seth vidal <skvidal(a)fedoraproject.org>
>
> I answered Denis immediately at the first post and he concurred it was
> a problem. I like to think the conversation evolved as we discussed.
>
Yes, the conversation has shifted... Indeed, I mixed two distinct ideas:
1. One corresponding to an actual use case: using a private/trusted cloud
service to do scratch, chain or even massive builds.
2. Another one corresponding to a dream, really: a P2P cloud, just because
it sounds exciting, and would certainly be a USP (unique selling point) for
Fedora.
>From the answers, it seems that both ideas ring a bell. And, of course, the
dream does not seem doable, mainly for security reason. Or it could be
implemented as a proof-of-concept of all the technologies and skills, which
Fedora gathers under its umbrella?
Nevertheless, for now, I am really interested by the item #1 above. For the
#2, we never know. Maybe a GSoC, or something like that, could make it
happen...
Thanks for having shared your thoughts!
Regards
Denis
12 years, 4 months
Re: [fedora-virt] kvm "tablet" device burning cpu cycles
by Eric Blake
[redirecting to the fedora virt list]
On 12/06/2011 03:36 PM, Dennis Jacobfeuerborn wrote:
> Hi,
> I noticed that when you install a virtual system with virt-manager it
> always installs a tablet device by default.
> The problem is that this device consumes 10% of cpu resources of the host
> according to "top" which should probably be considered a bug.
The poor behavior of a tablet device should be raised against the qemu
team, to see if it can be made more efficient.
> What is worse is that removing the tablet also means no mouse pointer
> showing up in a centos 6 guest which means you are pretty much forced to
> use the tablet device.
Meanwhile, sufficiently new qemu provides USB device emulation, which is
more efficient than the PCI tablet emulation; although it is not as
apparent whether typical guests support that device driver in their
default install (one of the reasons we default to the older tablet
emulation is that it is likely to have a driver pre-installed on most
guest OSs). The idea of swapping the default to a USB pointer should be
raised against virt-manager and/or python-virtinst, when installing a
new-enough guest OS with new enough qemu support, while continuing to
provide the compatible fallback of the tablet for older setups.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
12 years, 4 months
