IT From All Angles

I have always been a big fan of Hyper-V, and was actually a Virtualization MVP 2 years in a row.  However recently I haven’t been able to get past the really poor support for Linux on the Hyper-V platform.  We run a large number of hypervisors in our international sales offices (15+) and have a need to run both Linux and Windows on them.  This has necessitated our switch to Linux-KVM as their Windows support is far better than Hyper-V’s Linux support.  As such with an upcoming trip planned to our European offices I have been planning exactly how our migration will look, of course the first iteration of this plan consisted of me deploying replacement VMs on the KVM stack then migrating to the VMs individually.  Though this plan was lengthy and cumbersome it would work.

Thus it was time to set out on a journey of laziness.  I started by investigating physical to virtual conversion utilities and unfortunately KVM doesn’t seem to have a lot of value in this area.  So I started looking at some more basic methods of accomplishing my task.  Enter kvm-img (also called qemu-img) this is basic disk management utility that you will use to create image files, monitor their growth, snapshot, basically anything to do with managing a disk image…  Including converting from one format to another.  Wait, what formats?

raw – The most simple file format and can be mounted locally

qcow2 – The most versatile file format supporting layered images, encryption, compression, and snapshots although there seems to be some performance issues

vdi – Virtualbox 1.1 compatible image format

vmdk – VMWare 3 and 4 compatible image format

vpc – VirtualPC compatible image format

I left out some formats which aren’t terribly useful, for more information see the man pages.  Now lets review VirtualPC and Virtual Server were the precursors to Hyper-V.  However with the advent of Hyper-V we lost the compatibility of VMs between Hyper-V and Virtual PC.  Or did we?  It was true that you could not take a Hyper-V VM with the Integration Services installed and run it on Virtual PC.  Though the issue was never the VHD format.  That specification remained the same.  The actual issue was that when you installed the Hyper-V Integration Services it forced the install of an APIC HAL, and since Virtual PC did not support an APIC HAL it would fail to boot.  Now since Hyper-V does support APIC this should not be a problem.  Assuming that we can successfully convert it.

Conversion Command from VHD to a Raw Image

# kvm-img convert -f vpc -O raw /kvm/images/disk/disk.vhd /kvm/images/disk/disk.img

Above you will see the -f option indicates the format of the source image and the -O (capital “o”) then followed by the path to the source file and the path to the output file.

I was able to successfully convert a Windows 2003 Server amd64 as well as Windows 2008 R2 Standard.  Once converted I was able to create a VM and boot it straight away.  On the Windows 2003 VM I needed to uninstall the Integration Components, though 2008 R2 includes them in the kernel so it was not necessary to uninstall them.

So obviously the next thing I thought of is that if kvm-img supports vpc as a file format, perhaps KVM can boot it.  Well it can.  So if you are so inclined you could simply copy the file from the Hyper-V server to the KVM server and start it (and uninstall the Integration Components if applicable) I plan on investigating the perfomance implications of this choice though that is not part of this article.

Also please keep in mind that you will need to install the VirtIO drivers into your Windows VMs in order to take advantage of the VirtIO Interface of Storage and Network.  If you do this your performance is very fast.  I will most likely document this in a future article though this is fairly well documented on the Internet currently.

Windows guests on the KVM hypervisors can get a very large kick in the pants when it comes to performance if you install the drivers necessary to leverage the VirtIO bus.  So first here are the necessary download links so that you can download the drivers.

http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/virtio-win-1.1.16.iso

http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/

Inside of the ISO we will find four directories Balloon, NetKVM, vioserial, and viostor.  We are only concerned with viostor and NetKVM, for the storage and networking drivers.  Vioserial is a serial interface which essentially lifts the single serial device limitation within KVM, and Balloon is a balloon memory driver I personally do not find this necessary due to the efficacy of the Kernel Samepage Merging (KSM) which is essentially memory deduplication.

