yes, the VM looks fine... to investigate this further I'd need the
full log vdsm log with error, please share it
On Wed, Dec 9, 2020 at 3:01 PM Joseph Goldman wrote:
>
> Attached XML dump.
>
> Looks like its let me run a 'reboot' but im afraid to do a shutdown at
> this point.
>
> I have taken
Attached XML dump.
Looks like its let me run a 'reboot' but im afraid to do a shutdown at
this point.
I have taken just a raw copy of the whole image group folder in the hope
if worse came to worse I'd be able to recreate the disk with the actual
files.
All existing files seem to be
The VM is running, right?
Can you run:
$ virsh -r dumpxml
On Wed, Dec 9, 2020 at 2:01 PM Joseph Goldman wrote:
>
> Looks like the physical files dont exist:
>
> 2020-12-09 22:01:00,122+1000 INFO (jsonrpc/4) [api.virt] START
> merge(drive={u'imageID': u'23710238-07c2-46f3-96c0-9061fe1c3e0d',
>
On top of this, looks like this redhat article may have the solution but
I cant access it, any help someone?
https://access.redhat.com/solutions/2852341
Thanks.
On 9/12/2020 10:51 pm, Joseph Goldman wrote:
This looks to be the problem:
2020-12-09 22:01:00,122+1000 INFO (jsonrpc/4)
Looks like the physical files dont exist:
2020-12-09 22:01:00,122+1000 INFO (jsonrpc/4) [api.virt] START
merge(drive={u'imageID': u'23710238-07c2-46f3-96c0-9061fe1c3e0d',
u'volumeID': u'4b6f7ca1-b70d-4893-b473-d8d30138bb6b', u'domainID':
u'74c06ce1-94e6-4064-9d7d-69e1d956645b', u'poolID':
On 12/8/20 5:30 AM, Magnus Isaksson wrote:
Hi
We have the same issue as you, and we are also using vProtect.
I have no solution, but I'm very interested in how to address this.
Some VM:s we do have managed to remove the illegal snapshots after changing
storage for the VM:s disks, but we have
>[root@ov-engine ~]# tail -f /var/log/ovirt-engine/engine.log | grep ERROR
grepping error is ok, but it does not show the reason for the failure,
which will probably be on the vdsm host (you can use flow_id
9b2283fe-37cc-436c-89df-37c81abcb2e1 to find the correct file
Need to see the underlying
On 8/12/2020 10:55 pm, Benny Zlotnik wrote:
Do you know why your snapshot creation failed? Do you have logs with the error?
Here is the log (grepped for ERROR only to keep it a bit less verbose):
[root@ov-engine ~]# tail -f /var/log/ovirt-engine/engine.log | grep ERROR
2020-12-08
Do you know why your snapshot creation failed? Do you have logs with the error?
On paper the situation does not look too bad, as the only discrepancy
between the database and vdsm is the status of the image, and since
it's legal on vdsm, changing it legal in database should work (image
status 1)
Hi
We have the same issue as you, and we are also using vProtect.
I have no solution, but I'm very interested in how to address this.
Some VM:s we do have managed to remove the illegal snapshots after changing
storage for the VM:s disks, but we have 3-4 VM:s that will not want to remove
the
10 matches
Mail list logo
