On Sat, Jul 2, 2016 at 1:33 AM, Fernando Fuentes <ffuentes@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.
Now here is an example of one that I migrated from the NFS domain to the iscsi domain and stop working: VM: Win7-QA5 Host: Alpha Info as requested: http://pastebin.com/BXqLFqZt
The same VM I moved it back to the NFS domain and boot it just fine: VM: Win7-QA5 Host: Zeta Info as requested: http://pastebin.com/7BA97CsC
Diffing both xmls show: $ diff -u win-qa5-iscsi.txt win-qa5-nfs.txt --- win-qa5-iscsi.txt 2016-07-02 12:10:17.094202558 +0300 +++ win-qa5-nfs.txt 2016-07-02 12:11:06.729375231 +0300 @@ -60,13 +60,13 @@ <readonly/> <serial/> </disk> - <disk device="disk" snapshot="no" type="block"> + <disk device="disk" snapshot="no" type="file"> Expected, one vm is using block based disk and the other file based disk <address bus="0x00" domain="0x0000" function="0x0" slot="0x06" type="pci"/> - <source dev="/rhev/data-center/mnt/blockSD/4861322b-352f-41c6-890a-5cbf1c2c1f01/images/25ebd3ac-fe5a-4cbb-9f71-c6b4325231d8/763a9a47-6b29-420a-83c9-c8a887bd15df"/> + <source file="/rhev/data-center/mnt/172.30.10.5:_opt_libvirtd_images/ecfaf7ac-5459-4c83-bd97-2bb448e38526/images/25ebd3ac-fe5a-4cbb-9f71-c6b4325231d8/763a9a47-6b29-420a-83c9-c8a887bd15df"/> Expected, file and block disks are mounted on different paths <target bus="virtio" dev="vda"/> <serial>25ebd3ac-fe5a-4cbb-9f71-c6b4325231d8</serial> <boot order="1"/> - <driver cache="none" error_policy="stop" io="native" name="qemu" type="qcow2"/> + <driver cache="none" error_policy="stop" io="threads" name="qemu" type="qcow2"/> Expected, we use different io for file and block </disk> </devices> <os> @@ -78,7 +78,7 @@ <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? <entry name="uuid">46e6d52c-2567-4f23-9a07-66f64990663a</entry> </system> </sysinfo>
-- Fernando Fuentes ffuentes@txweather.org http://www.txweather.org
On Fri, Jul 1, 2016, at 03:22 PM, Nir Soffer wrote:
Fernando,
These logs do not contain the libvirt xml.
I want to see the part that start like this:
Thread-17656::INFO::2016-07-01 23:17:33,845::vm::2032::virt.vm::(_run) vmId=`f66da2b0-0f71-490b-a57e-eceb9be9cade`::<?xml version="1.0" encoding="utf-8"?> <domain type="kvm" xmlns:ovirt="http://ovirt.org/vm/tune/1.0"> <name>test-iscsi</name> <uuid>f66da2b0-0f71-490b-a57e-eceb9be9cade</uuid> ...
The most important part is the devices sections showing the disks:
<disk device="disk" snapshot="no" type="block"> <address bus="0" controller="0" target="0" type="drive" unit="0"/> <source dev="/rhev/data-center/f9374c0e-ae24-4bc1-a596-f61d5f05bc5f/5f35b5c0-17d7-4475-9125-e97f1cdb06f9/images/8f61b697-b3e4-4f63-8951-bdf9b6b39192/f409cc48-8248-4239-a4ea-66b0b1084416"/> <target bus="scsi" dev="sda"/> <serial>8f61b697-b3e4-4f63-8951-bdf9b6b39192</serial> <boot order="1"/> <driver cache="none" error_policy="stop" io="native" name="qemu" type="qcow2"/> </disk>
Please try to find the logs (probably already rotated to vdsm.log.N.xz) containing the xml for this vm when running on nfs and iscsi.
Nir
On Fri, Jul 1, 2016 at 10:31 PM, Fernando Fuentes <ffuentes@darktcp.net> wrote:
Nir.
Thank you for your reply.
Attached is the vdsm log of the hosts that power on the vm in this example.
VM name is Win7-QA5 vdsm_alpha.log was the host that started the VM when it got transfer to the iscsi domain. vdsm_zeta.log was the host that started the VM when it got transfer back to the nfs domain.
I included everything for trouble shooting purposes.
Also here is the engine log that talks about it as well: http://pastebin.com/3cHBNMcg
Hope this helps.
Regards, -- Fernando Fuentes ffuentes@txweather.org http://www.txweather.org
On Fri, Jul 1, 2016, at 01:58 PM, Nir Soffer wrote:
On Fri, Jul 1, 2016 at 7:58 PM, Fernando Fuentes <ffuentes@darktcp.net> wrote:
Pavel,
Thanks for your reply, But thats not the problem The disk is active and is set with to bootable. The problem presents it self only if I move Windows VM DIsks. All my Linux VM Disk's move across storage domains just fine.
As a matter of fact I moved the disk back to the original nfs domain and it started working. Could this be a bug?
Can you share the vdsm log showing startup of the vm when the disk is on on nfs storage domain (vm starts) and iscsi storage domain (vm fail)?
The most interesting part in the logs is the libvirt xml describing the vm.
Nir
Regards,
-- Fernando Fuentes ffuentes@txweather.org http://www.txweather.org
On Fri, Jul 1, 2016, at 11:33 AM, Pavel Gashev wrote:
Fernando,
One from VM disks have to have bootable flag. See http://www.ovirt.org/images/wiki/Add_Virtual_Disk.png?1454370862
On 01/07/16 19:09, "users-bounces@ovirt.org on behalf of Fernando Fuentes" <users-bounces@ovirt.org on behalf of ffuentes@darktcp.net> wrote:
Team,
After I successfully copy my template from one storage to another I was able to move my VM disks from my nfs domain to my iscsi domain. My linux vms which are basic template (No template) moved just fine and boot just fine. On the other hand my windows vms (Template) once moved they cant boot. Complaining that there is no bootable disk available. What is going on?
oVirt 3.6.6 Hosts Centos 6.6 x86_64 iSCSI Domain on TrueNAS Attached via ovirt.
-- Fernando Fuentes ffuentes@txweather.org http://www.txweather.org _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users