Now when you are going to install the guest you need to install it with the IDE interface disks and the e1000 or rtl8139 network card in order to use the devices.  Once the install is completed, you can switch the NIC to virtio, attach a secondary disk using the VirtIO interface instead of IDE, and mount the VirtIO driver iso image as your CDROM and then install the device drivers as the new hardware is detected.  Also I noticed that when I installed the XP Guest my video controller did not detect a driver under Windows XP Pro x86, however if I switched the Video Model to cirrus it worked fine and detected the device properly.  If you are using virt-install to create the VM you can use the –video=cirrus parameter.  Once you have your devices installed properly a quick peak at Device Manager inside of the guest should reveal the VirtIO devices.

You can see the devices in question the “Red Hat VirtIO SCSI controller” and the “Red Hat VirtIO Ethernet Adapter.”

When I first started using KVM, I was quite disappointed with the graphical management abilities of KVM.  Basically if you want to manage via the command line KVM is a fantasical dream world where anything is possible and it is all “musical sunshine” and “double rainbows” but if you want the ability to manage graphically it was a world which was very one sided in that if you wanted the ability to graphically manage your VMs then you had to use Linux.  Or so I thought…

Graphical Management of Guests

The standard utility for graphical management of guests is virt-manager which is comparable to Hyper-V Manager, in that it can manage the specifics of a given virtual machine on either a local or remote server.  You can also connect to the console regardless of network connectivity, and create and destroy guests.  This is not enterprise management, for that you would need to look at Convirt or RHEV.  Now as you will see there is no Windows version of Virt-Manager.  So how can we use Windows to graphically manage KVM?  X11 Forwarding through SSH.  This requires 2 bits of software to be installed on the Windows machine (1) a X Window Server, I used XMing which is freely available (2) a SSH Client, XMing will install PuTTy for you, if you are using a different X Window Server you may or may not need to install PuTTy manually.

When installing XMing simply accept all defaults.  Then to initiate the connection, launch XMing which will launch into the background.  Then setup your PuTTy connection and under the SSH options enable X11 Forwarding.  Then initiate your connection to the server and launch virt-manager.

On the server side the only configuration that needs to take place is the installation of the utility you wish to use (virt-manager, virt-viewer, etc).

Figure 1 – Showing the X Window server (XMing) running in the taskbar.

Figure 2 – Showing the X11 Forwarding configuration for PuTTy connections.

Figure 3 – Showing the PuTTy session where we launch the virt-manager utility which is running in the background.

Figure 4 – Showing the Console view of a VM via virt-manager running in Windows 7 by X11 Forwarding.

Figure 5 – Showing the Details view of a VM via virt-manager running in Windows 7 by X11 Forwarding.

One small caveat that I have noticed with this configuration, when redirecting X, virt-manager does not close all of the processes it is using when you close it, thus when you go to exit the PuTTy session it hangs.  If you close your X Window server on Windows (in my case XMing) it will close your PuTTy as well (as long as you have already exited from the session).  If you are redirecting X on Linux, a control + c will kill the process.

Disk images have long been the traditional form of storage for virtualized environments, they are essentially containers in the form of a file on the host’s file system.  These files can be either fully allocated or sparsely allocated at time of disk creation, a fully allocated 20GB disk image will take up 20GB of storage on the host file system, a sparsely allocated 20GB disk image will only take up as much storage on the host file system as has actually been written inside of the disk, so if you have a newly created sparse file the file will be just a few KB in size.

Disk images can be very flexible, especially if they have been sparsely allocated.  This allows you to move VM files between hosts as needed, if they have not been sparsely allocated it could potentially take too long to do any sort of move from one host to another.  If you are using shared storage this can reduce some of the issues relating to large disk images.

When I use disk images I prefer to create them via the virt-install script, however if you’d like to manually create them you could use kvm-img (also known as qemu-img).

View Disk Image Information

# kvm-img info /kvm/images/disk/disk.img

Create a Raw Image (Sparse)

# kvm-img create -f raw /kvm/images/disk/disk.img 20G

Create a QCow2 Image (Sparse)

# kvm-img create -f qcow2 /kvm/images/disk/disk.img 20G

Create Snapshots (qcow2)

# kvm-img snapshot -c snapshot01 /kvm/images/disk/disk.img

List Snapshots (qcow2)

# kvm-img snapshot -l /kvm/images/disk/disk.img

Apply Snapshots (qcow2)

# kvm-img snapshot -a snapshot01 /kvm/images/disk/disk.img

