• (logfile /var/log/xen/xend.log) #write log to the xend.log, keep the xend log out of the main syslog which is handy for debugging
• (network-script network-bridge) #use this script to bridge network traffic, I made backup of the original network-bridge as network-bridge-bak
• (vif-script vif-bridge) #default option. The default interface will serve as the bridge.
• (dom0-min-mem 196) #min memory level of dom0
• (enable-dom0-ballooning yes) #use together with the command above, when memory low dom0 will balloon out.
• (vnc-listen '0.0.0.0') #vnc server listens to the port defined, this let VNS listens to every port, not very secure for now but easy for debugging
• (vncpasswd '***') #vnc password

and some other options, might be useful for future

other options and explanation

logfile
    The location of the file to record runtime log messages. Defaults to /var/log/xen/xend.log. 
loglevel
    Filters out messages below the specified level. Possible values are DEBUG, INFO, WARNING, ERROR, CRITICAL. Defaults to DEBUG. 
xend-http-server
    A boolean value that tells xend whether or not to start the http stream socket management server. Defaults to no. 
xend-unix-server
    A boolean value that tells xend whether or not to start the unix domain socket management server. This is required for the CLI tools to operate. Defaults to yes. 
xend-relocation-server
    A boolean value that tells xend whether or not to start the relocation server. This is required for cross-machine migrations. Defaults to no. 
xend-unix-path
    The location of the unix domain socket the xend-unix-server will use to communicate with the management tools. Defaults to /var/lib/xend/xend-socket. 
xend-port
    The port that will be used by the http management server. Defaults to 8000. 
xend-relocation-port
    The port that will be used by the relocation server. Defaults to 8002. 
xend-address
    The address to which the http management server will bind. Defaults to '' which means ``all interfaces''. 
xend-relocation-address
    The address to which the relocation server will bind. Defaults to '' which means ``all interfaces''. 
console-limit
    The kilobyte buffer limit that will be enforced by the console server. This limit is set per-domain, and is needed to prevent a single domain from overwhelming the console server with massive amounts of data. Defaults to 1024. 
network-script
    The name of the script in /etc/xen/scripts that will be run to setup the networking environment. This can be any name, but in general is either network-bridge or network-route. 
vif-script
    The name of the script in /etc/xen/scripts that will be run to setup a virtual interface when it is created or destroyed. This needs to (in general) work in unison with the network-script. 
dom0-min-mem
    This specifies the minimum number of megabytes that will be reserved for Domain0. If this value is positive, Domain0 will be automatically ballooned down to this limit to make space for new domains. If this is set to 0, Domain0 will not be automatically ballooned. 
dom0-cpus
    This specifies the number of CPUs that Domain0 will be allowed to use. If the value is 0, all available CPUs will be used by Domain0. 
enable-dump
    A boolean value that tells xend whether or not core dumps of guest domains should be saved when a crash occurs. Defaults to no. 

<hi #c0c0c0>original HVM = hardware virtual machine (full virtualization). The alternative is para-virtuallization. Full virtualization create a total virtual environment which the guest will not even notice that it is running on a VM. It can support the domU running the original OS, like it is really installed on a real machine. Drawback is it need hardware support like VT from intel, AMD-V from AMD. Para-virtulization needs modified OS for its domU as it is running on a virtulized software interface layer. It does not need hardware support. The guest running on it will also be aware that it is running on a VM. </hi>

<hi #808000>improve</hi>
HVM = hardware virtual machine. There different types of virtuallization according to different viewing angle. But in general there are three: full virtuallization, para-virtuallization and hardware assisted virtuallization. It is doubtful whether the last one should be a type or just a supporting technology of the earlier two.

Full virtualization create a total virtual environment which the guest will not even notice that it is running on a VM. The VMM layer emulates a totally different or somehow similar hardware layer to run the guestOS. It can support the domU running the original OS, like it is really installed on a real machine. Drawback is its performance is in general low while running without hardware support like VT from intel, AMD-V from AMD. Para-virtulization needs modified OS for its domU as it is running on a partially virtulized/emulated software interface layer. The guest running on it will also be aware that it is running on a VM or even be notified explicitly that it is running on a VM. The advantage is the performance is high.

debootstrap can be used to install another base system to a directory of another system. It can also be installed and run from another operating system, for instance, you can use debootstrap to install Debian onto an unused partition from a running Gentoo install. It can also be used to create a rootfs for a machine of a different architecture.

dd is a converter and copier of files (since everything is a file in *nix).

dd if=<input> of=<output> bs=<blcoksize> seek=<skipbeforewrite> count=<block>

• “if” select /dev/zero as the source instead of stdin.
• “of” select the destination file to be used, instead of the stdout.
• “bs” controls the amount of data being read&write at a time in BYTEs.
• “seek” tells that skip certain amount of blocks before output.
• “count” tells that only copy COUNT, in this case 1, time(s) the input.

A sparse file is a file which can “grow” when it contains the real data and keep small when it does not have much data. In the dd command we specify seek to create such a sparse file. If we set seek=1G , it will skip 1G before write back to the output, which will save a lot of disk space, but still “declare” the space in the OS. We see the effect from the following ls command and du command. In ls , the file is the “claim” size, in du it is the real size of the file at this moment.

