Re: [ovirt-users] disk not bootable

Nir, I try to follow your steps but I cant seem to find the ID of the template.

Regards, -- Fernando Fuentes ffuentes(a)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(a)justmelly.com&gt; > 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(a)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(a)redhat.com&gt; > >> > wrote: > >> > > ----- Original Message ----- > >> > >> From: "Nir Soffer" <nsoffer(a)redhat.com&gt; > >> > >> To: "Fernando Fuentes" <ffuentes(a)darktcp.net&gt; > >> > >> Cc: "Francesco Romani" <fromani(a)redhat.com&gt;, "users" <users(a)ovirt.org&gt; > >> > >> 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(a)darktcp.net&gt; > >> > >> 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(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/users > > > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > >