# Correct way to move kvm vm?

**URL:** <https://forums.rockylinux.org/t/correct-way-to-move-kvm-vm/11320>\
**Category:** Rocky Linux Help & Support\
**Created:** [September 17, 2023, 3:01pm UTC](https://forums.rockylinux.org/t/correct-way-to-move-kvm-vm/11320 "2023-09-17T15:01:51Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![pseud](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/pseud/32/1323_2.png) [@pseud](https://forums.rockylinux.org/u/pseud)\
**Post date:** [September 17, 2023, 3:01pm UTC](https://forums.rockylinux.org/t/correct-way-to-move-kvm-vm/11320/1 "2023-09-17T15:01:51Z")

</div>

I wonder if someone can give me a pointer on where in this seemingly straight forward process I’ve gone awry. I’ve taken a quick pointer from [this brief Server Fault post](https://serverfault.com/questions/434064/correct-way-to-move-kvm-vm).

But, on the two machines I’m moving I end up with:

```auto
error: Failed to define domain from Win7.xml
error: unsupported configuration: domain configuration does not support video model 'qxl'

```

EDIT: Oops, should have done more home work on that one, answered [here](https://forums.rockylinux.org/t/libvirt-issue-domain-configuration-does-not-support-video-model-qxl/6752) a year ago…

And this one’s coming from a Debian (PureOS) based system - I wonder if binaries are in a different place or name? `which qemu-system-x86_64` or `qemu-system` brings up nothing:

```auto
error: Failed to define domain from Android-x86-9.0.xml
error: Cannot check QEMU binary /usr/bin/qemu-system-x86_64: No such file or directory

```

Here’s the whole process:

> **Summary**
>
> ```auto
> [root@frontserver ~]# virsh list --all
> Id Name State
> -----------------------
> - Win7 shut off
> 
> [root@frontserver ~]# virsh dumpxml Win7 > Win7.xml
> [root@frontserver ~]#
> 
> ```
> 
> ```auto
> [root@server ~]# rsync -avzXA root@frontserver.lan:/var/lib/libvirt/images/Win7.qcow2 /var/lib/libvirt/images/Win7.qcow2
> root@frontserver.lan's password: 
> receiving incremental file list
> 
> sent 20 bytes received 100 bytes 16.00 bytes/sec
> total size is 32,216,317,952 speedup is 268,469,316.27
> [root@server ~]#
> 
> ```
> 
> ```auto
> [root@server ~]# scp root@frontserver.lan:/root/Win7.xml /root/Win7.xml
> root@frontserver.lan's password: 
> Win7.xml 100% 5880 2.3MB/s 00:00    
> [root@server ~]#
> 
> ```
> 
> ```auto
> [root@server ~]# virsh define Win7.xml
> error: Failed to define domain from Win7.xml
> error: unsupported configuration: domain configuration does not support video model 'qxl'
> 
> [root@server ~]#
> 
> ```
> 
> And:
> 
> ```auto
> root@mysmachine:~# virsh list --all
> Id Name State
> ----------------------------------
> - Android-x86-9.0 shut off
> 
> root@mysmachine:~# virsh dumpxml Android-x86-9.0 > Android-x86-9.0.xml
> root@mysmachine:~#
> 
> ```
> 
> ```auto
> [root@server ~]# rsync -avzXA --progress root@mysmachine.lan:/home/libvirt/images/Android-x86.qcow2 /var/lib/libvirt/images/Android-x86.qcow2
> root@mysmachine.lan's password: 
> receiving incremental file list
> rsync: [receiver] rsync_xal_set: lremovexattr("/var/lib/libvirt/images/Android-x86.qcow2","security.selinux") failed: Permission denied (13)
> 
> sent 28 bytes received 96 bytes 16.53 bytes/sec
> total size is 15,034,941,440 speedup is 121,249,527.74
> rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1823) [generator=3.2.3]
> [root@server ~]# rsync -avz --progress root@mysmachine.lan:/home/libvirt/images/Android-x86.qcow2 /var/lib/libvirt/images/Android-x86.qcow2
> root@mysmachine.lan's password: 
> receiving incremental file list
> 
> sent 20 bytes received 88 bytes 12.71 bytes/sec
> total size is 15,034,941,440 speedup is 139,212,420.74
> [root@server ~]#
> 
> ```
> 
> ```auto
> [root@server ~]# scp root@mysmachine.lan:/root/Android-x86-9.0.xml /root/Android-x86-9.0.xml
> root@mysmachine.lan's password: 
> Android-x86-9.0.xml 100% 5242 287.7KB/s 00:00    
> [root@server ~]#
> 
> ```
> 
> ```auto
> [root@server ~]# virsh define Android-x86-9.0.xml
> error: Failed to define domain from Android-x86-9.0.xml
> error: Cannot check QEMU binary /usr/bin/qemu-system-x86_64: No such file or directory
> 
> [root@server ~]#
> 
> ```

---

<div class="post-metadata">

**Author:** ![pseud](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/pseud/32/1323_2.png) [@pseud](https://forums.rockylinux.org/u/pseud)\
**Post date:** [September 17, 2023, 4:00pm UTC](https://forums.rockylinux.org/t/correct-way-to-move-kvm-vm/11320/2 "2023-09-17T16:00:40Z")

</div>

> [@pseud](#):
>
> EDIT: Oops, should have done more home work on that one, answered [here](https://forums.rockylinux.org/t/libvirt-issue-domain-configuration-does-not-support-video-model-qxl/6752) a year ago…

I weep - what a absolute total flipping mess!  
(I realise I’m late to the party - would have been sooner if RH hadn’t dropped hardware support in 9 for my old laptop pressed into service as server…)  
After close to 20 years of Fedora I started looking for a bit more stability a couple of years ago and all I’ve found since is a mess…

---

<div class="post-metadata">

**Author:** ![pseud](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/pseud/32/1323_2.png) [@pseud](https://forums.rockylinux.org/u/pseud)\
**Post date:** [September 17, 2023, 4:39pm UTC](https://forums.rockylinux.org/t/correct-way-to-move-kvm-vm/11320/3 "2023-09-17T16:39:25Z")

</div>

Is the Jean-Marc Liger’s Paris City Uni [copr](https://copr.fedorainfracloud.org/coprs/ligenix/enterprise-qemu-spice/) repo the best answer atm?

EDIT:  
`dnf -y copr enable ligenix/enterprise-qemu-spice ; dnf update`

```auto
[root@server ~]# virsh define Win7.xml
Domain 'Win7' defined from Win7.xml

[root@server ~]#

```

Hope so…

---

<div class="post-metadata">

**Author:** ![jlehtone](https://avatars.discourse-cdn.com/v4/letter/j/e9a140/32.png) [@jlehtone](https://forums.rockylinux.org/u/jlehtone)\
**Post date:** [September 18, 2023, 8:53am UTC](https://forums.rockylinux.org/t/correct-way-to-move-kvm-vm/11320/4 "2023-09-18T08:53:50Z")

</div>

> [@pseud](#):
>
> `Cannot check QEMU binary /usr/bin/qemu-system-x86_64`

The binary seems to be: /usr/libexec/qemu-kvm in EL.

> [@pseud](#):
>
> ```auto
> error: Failed to define domain from Win7.xml
> error: unsupported configuration: domain configuration does not support video model 'qxl'
> 
> ```
> 
> EDIT: Oops, should have done more home work on that one, answered [here](https://forums.rockylinux.org/t/libvirt-issue-domain-configuration-does-not-support-video-model-qxl/6752) a year ago…

What I did was to first remove all QLX & spice devices from the VM in `virt-manager` that it could and switch graphics to “vnc” (and video to ‘virtio’). If something did block that, then `virsh edit domain_name`  
to delete the offending bits. That is, convert away from QLX/sprice _before_ the move.

---

<div class="post-metadata">

**Author:** ![pseud](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/pseud/32/1323_2.png) [@pseud](https://forums.rockylinux.org/u/pseud)\
**Post date:** [September 18, 2023, 1:21pm UTC](https://forums.rockylinux.org/t/correct-way-to-move-kvm-vm/11320/5 "2023-09-18T13:21:36Z")

</div>

Thanks @jlehtone - I actually installed the `copr` repo and that seems to doing the job while I scratch my head (again). It seems to be getting recent attention and updates.

I tracked down the binary too - it seems it moved from the `bin` to `libexec` location a few years back on `rpm` distros - but, there’s not much on that Android anyway and I might just reinstall it. Many thx, M

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/1X/91b7219eec10e30013422e4df76c1d898711a5d5.svg) [@system](https://forums.rockylinux.org/u/system)\
**Post date:** [November 17, 2023, 1:21pm UTC](https://forums.rockylinux.org/t/correct-way-to-move-kvm-vm/11320/6 "2023-11-17T13:21:38Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
