- Users - libvirt List Archives

[libvirt-users] W2k3 with more than one QXL video card
by Ruzsinszky Attila 12 Aug '15

12 Aug '15

Hi, Is that possible? If I start in normal VGA mode I can see yellow ! next to the 2nd and 3rd QXL card and Win complains about can't start (Code 10). If I want to change the normal VGA resolution in a higher res (for example 800x600) I got black screen in virt-manager. I use SPICE protocol (for more screens). Any solution? W2k3 R2 Ent. Ed. SP2 TIA, Ruzsi

2 2

[libvirt-users] Do I need to enable qemu-ga's guest-suspend: hybrid/suspend-ram/disk/shutdown?
by james harvey 11 Aug '15

11 Aug '15

How do I "enable" qemu-ga on a guest to be able to (I think this means have a success-response:true) for: guest-suspend-hybrid; guest-suspend-ram; guest-suspend-disk; and guest-shutdown? At least I think that's my question. http://wiki.stoney-cloud.org/wiki/Qemu_Guest_Agent_Integration shows these same 4 as false, so I'm not sure if they're always supposed to be that way. My overall point is to be able to run dompmsuspend servo disk. After setting up qemu-ga as far as I have, it at least says: ===== Domain <vmname> successfully suspended ===== But, Using libvirt 1.2.18 (-1 Arch) and QEMU git-master (2.4.0.r40384.2d69736). pm-utils 1.4.1-6. acpid 2.0.23-4 Installed using Q35 chipset. ====== {{{ domain xml file includes: }}} <pm> <suspend-to-mem enables='yes'/> <suspend-to-disk enables='yes'/> </pm> ... <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/<vmname>.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='2'/> </channel> ===== client # qemu-ga --verbose debug: received EOF {{{ server: virsh # shutdown <vmname> --mode agent error: Failed to shutdown domain <vmname> error: internal error: unable to execute QEMU agent command 'guest-shutdown': child process has failed to shutdown }}} debug: read data, count: 59, data: {"execute":"guest-sync", "arguments":{"id":1439251067706}} debug: process_event: called debug: processing command debug: sending data, count: 26 debug: read data, count: 62, data: {"execute":"guest-shutdown","arguments":{"mode":"powerdown"}} debug: process_event: called debug: processing command debug: sending data, count: 85 ===== {{{ server: virsh # qemu-agent-command <vmname> '{"execute":"guest-ping"}' {"return":{}} }}} debug: read data, count: 59, data: {"execute":"guest-sync", "arguments":{"id":1439251455241}} debug: process_event: called debug: processing command debug: sending data, count: 26 debug: read data, count: 25, data: {"execute":"guest-ping"} debug: process_event: called debug: processing command debug: sending data, count: 15 ===== {{{ server - the json-type data is all on one line - i broke it up: virsh # qemu-agent-command servo '{"execute":"guest-info"}' {"return": {"version":"2.3.94","supported_commands": [{"enabled":true,"name":"guest-get-memory-block-info","success-response":true}, {"enabled":true,"name":"guest-set-memory-blocks","success-response":true}, {"enabled":true,"name":"guest-get-memory-blocks","success-response":true}, {"enabled":true,"name":"guest-set-user-password","success-response":true}, {"enabled":true,"name":"guest-get-fsinfo","success-response":true}, {"enabled":true,"name":"guest-set-vcpus","success-response":true}, {"enabled":true,"name":"guest-get-vcpus","success-response":true}, {"enabled":true,"name":"guest-network-get-interfaces","success-response":true}, {"enabled":true,"name":"guest-suspend-hybrid","success-response":*false*}, {"enabled":true,"name":"guest-suspend-ram","success-response":*false*}, {"enabled":true,"name":"guest-suspend-disk","success-response":*false*}, {"enabled":true,"name":"guest-fstrim","success-response":true}, {"enabled":true,"name":"guest-fsfreeze-thaw","success-response":true}, {"enabled":true,"name":"guest-fsfreeze-freeze-list","success-response":true}, {"enabled":true,"name":"guest-fsfreeze-freeze","success-response":true}, {"enabled":true,"name":"guest-fsfreeze-status","success-response":true}, {"enabled":true,"name":"guest-file-flush","success-response":true}, {"enabled":true,"name":"guest-file-seek","success-response":true}, {"enabled":true,"name":"guest-file-write","success-response":true}, {"enabled":true,"name":"guest-file-read","success-response":true}, {"enabled":true,"name":"guest-file-close","success-response":true}, {"enabled":true,"name":"guest-file-open","success-response":true}, {"enabled":true,"name":"guest-shutdown","success-response":*false*}, {"enabled":true,"name":"guest-info","success-response":true}, {"enabled":true,"name":"guest-set-time","success-response":true}, {"enabled":true,"name":"guest-get-time","success-response":true}, {"enabled":true,"name":"guest-ping","success-response":true}, {"enabled":true,"name":"guest-sync","success-response":true}, {"enabled":true,"name":"guest-sync-delimited","success-response":true}]}} }}} =====

