<div dir="ltr">The move command will first create the disk structure according to the snapshots on the destination , then a 'qemui-mg convert' will be performed for each snapshot.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 12, 2017 at 1:31 AM, Gianluca Cecchi <span dir="ltr"><<a href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 11, 2017 at 3:14 PM, Gianluca Cecchi <span dir="ltr"><<a href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="m_-3774471911594045803h5"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 11, 2017 at 2:59 PM, Gianluca Cecchi <span dir="ltr"><<a href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div>I have a source oVirt environment with storage domain on FC</div><div>I have a destination oVirt environment with storage domain on iSCSI</div><div>The two environments can communicate only via the network of their respective hypervisors.</div><div>The source environment, in particular, is almost isolated and I cannot attach an export domain to it or something similar.</div><div>So I'm going to plan a direct move through dd of the disks of some VMs</div><div><br></div><div>The workflow would be</div><div>On destination create a new VM with same config and same number of disks of the same size of corresponding source ones.</div><div>Also I think same allocation policy (thin provision vs preallocated)</div><div>Using lvs -o+lv_tags I can detect the names of my origin and destination LVs, corresponding to the disks</div><div>When a VM is powered down, the LV that maps the disk will be not open, so I have to force its activation (both on source and on destination)</div><div><br></div><div>lvchange --config 'global {use_lvmetad=0}' -ay vgname/lvname<br></div><div><br></div><div>copy source disk with dd through network (I use gzip to limit network usage basically...)</div><div>on src_host:</div><div>dd if=/dev/src_vg/src_lv bs=1024k | gzip | ssh dest_host "gunzip | dd bs=1024k of=/dev/dest_vg/dest_lv"<br></div><div><br></div><div>deactivate LVs on source and dest</div><div><br></div><div>lvchange --config 'global {use_lvmetad=0}' -an vgname/lvname<br></div><div><br></div><div>Try to power on the VM on destination</div><div><br></div><div>Some questions:</div><div>- about overall workflow</div><div>- about dd flags, in particular if source disks are thin vs preallocated</div><div><br></div><div>Thanks,</div><div>Gianluca</div><div><br></div></div>
</blockquote></div><br></div><div class="gmail_extra"><br></div></div></div><div class="gmail_extra">Some further comments:</div><div class="gmail_extra"><br></div><div class="gmail_extra">- probably better/safe to use SPM hosts for lvchange commands both on source and target, as this imply metadata manipulation, correct?</div><div class="gmail_extra">- when disks are preallocated, no problems, but when they are thin, I can be in this situation</div><div class="gmail_extra"><br></div><div class="gmail_extra">source disk defined as 90Gb disk and during time it has expanded up to 50Gb</div><div class="gmail_extra">dest disk at the beginning just after creation will normally be of few GB (eg 4Gb), so the dd command will fail when fulll...</div><div class="gmail_extra">Does this mean that it will be better to create dest disk as preallocated anyway or is it safe to run </div><div class="gmail_extra">lvextend -L+50G dest_vg/dest_lv</div><div class="gmail_extra">from command line?</div><div class="gmail_extra">Will oVirt recognize its actual size or what?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>
</blockquote></div><br></div></div></div><div class="gmail_extra">So I've done, both for thin provisioned (without having done snapshot on them, see below) and preallocated disks, and it seems to work, at least booting an OS boot disk copied over this way.<br><br></div><div class="gmail_extra">I have one further doubt.<br><br></div><div class="gmail_extra">For a VM I have a disk defined as thin provisioned and 90Gb in size.<br></div><div class="gmail_extra">Some weeks ago I created a snapshot for it.<br></div><div class="gmail_extra">Now, before copying over the LV, I have delete this snapshot.<br></div><div class="gmail_extra">But I see that at the end of the process, the size of the LV backing the VM disk is now actually 92Gb, so I presume that my dd over network will fail....<br></div><div class="gmail_extra">What could I do to cover this scenario?<br><br></div><div class="gmail_extra">What would be the command at os level in case I choose "move disk" in web admin gui to move a disk from a SD to another one?<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,<br></div><div class="gmail_extra">Gianluca <br></div></div>
<br>______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>