well,
if it is not "/var/something"
there is also
"/dev/pts"
Something is wrong around the "qemuMonitor" routines.
find why qemuMonitorIORead:487 is triggered and the bug is closed !
I really don't understand the logic of 'upstart' to trace into it, sorry.
Openning a new bug on the same subject
Hello *,
@Serge,
I'm pretty sure now where is the problem.
Disk related.
The patch waiting for 'disk' is not sufficient.
I have updated the libvirt.0.8.8 with 0.9.3 compiled locally.
Nothing changes, one VM (over two in autostart) is starting.
Short libvirt log activated :
20:38:48.728: 122
Hello,
The disk subsystem may or may not be involved on my system. Difficult to say
and have no relation with the 'virbr0' (when defined virbr0=>everything OK at
least with two VMs booting).
I have compiled 0.9.2 and 0.9.3 for my 11.04 system. I will try again with
those updated libvirt-bin (inc
@Serge,
here is one domain; other is a duplicate. It a test machine.
I think the apport-collect is unhappy...
see log after this dumpxml
Maybe the disk system is also mandatory to complete ?
I have two 2TB drives mirrored+lvm2 on a not so slow board
(phenom2 6hearts on gigabyte ga890fxa-ud7)
As
Hello,
Using ubuntu server 11.04
The fix does nothing "start on (runlevel [2345] and stopped networking
RESULT=ok)"
Have patche applied
ii libvirt-bin0.8.8-1ubuntu6.3
ii libvirt00.8.8-1ubuntu6.3
BUT I found on my installation that when
1/ the def
