7:10 p.m.
This is a multi-part message in MIME format.
--------------000403020406090108090604
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Allon,
We are on the same track, since the additional steps I mentioned are
only for reducing downtime (big backing chain images should be copied
while VMs are still running and writing to a small active snapshot that
would be copied at the end).
I'm basically reattaching an existing storage domain (with VM and
OVF_STORE disks) on another ovirt installation, but doing a copy of the
storage domain, instead of detaching it from the source data center.
Benefit for oVirt : Live export/import
The problem is that something is missing, since the VMs are not
displayed when I attach and activate the cloned storage domain on the
destination data center.
Maybe the detach process does something that is required to show the VMs
later. Again, I'm not doing a detach, but cloning the storage domain
with active VMs.
I saw in the logs that oVirt is getting the OVF files from a tar file.
Start fetching OVF files from tar file
File 'info.json' is not an OVF file, will be ignored.
Finish to fetch OVF files from tar file. The number of OVF entities
are 0
_*Maybe this tar file is written by the detach process? What else could
be missing?*_
I reported and shared the logs here:
https://bugzilla.redhat.com/show_bug.cgi?id=1234137
On 21-06-2015 12:04, Allon Mureinik wrote:
Another way, if you have a domain to spare, would be to detach the
domain containing the VM and attaching it to another setup.
Otherwise, you're limited to either an export domain (which requires copying twice,
as you mentioned), or some manual procedure like you suggested.
----- Original Message -----
> From: "Christopher Pereira" <kripper(a)imatronix.cl>
> To: devel(a)ovirt.org
> Sent: Saturday, June 20, 2015 2:48:20 AM
> Subject: [ovirt-devel] Live export/import
>
> Hi,
>
> I would like to migrate a VM between two different ovirt installations with
> minimum down time.
>
> Using a export domain is slow (requires copying twice) and requires to stop
> the VM.
>
> It seems like the best option is to 1) create a snapshot, 2) transfer the
> backing chain images and OVF files to the destination storage domain 3) stop
> the VM, 4) transfer the active snapshot and 5) import the VM from the
> destination storage domain.
>
> Can you please comment and suggest other alternatives?
>
> Thanks.
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
--------------000403020406090108090604
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Allon,<br>
<br>
We are on the same track, since the additional steps I mentioned are
only for reducing downtime (big backing chain images should be
copied while VMs are still running and writing to a small active
snapshot that would be copied at the end).<br>
<br>
I'm basically reattaching an existing storage domain (with VM and
OVF_STORE disks) on another ovirt installation, but doing a copy of
the storage domain, instead of detaching it from the source data
center.<br>
<br>
Benefit for oVirt : Live export/import<br>
<br>
The problem is that something is missing, since the VMs are not
displayed when I attach and activate the cloned storage domain on
the destination data center.<br>
Maybe the detach process does something that is required to show the
VMs later. Again, I'm not doing a detach, but cloning the storage
domain with active VMs.<br>
I saw in the logs that oVirt is getting the OVF files from a tar
file.<br>
<br>
Start fetching OVF files from tar file<br>
File 'info.json' is not an OVF file, will be ignored.<br>
Finish to fetch OVF files from tar file. The number of OVF
entities are 0<br>
<br>
<u><b>Maybe this tar file is written by the detach process? What
else could be missing?</b></u><br>
<br>
I reported and shared the logs here:<br>
<a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=1234137">h...
<br>
<div class="moz-signature">
<style>
.signature, .small-signature {
font-family:"Calibri","sans-serif";mso-fareast-font-family:"Times
New Roman";
color:#7F7F7F;
}
.signature {
font-size:10pt;
}
.small-signature {
font-size:8pt;
}</style></div>
<div class="moz-cite-prefix">On 21-06-2015 12:04, Allon Mureinik
wrote:<br>
</div>
<blockquote
cite="mid:47710768.5569550.1434899054757.JavaMail.zimbra@redhat.com"
type="cite">
<pre wrap="">Another way, if you have a domain to spare, would be to
detach the domain containing the VM and attaching it to another setup.
Otherwise, you're limited to either an export domain (which requires copying twice, as
you mentioned), or some manual procedure like you suggested.
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">From: "Christopher Pereira" <a
class="moz-txt-link-rfc2396E"
href="mailto:kripper@imatronix.cl"><kripper@imatronix.cl></a>
To: <a class="moz-txt-link-abbreviated"
href="mailto:devel@ovirt.org">devel@ovirt.org</a>
Sent: Saturday, June 20, 2015 2:48:20 AM
Subject: [ovirt-devel] Live export/import
Hi,
I would like to migrate a VM between two different ovirt installations with
minimum down time.
Using a export domain is slow (requires copying twice) and requires to stop
the VM.
It seems like the best option is to 1) create a snapshot, 2) transfer the
backing chain images and OVF files to the destination storage domain 3) stop
the VM, 4) transfer the active snapshot and 5) import the VM from the
destination storage domain.
Can you please comment and suggest other alternatives?
Thanks.
_______________________________________________
Devel mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Devel@ovirt.org">Devel@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/devel">http://...
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>
--------------000403020406090108090604--