is removable disk used as datastore or as passthrough ?PBS VM on a removable disk
datastore! no passthrough. mounted external per CLI/crontab.is removable disk used as datastore or as passthrough ?
Hi,datastore! no passthrough. mounted external per CLI/crontab.
qm config <VMID>
for the PBS VM as well as the storage config cat /etc/pve/storage.cfg
to get a better insight in your current setup.Hi,Hi,
please share the VM configqm config <VMID>
for the PBS VM as well as the storage configcat /etc/pve/storage.cfg
to get a better insight in your current setup.
Given that the datastore is managed by the VM, you should be able to simply shutdown the VM, remove the removable disk and attach it to the other PVE host using the same configuration. Then you will have to move the PBS VM (probably best by creating a regular vma backup and restore or use migration if part of a cluster) to the target PVE host.
boot: order=virtio1
cores: 4
cpu: x86-64-v2-AES
memory: 4096
meta: creation-qemu=8.0.2,ctime=1689006476
name: pbs
net0: virtio=7A:F3:7B:E9:D1:A7,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsihw: virtio-scsi-single
smbios1: uuid=f26953a9-bf86-4322-9856-484ca9c27310
sockets: 1
virtio0: local-backup:300/vm-300-disk-0.qcow2,iothread=1,size=2000G
virtio1: local-backup:300/vm-300-disk-1.qcow2,iothread=1,size=32G
vmgenid: b41137b2-e27b-4699-9da2-1398522d800e
dir: local
path /var/lib/vz
content iso,vztmpl
shared 0
lvmthin: local-lvm
thinpool data
vgname pve
content rootdir,images
dir: local-backup
path /mnt/backup
content vztmpl,iso,backup,images
prune-backups keep-last=3
shared 0
pbs: pbs
datastore pbs
server 192.168.5.84
content backup
fingerprint f2:66:a4:0c:6d:0e:98:e4:fc:3c:f0:fb:19:63:fd:36:24:51:d7:fc:fa:34:81:2a:bc:35:94:7e:76:c6:86:7d
prune-backups keep-all=1
username root@pam
Ah I see, you have this disk added as storage in PVE and created disks for the VM. Well in that case you first of all have to make sure that there are no other VMs on that host using this storage, only if that is the case you can move the disk without compromising other VMs. Is that the case?Hi,
There is an easily removable SATA SSD in the source host, which can be plugged into any target host using a USB housing.
How do I get the target host to display the VMs it contains in the WebUI and thus make them startable?
Please refer to: https://forum.proxmox.com/threads/external-storage.143797/
#qm config 300:
Code:boot: order=virtio1 cores: 4 cpu: x86-64-v2-AES memory: 4096 meta: creation-qemu=8.0.2,ctime=1689006476 name: pbs net0: virtio=7A:F3:7B:E9:D1:A7,bridge=vmbr0,firewall=1 numa: 0 ostype: l26 scsihw: virtio-scsi-single smbios1: uuid=f26953a9-bf86-4322-9856-484ca9c27310 sockets: 1 virtio0: local-backup:300/vm-300-disk-0.qcow2,iothread=1,size=2000G virtio1: local-backup:300/vm-300-disk-1.qcow2,iothread=1,size=32G vmgenid: b41137b2-e27b-4699-9da2-1398522d800e
cat /etc/pve/storage.cfg:
Code:dir: local path /var/lib/vz content iso,vztmpl shared 0 lvmthin: local-lvm thinpool data vgname pve content rootdir,images dir: local-backup path /mnt/backup content vztmpl,iso,backup,images prune-backups keep-last=3 shared 0 pbs: pbs datastore pbs server 192.168.5.84 content backup fingerprint f2:66:a4:0c:6d:0e:98:e4:fc:3c:f0:fb:19:63:fd:36:24:51:d7:fc:fa:34:81:2a:bc:35:94:7e:76:c6:86:7d prune-backups keep-all=1 username root@pam
That's right. Removing local backup does not affect any other VMs. So I can remove the part without any problem. How do I get the “Live VM” contained on it started on another host without a time-consuming restore?Ah I see, you have this disk added as storage in PVE and created disks for the VM. Well in that case you first of all have to make sure that there are no other VMs on that host using this storage, only if that is the case you can move the disk without compromising other VMs. Is that the case?
That's right. Removing local backup does not affect any other VMs. So I can remove the part without any problem. How do I get the “Live VM” contained on it started on another host without a time-consuming restore?
local-backup
, so that the storage can be accessed by PVE (not recreating the storage, rather reconfigure it). For this to work, the disk has to be mounted to the exact same path via e.g. an fstab entry or a systemd mount unit file. Since also the VM root disk is located on that storage, it is further only neccessary to transfer the VM config located at /etc/pve/qemu-server/300.conf
, make however sure that there is no duplicate VMID.