Mauricio Tavares
2014-Mar-06 05:16 UTC
[libvirt-users] ISO refuses to let vm starts (and is not mentioned in config)
Trying to start one of my vms, a centos one at that, but am
getting the following message:
[root@vmhost ~]# virsh start voip --paused
error: Failed to start domain voip
error: cannot open file
'/var/tmp/FreePBX-5.211.65-3-x86_64-Full-1388073872.iso': No such file
or directory
[root@vmhost ~]#
But, virsh dumpxml voip shows no info onto the .iso
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'
io='native'/>
<source file='/dev/vmhost_vg0/voip'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x04'
function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hda' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='0'
target='0' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hdb' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='0'
target='0' unit='1'/>
</disk>
Log file is not particularly helpful:
2014-03-04 22:57:46.121+0000: shutting down
2014-03-05 23:42:18.528+0000: shutting down
2014-03-05 23:47:07.375+0000: shutting down
2014-03-06 00:56:32.908+0000: shutting down
2014-03-06 01:11:32.582+0000: shutting down
So, the question is how did this iso got involved in this specific vm?
I can start my other vms without them even knowing about this .iso.
Mauricio Tavares
2014-Mar-06 12:59 UTC
Re: [libvirt-users] ISO refuses to let vm starts (and is not mentioned in config)
On Thu, Mar 6, 2014 at 12:16 AM, Mauricio Tavares <raubvogel@gmail.com> wrote:> Trying to start one of my vms, a centos one at that, but am > getting the following message: > > [root@vmhost ~]# virsh start voip --paused > error: Failed to start domain voip > error: cannot open file > '/var/tmp/FreePBX-5.211.65-3-x86_64-Full-1388073872.iso': No such file > or directory > > [root@vmhost ~]# > > But, virsh dumpxml voip shows no info onto the .iso > > <disk type='file' device='disk'> > <driver name='qemu' type='raw' cache='none' io='native'/> > <source file='/dev/vmhost_vg0/voip'/> > <target dev='vda' bus='virtio'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x04' > function='0x0'/> > </disk> > <disk type='file' device='cdrom'> > <driver name='qemu' type='raw'/> > <target dev='hda' bus='ide'/> > <readonly/> > <address type='drive' controller='0' bus='0' target='0' unit='0'/> > </disk> > <disk type='file' device='cdrom'> > <driver name='qemu' type='raw'/> > <target dev='hdb' bus='ide'/> > <readonly/> > <address type='drive' controller='0' bus='0' target='0' unit='1'/> > </disk> > > Log file is not particularly helpful: > > 2014-03-04 22:57:46.121+0000: shutting down > 2014-03-05 23:42:18.528+0000: shutting down > 2014-03-05 23:47:07.375+0000: shutting down > 2014-03-06 00:56:32.908+0000: shutting down > 2014-03-06 01:11:32.582+0000: shutting down > > So, the question is how did this iso got involved in this specific vm? > I can start my other vms without them even knowing about this .iso.This might not be relevant but many moons ago when I would create a vm in this host, I would put the OS install iso in /var/tmp. I did create a freebsd vm there before, but since I built a second vm host (esxi), I moved my testing vms there and kept the production ones in the qemu-based one. The point of this long and irrelevant sappy story is that it seems libvirt remembers that I used that iso before, kinda like what virtualbox does. I know how to make virtuabox forget about an iso/disk or find which vm is using that, but not on libvirt.
Mauricio Tavares
2014-Mar-07 14:28 UTC
Re: [libvirt-users] ISO refuses to let vm starts (and is not mentioned in config)
On Thu, Mar 6, 2014 at 7:59 AM, Mauricio Tavares <raubvogel@gmail.com> wrote:> On Thu, Mar 6, 2014 at 12:16 AM, Mauricio Tavares <raubvogel@gmail.com> wrote: >> Trying to start one of my vms, a centos one at that, but am >> getting the following message: >> >> [root@vmhost ~]# virsh start voip --paused >> error: Failed to start domain voip >> error: cannot open file >> '/var/tmp/FreePBX-5.211.65-3-x86_64-Full-1388073872.iso': No such file >> or directory >> >> [root@vmhost ~]# >> >> But, virsh dumpxml voip shows no info onto the .iso >> >> <disk type='file' device='disk'> >> <driver name='qemu' type='raw' cache='none' io='native'/> >> <source file='/dev/vmhost_vg0/voip'/> >> <target dev='vda' bus='virtio'/> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' >> function='0x0'/> >> </disk> >> <disk type='file' device='cdrom'> >> <driver name='qemu' type='raw'/> >> <target dev='hda' bus='ide'/> >> <readonly/> >> <address type='drive' controller='0' bus='0' target='0' unit='0'/> >> </disk> >> <disk type='file' device='cdrom'> >> <driver name='qemu' type='raw'/> >> <target dev='hdb' bus='ide'/> >> <readonly/> >> <address type='drive' controller='0' bus='0' target='0' unit='1'/> >> </disk> >> >> Log file is not particularly helpful: >> >> 2014-03-04 22:57:46.121+0000: shutting down >> 2014-03-05 23:42:18.528+0000: shutting down >> 2014-03-05 23:47:07.375+0000: shutting down >> 2014-03-06 00:56:32.908+0000: shutting down >> 2014-03-06 01:11:32.582+0000: shutting down >> >> So, the question is how did this iso got involved in this specific vm? >> I can start my other vms without them even knowing about this .iso. > > This might not be relevant but many moons ago when I would > create a vm in this host, I would put the OS install iso in /var/tmp. > I did create a freebsd vm there before, but since I built a second vm > host (esxi), I moved my testing vms there and kept the production ones > in the qemu-based one. The point of this long and irrelevant sappy > story is that it seems libvirt remembers that I used that iso before, > kinda like what virtualbox does. I know how to make virtuabox forget > about an iso/disk or find which vm is using that, but not on libvirt.I *fixed* (not solved because I do not know what caused that) the problem by virsh undefine --managed-save voip and then recreating the vm. Which was not as bad as it sounds because it just meant defining it, telling it to use the old MAC address for the network interface, and making it see the disk. Still I would like to have known what happened...