[Users] Can I move local_cluster in all-in-one setup?
Gianluca Cecchi
gianluca.cecchi at gmail.com
Wed Jan 9 18:41:28 EST 2013
On Wed, Jan 9, 2013 at 5:22 PM, René Koch (ovido) wrote:
> I hope this will help you with oVirt.
> Maybe you should cleanup your all-in-one setup and recreate it using the
> above steps.
>
I think substantially I made your steps.
I take another test.
The host comes with also another adapter (em4) that is on vlan66
This is unconfigured in oVirt.
Then I create a new vlan named vlan66 with target vm
Then I run another virt-v2v of a vm named zensrv that is on vlan 66 from
qemu on CentOS 6.3 to oVirt
# time virt-v2v -o rhev -osd 10.4.4.59:/EXPORT --network vlan66 zensrv
zensrv_002: 100%
[================================================================================]D
0h02m22s
virt-v2v: WARNING: /etc/fstab references unknown device /dev/vda2. This
entry must be manually fixed after conversion.
virt-v2v: WARNING: /etc/fstab references unknown device /dev/vda1. This
entry must be manually fixed after conversion.
virt-v2v: WARNING: /boot/grub/device.map references unknown device
/dev/vda. This entry must be manually fixed after conversion.
virt-v2v: zensrv configured with virtio drivers.
real 3m16.051s
user 0m58.953s
sys 0m46.729s
NOTE: actually the disk in oVirt after import is marked as VirtIO (as it
was on source) and boots without any problem....
Well, this vm is perfectly configured in its vlan and reachable as it was
on its original host.
After configuring this new vlan on host, this is the situation
[g.cecchi at f18aio ~]$ ip addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen
1000
link/ether 00:1e:0b:21:b8:c4 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21e:bff:fe21:b8c4/64 scope link
valid_lft forever preferred_lft forever
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
4: em2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen
1000
link/ether 00:1e:0b:21:b8:c6 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21e:bff:fe21:b8c6/64 scope link
valid_lft forever preferred_lft forever
5: em4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen
1000
link/ether 00:1c:c4:ab:3a:de brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:c4ff:feab:3ade/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 brd 10.4.4.255 scope global em3.65
inet6 fe80::21c:c4ff:feab:3add/64 scope link
valid_lft forever preferred_lft forever
10: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
link/ether ea:e8:c9:57:87:fb brd ff:ff:ff:ff:ff:ff
11: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
12: bond4: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
14: 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
15: em4.66 at em4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
master vlan66 state UP
link/ether 00:1c:c4:ab:3a:de brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:c4ff:feab:3ade/64 scope link
valid_lft forever preferred_lft forever
16: vlan66: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP
link/ether 00:1c:c4:ab:3a:de brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:c4ff:feab:3ade/64 scope link
valid_lft forever preferred_lft forever
17: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master vlan66 state UNKNOWN qlen 500
link/ether fe:54:00:43:d9:df brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe43:d9df/64 scope link
valid_lft forever preferred_lft forever
and, from a bridge point of view
[g.cecchi at f18aio ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
;vdsmdummy; 8000.000000000000 no
ovirtmgmt 8000.001cc4ab3add no em3
vnet0
vlan66 8000.001cc4ab3ade no em4.66
vnet1
vnet0 is interface of c56cr that shoud be in vlan65
vnet1 is interface of zensrv that is correctly on vlan66
Please note that while on ovirtmgmt bridge there is em3 as physical
interface, on vlan66 there is em3... while I think it should be em3.65
Also, I noticed in similar configurations in Qemu+KVM on CentOS, that the
ip (10.4.4.59 in my case) should be on the bridge, if present.
So in my situation it should be on ovirtmgmt, while it is on em3.65.....
I could tweak configuration files in /etc/sysconf/network-scripts. Now they
are this way
ovirtmgmt/vlan65
[g.cecchi at f18aio network-scripts]$ cat ifcfg-em3.65
DEVICE=em3.65
ONBOOT=yes
VLAN=yes
NM_CONTROLLED=no
VLAN_ID=65
BOOTPROTO=none
IPADDR=10.4.4.59
NETMASK=255.255.255.0
GATEWAY=10.4.4.250
IPV6INIT=no
[g.cecchi at f18aio network-scripts]$ cat ifcfg-ovirtmgmt
DEVICE=ovirtmgmt
ONBOOT=yes
TYPE=Bridge
DELAY=0
NM_CONTROLLED=no
STP=no
vlan66
[g.cecchi at f18aio network-scripts]$ cat ifcfg-em4.66
DEVICE=em4.66
ONBOOT=yes
VLAN=yes
BRIDGE=vlan66
NM_CONTROLLED=no
STP=no
[g.cecchi at f18aio network-scripts]$ cat ifcfg-vlan66
DEVICE=vlan66
ONBOOT=yes
TYPE=Bridge
DELAY=0
NM_CONTROLLED=no
STP=no
My idea would be to modify the ovirtmgmt ones this way and reboot:
[g.cecchi at f18aio network-scripts]$ cat ifcfg-em3.65
DEVICE=em3.65
ONBOOT=yes
VLAN=yes
NM_CONTROLLED=no
BRIDGE=ovirtmgmt
STP=no
[g.cecchi at f18aio network-scripts]$ cat ifcfg-ovirtmgmt
DEVICE=ovirtmgmt
ONBOOT=yes
TYPE=Bridge
DELAY=0
NM_CONTROLLED=no
STP=no
IPADDR=10.4.4.59
NETMASK=255.255.255.0
GATEWAY=10.4.4.250
I don't know it there is any other initialization information in DB that
can cause problems....
Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20130110/5d6494aa/attachment.html>
More information about the Users
mailing list