Delete Snapshots (qcow2)

# kvm-img snapshot -d snapshot01 /kvm/images/disk/disk.img

Create Layered Images (qcow2)

# kvm-img create -f qcow2 /kvm/images/disk/base.img 20G
# kvm-img create -f qcow2 -o backing_file=/kvm/images/disk/base.img /kvm/images/disk/disk.img
# kvm-img info /kvm/images/disk/disk.img
image: disk.img
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 136K
cluster_size: 65536
backing file: /kvm/images/disk/base.img (actual path: /kvm/images/disk/base.img)

Commit Image Changes into Backing Image (qcow2)

# kvm-img commit -f qcow2 /kvm/images/disk/disk.img

One of the most important things to keep in mind is when you are moving sparse images you need to ensure that you move it in such a way that you honor the “holes” in the file.  This ensures that after the copy you still have a sparse file.

Copy Sparse File with cp

# cp --sparse=always /kvm/images/disk/sparse.img /kvm/images/disk/newsparse.img

Copy Sparse File with rsync (Locally)

# rsync -S /kvm/images/disk/sparse.img /kvm/images/disk/newsparse.img

Copy Sparse File with rsync (Remotely)

# rsync -S /kvm/images/disk/sparse.img root@remotehost:/kvm/images/disk/newsparse.img

In addition to disk images there is a different (read: better) way of managing guest storage.  LVM Logical Volumes are incredibly flexible, they can be moved from one disk to another, they can be expanded (up to the limitations of the hardware).  The one inflexible portion of logical volumes through LVM is that there is no way to provide sparse storage.  This is my preferred method, as it is fairly standard when it comes to administration between a physical and a virtual machine.  In another article Linux LVM2: Flexible Local Storage Management I have detailed how you would go about expanding a LVM logical volume as well as how to perform a snapshot.  In my environment all of my production VMs run off of LVs however I keep my base images in the form a base image file which can be pasted onto an LV when it is time to put them into production.  In my article Linux-KVM: Converting Raw Disk Images to LVM Logical Volumes to see how you can implement this as well.

Today we are going to discuss using the underlying XML which libvirt uses to define a VM to either create VMs or to make simple changes.  This method has the advantage of more control over what you are creating, although it is more manual.  Now first off, when you use virt-install, virt-manager, or another tool which uses libvirt under the covers an XML file is created for every VM that you define, libvirt stores these in  /etc/libvirt/qemu/ and names them vmname.xml.

View VMs XML Configuration

# virsh dumpxml vmname

Example XML

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

<domain type='kvm'>
<name>vmname</name>
<uuid>8ca8ebe2-1eaa-1de6-b110-9823b99297ba</uuid>
<memory>2097152</memory>
<currentMemory>2097152</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='pc-0.12'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='localtime'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/kvm/images/disk/vmname_boot.img'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/kvm/images/iso/cdimage.iso'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' unit='0'/>
</disk>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<interface type='bridge'>
<mac address='52:54:00:07:ab:b0'/>
<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='-1' autoport='yes' keymap='en-us'/>
<video>
<model type='vga' 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='0x05' function='0x0'/>
</memballoon>
</devices>
</domain>

Above you will see an example XML which we will talk about.  Additionally I will have some different configuration examples below after we have discussed the different areas of the file.

Line 2 contains the VMs Name and can be changed to reflect the name of the new VM.

Line 3 is the UUID of the VM, this needs to be unique, so you can either generate and input one manually, or you can choose the super duper easy method and delete this entire line and allow libvirt to plug it in for you.

Lines 4 & 5 are the Memory Values these must match each other, although I suspect if you are using a balloon driver you could use that here.

Line 6 allows you to specify the number of virtual CPUs the guest will have.

Lines 22-27 specifies the virtual disk which the VM will use.  Line 24 contains the path of the image, which you will want to reflect your path.

Lines 28-34 specifies the virtual cdrom device.  Line 30 contains the path of the image, I like to have a cdrom if I need it but don’t necessarily want an image mounted.  If you don’t want an image, remove line 30 completely.

