Thanks for posting that Andrew. I had the same problem removing disks from a Gluster volume (disk state changed to Illegal and the actual disk file was not removed from the volume) and your method worked fine for me. Cheers, Chris Message: 3 Date: Thu, 26 Sep 2013 12:53:04 +1000 From: Andrew Lau <andrew@andrewklau.com> To: Dan Ferris <dferris@prometheusresearch.com> Cc: "Users@ovirt.org" <Users@ovirt.org> Subject: Re: [Users] Disk state - Illegal? Message-ID: <CAD7dF9droPuPGxqjM-9aTyE7_qLLhDnYxLLVVB_FtWQdkH0srw@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" I noticed that too, I wasn't sure if it was a bug or just how I had setup my NFS share.. There were three steps I did to remove the disk images, I'm sure there's a 100% easier solution..: I found the easiest way (graphically) was go to your https://ovirtengine/api/disks and so a search for the illegal disk. Append the extra ID eg. <disk href="/api/disks/lk342-dfsdf... into your URL this'll give you your image ID. Go to your storage share: cd /data/storage-id/master/vms/storage-id grep -ir 'vmname' * You'll find the image-id reference here too. Then the image you will want to remove is in the /data/storage-id/images/image-id I assume you could safely remove this whole folder if you wanted to delete the disk. To remove the illegal state I did it through the API so again with the URL above https://ovirtengine/disks/disk-id send a DELETE using HTTP/CURL Again, this was a poor mans solution but it worked for me. On Thu, Sep 26, 2013 at 4:04 AM, Dan Ferris <dferris@prometheusresearch.com>wrote:

Hi,

I have another hopefully simple question.

One VM that I am trying to remove says that it's disk state is "illegal" and when I try to remove the disk it says that it failed to initiate the removing of the disk.

Is there an easy way to get rid of these illegal disk images?

Dan

PLEASE CONSIDER THE ENVIRONMENT, DON'T PRINT THIS EMAIL UNLESS YOU REALLY NEED TO. This email and its attachments may contain information which is confidential and/or legally privileged. If you are not the intended recipient of this e-mail please notify the sender immediately by e-mail and delete this e-mail and its attachments from your computer and IT systems. You must not copy, re-transmit, use or disclose (other than to the sender) the existence or contents of this email or its attachments or permit anyone else to do so. ----------------------------- ______________________________**_________________

Users mailing list Users@ovirt.org http://lists.ovirt.org/**mailman/listinfo/users<http://lists.ovirt.org /mailman/listinfo/users>

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ovirt.org/pipermail/users/attachments/20130926/7b7ac24b/attachment-0001.html> ------------------------------ Message: 4 Date: Thu, 26 Sep 2013 08:35:07 +0100 From: "Richard W.M. Jones" <rjones@redhat.com> To: "emitor@gmail.com" <emitor@gmail.com> Cc: users@ovirt.org Subject: Re: [Users] importing VM from ESXI Message-ID: <20130926073507.GE1887@redhat.com> Content-Type: text/plain; charset=us-ascii On Wed, Sep 25, 2013 at 06:10:00PM -0300, emitor@gmail.com wrote:

could not open disk image /tmp/KxIoJI50Pc/2872ac3e-7340-4dfa-9801-0a1bd052b3a3/v2v._ApSlRZG/387a5113-bbc2-45a2-9c55-5dc3dade31a9/01c899de-131e-4407-a16c-8c5484ccb8bd: Permission denied

The error comes from qemu and indicates qemu cannot open this temporary disk image. I've no idea why it cannot open it, but possibilities include: SELinux, file permissions (eg on /tmp), setting of TMPDIR, relative path to a backing file, and more ... I'd suggest that you 'strace -f' the whole set of processes to see what precise system call fails. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) ------------------------------ _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users End of Users Digest, Vol 24, Issue 140 **************************************