[virt-tools-list] virt-v2v questions

Kenneth Armstrong digimars at gmail.com
Tue Nov 2 13:26:50 UTC 2010


Would DD work in this instance?

Say I had an external hard drive with device name of /dev/sdc1.  Could
I copy the logical volume to this device?

dd if=/dev/mapper/<GUID of Storage Domain>/<VM disk image which is an
LV> of=/dev/sdc1/vm_disk.img

On Tue, Nov 2, 2010 at 9:19 AM, Kenneth Armstrong <digimars at gmail.com> wrote:
>> virt-v2v doesn't support export from RHEV, only import. However, it doesn't sound like you need V2V here. Once you've
>> exported the VM to an export storage domain, you can simply back up the files in the export storage domain. tar would work > as well as anything else here.
>
> Thanks Matt.  Rich squared me away on not using virt-v2v for this.  My
> current question is how would I copy a logical volume onto an external
> storage unit.  Since it isn't a file on a filesystem, I'm not sure how
> to go about doing this.  I'm also going to research virt-inspector per
> Rich's input on how to give a more reasonable name to the disk images
> that RHEV exports.
>
> Thanks again.
>
>
> On Tue, Nov 2, 2010 at 9:15 AM, Kenneth Armstrong <digimars at gmail.com> wrote:
>>> Not sure what the difference is.  A shut down VM consists of just the
>>> disk image(s) and the hypervisor-specific configuration file.  The
>>> configuration file isn't really necessary, since you could reconstruct
>>> all the information in it (with some effort) by inspecting the disk
>>> image.
>>
>> I'm going to look into virt-inspector (just installed it) to see what
>> that all entails.  Currently, RHEV is still using VDSM and not libvirt
>> explicitly yet, so I can't do an XML dump of a VM as far as I know.
>>
>> How would I go about copying a logical volume off of a remote server
>> through SSH (or some other means)?
>>
>>> This seems like a very RHEV-M-specific question, but AFAIK RHEV-M just
>>> uses qcow2 format files stored in logical volumes.  qcow2 is about as
>>> portable and standard as it comes ("raw" being the only thing that is
>>> more portable and widely supported, and you can convert from qcow2 to
>>> raw with perfect fidelity using 'qemu-img convert').
>>
>> I'm just using RAW for my disk images (for the speed, and I have
>> enough storage to pull it off).
>>
>> Thanks again for your help.
>>
>>
>> On Tue, Nov 2, 2010 at 9:09 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
>>> On Tue, Nov 02, 2010 at 08:51:41AM -0400, Kenneth Armstrong wrote:
>>>> Are you saying just back up the contents of the VM itself or back up
>>>> the VM as a whole?
>>>
>>> Not sure what the difference is.  A shut down VM consists of just the
>>> disk image(s) and the hypervisor-specific configuration file.  The
>>> configuration file isn't really necessary, since you could reconstruct
>>> all the information in it (with some effort) by inspecting the disk
>>> image.
>>>
>>>> I'd like to find a way to just give the VM a
>>>> proper name (I'll look into virt-inspector, thanks for that) and copy
>>>> the logical volumes that make up the VM disks onto an external media.
>>>> Of course, I would have to use something else at a later time to
>>>> import the VM's back into RHEV or a KVM server later should I need to,
>>>> but for now I would like to get them off of my export storage domain
>>>> and store them in a more portable format than what RHEV does.
>>>
>>> This seems like a very RHEV-M-specific question, but AFAIK RHEV-M just
>>> uses qcow2 format files stored in logical volumes.  qcow2 is about as
>>> portable and standard as it comes ("raw" being the only thing that is
>>> more portable and widely supported, and you can convert from qcow2 to
>>> raw with perfect fidelity using 'qemu-img convert').
>>>
>>> Rich.
>>>
>>> --
>>> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>>> New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
>>> programs, test, and build Windows installers. Over 70 libraries supprt'd
>>> http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
>>>
>>
>




More information about the virt-tools-list mailing list