vic@rome:~$ du -s ubuntu.img
3504600 ubuntu.img
vic@rome:~$ ls -la ubuntu.img
-rw-r--r-- 1 root root 64424513536 Feb  1 14:20 ubuntu.img

<hi #808000>Improve</hi>
The above text still hold valid while there is deeper information about the sparse file system.

The sparse file system can be used to save disk space as it does not write empty data to the disk space. Instead, it write the empty block information as metadata of the file. Only when there are real data, so the blocks are not zero (empty) anymore, the real disk space will then be allocated. During read operation, the sparse file system will return the zero data blocks according to the metadata, so there will be no error in reading either.

However, not all file systems can support sparse file system. But most *nix systems can.

As of everything, when there is advantage, there is also disadvantage. The worst one is that the read data layout on the harddisk can be quite fragmented. The IO efficiency could be lower down.

We can disable the vif of the windows VM and install the patches from ISO file (mount as cd-rom)

Yes. There are two ways:

• like above mentioned, we can download every updates and make them into one iso file then install all of them.
• Instead of “network-bridge” we can configure xen to use “network-nat” to put the VMs behind a NAT which gains a bit time for us to install the patches.

Please see the work log

For each interface in domU, two interfaces are created. One is ethx in the domU and the other one is the vifi.0 in dom0. Two of them are connected to provide connectivity between dom0 and domU. But the domU still does not get outside connection, hence the dom0 has to read the data and send to the bridge, eth2 of dom0 in this case.

Every VM has its own network and connected to a virtual router running on dom0. Every frame for a domU from outside will be handled by the corresponding vif and send to domU's paired interface. And every frame sent from domU will be transferred to the corresponding vif then go through the virtual router.

tap is virtual network kernel driver. It runs in full-virtualization. In para-virtualization data are sent through vif but in full-virtualization data are sent through tap. But by default vif always exists. That's why we see vif and tap together in our setting. the command result below shows that actual transfer of data is done through tap device.

tap2.0    Link encap:Ethernet  HWaddr 66:fd:bc:16:b5:ef
          inet6 addr: fe80::64fd:bcff:fe16:b5ef/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1001116 errors:0 dropped:0 overruns:0 frame:0
          TX packets:72065 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:62803724 (59.8 MiB)  TX bytes:5419316 (5.1 MiB)
 
vif2.0    Link encap:Ethernet  HWaddr fe:ff:ff:ff:ff:ff
          inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:2645 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

pethi is physical eth<i>. It is the actual interface of NIC on dom0.

When running in a bridge environment, Xen “clone” an existing interface to serve as the bridge which connects all the vif interfaces and give them outside connectivity. The Xen rename the real interface to pethi. It does this to firstly keep the system safe, in the sense that we do not loss the physical interface. Secondly, we have a consistent naming. So eth0 still looks the same as before though actually it is already replaced and function in a bit different way and gives all the domUs access at the same time.

The host is uniquely identified after a fixed MAC address is given. Then I can let the DHCP server always give the same IP address to that VM. It is easier to manage and debug the machine.

it is easier to access the VMs if they have static IP addresses. Also it is easier for management and debugging.

I created a script for control the creating and assigning of ip address of bridge (eth2)

#!/bin/bash
 
 
function networkstart {
 
        #create bridge
        brctl addbr eth2
        #set address
        /sbin/ifconfig eth2 145.100.106.81 netmask 255.255.255.240 broadcast 145.100.106.95 up
        #enable routing function
        echo "1" > /proc/sys/net/ipv4/ip_forward
        #restart DHCP server
        service dhcpd start
}
 
 
function networkstop  {
 
        #stop DHCP service
        service dhcpd stop
        #bring down the interface
        /sbin/ifconfig eth2 down
        #remove the bridge
        brctl delbr eth2
}
function restart {
        networkstop
        networkstart
}
 
case "$@" in
 
    start)
        networkstart
        ;;
 
    stop)
        networkstop
        ;;
 
    restart)
        networkrestart
        ;;
 
    *)
        echo "Command usage: " >&2
        echo "network1 start|stop|restart" >&2
        exit 1
esac

the usage is ./network1 start|stop|restart

<hi #808000>Improvement on where to call the control script</hi>
I change the /etc/xen/scripts/network-bridge and call the script from the corresponding op_start and op_stop method. And cp the original one as netowrk-bridge.original

+ <code bash>

. op_start () {

  /home/vic/startxen networkstart

. . op_stop () {

  /home/vic/startxen networkstop

. #add a restart function op_restart () {

  /home/vic/startxen restart

}

#this is now the case switch for starting, stopping and restarting the xen

  start)
      op_start
      ;;
  
  stop)
      op_stop
      ;;
  restart)
      op_restart
      ;;
  status)
      show_status ${netdev} ${bridge}
      ;;

</code>

The start will add the bridge, assign the ip address, bring up the interface and then restart the DHCP server since the DHCP might fail before the eth2 is added. stop will do the opposite stop the DHCP server, take down the bridge and then remove it. restart will just restart the whole procedure by first stop then start .

Anything else in the first parameter, will let the script show the usage.

vic@rome:~$ ./network1 aaa
Command usage:
network1 start|stop|restart