[ovirt-users] disk not bootable

Mon Jul 11 02:56:06 UTC 2016

Nir,

I am on it and will reply with the requested info asap.

Regards,

-- 
Fernando Fuentes
ffuentes at txweather.org
http://www.txweather.org

On Sun, Jul 10, 2016, at 02:15 PM, Nir Soffer wrote:
> 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
> >