Another question with internal snapshots. I can see the snapshot tree with:
virsh snapshot-list Win7vm --tree
However, I would like to know from what previous snapshot I'm currently
running off. Something like the "You are here" that VMware shows. Is
there a way to find that out?
First off I'm not very experienced setting up and running virtual guest
systems. I install Fedora 20 Beta using virt-manager. It is hosted on a
Fedora 19 system.
1) Reocurring issue with the pointer not being visible in the guest
window. Some times cleared by stopping and restarting the guest
system. Most of the time need to force stop.
2) During initial install I did not seem to beable to create a network
bridge. I was able to add a network bridge after the install.
3) I shutdown the guest and when I went to bring it up it failed trying
to create the network bridge again. I then looked at configuration
and found two network bridge devices. I deleted one but it still
failed. So I deleted the other one and then added a new network
bridge which worked.
- Network bridge is macvtap off the host network device. Device model
rtl8139. Source mode is VEPA. Basically took defaults.
- Display is spice with no setting changes.
If someone have console=hvc0 kernel command line, it seems that it needs
to be removed or replaced with console=ttyS0 when migrating the VMs to
F20. With console=hvc0 and latest Fedora kernels, the VM refuses to boot.
Without any console= arg, hvc* consoles, defined by:
.../console/target/@type='virtio' in the libvirt xml defs, are remaining
usable *after* the boot, i.e.:
virsh start vm --console
will show the login prompt eventually, just does not dumps the kernel
messages during the boot. If you need the boot messages, might use
console=ttyS0 (+ .../@type='serial'), like before hvc0 feature instead.
This perhaps have something to do with the recent reconfiguration of
virtio_console as loadable module:
Maybe, the virtio_console module could be included again as builtin for
the Fedora Cloud product kernel?
PS: Some happy day, we might have semantic databases integrating
products changes with our local setups and helping with the faster,
reliable resolutions of these incompatibility introductions. Or at
least nobody can stop us to dream about :-).
PPS: My case:
Before .6-302, I was used with: console=hvc0 command line for direct
kernel boot (my VMs are the simplest possible, provisioned on plain
LVMs/ext4 with just yum+xquery and latter updated with in-house
[*] virsh dumpxml vm:
<type arch='x86_64' machine='pc-i440fx-1.6'>hvm</type>
<cmdline>ro root=/dev/vda console=hvc0</cmdline>
<target type='virtio' port='0'/>
With the latest kernels such configuration hangs, because of hvc0.
I have been experimenting with putting /var/lib/libvirt/images on a
btrfs subvolume. What I found was ... interesting.
Just doing nothing else, a disk image file can en up with something like
50,000 extents or more. Now, you can go do a btrfs fi defrag and it
will reduce but when you use the system, it will increase again.
OK, you cannot turn off "cow" for a subvolume but you can turn it off
for a new file (or more important) for an new file in a directory:
chattr +C /var/lib/libvirt/images and any new disk image file will have
OK, install a system with a new disk file. The result: a file with
47,000 extents. The reason, I used virt-manager and the disk image file
allocated was a sparse file. Now in some respects sparse files are good
because they do not use space unless they need it. But, with BTRFS, the
result is large scale fragmentation. And, btrfs fi defrag does not
work on this file /directory.
OK, another try. Preallocate a file using dd if=/dev/zero
of=/var/lib/libvirt/images/xxx.img bs=1024 count=12587000 and the result
is a 12GB (more or less) virtual disk. Install a system using this as
the virtual disk. extents=9. install a second system subvol=root2 (it
is a virtual btrfs system). extents=9. And a third one. extents=9.
BTW, these installs were about the fastest I have ever seen!
So, is there a way to do this "sparse=false" disk allocation with
virt-manager, or do I need to do an RFE?
For a system where the disk images are going to be on BTRFS, a fully
allocated disk has definite benefits.
I'm trying to use virt-sysprep for the first time, and getting the
[root@ian ~]# virt-sysprep -d rdo-template
Examining the guest ...
Fatal error: exception Guestfs.Error("could not create appliance through
libvirt: Unable to read from monitor: Connection reset by peer [code=38
Digging into the qemu log, I see:
could not open disk image /var/lib/libvirt/images/rdo-template.img:
qemu-img -info says this about the file:
file format: qcow2
virtual size: 8.0G (8589934592 bytes)
disk size: 1.3G
Any ideas what's going on?
Ian Pilcher arequipeno(a)gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
When I start a new VM, my host network stops functioning, and then I
have persistent issues with the host network thereafter, even after
shutting down all VMs.
The symptom of my network issues is that it intermittently goes down.
ping returns "Destination Host Unreachable" even for hosts on my local
network, although my routes still look good according to 'route -rn'. I
believe my network is flooded with STP packets at this point and all my
switches will go down shortly thereafter. I can recover for a while by
unplugging/replugging network cable but the problem comes back after a
few minutes. A reboot will clear it up.
On the host dmesg output, I see the following when this occurs:
I am using the alx driver (AR816x/AR817x network controller) with Fedora 19.
I have attached output of 'brctl show', 'ip link', and 'ip address'. I
use NetworkManager, and disable WiFi manually before using libvirt.
I would very much appreciate any guidance.
Some of you may be interested in running your qemu-kvm (or other) disk
image files on BTRFS. After some fumbling around, I have found out how
to do it so it works and works very well (especially if it is on an SSD).
Anyone investigating running on BTRFS immediately finds out that there
is a fragmentation problem (just putting image files on btrfs can result
in them having between 50,000 and 100,000 extents). Some may have seen
that adding nodatacow to the mount option is a solution ... it is not.
So what is the solution?
1. execute: chattr +C /var/lib/libvirt/images
or wherever your image files are. This needs to be done on the
directory whether you have a separate subvol or not.
2. This ONLY works for new files and ONLY works for "raw" storage
format files. Pretty much by definition, qcow2 files are sparse format
files and that is the primary problem on btrfs.
So that the vm creation wizard will create a new disk using the raw
storage format, you need to select:
Edit->Preferences->VM Details->Default Storage Format->Raw
After then, an created virtual will have the correct disk format.
You can use "filefrag" to verify that things are working.