2 3

[libvirt-users] libvirt-guests.service doesn't work, but manually running libvirt-guests.sh stop does
by james harvey 11 Aug '15

11 Aug '15

Using libvirt 1.2.18 (-1 Arch) and QEMU git-master (2.4.0.r40384.2d69736). pm-utils 1.4.1-6. acpid 2.0.23-4 Installed using Q35 chipset. I can perform virsh # shutdown <vmname>, and watching the client VM console see a graceful shutdown. On host: ===== # systemctl reboot {{{ client VM console immediately blanks out - I do NOT see a graceful shutdown }}} libvirt-guests.sh: Running guests on default URI: <vmname> libvirt-guests.sh: Shuitting down guests on default URI... libvirt-guests.sh: Starting shutdown on guest: <vmname> libvirt-guests.sh: Waiting for 1 guests to shut down, 300 seconds left A stop job is running for Suspend Active Libvirt Guests... libvirt-guests.sh: Waiting for 1 guests to shut down ===== In about 85 seconds, it moves past this, but guest was not suspended or gracefully shutdown. Guest's "last" shows a crash. And, watching on the VM console, the minute systemctl restart runs on the host, the VM console disconnects. ===== # systemctl status libvirt-guests ● libvirt-guests.service - Suspend Active Libvirt Guests Loaded: loaded (/usr/lib/systemd/system/libvirt-guests.service; enabled; vendor preset: disabled) Active: active (exited) since Mon 2015-08-10 20:27:57 EDT; 6s ago Docs: man:libvirtd(8) http://libvirt.org Process: 751 ExecStart=/usr/lib/libvirt/libvirt-guests.sh start (code=exited, status=0/SUCCESS) Main PID: 751 (code=exited, status=0/SUCCESS) ===== $ cat /etc/conf.d/libvirt-guests BYPASS_CACHE=0 CONNECT_RETRIES=10 ON_BOOT=start ON_SHUTDOWN=shutdown PARALLEL_SHUTDOWN=4 RETRIES_SLEEP=1 SHUTDOWN_TIMEOUT=300 START_DELAY=0 URIS=default ===== A virsh # shutdown <vmname> or an in-guest systemctl poweroff takes a few seconds (3-5?) ===== {{{ libvirt-guests.service is: }}} [Unit] Description=Suspend Active Libvirt Guests After=network.target libvirtd.service time-sync.target Documentation=man:libvirtd(8) Documentation=http://libvirt.org [Service] EnvironmentFile=-/etc/conf.d/libvirt-guests # Hack just call traditional service until we factor # out the code ExecStart=/usr/lib/libvirt/libvirt-guests.sh start ExecStop=/usr/lib/libvirt/libvirt-guests.sh stop Type=oneshot RemainAfterExit=yes StandardOutput=journal+console [Install] WantedBy=multi-user.target ===== Strangely, manually running "/usr/lib/libvirt/libvirt-guests.sh stop" lets me see a graceful shutdown on the VM console and shows (executing in a few seconds): Running guests on default URI: <vmname> Shutting down guests on default URI... Starting shutdown on guest: <vmname> Waiting for 1 guests to shut down, 300 seconds left Shutdown of guest <vmname> complete. =====

