[ovirt-users] disk not bootable

[Nir Soffer]

On Thu, Jul 7, 2016 at 7:46 PM, Melissa Mesler <melissa at justmelly.com> wrote:
> All, I did a test for Fernando in our ovirt environment. I created a vm
> called win7melly in the nfs domain. I then migrated it to the iscsi
> domain. It booted without any issue. So it has to be something with the
> templates. I have attached the vdsm log for the host the vm resides on.

The log show a working vm, so it does not help much.

I think that the template you copied from the nfs domain to the block domain is
corrupted, or the volume metadata are incorrect.

If I understand this correctly, this started when Fernando could not copy the vm
disk to the block storage, and I guess the issue was that the template
was missing
on that storage domain. I assume that he copied the template to the
block storage
domain by opening the templates tab, selecting the template, and choosing copy
from the menu.

Lets compare the template on both nfs and block storage domain.

1. Find the template on the nfs storage domain, using the image uuid in engine.

It should be at

    /rhev/data-center/mnt/server:_path/domain-uuid/images/image-uuid/volume-uuid

2. Please share the output of:

    cat /path/to/volume.meta
    qemu-img info /path/to/volume
    qemu-img check /path/to/volume

4. Find the template on the block storage domain

You should have an lv using the same volume uuid and the image-uuid
should be in the lv tag.

Find it using:

    lvs -o vg_name,lv_name,tags | grep volume-uuid

5. Activate the lv

    lvchange -ay vg_name/lv_name

6. Share the output of

    qemu-img info /dev/vg_name/lv_name
    qemu-img check /dev/vg_name/lv_name

7. Deactivate the lv

    lvchange -an vg_name/lv_name

8. Find the lv metadata

The metadata is stored in /dev/vg_name/metadata. To find the correct block,
find the tag named MD_N in the lv tags you found in step 4

The block we need is located at offset N from start of volume.

9. Share the output of:

    dd if=/dev/vg_name/metadata bs=512 skip=N count=1 iflag=direct

The output of this command should show the image-uuid.

Nir

>
> - MeLLy
>
> On Mon, Jul 4, 2016, at 11:52 PM, Fernando Fuentes wrote:
>> Nir,
>>
>> That's exactly how I did it Nir.
>> I will test tomorrow with a new Windows VM and report back.
>>
>> Regards,
>>
>> --
>> Fernando Fuentes
>> ffuentes at txweather.org
>> http://www.txweather.org
>>
>> On Mon, Jul 4, 2016, at 10:48 AM, Nir Soffer wrote:
>> > On Mon, Jul 4, 2016 at 6:43 PM, Francesco Romani <fromani at redhat.com>
>> > wrote:
>> > > ----- Original Message -----
>> > >> From: "Nir Soffer" <nsoffer at redhat.com>
>> > >> To: "Fernando Fuentes" <ffuentes at darktcp.net>
>> > >> Cc: "Francesco Romani" <fromani at redhat.com>, "users" <users at ovirt.org>
>> > >> Sent: Saturday, July 2, 2016 11:18:01 AM
>> > >> Subject: Re: [ovirt-users] disk not bootable
>> > >>
>> > >> On Sat, Jul 2, 2016 at 1:33 AM, Fernando Fuentes <ffuentes at darktcp.net>
>> > >> wrote:
>> > >> > Nir,
>> > >> >
>> > >> > Ok I ran another test and this one I moved from NFS domain to iSCSI and
>> > >> > stop working than I moved it back and still unable to run... Windows VM
>> > >> > is saying "no available boot disk"
>> > >> > VM: Win7-Test
>> > >> > Host: Zeta
>> > >> > Info as requested:  http://pastebin.com/1fSi3auz
>> > >>
>> > >> We need a working xml to compare to.
>> > >
>> > > [snip expected changes]
>> > >
>> > >
>> > >>   <entry name="manufacturer">oVirt</entry>
>> > >>   <entry name="product">oVirt Node</entry>
>> > >>   <entry name="version">6-5.el6.centos.11.2</entry>
>> > >> - <entry name="serial">C938F077-55E2-3E50-A694-9FCB7661FD89</entry>
>> > >> + <entry name="serial">735C7A01-1F16-3CF0-AF8C-A99823E95AC0</entry>
>> > >>
>> > >> Not expected - maybe this is confusing windows?
>> > >>
>> > >> Francesco, why vm serial has changed after moving disks from one storage
>> > >> domain
>> > >> to another?
>> > >
>> > > We put in serial either
>> > > 1. the UUID Engine send to us
>> > > 2. the host UUID as returned by our getHostUUID utility function
>> > >
>> > > the latter is unlikely to change, even after this disk move.
>> >
>> > Fernando, can you describe exactly how you moved the disk?
>> >
>> > I assume that you selected the vm in the virtual machines tab, then
>> > selected
>> > disks from the sub tab, then selected move, and selected the target
>> > storage domain.
>> >
>> > Also, can you reproduce this with a new vm? (create vm with disk nfs,
>> > stop vm,
>> > move disk to iscsi, start vm).
>> >
>> > > So the first suspect in line is Engine
>> > >
>> > > Arik, do you know if Engine is indeed supposed to change the UUID in this flow?
>> > > That seems very surprising.
>> > >
>> > > Thanks and bests,
>> > >
>> > > --
>> > > Francesco Romani
>> > > RedHat Engineering Virtualization R & D
>> > > Phone: 8261328
>> > > IRC: fromani
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>