Line 38-43 specifies the virtual network card, obviously with networking duplicate MACs is a bad thing, so you can either specify a unique MAC or you can as with the UUID remove line 39 in its entirety.

Line 44-49 specifies the virtual serial device.  You should not need to adjust this.

Line 52 specifies the method with which you can connect to the console of the guest, which is most likely going to be VNC.  However one thing to watch here is for listen=0.0.0.0 this will allow all machines to connect to your guests via VNC without a password (so if the console was not locked this would be a problem).  If listen is not defined then it defaults to listen=127.0.0.1 which is what you actually want.

Line 53-56 specifies the virtual video card, the only thing I have had to adjust here is for Windows XP guests I use the cirrus type on line 54, XP doesn’t have a driver for vga.

Below you will find a series of “templates” meaning that I have removed the automatically generated lines so all you would need to do is copy these and then adjust the names and paths of the devices as I outlined above.  The only thing to keep in mind is the Video, if you are running Windows XP you will want to switch the video type to cirrus.  It didn’t make sense to do that for you.  The only other bit that we have not covered is the actual creation of VMs.  This is the ridiculously easy part.

Create a VM

# virsh define vmname.xml

Start a VM

# virsh start vmname

Create and Start a VM

# virsh create vmname.xml

Shutdown a VM

# virsh shutdown vmname

Poweroff a VM (Pull the Plug)

I know this sounds really scary and counter-intuitive, however the destroy parameter actually refers to the fact that you are destroying the contents of the memory.  They also don’t want you to get used to using this instead of a more orderly shutdown.

# virsh destroy vmname

Delete a VMs Configuration (Does not delete disk images)

# virsh undefine vmname

Edit a Defined VMs Configuration

# virsh edit vmname

Libvirt XML Template (Single Disk with VirtIO, Empty CDROM)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

<domain type='kvm'>
<name>vmname</name>
<memory>2097152</memory>
<currentMemory>2097152</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='pc-0.12'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='localtime'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/kvm/images/disk/vmname_boot.img'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/kvm/images/iso/cdimage.iso'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' unit='0'/>
</disk>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<interface type='bridge'>
<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='-1' autoport='yes' keymap='en-us'/>
<video>
<model type='vga' 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='0x05' function='0x0'/>
</memballoon>
</devices>
</domain>

Libvirt XML Template (Single Disk without VirtIO, Empty CDROM)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

<domain type='kvm'>
<name>vmname</name>
<memory>2097152</memory>
<currentMemory>2097152</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='pc-0.12'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='localtime'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/kvm/images/disk/vmname_boot.img'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' unit='0'/>
</disk>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<interface type='bridge'>
<source bridge='br0'/>
<model type='e1000'/>
<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='-1' autoport='yes' keymap='en-us'/>
<video>
<model type='vga' 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='0x05' function='0x0'/>
</memballoon>
</devices>
</domain>

Libvirt XML Template (Multiple Disks with VirtIO, Empty CDROM)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

<domain type='kvm'>
<name>vmname</name>
<memory>2097152</memory>
<currentMemory>2097152</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='pc-0.12'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='localtime'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/kvm/images/disk/vmname_boot.img'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/kvm/images/disk/vmname_data_1.img'/>
<target dev='vdb' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' unit='0'/>
</disk>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<interface type='bridge'>
<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='-1' autoport='yes' keymap='en-us'/>
<video>
<model type='vga' 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='0x05' function='0x0'/>
</memballoon>
</devices>
</domain>

Libvirt XML Template (Multiple Disks without VirtIO, Empty CDROM)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

<domain type='kvm'>
<name>vmname</name>
<memory>2097152</memory>
<currentMemory>2097152</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='pc-0.12'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='localtime'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/kvm/images/disk/vmname_boot.img'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' unit='0'/>
</disk>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/kvm/images/disk/vmname_data_1.img'/>
<target dev='hdb' bus='ide'/>
<address type='drive' controller='0' bus='0' unit='1'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' unit='0'/>
</disk>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<interface type='bridge'>
<source bridge='br0'/>
<model type='e1000'/>
<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='-1' autoport='yes' keymap='en-us'/>
<video>
<model type='vga' 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='0x05' function='0x0'/>
</memballoon>
</devices>
</domain>