1 0

[libvirt-users] managedsave/start causes IRQ and task blocked for more than 120 seconds errors
by james harvey 11 Aug '15

11 Aug '15

If I manually delete the Q35 USB Controllers, I can use managedsave/start, but I start getting tty errors that don't happen before the managedsave/start. Using libvirt 1.2.18 (-1 Arch) and QEMU git-master (2.4.0.r40384.2d69736). Installed using Q35 chipset. I'm running QEMU git, which allows SCSI controller migration, so I can attempt doing this. I started my guest, and waited for 15 minutes. No post-booting tty1/dmesg messages. After a managedsave/start, I start getting tty1/dmesg errors. I can also no longer ping the guest system. ===== $ dmesg|grep "IRQ 21" [ 1.141040] ACPI: PCI Interrupt Link [GSIF] enabled at IRQ 21 $ ls -lA /proc/irq/21 total 0 -r--r--r-- 1 root root 0 Aug 10 19:42 affinity_hint -r--r--r-- 1 root root 0 Aug 10 19:42 node dr-xr-xr-x 2 root root 0 Aug 10 19:42 qxl -rw-r--r-- 1 root root 0 Aug 10 19:42 smp_affinity -rw-r--r-- 1 root root 0 Aug 10 19:42 smp_affinity_list -r--r--r-- 1 root root 0 Aug 10 19:42 spurious dr-xr-xr-x 2 root root 0 Aug 10 19:42 virtio2 $ ls -lA /proc/irq/21/qxl total 0 $ ls -lA /proc/irq/21/virtio2 total 0 ===== {{{ on host, everything else is on guest }}} virsh # managedsave <vmname> Domain servo state saved by libvirt virsh # start <vmname> Domain <vmname> started ===== [ 1117.083236] irq 21: nobody cared (try booting with the "irqpoll" option) [ 1117.083236] handlers: [ 1117.083236] [<ffffffffa00cfc60>] qxl_irq_handler [qxl] [ 1117.083236] [<ffffffffa00f2530>] vp_interrupt [virtio_pci] [ 1117.083236] Disabling IRQ #21 ===== {{{ bit later, doing nothing, just waiting }}} [ 1440.223239] INFO: task vballoon:147 blocked for more than 120 seconds. [ 1440.223409] Not tainted 4.1.4-1-ARCH #1 [ 1440.223556] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1440.223805] INFO: task btrfs-transacti:242 blocked for more than 120 seconds. [ 1440.223947] Not tainted 4.1.4-1-ARCH #1 [ 1440.224069] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1440.224422] INFO: task systemd-journal:280 blocked for more than 120 seconds. [ 1440.224575] Not tainted 4.1.4-1-ARCH #1 [ 1440.224710] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. {{{ these message lines show up very slowly, as if the VM console video is running at 1% speed }}} ===== {{{ bit later, doing nothing, just waiting }}} [ 1560.223227] {{{ repeats the above 9 lines, vballoon:147/btrfs-transacti:242/systemd-journal:280] blocked for more than 120 seconds }}} ===== {{{ bit later, doing nothing, just waiting }}} [ 1680.223217] {{{ repeats the above 9 lines, vballoon:147/btrfs-transacti:242/systemd-journal:280] blocked for more than 120 seconds }}} [ 1688.885605] systemd[1]: systemd-journald.service: Watchdog timeout (limit 1min)! =====

1 0

