[Users] Successfully virt-v2v from CentOS 6_3 VM to Ovirt 3_2
nightly.eml
Subject:
[Users] Successfully virt-v2v from CentOS 6.3 VM to Ovirt 3.2 nightly
From:
Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
Date:
09/01/13 15:55
To:
users <users(a)ovirt.org>
Hello,
on my oVirt Host configured with F18 and all-in-one and ovirt-nightly as of
ovirt-engine-3.2.0-1.20130107.git1a60fea.fc18.noarch
I was able to import a CentOS 5.8 VM coming from a CentOS 6.3 host.
The oVirt node server is the same where I'm unable to run a newly
created WIndows 7 32bit vm...
See
http://lists.ovirt.org/pipermail/users/2013-January/011390.html
In this thread I would like to report about successful import phases and
some doubts about:
1) no password requested during virt-v2v
2) no connectivity in guest imported.
On CentOS 6.3 host
# virt-v2v -o rhev -osd 10.4.4.59:/EXPORT --network ovirtmgmt c56cr
c56cr_001: 100%
[===================================================================================]D
0h02m17s
virt-v2v: c56cr configured with virtio drivers.
---> I would expect to be asked for the password of a privileged user in
oVirt infra, instead the export process started without any prompt.
Is this correct?
In my opinion in this case it could be a security concern....
virt-v2v doesn't require a password here because it connects directly to
your NFS server. This lack of security is inherent in NFS(*). This is a
limitation you must manage within your oVirt deployment. Ideally you
would treat your NFS network as a SAN and control access to it accordingly.
* There is no truth in the rumour that this stands for No F%*$&"£g
Security ;)
Import process has begun for VM(s): c56cr.
You can check import status in the 'Events' tab of the specific
destination storage domain, or in the main 'Events' tab
---> regarding the import status, the "specific destination storage
domain" would be my DATA domain, correct?
Because I see nothing in it and nothing in export domain.
Instead I correctly see in main events tab of the cluster these two messages
2013-Jan-09, 16:16 Starting to import Vm c56cr to Data Center Poli,
Cluster Poli1
2013-Jan-09, 16:18 Vm c56cr was imported successfully to Data Center
Poli, Cluster Poli1
SO probably the first option should go away....?
I'm afraid I didn't follow this. Which option?
I was then able to power on and connect via vnc to the console.
But I noticed it has no connectivity with its gateway
Host is on vlan 65
(em3 + em3.65 cofigured)
host has
3: em3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master
ovirtmgmt state UP qlen 1000
link/ether 00:1c:c4:ab:3a:dd brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:c4ff:feab:3add/64 scope link
valid_lft forever preferred_lft forever
...
6: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP
link/ether 00:1c:c4:ab:3a:dd brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:c4ff:feab:3add/64 scope link
valid_lft forever preferred_lft forever
7: em3.65@em3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP
link/ether 00:1c:c4:ab:3a:dd brd ff:ff:ff:ff:ff:ff
inet 10.4.4.59/24 <
http://10.4.4.59/24> brd 10.4.4.255 scope global
em3.65
inet6 fe80::21c:c4ff:feab:3add/64 scope link
valid_lft forever preferred_lft forever
...
13: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master ovirtmgmt state UNKNOWN qlen 500
link/ether fe:54:00:d3:8f:a3 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fed3:8fa3/64 scope link
valid_lft forever preferred_lft forever
[g.cecchi@f18aio ~]$ ip route list
default via 10.4.4.250 dev em3.65
10.4.4.0/24 <
http://10.4.4.0/24> dev em3.65 proto kernel scope link
src 10.4.4.59
ovirtmgmt is tagged in datacenter Poli1
guest is originally configured (and it maintained this) on bridged
vlan65 on CentOS 63 host. Its parameters
eth0 with
ip 10.4.4.53 and gw 10.4.4.250
from webadmin pov it seems ok. see also this screenshot
https://docs.google.com/open?id=0BwoPbcrMv8mvbENvR242VFJ2M1k
any help will be appreciated.
do I have to enable some kind of routing not enabled by default..?
virt-v2v doesn't update IP configuration in the guest. This means that
the target guest must be on the same ethernet segment as the source, or
it will have to be manually reconfigured after conversion.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490