Re: query-block command is missing device name. Deprecated?
Max, Thanks for the thorough explanation. I finaly found some QEMU pdf docs out there describing that -blockdev was the way of the furture. I'll try providing a job-id for the backups. Again thanks for the reply/feedback. It's great to see how fast this stuff is progressing, even if it causes some usage gotchas from time to time. Have a good one! Mike On Tue, 2020-02-04 at 12:29 +0100, Max Reitz wrote: > On 31.01.20 05:06, Mike Lee wrote: > > Hello All, > > Hi Mike, > > Most of the changes you’re seeing are probably due to libvirt using > node > names to create block devices now. So every node in the block graph > (e.g. a file node to read a file from the normal filesystem, or a > qcow2 > node to interpret the qcow2 format) is now created explicitly by > libvirt, and every such node needs a node name. > > Before this (very recent) change, libvirt used -drive (I think), > which > either creates a guest device along with an attached full block node > tree, or just the tree without the device – but that tree still gets > a > name as whole, and that was the name shown by query-block. (The > guest > device name is shown under @qdev.) > > With libvirt now using -blockdev instead of -drive and thus creating > single block nodes, there is no such tree name anymore. That’s why > it’s > shown as empty. > > > IN CLOSING: > > 1.) I suspect the error I get when starting the backup is simply a > > bug. > > Am I correct in assuming this, since the backup actually > > starts? If > > I'm wrong what do I need to change to not get the error? > > This is also related to the libvirt change described above. You used > to > have to specify the tree name (generally called “device name” in > QAPI), > but now there is no such name. As such, you have to specify the node > name now. You did that, but you also need to specify a job-id then. > > The documentation isn’t really clear about this, but job-id will only > default to the device name, not to what @device says. There is no > device name (or “tree name”, as I’ve called it above), so it cannot > default to anything. Hence the error message, that an empty job ID > is > not permissible. > > So long story short, you need to specify something for @job-id. (And > then all further job commands/events will use that for their > respective > @device field. That will be a bit confusing, but, well, we had to > for > compatibility.) > > > 2.) Has the "device" attribute in the "query-block" command been > > deprecated and is that why that attribute's value is now > > blank? I've > > gone back through all of the QEMU release notes and see no mention > > of > > this. > > It hasn’t, but when using -blockdev instead of -drive for block > devices, > it will be empty. (And libvirt does use -blockdev now.) > > > 3.) What's with the "libvirt-X-format" node name? The "drive- > > virtio- > > diskX" seemed more logical. Is this naming change a libvirt thing > > and > > not qemu? > > That has the same reason, libvirt now uses -blockdev, so it specifies > node names. “libvirt-X-format” looks like a typical node name > (“format” > is a type of node that interprets image formats, like qcow2 or raw), > whereas “drive-virtio-diskX” seems like a name for a whole tree of > block > nodes (i.e., a device name). > > Max >
query-block command is missing device name. Deprecated?
Hello All,
I've discovered that when I run the command "query-block" command, the
"device:" attribute's value is now blank. I use this to help execute
incremental backups of my VMs. In previous versions this worked but now
that I'm on a rolling distro I no longer receive this info. I'm
wondering if this is a bug or intended, and if so why. Details of my
findings are below.
PREVIOUS SYSTEM:
Distro: Mint 19.1
Kernel: 4.15.0-74-generic #84-Ubuntu SMP
Virsh ver: 4.0
QEMU Version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.21)
In the old Mint distro I could run something like the below to create
the dirty bitmap and then kick-off a backup (I'm aware I can combine
the two into one trasaction but I am separating them out here for
readability):
CREATE BITMAP: (drive-virtio-disk0 was the "device" name that was
always returned by the qemu-monitor "query-block" command.)
virsh qemu-monitor-command manjaro-xfce --pretty \
'{"execute": "transaction",' \
'"arguments":' \
'{' \
'"actions":' \
'[' \
'{"type": "block-dirty-bitmap-add",' \
' "data": {"node": "drive-virtio-disk0", "name":
"bitmap0"}' \
'}' \
']' \
'}' \
'}'
KICK-OFF BACKUP:
virsh qemu-monitor-command manjaro-xfce --pretty \
'{"execute": "transaction",' \
'"arguments":' \
'{' \
'"actions":' \
'[' \
'{"type": "drive-backup",' \
' "data": {"device": "drive-virtio-disk0",' \
' "target": "/libvirt-backups/manjaro-xfce-full-
backup.qcow2",' \
' "sync": "full", "format": "qcow2"' \
' }' \
'}' \
']' \
'}' \
'}'
CURRENT SYSTEM:
Distro: Manjaro
Kernel: 5.4.15-2-MANJARO #1 SMP PREEMPT
Virsh ver: 5.10.0
QEMU Version: 4.2.0
Now when I run the above command to create the dirty bitmap I get:
--
virsh qemu-monitor-command manjaro-xfce --pretty \
> '{"execute": "transaction",' \
> '"arguments":' \
> '{' \
> '"actions":' \
> '[' \
> '{"type": "block-dirty-bitmap-add",' \
> ' "data": {"node": "drive-virtio-disk0", "name":
"bitmap0"}' \
> '}' \
> ']' \
> '}' \
> '}'
{
"id": "libvirt-389",
"error": {
"class": "GenericError",
"desc": "Cannot find device=drive-virtio-disk0 nor node_name=drive-
virtio-disk0"
}
}
--
Querying the manjaro-xfce VM for block info I get the below. NOTE the
blank "device" entry. Previously this was populated with "drive-
virtio-disk0" . So what do I use for the device now on the new
version of qemu?
--
virsh qemu-monitor-command manjaro-xfce --pretty '{"execute":"query-
block"}'
{
"return": [
{
"io-status": "ok",
--->> "device": "", <<-
"locked": false,
"removable": false,
"inserted": {
"iops_rd": 0,
"detect_zeroes": "off",
"image": {
"virtual-size": 8589934592,
"filename": "/var/lib/libvirt/images/manjaro-xfce.qcow2",
"cluster-size": 65536,
"format": "qcow2",
"actual-size": 8591200256,
"format-specific": {
"type": "qcow2",
"data": {
"compat": "1.1",
"lazy-refcounts": true,
"refcount-bits": 16,
"corrupt": false
}
},
"dirty-flag": false
},
"iops_wr": 0,
"ro": false,
"node-name": "libvirt-3-format",
"backing_file_depth": 0,
"drv": "qcow2",
"iops": 0,
"bps_wr": 0,
"write_threshold": 0,
"encrypted": false,
"bps": 0,
"bps_rd": 0,
"cache": {
"no-flush": false,
"direct": false,
"writeback": true
},
"file": "/var/lib/libvirt/images/manjaro-xfce.qcow2",
"encryption_key_missing": false
},
"qdev": "/machine/peripheral/virtio-disk0/virtio-backend",
"type": "unknown"
},
{
"io-status": "ok",
"device": "",
"locked": false,
"removable": false,
"inserted": {
"iops_rd": 0,
"detect_zeroes": "off",
"image": {
"virtual-size": 2147483648,
"filename": "/var/lib/libvirt/images/manjaro-xfce-1.qcow2",
"cluster-size": 65536,
"format": "qcow2",
"actual-size": 2148020224,
"format-specific": {
"type": "qcow2",
"data": {
"compat": "1.1",
"lazy-refcounts":
[Qemu-discuss] Permission denied when using block-dirty-bitmap on dynamically-mounted backup drive.
I am using Qemu's block-dirty-bitmap features to perform full/incremental
backups of my qcow2 images. Things are working great but when I go to
perform the initial full backup command to create the bitmap I get
"libvirt-49 Could not create file: Permission denied". I'm issuing these
json-based commands to the qemu monitor via the virsh qemu-monitor-command
command. Yes, the dest. dir is owned by libvirt-qemu.kvm user/group.
The only time I get this permission error is when I'm trying to write
backup qcow2 files to a dynamically-mounted external drive (USB, etc.). If
I create a manual mount point for it and provide an entry in my fstab file,
things work great.
Any idea how I can do backups to destination disks that are auto-mounted
(mounted automatically when I plug-in the external USB disk?
The command I'm running is:
virsh qemu-monitor-command ubuntu16.04 --pretty \
'{"execute":
"transaction",' \
'"arguments":' \
'{' \
'"actions":' \
'[' \
'{"type": "block-dirty-bitmap-add",' \
' "data": {"node": "drive-virtio-disk1", "name": "bitmap0"}' \
'},' \
'{"type": "drive-backup",' \
' "data": {"device": "drive-virtio-disk1",' \
' "target":
"/media/mike/Seagate2TB/backups/qemu/ubuntu16.04/2014-09-24/ubuntu16.04_full_backup_2017-09-24.qcow2",'
\
' "sync": "full", "format": "qcow2"' \
' }' \
'}' \
']' \
'}' \
'}'
Thanks.
Mike