[libvirt-users] managedsave/start fails because of Q35 UHCI Host Controller
by james harvey 11 Aug '15

11 Aug '15

managedsave/start appears to work, but VM is unusable due to non-stop repeating uhci_hcd errors. I can't remove the USB controller from QEMU, but I CAN remove it through virsh edit. Doing so eliminates the USB controller in the guest, preventing non-stop repeating uhci_hcd errors. (QEMU only lets you remove the USB redirection entries, which didn't help.) Using libvirt 1.2.18 (-1 Arch) and QEMU git-master (2.4.0.r40384.2d69736). Installed using Q35 chipset. I'm running QEMU git, which allows SCSI controller migration, so I can attempt doing this. ========== virsh # managedsave <vmname> Domain <vmname> state saved by libvirt virsh # start <vmname> Domain <vmname> started {{{ Then, viewing the VM console through QEMU, its screen is extremely laggy, taking about a minute to fill up the screen with repeating errors within 0.003 kernel seconds: }}} uhci_hcd 0000:02:02.2: host system error, PCI problems? uhci_hcd 0000:02:02.2: host controller process error, something bad happened! {{{ repeats }}} ========== {{{ after a forced reboot }}} $ dmesg|grep 0000:02:02 [ 0.480054] pci 0000:02:02.0: [8086:2934] type 00 class 0x0c0300 [ 0.498451] pci 0000:02:02.0: reg 0x20: [io 0xc0e0-0xc0ff] [ 0.506965] pci 0000:02:02.1: [8086:2935] type 00 class 0x0c0300 [ 0.525101] pci 0000:02:02.1: reg 0x20: [io 0xc100-0xc11f] [ 0.533634] pci 0000:02:02.2: [8086:2936] type 00 class 0x0c0300 [ 0.554992] pci 0000:02:02.2: reg 0x20: [io 0xc120-0xc13f] [ 0.563642] pci 0000:02:02.7: [8086:293a] type 00 class 0x0c0320 [ 0.566679] pci 0000:02:02.7: reg 0x10: [mem 0xfc041000-0xfc041fff] [ 1.720668] ehci-pci 0000:02:02.7: EHCI Host Controller [ 1.720709] ehci-pci 0000:02:02.7: new USB bus registered, assigned bus number 1 [ 1.721343] ehci-pci 0000:02:02.7: irq 22, io mem 0xfc041000 [ 1.730198] ehci-pci 0000:02:02.7: USB 2.0 started, EHCI 1.00 [ 1.740641] uhci_hcd 0000:02:02.0: UHCI Host Controller [ 1.740667] uhci_hcd 0000:02:02.0: new USB bus registered, assigned bus number 2 [ 1.740813] uhci_hcd 0000:02:02.0: detected 2 ports [ 1.741026] uhci_hcd 0000:02:02.0: irq 23, io base 0x0000c0e0 [ 1.747517] uhci_hcd 0000:02:02.1: UHCI Host Controller [ 1.747543] uhci_hcd 0000:02:02.1: new USB bus registered, assigned bus number 3 [ 1.747664] uhci_hcd 0000:02:02.1: detected 2 ports [ 1.747904] uhci_hcd 0000:02:02.1: irq 20, io base 0x0000c100 [ 1.753055] uhci_hcd 0000:02:02.2: UHCI Host Controller [ 1.753074] uhci_hcd 0000:02:02.2: new USB bus registered, assigned bus number 4 [ 1.753624] uhci_hcd 0000:02:02.2: detected 2 ports [ 1.753724] uhci_hcd 0000:02:02.2: irq 21, io base 0x0000c120 ==========

1 0

Re: [libvirt-users] machine='pc-q35-2.1' and sata controller
by Michael Darling 10 Aug '15

10 Aug '15

