I'm trying to install xp virtual machine from an .iso on the disk,
I have a virtual machine called localhost with qemu as ID. It has a storage
area at /var/lib/libvirt/images, i'm right clicking on that and choosing new
then following the wizard but it keeps failing whilst creating the domain.
Is anyone familiar with this scenario or have any suggestions?
Unable to complete install '<class 'libvirt.libvirtError'> internal error
Domain microXP didn't show up
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/create.py", line 1501, in
dom = guest.start_install(False, meter = meter)
File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 541, in
return self._do_install(consolecb, meter, removeOld, wait)
File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 633, in
self.domain = self.conn.createLinux(install_xml, 0)
File "/usr/lib64/python2.6/site-packages/libvirt.py", line 974, in
if ret is None:raise libvirtError('virDomainCreateLinux() failed',
libvirtError: internal error Domain microXP didn't show up
If you are running a number of qemu-kvm's with similar guests, you can
gain a lot of memory by using ksm properly.
An unattended host running a variable number of qemu-kvm's needs to tune
ksm automatically, since when memory is tight, it's better to spend more
cpu on merging pages. In more relaxed cases, it's just a waste of time.
The attached service tries to do just that.
It monitors how much memory is used by qemu-kvm processes, and starts
ksm when a threshold is passed. Ksm usually manages to free up some
As long as memory used by qemu is above the defined threshold, ksm tries
harder and harder to share memory pages (up to a limit). This may happen
if a guest starts working and consumes new memory. If there's enough
free memory, ksm cools down.
Ksmd service has the usual start/status/stop verbs, and an additional
one: signal. One should use that verb just after one starts a new
qemu-kvm process or just after such process dies, to let ksm adjust
Comments and suggestion are welcome.
I have build virt-viewer-0.2.0 for windows.
now when I tried to run that "virt-viewer.exe" for the 1st time.
it gave me this error:
(virt-viewer.exe:8464): Pango-WARNING **:
\lib\pango\1.6.0\modules\pango-basic-win32.dll': The specified module could
To solve this I had to rename one of my Disk to Z and the copied the
pango-basic-win32.dll at the specified path.
now it didnt give me any error.
But what happens now is:
1. virt-viewer.exe -c qemu+tcp://192.168.1.106/session 1 ; where
192.168.1.106 is the ip address of my machine where qemu is running and 1 is
the id of the VM.
2. A blank screen opens up with "virt-viewer.exe" written on its top and
then that program does not responds.
Could someone please help me out with this.
Thanks in advance
My home-server is running rawhide. To get some virtual machines working
on it I did:
* disable Networkmanager
* setup a br0-Device that includes eth0
* disable the libvirt default network virbr0 using virsh net-autostart
When I now try to install a new vm using virt-manager this fails:
I'm asked (under advanced options) to choose a network - the only
network available ist the (deactivated) virbr0 network. When I then try
to proceed anyway I am told that the virbr0 is inactive and would I like
to start it. Choosing no doesn't allow me to finish the installation
When I edit an xml definition manually to add the br0-Bridge as network
device things work fine.
Shouldn't this be possible from within virt-manager?
sven === jabber/xmpp: sven(a)lankes.net
On Thu, 01 Oct 2009 21:59:01 +0100 Mark McLoughlin wrote:
> == virt-manager ==
> * Tue Sep 29 2009 Cole Robinson <crobinso redhat com> - 0.8.0-6.fc12
> - Fix VCPU hotplug
any info on about what would have been fixed? And also provided
In my env with 0.8.0-6 and f11 with virt-preview it seems I cannot
hotplug/unplug at all a cpu....
In details window of a rh 5.3 vm with 2 vCPUs, I cannot raise the
number (current is equal to maximum), while I can lower but I get that
the effect will be visible at next reboot.....
Or do I have to create a new VM with this peculiar version of
virt-manager to see different behaviour?
I'm working on migrating Fedora lists from RHT infrastructure to
Fedora infrastructure in the coming little bit. The question that I
had was does fedora-xen and fedora-virt both need to exist? I'm
subscribed to both, and certainly the conversations on each are
different, but could they be merged?
As of several months ago, the subscriber count of fedora-xen was WAY
higher than that of fedora-virt, this doesn't seem to make much sense
since Xen is not The Way Forward(TM), at least from what I can see.
I guess the question is could we merge the two lists, and have one
less to migrate, or are both really needed?
I have a powerful server but without VT capabilities, where I would like to
use virt-manager tools as of fedora-virt-preview repo and speed up somehow
things using kqemu.
It seems that kqemu support is not compiled in for this repo, correct?
Instead, as the kqemu kernel module is in rpmfusion, I presume that the
stock f11 qemu has this support built in....
Am I wrong?
Any problems to compile kqemu support ?
On another server, tried to rebuild qemu-0.11.0-2.fc11.src.rpm (from
fedora-virt) after installing kqemu from rpmfusion.
But while if I take the source I get kqemu as enabled in configure script,
in rpmbuild I don't get so.
I notice that inside the qemu tar.gz as provided by the source.rpm there are
three lines below in the top configure script:
if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
So I commented out the kqemu="no" line... and built the package (not
touching the other two configure scripts that seems related to kvm...)
After installing, if I run qem-kvm or qemu without kqemu all is ok.
[root@tekkaman bin]# ./qemu --enable-kqemu
Not enough memory (requested_size = 16777216, max memory = 146800640)
For Kqemu now gplv2, are there any barriers to have it included in fedora
Thanks in advance,