vmx setup guide for network engineer
DESCRIPTION
VMX Setup Guide for Network EngineerTRANSCRIPT
vMX setup guide for
Network Engineerwho use “request system power-off” instead of “shutdown –h now”
June, 2014
Version Description1.0 Initial release on June, 2014
1 | P a g e
ContentsAbout this document...................................................................................................................................4
Building the KVM Linux host........................................................................................................................5
Prepare the hardware.............................................................................................................................5
Install Linux base OS................................................................................................................................5
Prepare CentOS Linux and install KVM....................................................................................................8
Basic configuration & Operation of KVM...................................................................................................12
Administrate KVM via Virsh commands................................................................................................12
vMX Virtual Machine XML configuration...............................................................................................13
Virtual Network XML configuration.......................................................................................................19
Basic configuration & Operation of vMX...................................................................................................24
Interface Configuration.........................................................................................................................24
Upgrade vMX JUNOS version.................................................................................................................25
Some more advanced tasks.......................................................................................................................26
Blind VLAN tag interface into vMX........................................................................................................26
Attach windows client into testing network..........................................................................................30
Example: Create a 4 PE node eVPN network inside a single physical server.............................................35
Network Diagram..................................................................................................................................35
Virtual Machine and Virtual Network XML............................................................................................37
vMX Configuration.................................................................................................................................38
Running vMX over VirtualBox Hypervisor..................................................................................................39
Assumption & Background....................................................................................................................39
Convert vMX image to VirtualBox format..............................................................................................39
Load the vMX in VirtualBox...................................................................................................................39
JUNOS configuration in vMX..................................................................................................................47
Other hints............................................................................................................................................47
2 | P a g e
JUNOS firmware upgrade..................................................................................................................47
Additional NIC card in vMX................................................................................................................48
VLAN tagging.....................................................................................................................................48
Duplicate disk image/duplicated UUID issue.....................................................................................48
3 | P a g e
About this document
vMX is a solution to run a complete MX (including control and forwarding plane) in software environment.
Starting from JUNOS 14.1, vMX will be available on every JUNOS release. In 14.1, the vMX is in phase 1 format which basically try to emulate MX80 (single ASIC, single RE). In phase 2 of vMX, multiple line card & RE support will be added to try to emulate more complex product like MX480. However, even for MX80 emulation alone, the vMX come with complete control and forwarding plane to make it ideal for solution testing. SE no longer need to have multiple MX on hand for feature testing or run multipe logical system in a physical box and do those hair pin patching. All they need is a PC with modern CPU and enough memory.
Unfortunately, the vMX is designed to run over KVM platform. There are some document in Matrix talk about using vMX but most of them are not written for network engieer who do not have background on KVM. As a result, I create this document to fill-up the blank for network engieer without prior KVM knowledge. So that they can make use of vMX as a powerful tool for their internal testing.
The majority of the document will focus on running vMX over KVM. This is because vMX itself is designed to run over KVM. However, not every network engineer have additional spare linux PC to run KVM. As a result, in second part of document, we will also share the trick to run vMX over VirtualBox hypervisor which is free of charge and support Windows/MacOS as host OS. Although VirtualBox is not a supported configuration and it run slower than KVM, running vMX over VirtualBox allows SE to use their own notebook for network simulation without building a dedicated KVM machine. Also VirtualBox hypervisor come with a easy to use GUI. So if you do not have any Linux knowledge, you may want to jump to VirtualBox section instead.
4 | P a g e
Building the KVM Linux hostPrepare the hardwareKVM run over Linux. Before install the Linux, we need to make sure there is hardware virtualization acceleration support enabled. Otherwise, the hypervisor will run under software emulation mode which is extremely slow.
Most modern CPU support hardware virtualization acceleration, what you need to do is goto system BIOS to make sure something like Intel VT or AMD-V is enabled. Also, you may want to make sure you get enough RAM in your server to host enough vMX for your testing. The official memory requirement for vMX is 4GB. In reality, I found it can work well in 2GB. So if you want to emulate a network with 4 vMX in your server, you need to make sure your server got minimum 8GB RAM.
Install Linux base OSKVM is supported in most Linux distribution. In this document, I use CentOS as example because it closely follows RedHat Enterprise Linux and being used extensively in the industry. I use CentOS 6.5 in this example but it should work in other CentOS release as well. You can download CentOS6.5 from:
http://isoredirect.centos.org/centos/6/isos/x86_64/CentOS-6.5-x86_64-bin-DVD1.iso
After boot-up from the CentOS DVD, can follow following screen-shot for basic OS installation.
5 | P a g e
6 | P a g e
Configure the NIC card IPv4 info if needed. Default is DHCP.
7 | P a g e
Select “Basic server” is okay. We will add KVM related packages in future.
Prepare CentOS Linux and install KVMAfter CentOS is installed and boot-up, you can login to the host. You need to disable SELinux which is enabled by default. To switch-off SELinux:
Vi /etc/selinux/config
Change SELINUX=disable as:
# This file controls the state of SELinux on the system.# SELINUX= can take one of these three values:# enforcing - SELinux security policy is enforced.# permissive - SELinux prints warnings instead of enforcing.# disabled - No SELinux policy is loaded.SELINUX=disabled# SELINUXTYPE= can take one of these two values:# targeted - Targeted processes are protected,# mls - Multi Level Security protection.SELINUXTYPE=targeted
8 | P a g e
After that, reboot the linux OS for change to take effect.
Once rebooted, assume you got Internet connectivity from your server, you can install KVM and related packages with following command:
yum install kvm libvirt python-virtinst qemu-kvm bridge-utils
Then you can start the libvirt daemon as:
/etc/init.d/libvirtd start
To ensure you are running KVM under hardware mode, you can run following command:
[root@server1 ~]# lsmod | grep kvmkvm_intel 54285 6 kvm 333172 1 kvm_intel
The command output should indicate KVM_intel module is loaded (assume you are using Intel CPU).
To ensure there is no potential blocking of network access, we also recommend to disable the IPTable firewall in the Linux host which is enabled by default:
[root@server4 qemu]# iptables --flush[root@server4 qemu]# chkconfig iptables off
In KVM environment, there are several method to connect guest VM’s network interface into host NIC like macvtap and others. I tried several of them and found the easiest and most compatible way to do that is via creating a network bridge interface and assign VM to the network bridge. In order to create a network bridge interface in the host PC, we have to change the interface configuration as below:
1. Create a network bridge interface
vi /etc/sysconfig/network-scripts/ifcfg-br0
With following content:
DEVICE="br0"NM_CONTROLLED="no"ONBOOT=yesTYPE=BridgeBOOTPROTO=noneIPADDR=192.168.0.100PREFIX=24GATEWAY=192.168.0.1
9 | P a g e
DNS1=8.8.8.8DNS2=8.8.4.4DEFROUTE=yesIPV4_FAILURE_FATAL=yesIPV6INIT=noNAME="System br0"
You may want to change RED text to suit your environment.
2. Modify existing physical interface to map to newly created network bridge interface
vi /etc/sysconfig/network-scripts/ifcfg-eth0Assume your server’s physical NIC is eth0 in above example.
You will need to comment out BOOTPROTO, IPADDR, PREFIX, GATEWAY, DNS1, DNS2 and add BRIDGE=br0 as follow example:
DEVICE="eth0"#BOOTPROTO=noneNM_CONTROLLED="yes"ONBOOT=yesTYPE="Ethernet"UUID="73cb0b12-1f42-49b0-ad69-731e888276ff"HWADDR=00:1E:90:F3:F0:02#IPADDR=192.168.0.100#PREFIX=24#GATEWAY=192.168.0.1#DNS1=8.8.8.8#DNS2=8.8.4.4DEFROUTE=yesIPV4_FAILURE_FATAL=yesIPV6INIT=noNAME="System eth0"BRIDGE=br0
After that, restart the network to make sure the configuration change is effective:
[root@server1 network-scripts]# service network restart
You can also run “brctl show” to verify the output, it should looks like:
[root@server4 ~]# brctl showbridge name bridge id STP enabled interfacesbr0 8000.002590a9ddcb no eth0 br1 8000.002590a9ddca no eth1
The br0 is the bridge network interface and you will assign VM into the bridge interface in the future if you want them to access to outside world. If you got other physical interface (e.g. eth1) want to
10 | P a g e
blind VM’s NIC into it, you can re-use above procedure to create more bridge interface like br1 and assign eth1 into br1.
From time to time, you may also want to do a system-wide update to make your system up to date for security patch and software bug fix, you can do that easily in CentOS via “yum update”:
[root@server4 qemu]# yum update
11 | P a g e
Basic configuration & Operation of KVMAdministrate KVM via Virsh commandsThe Linux hypervisor can be administrated via GUI and several CLI commands. In following section, I will introduce “virsh” command which is good enough to complete most common hypervisor related tasks.
Virsh means virtual shell. To access the virtual shell, simple type virsh in command prompt:
[root@server4 ~]# virshWelcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands 'quit' to quit
virsh #
There are several useful administrative commons like:
virsh # list <- list currently running VMs Id Name State---------------------------------------------------- 15 vSRX1 running 24 vMX2 running
virsh # list –all <-list VMs including the one being shut off Id Name State---------------------------------------------------- 15 vSRX1 running 24 vMX2 running - vMX1 shut off
virsh #destroy <vm name> <- hard shutdown VM
virsh #reboot <vm name> <- hard reboot VM
virsh #edit <vm name> <- edit the XML config file of VM
virsh #define <xml path of VM> <- update XML config of VM
virsh #undefine <vm name> delete the VM cfg from hypervisor
12 | P a g e
The last 3 commands will be discussed in details in following section. You can always type “help” to list available command in virsh. But above are most common commands we will use.
vMX Virtual Machine XML configurationEvery VM in KVM got a XML file to specify the parameters of VM like CPU/memory/ interface/HD…. By default, it will be stored in /etc/libvirt/qemu/
Here is a sample XML configuration for a vMX, I highlighted important section in RED color:
[root@server4 qemu]# more vMX1.xml<!--WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: virsh edit vMX1or other application using the libvirt API.-->
<domain type='kvm'> <name>vMX1</name> <- this is name of VM show under virsh <memory unit='KiB'>2097152</memory> <-this is total memory (2G) allocated to VM <currentMemory unit='KiB'>2097152</currentMemory> <- this is total memory (2G) allocated to VM <vcpu placement='static'>4</vcpu> <- this is total virtual CPU core map to VM. Usually equal to total CPU core in your server <os> <type arch='x86_64' machine='rhel6.5.0'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none' io='threads'/> <source file='/home/guest_images/vMX1.img'/> <- this is where you place your vMX disk image <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <controller type='ide' index='0'>
13 | P a g e
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller>
Below is section for network interface blind to the vMX. There are 4 NIC blind to the vMX in below example. You need to define the virtual MAC for each interface and also specify where the virtual NIC is blind to.
<interface type='bridge'> <mac address='52:54:00:08:ee:30'/> <- this is the virtual MAC for this NIC <source bridge='br0'/> <- here we specify this NIC blind to the network bridge we created previously <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> <- please note the slot # of the NIC card, it will increase with # of NIC, see below for example </interface> <interface type='bridge'> <mac address='52:54:00:a6:40:3a'/> <source bridge='br1'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </interface> <interface type='bridge'> <mac address='52:54:00:08:ee:31'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </interface> <interface type='bridge'> <mac address='52:54:00:a6:40:4a'/> <source bridge='br1'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <input type='mouse' bus='ps2'/>We will access vMX’s console via VNC. As a result, we need to specify the listening IP address and port # of VNC in below section
<graphics type='vnc' port='5902' autoport='no' listen='172.27.62.131' passwd='contrail123'><- the IP address is equal to the KVM server IP address, also note you can specify VNC
14 | P a g e
password to protect the console access <listen type='address' address='172.27.62.131'/> </graphics> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </memballoon> </devices></domain>
You can copy and paste above sample xml into a text file and upload it into your KVM host. Place it under /etc/libvirt/qemu/ Make sure you have made necessary modification like network interface and VNC IP to suit your deployment.
In order for the vMX to boot, you need to download the vMX disk image file. It is available from jtac-tools server. The current latest edition is 14.1R.10 and it is located under:
/volume/build/junos/14.1/release/14.1R1.10/ship/jinstall-vmx-14.1R1.10-domestic.img
Alternatively, you can download the disk image from following internal server:
http://backup.kdc.jnpr.net/vMX/jinstall-vmx-14.1R1.10-domestic.img
You will need to place the disk image into location specified in your XML file (e.g. /home/guest_image/ in my example)
Once both XML and disk image is ready. You can use “define <path of XML>” command to create the vMX instance like:
[root@server4 qemu]# virshWelcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands 'quit' to quit
virsh # define /etc/libvirt/qemu/vMX1.xml <- define the vMX instance from configuration fileDomain vMX1 defined from /etc/libvirt/qemu/vMX1.xml
virsh # list –all <- check to make sure vMX1 is defined Id Name State---------------------------------------------------- 15 vSRX1 running
15 | P a g e
24 vMX2 running - vMX1 shut off
virsh # start vMX1 <- start the vMXDomain vMX1 started
virsh #
Once the vMX is started, you can access to the console via VNC with correct IP and port defined in XML:
If you want to stop the vMX (e.g. you want to shutdown the KVM server or free up more memory for other VM), you can use “destroy <VM name>”. Before doing that, better use “request system halt” command in vMX console to prevent disk corruption. The “request system power-off” command will NOT power-off the vMX in KVM. Need to use “destroy” command in virsh to stop it completely.
16 | P a g e
Then
virsh # destroy vMX1Domain vMX1 destroyed
virsh # list --all Id Name State---------------------------------------------------- 15 vSRX1 running 24 vMX2 running - vMX1 shut off
virsh #
If you want to change the XML definition of vMX like adding more memory/NIC card, you can use “edit <VM name>” command in virsh to edit the XML directly. This is actually the preferred method to edit VM XML because virsh will perform syntax check for you before save.
virsh # edit vMX1….<domain type='kvm'>
17 | P a g e
<name>vMX1</name> <uuid>27f16d4f-b26d-1c84-e98e-b2eaac008d7b</uuid> <memory unit='KiB'>2097152</memory> <currentMemory unit='KiB'>2097152</currentMemory> <vcpu placement='static'>4</vcpu> <os> <type arch='x86_64' machine='rhel6.5.0'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_c……
You can navigate the text file via standard VI command like “:q!” to save and “I” to insert
Once the XML is edited and saved, it will NOT apply to the running VM. It will take effect on its next reboot. You can power cycle the VM via “destroy <VM name> + start <VM name>” command.
"/tmp/virshLqI7Kb.xml" 94L, 3346C written <- type “:wq!” to save the XML. Virsh will do syntax checkDomain vMX1 XML configuration not changed.
virsh # define /etc/libvirt/qemu/vMX1.xml <- need to define the XML config again for change to take effectDomain vMX1 defined from /etc/libvirt/qemu/vMX1.xml
virsh # start vMX1 <- start the vMX for change to take effectDomain vMX1 started
virsh #
If you want to remove the VM definition from KVM completely, you can use “undefined <VM name>” command in virsh. Please note this will DELETE the XML file as well. So please make sure you make the backup of XML file in /etc/libvirt/qemu directory in case you want to re-create the VM in the future.
virsh # undefine vMX1Domain vMX1 has been undefined
virsh # list --all Id Name State----------------------------------------------------
18 | P a g e
15 vSRX1 running 24 vMX2 running 29 vMX1 running
virsh # destroy vMX1Domain vMX1 destroyed
virsh #
Virtual Network XML configurationIn previous section, we discuss about blind vMX’s NIC into KVM host’s network bridge interface. This allows you to communicate vMX to outside worlds and perform remote administration. However, if we want to connect multiple vMX inside a physical server together, we will not want to connect them via physical wire. Instead, we may want to do that virtually like LT interface in JUNOS to connect multiple logical systems together. In order to do that, we have to create virtual bridge in KVM host:
The virtual bridge (virbr0 in this case) do not blind to any physical interface and only exist inside the KVM host. We can connect the vMX or other VM to the virtual bridge like we do for bridge interface (e.g. br0):
19 | P a g e
In above example, 2 vMX will be able to connect to each other via virtual bridge. In reality, it works better than JUNOS LSYS LT interface because you actually created a virtual broadcast domain and you can assign more than 2 VM into the virtual bridge.
Before you can specify virtual bridge in your vMX configuration file, you need to create them under virsh. Similar to VM, every virtual network (VN) is defined with XML file. By default, they are stored under /etc/libvirt/qemu/networks
Here is a sample XML for a private virtual network:
<network> <name>private1</name> <- this is the network name show under virsh <bridge name='virbr1' stp='on' delay='0' /> <- virbr1 is the name used by VM XML file <mac address='52:54:00:2C:C7:18'/> <- each virtual bridge need to have unique MAC address</network>
Similar to virtual machine management, you will manage virtual network via virsh. The available command in virsh for networking are:
virsh # help network Networking (help keyword 'network'): net-autostart autostart a network net-create create a network from an XML file net-define define (but don't start) a network from an XML file net-destroy destroy (stop) a network net-dumpxml network information in XML net-edit edit XML configuration for a network net-info network information net-list list networks net-name convert a network UUID to network name
20 | P a g e
net-start start a (previously defined) inactive network net-undefine undefine an inactive network net-update update parts of an existing network's configuration net-uuid convert a network name to network UUID
virsh #
Inside, we are going to use net-define, net-edit, net-list, net-autostart, net-start. Here assume we are going to create a new virtual network called: “private3” with bridge name=”virbr3”. We are going to create a XML with following content and place it under /etc/libvirt/qemu/networks/ as private3.xml
[root@server4 networks]# more private3.xml <network> <name>private3</name> <bridge name='virbr3' stp='on' delay='0' /> <mac address='52:54:00:2C:D7:19'/></network>[root@server4 networks]#
We can define the network in virsh via “net-define <path to xml>”
[root@server4 networks]# virshWelcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands 'quit' to quit
virsh # net-define /etc/libvirt/qemu/networks/private3.xml Network private3 defined from /etc/libvirt/qemu/networks/private3.xml
virsh # net-list --allName State Autostart Persistent--------------------------------------------------default active yes yesprivate1 active yes yesprivate2 active yes yesprivate3 inactive no yes
virsh #
You can see the private3 virtual network is defined but not started and also will not auto-start with KVM machine. We can start the network via “net-start <VN name>” and mark it as auto-start via “net-autostart <VN name>”
21 | P a g e
virsh # net-start private3Network private3 started
virsh # net-autostart private3Network private3 marked as autostarted
virsh # net-listName State Autostart Persistent--------------------------------------------------default active yes yesprivate1 active yes yesprivate2 active yes yesprivate3 active yes yes
virsh #
In case you want to change the property of virtual network, you can use “net-edit <VN name>” and use “net-define <path to XML>” to update the configuration. Just like what we did in manage VM section. However, unlike virtual machine, once created, it is less likely for us to change virtual network configuration.
Once the virtual network is created, we can blind it to vMX’s additional interfaces by editing the XML file, here is some sample XML configuration referring use of virtual bridge. In following example, there are total 7 interfaces defined in the vMX xml with following blinding:
Interface 1: br0 -> eth0 of host
Interface 2: br1 -> eth1 of host
Interface 3: br0 -> eth0 of host
Interface 4: br1 -> eth1 of host
Interface 5: br0 -> eth0 of host
Interface6: virbr0
Interface7: virbr1
Please note that each interface was defined with unique MAC address and PCI slot #.
<interface type='bridge'> <mac address='52:54:00:08:ee:30'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
22 | P a g e
</interface> <interface type='bridge'> <mac address='52:54:00:a6:40:3a'/> <source bridge='br1'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </interface> <interface type='bridge'> <mac address='52:54:00:08:ee:31'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </interface> <interface type='bridge'> <mac address='52:54:00:a6:40:4a'/> <source bridge='br1'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </interface> <interface type='bridge'> <mac address='52:54:00:08:ee:41'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </interface> <interface type='bridge'> <mac address='52:54:00:a6:40:4b'/> <source bridge='virbr1'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </interface> <interface type='bridge'> <mac address='52:54:00:08:ee:42'/> <source bridge='virbr2'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/> </interface>
Once saved, remember to re-define the vMX XML and restart the vMX instance for it to take effect.
23 | P a g e
Basic configuration & Operation of vMXInterface ConfigurationInside vMX, all interfaces you mapped in KVM appear as em interface. There is a default mapping of em-X interface to ge-0/0/Y interface defined under /etc/rpio.conf as:
Em0 – Connect to RE
Em1 – Connect to RE
Em2 – ge-0/0/0
Em3 – ge-0/0/1
Em4 – ge-0/0/2
Em5 – ge-0/0/3
Em6 – ge-0/0/4
Em7 – ge-0/0/5
Em8 – ge-0/0/6
Em9 – ge-0/0/7
Em10 – ge-0/0/8
Em11 – ge-0/0/9
The Em0 is the first NIC defined in vMX XML and Em1 is the second NIC and so on. So by referring to above table, you will be able to locate which GE port in vMX is mapped to which virtual NIC in KVM.
vMX’s GE interface by default come with Juniper MAC which is not equal to the MAC you defined in vMX XML configuration. As a result, we need to specify the MAC address of GE interface manually and JUNOS interface configuration will looks like:
interfaces { ge-0/0/0 { mac 52:54:00:08:ee:31; <- this is the MAC you defined in vMX XML’s 3rd NIC unit 0 { family inet { address 172.27.62.31/24; } }
24 | P a g e
} ge-0/0/1 { mac 52:54:00:a6:40:4a; <- this is the MAC you defined in vMX XML’s 4th MAC unit 0 { family inet { address 192.168.10.253/24; } } }
Other than that, all vMX configuration is identical to normal MX80. It supports everything including tunnel service. The only limitation is on performance and QoS which is expected for a software emulated solution. However, it is good enough for feature testing.
Please note above setting is specific to vMX. If you run vSRX (FireFly Perimeter) over KVM, there is no such emX to ge-X mapping problem and you do not need to specify MAC in interface config.
Also during my testing, I found in rare occasion, even specified correct MAC under interface will cause traffic forward problem. In this case, simply “deactivate” -> “commit” -> “activate” -> “commit” the MAC portion of configuration seems to solve it.
Upgrade vMX JUNOS versionInside JTAC tools server, every JUNOS release after 14.1 should come with 2 files namely:
Jinstall-vmx-<version>.img and
Jinstall-vmx-<version>.tgz
The former file is disk image for you to start the vMX from factory default. Once started and configured, if you want to upgrade the vMX server to later release, you can simply download and copy the jinstall-vmx-<version>.tgz file into the vMX RE and use ordinary “request system software add <path to jinstall-vmx-<version>.tgz>” method to upgrade your vMX installation.
You can also download the tgz image from following intranet server:
http://backup.kdc.jnpr.net/vMX/jinstall-vmx-14.1R1.10-domestic.tgz
root@vMX2> request system software add /var/tmp/jinstall-vmx-14.1R1.4-domestic-signed.tgz NOTICE: Validating configuration against jinstall-vmx-14.1R1.4-domestic-signed.tgz.NOTICE: Use the 'no-validate' option to skip this if desired.Checking compatibility with configurationInitializing...Using jbase-14.1B2.3veriexec: accepting signer: PackageDevelopmentEc_2014
25 | P a g e
Some more advanced tasksBlind VLAN tag interface into vMXIn previous example, you blind the host NIC into network bridge (br0). We assume the host NIC is running in untagged mode. If you want to connect vMX to multiple external interfaces while you don’t want to install multiple NIC card, the better idea is to run host NIC in VLAN tagged mode and assign each sub-interface into separated network bridge.
In order to do this, we have to enable VLAN tagging in Linux interface and create sub-interface for different VLAN tag.
First we need to ensure 802.1q kernel module is loaded:
[root@server4 sysconfig]# lsmod | grep 8021q <- Check to see if 802.1q kernel module is loaded or not[root@server4 sysconfig]# modprobe 8021q <- load the kernel module if not already did[root@server4 sysconfig]# lsmod | grep 8021q8021q 25349 0 garp 7152 1 8021q[root@server4 sysconfig]# echo modprobe 8021q >> /etc/rc.modules && chmod +x /etc/rc.modules <- make it persistent across reboot
26 | P a g e
eth0 eth1
vMX
ge-0/0/0 ge-0/0/1
br10
Host ManagementTagged interface connect to external switch:
VLAN10 -> br10 -> ge-0/0/0VLAN20 -> br20 -> ge-0/0/1
br20
eth1.10 eth1.20
CentOS KVM
After that, we can edit the /etc/sysconfig/network-script/ as:
[root@server4 ~]# cd /etc/sysconfig/network-scripts/[root@server4 network-scripts]# cat ifcfg-eth1DEVICE=eth1HWADDR=00:25:90:A9:DD:CATYPE=EthernetONBOOT=yesNM_CONTROLLED=no [root@server4 network-scripts]# cat ifcfg-eth1.10DEVICE=eth1.10HWADDR=00:25:90:A9:DD:CATYPE=EthernetONBOOT=yesNM_CONTROLLED=noBRIDGE="br10"VLAN=yes[root@server4 network-scripts]# cat ifcfg-eth1.20DEVICE=eth1.20HWADDR=00:25:90:A9:DD:CATYPE=EthernetONBOOT=yesNM_CONTROLLED=noBRIDGE="br20"VLAN=yes[root@server4 network-scripts]# cat ifcfg-br10DEVICE="br10"NM_CONTROLLED="yes"ONBOOT=yesTYPE=BridgeBOOTPROTO=noneIPADDR=192.168.10.201PREFIX=24DEFROUTE=noIPV4_FAILURE_FATAL=yesIPV6INIT=noNAME="System br10"[root@server4 network-scripts]# cat ifcfg-br20DEVICE="br20"NM_CONTROLLED="yes"ONBOOT=yesTYPE=BridgeBOOTPROTO=noneIPADDR=192.168.20.201PREFIX=24DEFROUTE=no
27 | P a g e
IPV4_FAILURE_FATAL=yesIPV6INIT=noNAME="System br20"[root@server4 network-scripts]#
Restart network daemon for change to take effect:
[root@server4 network-scripts]# service network restartShutting down interface br0: [ OK ]Shutting down interface br10: [ OK ]Shutting down interface br20: [ OK ]Shutting down interface eth1.10: [ OK ]Shutting down interface eth1.20: [ OK ]Shutting down interface eth0: [ OK ]Shutting down interface eth1: [ OK ]Shutting down loopback interface: [ OK ]Bringing up loopback interface: [ OK ]Bringing up interface eth0: [ OK ]Bringing up interface eth1: [ OK ]Bringing up interface eth1.10: [ OK ]Bringing up interface eth1.20: [ OK ]Bringing up interface br0: Determining if ip address 172.27.62.131 is already in use for device br0...[ OK ]Bringing up interface br10: Determining if ip address 192.168.10.201 is already in use for device br10...[ OK ]Bringing up interface br20: Determining if ip address 192.168.20.201 is already in use for device br20...[ OK ][root@server4 network-scripts]# service libvirtd restartStopping libvirtd daemon: [ OK ]Starting libvirtd daemon: [ OK ][root@server4 network-scripts]#
Check to make sure the configuration is working:
[root@server4 ~]# ifconfig -abr0 Link encap:Ethernet HWaddr 00:25:90:A9:DD:CB inet addr:172.27.62.131 Bcast:172.27.62.255 Mask:255.255.255.0 inet6 addr: fe80::225:90ff:fea9:ddcb/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:311 errors:0 dropped:0 overruns:0 frame:0 TX packets:57 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:22024 (21.5 KiB) TX bytes:6732 (6.5 KiB)
br10 Link encap:Ethernet HWaddr 00:25:90:A9:DD:CA inet addr:192.168.10.201 Bcast:192.168.10.255 Mask:255.255.255.0
28 | P a g e
inet6 addr: fe80::225:90ff:fea9:ddca/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:746 (746.0 b)
br20 Link encap:Ethernet HWaddr 00:25:90:A9:DD:CA inet addr:192.168.20.201 Bcast:192.168.20.255 Mask:255.255.255.0 inet6 addr: fe80::225:90ff:fea9:ddca/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:746 (746.0 b)
eth0 Link encap:Ethernet HWaddr 00:25:90:A9:DD:CB inet6 addr: fe80::225:90ff:fea9:ddcb/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:788 errors:0 dropped:0 overruns:0 frame:0 TX packets:57 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:428452 (418.4 KiB) TX bytes:6816 (6.6 KiB) Interrupt:20 Memory:dfb00000-dfb20000
eth1 Link encap:Ethernet HWaddr 00:25:90:A9:DD:CA inet6 addr: fe80::225:90ff:fea9:ddca/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:86 errors:0 dropped:0 overruns:0 frame:0 TX packets:35 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5160 (5.0 KiB) TX bytes:2554 (2.4 KiB) Interrupt:16 Memory:df900000-df920000
eth1.10 Link encap:Ethernet HWaddr 00:25:90:A9:DD:CA inet6 addr: fe80::225:90ff:fea9:ddca/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:802 (802.0 b)
eth1.20 Link encap:Ethernet HWaddr 00:25:90:A9:DD:CA inet6 addr: fe80::225:90ff:fea9:ddca/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
29 | P a g e
RX bytes:0 (0.0 b) TX bytes:1104 (1.0 KiB)
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)………..
[root@server4 ~]# [root@server4 ~]# [root@server4 ~]# brctl showbridge name bridge id STP enabled interfacesbr0 8000.002590a9ddcb no eth0br10 8000.002590a9ddca no eth1.10br20 8000.002590a9ddca no eth1.20virbr0 8000.525400561f1d yes virbr0-nicvirbr1 8000.5254002cc718 yes virbr1-nicvirbr2 8000.5254002cd718 yes virbr2-nicvirbr3 8000.5254002cd719 yes virbr3-nic[root@server4 ~]# cat /proc/net/vlan/config VLAN Dev name | VLAN IDName-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PADeth1.10 | 10 | eth1eth1.20 | 20 | eth1
After that, you can assign br10 and br20 to vMX’s XML as illustrated in previous sections.
Attach windows client into testing networkWith the vMX in place, we can construct a complex network purely in virtualized software environment. Although the setup can’t be used for performance testing, it is good enough for functional and failover test. However, it will be great if we can attach client OS to the virtual environment to perform functions like ping, file transfer, packet captures and others. Actually, it is pretty easy to do that in virtualized software environment, simply attach a client OS as VM into the VN.
Unfortunately, most network engineer is familiar with Windows client and KVM by itself it not as Windows friendly as other hypervisor like VMWare and virtualbox. Here we provide the step to install and run WinXP client under KVM environment to fill the gap.
Assume you got winxp.iso on hand, you will need to install it via virt-install command. Following is the command example:
30 | P a g e
virt-install --connect qemu:///system -n winxp -r 1024 --vcpus=2 --disk bus=virtio,path=/home/guest_images/winxp.img,size=20 --cdrom /var/lib/libvirt/images/WXPCCP_EN.iso --cdrom /var/lib/libvirt/images/virtio-win-0.1-74.iso --graphic vnc,port=5900,listen=172.27.62.129 --noautoconsole --os-type windows --os-variant=winxp --accelerate --network=bridge:br0 --hvm --boot cdrom
Above command specified:
- Name of VM: winxp- Memory of VM: 1G- # of vCPU: 2- Disk image location: /home/guest_images/winxp.img- Disk image size: 20GB- 1st CDROM image location: /var/lib/libvirt/images/WXPCCP_EN.iso- 2nd CDROM image location: /var/lib/libvirt/images/ virtio-win-0.1-74.iso- VNC console IP and port: 172.27.62.129:5900- NIC card: Attach to host’s network bridge: br0- Boot from 1st CDROM
The virtio-win iso provide the HDD and Ethernet driver for Windows to run over KVM. It can be downloaded from Internet.
https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
Virt-install is another way to create VM in KVM. Instead of editing a XML and use “define <xml location>” command under virsh. Virt-install creates the XML for user.
Once the WinXP installation iso is booted, user need to push “F6” to load the Virtio driver from 2nd CDROM disk. Otherwise, the WinXP installation will fail as it can’t recognize the store media provided by KVM.
31 | P a g e
After that, the installation will went through normally. Once boot into the WinXP screen, you will need to make use the driver inside 2nd CDROM to load the Ethernet driver for Virtio IO provided by KVM.
In order to save time, we have created a WinXP disk image file and a sample WinXP.xml. You can download it from following Intranet server.
http://backup.kdc.jnpr.net/vMX/winxp.qcow2
Once downloaded, you can modify the WinXP.xml file to make it work under your environment. Following are example. The potential change items are marked in RED color.
<domain type='kvm'> <name>winxp</name> <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <vcpu placement='static'>2</vcpu> <os> <type arch='x86_64' machine='rhel6.5.0'>hvm</type> <boot dev='hd'/>
32 | P a g e
</os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='localtime'> <timer name='rtc' tickpolicy='catchup'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/home/guest_images/winxp.qcow2'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='fdc' index='0'/> <interface type='bridge'> <mac address='52:54:00:8e:7c:d6'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='5920' autoport='no' listen='172.27.62.131'> <listen type='address' address='172.27.62.131'/> </graphics> <video> <model type='vga' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video>
33 | P a g e
<memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </memballoon> </devices></domain>
After that, you can use “define <xml location>” command to load the VM and “start winxp” to start it.
34 | P a g e
Example: Create a 4 PE node eVPN network inside a single physical serverNetwork Diagram
The topology consists of 4 vMX and 4 WinXP clients. It tried to emulate 2 DC inter-connected with eVPN service. In this test, all components are emulated in a single PC running quad core CPU with 16GB RAM. We try to simulate a setup consist of 2 DC interconnected by MX . eVPN is used to provide layer 2 transport and IRB is integrated into eVPN instance to provide inter-VLAN routing.
2 VLANs are created in the topology. VLAN 10 and VLAN 20. WinXP1 and WinXP3 are connected to VLAN10. WinXP2 and WinXP4 are connected to VLAN20.
35 | P a g e
PE1 (vMX1)G
e-0/
0/1
PE2 (vMX2)
Ge-0/0/0
Ge-0/0/0
Ge-0/0/1
PE3 (vMX3)
PE4 (vMX4)
winxp1
winxp2
winxp3
winxp4
Ge-0/0/3 Ge-0/0/3
Ge-0/0/3Ge-0/0/3
Ge-0/0/0
Ge-0/0/2
Ge-0/0/2
Ge-0/0/2
Ge-0/0/2
Ge-
0/0/
0
Ge-0/0/1
PE1 (vMX1)
PE2 (vMX2)Ge-0/0/1
PE3 (vMX3)
PE4 (vMX4)
winxp1
winxp2
winxp3
winxp4
Ge-0/0/3Ge-0/0/3
Ge-0/0/3Ge-0/0/3
Ge-0/0/2
Ge-0/0/2
Ge-0/0/2
Ge-0/0/2
Ge-0/0/1
VLAN: 10
VLAN: 20
In JUNOS 14.1, active/standby multi-homing is supported in eVPN to prevent looping on layer 2 domain. Here vMX1 and vMX3 is elected as Designated Forwarder (DF) for traffic forwarding.
In JUNOS 14.1, IRB feature can be incorporated into eVPN to provide intra-VLAN routing. This feature work with active/standby mult-homing to ensure optimum traffic forwarding path.
36 | P a g e
PE1 (vMX1)
Ge-
0/0/
1
PE2 (vMX2)
Ge-0/0/0
Ge-0/0/0
Ge-0/0/1
PE3 (vMX3)
PE4 (vMX4)
winxp1
winxp2
winxp3
winxp4
Ge-0/0/3 Ge-0/0/3
Ge-0/0/3Ge-0/0/3
Ge-0/0/0
Ge-0/0/2
Ge-0/0/2
Ge-0/0/2
Ge-0/0/2
Ge-
0/0/
0
Ge-0/0/1
PE1 (vMX1)
PE2 (vMX2)Ge-0/0/1
PE3 (vMX3)
PE4 (vMX4)
winxp1
winxp2
winxp3
winxp4
Ge-0/0/3Ge-0/0/3
Ge-0/0/3Ge-0/0/3
Ge-0/0/2
Ge-0/0/2
Ge-0/0/2
Ge-0/0/2
Ge-0/0/1
VLAN: 10
VLAN: 20
Ge-0/0/1
The intra-VLAN traffic optimization happens even after host migration from DC-1 to DC-2. In above diagram, the WinXP1 is moved from left DC to right DC. Please note the default gateway (IRB) of all PE is the same. So moving WinXP1 to right DC doesn’t need to change default GW configuration of the WinXP OS. Inside eVPN, the PE will sync peer-gateway-macs so although the winxp1’s ARP record for gateway still pointed to PE1, PE3 (new GW) will impersonate IRB mac of PE1 and provide L3 routing feature. This is the best part of eVPN from my point of view.
Here is the detail description of what is happening. The slide is copied from eVPN 14.1 update which can be found in matrix: https://matrix.juniper.net/thread/30470
37 | P a g e
PE1 (vMX1)
PE2 (vMX2)Ge-0/0/1
PE3 (vMX3)
PE4 (vMX4)
winxp1
winxp2
winxp3
winxp4
Ge-0/0/3Ge-0/0/3
Ge-0/0/3Ge-0/0/3
Ge-0/0/2
Ge-0/0/2
Ge-0/0/2
Ge-0/0/2
Ge-0/0/1
VLAN: 10
VLAN: 20
Ge-0/0/1
Virtual Machine and Virtual Network XML
vMX1 WinXP1
vMX2 WinXP2
vMX3 WinXP3
vMX4 WinXP4
Virbr1 Connect WinXP1, vMX1-ge-0/0/0, vMX2 ge-0/0/0
Virbr2 Connect WinXP2, vMX1 ge-0/0/1, vMX2 ge-0/0/1
Virbr3 Connect WinXP3, vMX3 ge-0/0/0, vMX4 ge-0/0/0
Virbr4 Connect WinXP4, vMX3 ge-0/0/1, vMX4 ge-0/0/1
Virbr5 Connect vMX1 ge-0/0/3, vMX3 ge-0/0/3
Virbr6 Connect vMX2 ge-0/0/3, vMX4 ge-0/0/3
Virbr7 Connect vMX1 ge-0/0/2, vMX2 ge-0/0/2
Virbr8 Connect vMX3 ge-0/0/2, vMX4 ge-0/0/2
38 | P a g e
vMX Configuration
vMX1 vMX3
vMX2 vMX4
Running vMX over VirtualBox HypervisorAssumption & BackgroundvMX itself is designed to run over KVM. However, it can be converted to run over VirtualBox environment as well. Although the performance is notable slower than KVM, this help network engineer to use their own Mac/Windows notebook for vMX simulation.
In following section, we will list out key points to load vMX into VirtualBox. The VirtualBox version we used is: 4.3.12 However, it should run fine in other recent VirtialBox version.
We assume the audience already familiar with install and using VirtualBox as hypervisor.
Please note running vMX over VirtualBox is not a supported function. It may break in future vMX version.
Convert vMX image to VirtualBox formatThe default vMX image is packaged in qcow2 format. VirtualBox do not support qcow2 so we need to convert the disk image from qcow2 to vdi. Hopefully, there is an image conversion tool available in every KVM Linux installation. You can use following command to convert vMX image:
[root@server1 guest_images]# qemu-img convert -O vdi vMX1.img vMX1.vdi
In order to save time, you can download a pre-converted vMX vdi image from below intranet web server:
http://backup.kdc.jnpr.net/vMX/vMX.vdi
39 | P a g e
Load the vMX in VirtualBoxOnce the vMX image is converted, we can start loading it into VirtualBox. Here is some screen-shot
Select type: Linux, Version: Other Linux (32bit)
40 | P a g e
The official memory requirement is 4GB but you can boot a vMX with minimum 1GB RAM.
Select the vdi image file you converted in previous step
41 | P a g e
After that, you need to edit the VM to complete further setting
First, you need to enable additional NIC in vMX. Adapter 1 connected to em0 which can be used for remote administration. You can bridge it to your PC’s Ethernet interface if you want. Please choose “virtio-net” on adapter type as this is the default NIC driver on vMX.
42 | P a g e
Adapter 2-> em1. Basically, we are not going to use this interface so just enable it but do not attach to anything.
43 | P a g e
Adapter 3-> em2 -> ge-0/0/0 in vMX. Here we attach it to a “internal network” name intnet. This is a private network inter-connect multiple VM together inside VirtualBox. We can use this like virbr in KVM to inter-connect multiple vMX together.
Adapter4-> em3 -> ge-0/0/1. Here we attach to another “internal network” called intnet2.
For detail explanation on VM NIC mapping, please refer to “interface configuration” of page 23.
By default, console of vMX show –up on com1. So we are going to re-direct com1 of vMX to host. We can do that in VirtualBox as:
44 | P a g e
Please note the port/file_path is in format: \\.\pipe\<VM name> There is no space before and after the text.
Once the network and console property is configured, you can start the vMX VM in VirtualBox. To access to vMX console, you can open putty and use following setting to connect to the host pipe:
45 | P a g e
Select “serial” then input \\.\pipe\<VM name> into the serial line.
46 | P a g e
JUNOS configuration in vMXSimilar to what we mentioned in KVM section: “interface configuration” page 23, we need to configure MAC address of ge-0/0/x manually for traffic to pass-through. For details, please refer back to KVM section.
Other hints
JUNOS firmware upgradeOnce the vMX is up and running, it can be upgraded via traditional method via “request system software add …”. For details, please refer to “Upgrade vMX JUNOS version” in page 24.
47 | P a g e
Additional NIC card in vMXVirtualBox UI supports maximum 4 NIC. In order to create more NIC on vMX, you have to use “VBoxManage modifyvm” command. For details, please refer to:
http://www.virtualbox.org/manual/ch08.html#vboxmanage-modifyvm
The maximum # of NIC currently supported is 8. If more inter-connect is needed, you may consider to use VLAN tagging to create more IFL for vMX inter-connection.
VLAN taggingThe “Internal Network” bridge in VirtualBox support VLAN tagging natively. It will forward VLAN tagged frame without problem. It works like a bridge which forward traffic base on MAC only without looking at VLAN tag.
So you just need to enable VLAN tag in vMX for it to work.
Duplicate disk image/duplicated UUID issueIt is a common practice to copy vMX disk image file (the vdi file) if we want to create additional vMX under VirtualBox. However, this will create “duplicated UUID” error when we try to create the VM as below:
48 | P a g e
This is because every virtual disk image contains a UUID to identify itself. VirtualBox do not allow 2 virtual disks with the identical UUID. To resolve this issue, you have to change the UUID of the VDI copy with VBoxManage.exe comand:
VBoxManage.exe internalcomands sethduuid <path to new VDI file>
This is the end of this doc. Free to email me if you have any suggestion/comment.
Welcome to the world of software & virtualization. Enjoy.
--- End ---
49 | P a g e