Updates for Proxmox VE 3.0 - including storage migration ("qm move")

[martin]

We just uploaded a bunch of packages to our pvetest repository, including a lot of bug fixes, code cleanups, qemu 1.4.2 and also a new quite cool new feature - storage migration ("qm move").

A big Thank-you to our active community for all feedback, testing, bug reporting and patch submissions.

Release Notes

- ceph (0.61.3-1~bpo70+1)

• update of ceph-common, librbd1 and librados2

- libpve-storage-perl (3.0-8)

• rdb: --format is deprecated, use --image-format instead
• be more verebose on rbd commands to get progress
• various fixes for nexenta plugin

- vncterm (1.1-4)

• Allow to add intermediate certificates to /etc/pve/local/pve-ssl.pem (users previously used apache option SSLCertificateChainFile for that)

- pve-qemu-kvm (1.4-13)

• update to qemu 1.4.2
• remove rbd-add-an-asynchronous-flush.patch (upstream now)

- qemu-server (3.0-20)

• new API to update VM config: this one is fully asynchronous.
• snapshot rollback: use pc-i440fx-1.4 as default
• config: implement new 'machine' configuration
• migrate: pass --machine parameter to remote 'qm start' command
• snapshot: store/use 'machine' confifiguration
• imlement delete flag for move_disk
• API: rename move to move_disk
• implement storage migration ("qm move")
• fix bug 395: correctly handle unused disk with storage alias
• fix unused disk handling (do not hide unused disks when used with snapshot).

- pve-manager (3.0-23)

• fix bug #368: use vtype 'DnsName' to verify host names
• fix bug #401: disable connection timeout during API call processing
• add suport for new qemu-server async configuration API
• support 'delete' flag for 'Move disk'
• add 'Move disk' button for storage migration

__________________
Best regards,

Martin Maurer
Proxmox VE project leader

 

[SergioF]

Very great news: "new quite cool new feature - storage migration ("qm move")."
Could you specify in which conditions it's possible to exploit the storage migration? (i.e. only when the vm disk is a raw or .qcow file? lvm/iscsi raw ?)

Thanks to all for the excellent product and work!
Best Regards
SergioF

 

[mir]

Storage migration works on all formats. It is even possible to convert the storage format while moving.

 

[PigLover]

Storage live migration or offline only?

 

[mir]

both options available.

 

[PigLover]

both options available.

Thank you.

 

[jleg]

storage migration - great feature, thanks!

just testing a bit - two findings so far:

- if the target storage is too small to hold the to-be-migrated image physically, the migration process stalls and times out with some message about "probable bad sectors"

- a qcow2 image (preallocation:metadata) gets "expanded" during migration, means a "thin provisioned" platform may get disk space problems:
before migration:
# qemu-img info ./101/vm-101-disk-1b.qcow2
image: ./101/vm-101-disk-1.qcow2
file format: qcow2
virtual size: 100G (107374182400 bytes)
disk size: 6.5G
cluster_size: 65536

after migration:
# qemu-img info ./101/vm-101-disk-1.qcow2
image: ./101/vm-101-disk-1.qcow2
file format: qcow2
virtual size: 100G (107374182400 bytes)
disk size: 100G
cluster_size: 65536

(a manual 'qemu-img convert' afterwards re-creates the sparse image)