What's the status of the SATA controller migration bug? Are the patches for it expected to be in 2.4? Looks like they didn't make it into 2.3. Since you last wrote, if the SATA controller patches aren't in yet, is there any new way to avoid the SATA controller device, if you have no SATA devices? Thank you. === REPLYING TO === On 02/23/2015 02:26 PM, Thomas Stein wrote: > Hello. > > I'm not able to disable the sata controller on a machine='pc-q35-2.1' type VM. > Whenever i delete: > > <controller type='sata' index='0'> > <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' > function='0x2'/> > </controller> > > it gets added again when i close the editor. > > The reason i would like to delete the sata controller is this error while > trying to migrate the machine: > > 2015-02-23 19:04:11.181+0000: 1972: error : qemuMonitorJSONCheckError:381 : > internal error: unable to execute QEMU command 'migrate': State blocked by > non-migratable device '0000:00:1f.2/ich9_ahci' > > Someone has an idea to solve this? > Yep. You have described the situation perfectly. Here are my notes from libvirt commit c27b0bb171d9bdac10a93492a2a99eaa22746694, which fixed the handling of "default" devices in the Q35 machinetype: sata - a q35 machine always has a sata controller implicitly added at slot 0x1F, function 2. There is no way to avoid this controller, so we always add it. Note that the xml2xml tests for the pcie-root and q35 cases were changed to use DO_TEST_DIFFERENT() so that we can check for the sata controller being automatically added. This is especially important because we can't check for it in the xml2argv output (it has no effect on that output since it's an implicit device). So basically when you specify a q35 machinetype, you get a SATA controller at 00:1f.2 even though you have added no commandline args to ask for it. And unlike the default network device (which libvirt can eliminate by adding "-net none" to the qemu commandline), there is no way to avoid this device. And it is also true that any machine with a SATA controller can't be migrated because of problems with the driver. I just talked to the person responsible for fixing these bugs in qemu, and he said that the patches will go upstream "soon", and that he hopes they will be in qemu 2.3. In the meantime, the only way to avoid this problem is to switch to an i440fx-based machinetype (this will require removing all the pci controllers from your config as well as removing all <address type='pci' .../> elements within all devices in the domain; libvirt will then reassign PCI addresses in the guest appropriate to the new machine type. IMPORTANT: If the guest is running MS Windows, this may require a new "activation"; best to keep a copy of the old config and an image of the disk just in case there are problems!)

3 2

[libvirt-users] NVidia Grid on libvirt.
by Dominique Ramaekers 10 Aug '15

10 Aug '15

Hi, I'm investigating the possibility to use a Nvidia Grid graphics card to use in libvirt. I found this resource on the subject from the end of 2014: http://www.linux-kvm.org/images/b/b3/01x09b-VFIOandYou-small.pdf It should be possible. However libvirt didn't support it at that time. Does anyone has experience on the subject? Greetings, Dominique.

2 1

[libvirt-users] NVidia Grid on libvirt.
by Dominique Ramaekers 08 Aug '15

08 Aug '15

Hi, I'm investigating the possibility to use a Nvidia Grid graphics card to use in libvirt. I found this resource on the subject from the end of 2014: http://www.linux-kvm.org/images/b/b3/01x09b-VFIOandYou-small.pdf It should be possible. However libvirt didn't support it at that time. Does anyone has experience on the subject? Greetings, Dominique.

1 0

[libvirt-users] Enabling capabilities in a container
by Peter Steele 08 Aug '15

08 Aug '15

I'm using libvirt_lxc to create and manage various containers. I need to enable certain capabilities in a container to support ctdb, and as a quick solution I decided to just enable them all. I *thought* this would do the trick, adding the following XML to my container config: <features> <capabilities policy='allow'> </capabilities> </features> After adding this to my container, I restarted it and tried to start the ctdb service again: # systemctl start ctdb.service Job for ctdb.service failed. See 'systemctl status ctdb.service' and 'journalctl -xn' for details. # systemctl status ctdb.service ctdb.service - CTDB Loaded: loaded (/usr/lib/systemd/system/ctdb.service; disabled) Active: failed (Result: exit-code) since Tue 2015-08-04 14:10:39 PDT; 8s ago Process: 4612 ExecStart=/usr/sbin/ctdbd_wrapper /run/ctdb/ctdbd.pid start (code=exited, status=1/FAILURE) Aug 04 14:10:37 pws-01 systemd[1]: Starting CTDB... Aug 04 14:10:37 pws-01 ctdbd[4629]: CTDB starting on node Aug 04 14:10:37 pws-01 ctdbd[4631]: Starting CTDBD (Version 2.5.4) as PID: 4631 Aug 04 14:10:37 pws-01 ctdbd[4631]: Created PID file /run/ctdb/ctdbd.pid Aug 04 14:10:37 pws-01 ctdbd[4631]: Unable to set scheduler to SCHED_FIFO (Operation not permitted) Aug 04 14:10:37 pws-01 ctdbd[4631]: CTDB daemon shutting down Aug 04 14:10:39 pws-01 ctdbd_wrapper[4612]: CTDB exited during initialisation - check logs. Aug 04 14:10:39 pws-01 systemd[1]: ctdb.service: control process exited, code=exited status=1 Aug 04 14:10:39 pws-01 systemd[1]: Failed to start CTDB. Aug 04 14:10:39 pws-01 systemd[1]: Unit ctdb.service entered failed state. This implies that the container still doesn't have access to the capabilities it needs to use. I believe this error in fact is caused by the container not having the sys_nice capability. So I tried to allow this specific capability using: <features> <capabilities policy='default'> <sys_nice state='on'/> </capabilities> </features> This did not work either. So, what *is* the correct way to add capabilities to a container?

1 1

[libvirt-users] Cannot boot libvirt guests with OVMF. Raw qemu-kvm works as expected
by Ryan Barry 07 Aug '15

07 Aug '15

Using: edk2.git-0-20150803.b1141.ga0973dc.x86_64 edk2.git-ovmf-x64-0-20150802.b1139.gb234418.noarch On Fedora 22. Provisioning a i440FX system in virt-manager and attempting to boot results in successful EFI initialization, but the VM exits ungracefully after the bootloader (with F22 and CentOS 7 installer images). There's no really useful information in any of the logs. Using qemu-kvm directly (qemu-kvm -bios /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd -m 1G -cdrom ~rbarry/Downloads/Fedora-Server-netinst-x86_64-22.iso) boots and loads successfully. What's the difference here? Where can I go for troubleshooting? libvirt XML is below: <domain type='kvm'> <name>fedora22</name> <uuid>7f363d28-881f-4240-97eb-9b8d49cfb282</uuid> <memory unit='KiB'>2097152</memory> <currentMemory unit='KiB'>2097152</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/var/lib/libvirt/qemu/nvram/fedora22_VARS.fd</nvram> </os> <features> <acpi/> <apic/> <pae/> </features> <cpu mode='custom' match='exact'> <model fallback='allow'>Haswell-noTSX</model> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <pm> <suspend-to-mem enabled='no'/> <suspend-to-disk enabled='no'/> </pm> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/fedora22.qcow2'/> <target dev='vda' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/home/rbarry/Downloads/Fedora-Server-netinst-x86_64-22.iso'/> <target dev='hda' bus='ide'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </controller> <interface type='network'> <mac address='52:54:00:35:b6:00'/> <source network='default'/> <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> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/fedora22.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <channel type='spicevmc'> <target type='virtio' name='com.redhat.spice.0'/> <address type='virtio-serial' controller='0' bus='0' port='2'/> </channel> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='spice' autoport='yes'> <image compression='off'/> </graphics> <sound model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <redirdev bus='usb' type='spicevmc'> </redirdev> <redirdev bus='usb' type='spicevmc'> </redirdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </memballoon> </devices> </domain>

2 6