[Users] Fwd: Successfully virt-v2v from CentOS 6.3 VM to Ovirt 3.2 nightly

Matthew Booth mbooth at redhat.com
Mon Jan 14 10:55:27 UTC 2013


> [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 at gmail.com>
> Date:
> 09/01/13 15:55
> 
> To:
> users <users at 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 at 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 at 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



More information about the Users mailing list