- Users - libvirt List Archives

FYI: Planned list outage Mon 25th Aug from 10:00 JST
by Daniel P. Berrangé 20 Aug '25

20 Aug '25

We have a planned outage of the libvirt.org mailing lists on Monday 25th August. The outage is anticipated to begin at approx 10:00 JST (Japan), and all going well, should last no more than a couple hours. There will be various cosmetic changes to the lists.libvirt.org web interface after the upgrade, due to the newer software versions introduced. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

1 0

Re: Clarification Needed: virsh snapshot-delete Behavior with External Snapshots (--disk-only)
by Peter Krempa 25 Jul '25

25 Jul '25

On Wed, Jul 23, 2025 at 04:57:57 +0000, P, Rajasekar via Users wrote: > Hello libvirt community, > > I am seeking clarification on the behavior of `virsh snapshot-delete` when used with external snapshots (created with the `--disk-only` option). > > **Environment:** > - libvirt version: 10.5.0 Note that this was released almost a year ago. > - Kernel version: 5.14.0-503.22.1.el9_5.x86_64 > - Disk image format: qcow2 > - Host OS: RHEL 9.5 > > **Steps to reproduce:** > 1. Create an external snapshot: > virsh snapshot-create-as --domain <vm> --name snap1 --disk-only --atomic > 2. Delete the snapshot: > virsh snapshot-delete <vm> --snapshotname snap1 > > **Observed behavior:** > - Changes from the overlay (snapshot) file are merged into the base image. > - The snapshot metadata is removed from libvirt. > - The snapshot file remains on disk (appears orphaned). You mean that the original overlay images remained on disk? e.g. /path/to/originalimage.snap1 ? > **Questions:** > - Is the observed automatic merge of the overlay file into the base image during `snapshot-delete` the intended behavior for external snapshots in recent libvirt versions? Or we need separate `blockcommit` step. Yes it is intended, because deleting a snapshot is effectively meaning "I don't want to return to this point any more" so the extra overlay makes no sense. > - Should the snapshot file be deleted automatically, or is manual cleanup required? If you mean the overlay, then yes it should have been deleted. > - Is there any official documentation that clarifies this behavior for external snapshots, as most documentation seems to focus on internal snapshots? The semantics of external and internal snapshots are supposed to be indentical. I don't think we document to a deep extent the actual behaviour WRT to the disk files.

1 0

Clarification Needed: virsh snapshot-delete Behavior with External Snapshots (--disk-only)
by P, Rajasekar 23 Jul '25

23 Jul '25

Hello libvirt community, I am seeking clarification on the behavior of `virsh snapshot-delete` when used with external snapshots (created with the `--disk-only` option). **Environment:** - libvirt version: 10.5.0 - Kernel version: 5.14.0-503.22.1.el9_5.x86_64 - Disk image format: qcow2 - Host OS: RHEL 9.5 **Steps to reproduce:** 1. Create an external snapshot: virsh snapshot-create-as --domain <vm> --name snap1 --disk-only --atomic 2. Delete the snapshot: virsh snapshot-delete <vm> --snapshotname snap1 **Observed behavior:** - Changes from the overlay (snapshot) file are merged into the base image. - The snapshot metadata is removed from libvirt. - The snapshot file remains on disk (appears orphaned). **Questions:** - Is the observed automatic merge of the overlay file into the base image during `snapshot-delete` the intended behavior for external snapshots in recent libvirt versions? Or we need separate `blockcommit` step. - Should the snapshot file be deleted automatically, or is manual cleanup required? - Is there any official documentation that clarifies this behavior for external snapshots, as most documentation seems to focus on internal snapshots? Thank you for your help and clarification! Best regards, Raj.

1 0

Hanging migration leaving domain in paused state
by Yangchen Ye 22 Jul '25

22 Jul '25

Hi, We are running libvirt 8.0.0, and sometimes live migration could not finish (because the guest is dirtying the memory too fast). We implemented a monitor that increases max downtime when it observed that "Data Remaining" bumps up. But we found a strange sequence of events from the monitor, which leads to a paused domain on the destination hypervisor: The monitor sees Data Remaining bumping up and increases max downtime up to 20 seconds, but weird thing is that after a period of time, it started reporting "Data Remaining" and "Data Total" is both 0, but the migration job is still unfinished: "Migration in progress - DataTotal: 85 904728064, DataRemaining: 22201458688, TimeElapsed: 20005, MaxDowntime: 500, DirtyRate: 0" "Migration in progress - DataTotal: 85904728064, DataRemaining: 43801825280, TimeElapsed: 10005, MaxDowntime: 500, DirtyRate: 0" "Migration in progress - DataTotal: 85904728064, DataRemaining: 52382912512, TimeElapsed: 10004, MaxDowntime: 500, DirtyRate: 0" (DataRemaining bumps up, we start increasing max downtime) "Migration in progress - DataTotal: 85904728064, DataRemaining: 4219596800, TimeElapsed: 40004, MaxDowntime: 1500, DirtyRate: 0" (Last poll where we see the job info) After which monitor logs "Migration in progress - DataTotal: 0, DataRemaining: 0, TimeElapsed: 40004, MaxDowntime: 13500, DirtyRate: 0" The domain is always running on the source hypervisor but there is a paused domain on the destination hypervisor which is paused at start up. Trying to understand what might have happened: - Is this a known issue for live migrating high memory activity guests and the way we interact with libvirt? - What is the recommended way to ensure that a started live migration always run to completion if we don't care about downtime? Appreciate any help here Yangchen Ye

1 1

How to disable sysctl calls performed by libvirt?
by Chimmie Firefly 11 Jul '25

11 Jul '25

Hello, I have an issue whenever using `/proc/sys/ipv6/conf` as read-only mountpoint. While the libvirt by itself is running fine, I'm unable to create NAT network interfaces because of the following error: ``` 2025-07-05 19:33:32.821+0000: 100: error : networkSetIPv6Sysctl:1847 : cannot write to '/proc/sys/net/ipv6/conf/virbr0/disable_ipv6' on bridge 'virbr0': Read-only file system 2025-07-05 19:33:32.841+0000: 100: error : virNetDevSetIFFlag:601 : Cannot get interface flags on 'virbr0': No such device 2025-07-05 19:33:32.947+0000: 100: error : virNetlinkDelLink:688 : error destroying network device virbr0: No such device ``` While using iproute2 and bridge utils, I'm able to create and configure new bridge device, along with attaching the VM to the interface. I've used the following commands: ``` sysctl -w net.ipv4.ip_forward=1 brctl addbr br0 ip link set br0 up ip addr add 192.168.100.1/24 dev br0 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i br0 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o br0 -m state --state RELATED,ESTABLISHED -j ACCEPT ``` Is libvirt allowing to disable sysctl calls in the configuration files? If so, what should I set in the config?

2 1

fsck unable to fix fs issue
by ola . 08 Jul '25

08 Jul '25

I am able to boot VMs by using rbd as the root disk. When I restart and stop the VM everything works fine however, anytime the host goes down say due to a power outage, when next I try to boot the VM, I run into a situation where the root disk gets corrupted and get stuck at "initramfs". I have tried to fix this but to no avail. Here are the errors I get when I try yo use fix the fs issue with fsck manually. done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... [ 7.760625] Btrfs loaded, crc32c=crc32c-intel, zoned=yes, fsverity=yes Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.37.2 [/usr/sbin/fsck.ext4 (1) -- /dev/vda1] fsck.ext4 -a -C0 /dev/vda1 [ 7.866954] blk_update_request: I/O error, dev vda, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 cloudimg-rootfs: recovering journal [ 8.164279] blk_update_request: I/O error, dev vda, sector 227328 op 0x1:(WRITE) flags 0x800 phys_seg 24 prio class 0 [ 8.168272] Buffer I/O error on dev vda1, logical block 0, lost async page write [ 8.170413] Buffer I/O error on dev vda1, logical block 1, lost async page write [ 8.172545] Buffer I/O error on dev vda1, logical block 2, lost async page write [ 8.174601] Buffer I/O error on dev vda1, logical block 3, lost async page write [ 8.176651] Buffer I/O error on dev vda1, logical block 4, lost async page write [ 8.178694] Buffer I/O error on dev vda1, logical block 5, lost async page write [ 8.180601] Buffer I/O error on dev vda1, logical block 6, lost async page write [ 8.182641] Buffer I/O error on dev vda1, logical block 7, lost async page write [ 8.184710] Buffer I/O error on dev vda1, logical block 8, lost async page write [ 8.186744] Buffer I/O error on dev vda1, logical block 9, lost async page write [ 8.188748] blk_update_request: I/O error, dev vda, sector 229392 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 8.191433] blk_update_request: I/O error, dev vda, sector 229440 op 0x1:(WRITE) flags 0x800 phys_seg 32 prio class 0 [ 8.194204] blk_update_request: I/O error, dev vda, sector 229480 op 0x1:(WRITE) flags 0x800 phys_seg 16 prio class 0 [ 8.196976] blk_update_request: I/O error, dev vda, sector 229512 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 8.243612] blk_update_request: I/O error, dev vda, sector 229544 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 8.246068] blk_update_request: I/O error, dev vda, sector 229640 op 0x1:(WRITE) flags 0x800 phys_seg 32 prio class 0 [ 8.248668] blk_update_request: I/O error, dev vda, sector 229688 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 8.251174] blk_update_request: I/O error, dev vda, sector 229704 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 fsck.ext4: Input/output error while recovering journal of cloudimg-rootfs fsck.ext4: unable to set superblock flags on cloudimg-rootfs cloudimg-rootfs: ********** WARNING: Filesystem still has errors ********** fsck exited with status code 12 done. Failure: File system check of the root filesystem failed The root filesystem on /dev/vda1 requires a manual fsck BusyBox v1.30.1 (Ubuntu 1:1.30.1-7ubuntu3.1) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) fsck.ext4 -f -y /dev/vda1 e2fsck 1.46.5 (30-Dec-2021) [ 24.286341] print_req_error: 174 callbacks suppressed [ 24.286358] blk_update_request: I/O error, dev vda, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 cloudimg-rootfs: recovering journal [ 24.552343] blk_update_request: I/O error, dev vda, sector 227328 op 0x1:(WRITE) flags 0x800 phys_seg 24 prio class 0 [ 24.556674] buffer_io_error: 5222 callbacks suppressed [ 24.558925] Buffer I/O error on dev vda1, logical block 0, lost async page write [ 24.562116] Buffer I/O error on dev vda1, logical block 1, lost async page write [ 24.565161] Buffer I/O error on dev vda1, logical block 2, lost async page write [ 24.567872] Buffer I/O error on dev vda1, logical block 3, lost async page write [ 24.570586] Buffer I/O error on dev vda1, logical block 4, lost async page write [ 24.573418] Buffer I/O error on dev vda1, logical block 5, lost async page write [ 24.575940] Buffer I/O error on dev vda1, logical block 6, lost async page write [ 24.578622] Buffer I/O error on dev vda1, logical block 7, lost async page write [ 24.581386] Buffer I/O error on dev vda1, logical block 8, lost async page write [ 24.583873] Buffer I/O error on dev vda1, logical block 9, lost async page write [ 24.586410] blk_update_request: I/O error, dev vda, sector 229392 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 24.589821] blk_update_request: I/O error, dev vda, sector 229440 op 0x1:(WRITE) flags 0x800 phys_seg 32 prio class 0 [ 24.593380] blk_update_request: I/O error, dev vda, sector 229480 op 0x1:(WRITE) flags 0x800 phys_seg 16 prio class 0 [ 24.596615] blk_update_request: I/O error, dev vda, sector 229512 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 24.643829] blk_update_request: I/O error, dev vda, sector 229544 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 24.646924] blk_update_request: I/O error, dev vda, sector 229640 op 0x1:(WRITE) flags 0x800 phys_seg 32 prio class 0 [ 24.650051] blk_update_request: I/O error, dev vda, sector 229688 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 [ 24.653128] blk_update_request: I/O error, dev vda, sector 229704 op 0x1:(WRITE) flags 0x800 phys_seg 8 prio class 0 fsck.ext4: Input/output error while recovering journal of cloudimg-rootfs fsck.ext4: unable to set superblock flags on cloudimg-rootfs cloudimg-rootfs: ********** WARNING: Filesystem still has errors ********** This is what my rbd disk looks like <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <auth username='dove'> <secret type='ceph' uuid='b608caae-5eb4-45cc-bfd4-0b4ac11c7613'/> </auth> <source protocol='rbd' name='vms/wing-64700f1d-8c469a54-3f50-4d1e-9db2-2b6ea5f3d14a'> <host name='x.168.1.x' port='6789'/> </source> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> So, my questions are; - How do I prevent this from happening as i have tried different options like changing the "cache" value for the disk template? - How can this be fixed? Thanks

2 1

RBD Namespace
by Rodrigo Prieto 23 Jun '25

23 Jun '25

Hello, I want to connect to an RBD pool specifying the namespace, but it doesn’t work. If I connect directly to the pool, it works. For example: <source protocol="rbd" name="rbd-pool/vm"> But when I try to specify the namespace like this, I cannot connect: <source protocol="rbd" name="rbd-pool/vm" namespace="vms"> <source protocol="rbd" name="rbd-pool/vms/vm"> Error al iniciar dominio: error interno: process exited while connecting to monitor: 2025-06-20T22:54:55.076193Z qemu-system-x86_64: -blockdev {"driver":"rbd","pool":"rbd-pool","image":"loli/mari","server":[{"host":"ceph-admin","port":"6789"}],"user":"admin","auth-client-required":["cephx","none"],"key-secret":"libvirt-2-storage-auth-secret0","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}: error reading header from loli/mari: No such file or directory Using the rbd command from the terminal, I can connect both ways; the error occurs only with libvirt. I’m using the following versions on Debian 12: libvirtd (libvirt) 9.0.0 QEMU emulator version 7.2.17 (Debian 1:7.2+dfsg-7+deb12u13) Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers Thanks.

2 2

Re: Question about managed/unmanaged persistent reservation disks
by Michal Prívozník 18 Jun '25

18 Jun '25

On 6/10/25 19:15, Simon Coter wrote: > Adding users DL to possibly reach out a wider audience. > > Simon > Dropping devel list as this is users list material. >> On Jun 9, 2025, at 7:28 PM, Annie Li <annie.li(a)oracle.com> wrote: >> >> Hello, >> >> I've been looking at source code related to persistent reservation and >> got confused a little bit about managed persistent reservation disks. >> For disk configured with 'managed=yes' as the following, >> >> <reservations managed='yes'> >> <source type='unix' path='/var/lib/libvirt/qemu/domain-7- >> brml10g19-iscsi-rese/pr-helper0.sock' mode='client'/> >> </reservations> >> >> libvirt is responsible for starting a pr-helper program with a >> specific associated socket file. The following source code shows that >> there is only one pr-helper and socket file associated with the >> managed disks for one VM. >> >> const char * >> qemuDomainGetManagedPRAlias(void) >> { >> return "pr-helper0"; >> } >> char * >> qemuDomainGetManagedPRSocketPath(qemuDomainObjPrivate *priv) >> { >> return g_strdup_printf("%s/%s.sock", priv->libDir, >> qemuDomainGetManagedPRAlias()); >> } >> >> So if the VM is booted with multiple disks configured with >> 'managed=yes' for reservation, I suppose these multiple disks share >> the this managed pr-helper and socket file. However, per the qemu >> document, https://www.qemu.org/docs/master/interop/pr-helper.html >> <https://www.qemu.org/docs/master/interop/pr-helper.html> >> "It is invalid to send multiple commands concurrently on the same >> socket. It is however possible to connect multiple sockets to the >> helper and send multiple commands to the helper for one or more file >> descriptors." >> This certainly did not use to be the case. IIRC this was discussed in this very old thread: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/UUL3… Maybe QEMU has some internal lock that does the right thing and serializes requests? Michal >> Due to this limitation above, only one persistent reservation disk is >> allowed as managed in theory. However, libvirt doesn't throw out any >> error or warning when the VM is booted up with multiple managed >> persistent reservation disks. I am wondering if I've missed something >> here? >> >> For unmanaged persistent reservation disks, libvirt doesn't start the >> pr-helper program for them. It is user's responsibility to start this >> program with customized socket file per disk, but the complexity >> increases with numbers of persistent reservation disks, especially in >> the case of hotplug/hotunplog. Is there any plan to support multiple >> managed persistent reservation disks with separate pr-helper/socket file? >> >> Any suggestions/clarifications are greatly appreciated. >> >> Thanks >> >> Annie >> >

3 7

significant delay live migrating a vm with an sr-iov interface
by Paul B. Henson 10 Jun '25

10 Jun '25

I'm using libvirt under Debian 12 (9.0.0-4+deb12u2 w/qemu 7.2+dfsg-7+deb12u12). I have a vm using sr-iov, and configured it with a failover macvtap interface so I could live migrate it. However, there is a significant delay at the end of the migration resulting in a lot of lost traffic. If I only have the macvtap interface, migration completes immediately at the end of the transfer of memory with no loss of traffic. I enabled debug logging, and found the following. On the source system, it logs that the system is paused for the cutover: 2025-04-30 01:08:12.526+0000: 1696180: debug : qemuMigrationAnyCompleted:1957 : Migration paused before switchover at that point, for almost a minute, the source system just keeps printing the same statistics: 2025-04-30 01:08:12.923+0000: 1696272: info : qemuMonitorJSONIOProcessLine:208 : QEMU_MONITOR_RECV_REPLY: mon=0x7f8fdc0ad2f0 reply={"return": {"expected-downtime": 300, "status": "device", "setup-time": 297, "total-time": 26107, "ram": {"total": 137452265472, "postcopy-requests": 0, "dirty-sync-count": 3, "multifd-bytes": 2821784576, "pages-per-second": 297855, "downtime-bytes": 13208, "page-size": 4096, "remaining": 0, "postcopy-bytes": 0, "mbps": 9786.9158461538464, "transferred": 3117658825, "dirty-sync-missed-zero-copy": 0, "precopy-bytes": 295861041, "duplicate": 32874480, "dirty-pages-rate": 56, "skipped": 0, "normal-bytes": 2804301824, "normal": 684644}}, "id": "libvirt-577"} [...] 2025-04-30 01:09:06.290+0000: 1696272: info : qemuMonitorJSONIOProcessLine:208 : QEMU_MONITOR_RECV_REPLY: mon=0x7f8fdc0ad2f0 reply={"return": {"expected-downtime": 300, "status": "device", "setup-time": 297, "total-time" : 79474, "ram": {"total": 137452265472, "postcopy-requests": 0, "dirty-sync-count": 3, "multifd-bytes": 2821784576, "pages-per-second": 297855, "downtime-bytes": 13208, "page-size": 4096, "remaining": 0, "postcopy-bytes" : 0, "mbps": 9786.9158461538464, "transferred": 3117658825, "dirty-sync-missed-zero-copy": 0, "precopy-bytes": 295861041, "duplicate": 32874480, "dirty-pages-rate": 56, "skipped": 0, "normal-bytes": 2804301824, "normal": 684644}}, "id": "libvirt-629"} until finally it completes: 2025-04-30 01:09:06.327+0000: 1696272: info : qemuMonitorJSONIOProcessLine:203 : QEMU_MONITOR_RECV_EVENT: mon=0x7f8fdc0ad2f0 event={"timestamp": {"seconds": 1745975346, "microseconds": 327382}, "event": "MIGRATION", "dat a": {"status": "completed"}} On the destination side, it says something about negotiating failover for the network link: 2025-04-30 01:08:12.923+0000: 1384503: info : qemuMonitorJSONIOProcessLine:203 : QEMU_MONITOR_RECV_EVENT: mon= 0x7fc7900ab2f0 event={"timestamp": {"seconds": 1745975292, "microseconds": 922783}, "event": "FAILOVER_NEGOTIA TED", "data": {"device-id": "ua-sr-iov-backup"}} Then nothing happens for about a minute until it says it is done: 2025-04-30 01:09:06.328+0000: 1384503: debug : qemuMonitorJSONIOProcessLine:189 : Line [{"timestamp": {"second s": 1745975346, "microseconds": 327991}, "event": "MIGRATION", "data": {"status": "completed"}}] Any thoughts on what is going on here to cause this delay? It's clearly somehow related to the sv-iov component of the migration. Thanks much…

2 1

virt-install iscsi direct - Target not found
by kgore4 une 10 Jun '25

10 Jun '25

When I try to use an iscsi direct pool in a "--disk" clause for virt-install, I get error "iSCSI: Failed to connect to LUN : Failed to log in to target. Status: Target not found(515)". I've seen that sort of error before when the initiator name isn't used. The SAN returns different LUNS depending on the initiator. I've run out of ideas on what to try next. Any advice welcome. I've included what I thought was relevent below. klint. The disk parameter to virt-install is (it's part of a script but the variables are correct when executed) [code] --disk vol=${poolName}/unit:0:0:${vLun1},xpath.set="./source/initiator/iqn/@name='iqn.2024-11.localdomain.agbu.agbuvh1:${vName}'" \ [/code] I added the xpath.set as I noticed that the initiator wasn't in the debug output of the disk definition and it didn't work without it either. The iscsi direct pool is defined and it appears to work - it's active and vol-list shows the correct luns. Using --debug on virt install, I can see the drive is detected early in the process as it's got the size of the drive. [code] [Wed, 19 Feb 2025 16:43:33 virt-install 2174805] DEBUG (cli:3554) Parsed --disk volume as: pool=agbu-ldap1 vol=unit:0:0:3 [Wed, 19 Feb 2025 16:43:33 virt-install 2174805] DEBUG (disk:648) disk.set_vol_object: volxml= <volume type='network'> <name>unit:0:0:3</name> <key>ip-10.1.4.3:3260-iscsi-iqn.1992-09.com.seagate:01.array.00c0fff6c846-lun-3</key> <capacity unit='bytes'>49996103168</capacity> <allocation unit='bytes'>49996103168</allocation> <target> <path>ip-10.1.4.3:3260-iscsi-iqn.1992-09.com.seagate:01.array.00c0fff6c846-lun-3</path> </target> </volume> [Wed, 19 Feb 2025 16:43:33 virt-install 2174805] DEBUG (disk:650) disk.set_vol_object: poolxml= <pool type='iscsi-direct'> <name>agbu-ldap1</name> <uuid>1c4ae810-9bae-433c-a92f-7d3501b6ba80</uuid> <capacity unit='bytes'>49996103168</capacity> <allocation unit='bytes'>49996103168</allocation> <available unit='bytes'>0</available> <source> <host name='10.1.4.3'/> <device path='iqn.1992-09.com.seagate:01.array.00c0fff6c846'/> <initiator> <iqn name='iqn.2024-11.localdomain.agbu.agbuvh1:agbu-ldap'/> </initiator> </source> </pool> [/code] The generated initial_xml for the disk looks like [code] <disk type="network" device="disk"> <driver name="qemu" type="raw"/> <source protocol="iscsi" name="iqn.1992-09.com.seagate:01.array.00c0fff6c846-lun-3"> <host name="10.1.4.3"/> <initiator> <iqn name="iqn.2024-11.localdomain.agbu.agbuvh1:agbu-ldap"/> </initiator> </source> <target dev="vda" bus="virtio"/> </disk> [/code] The generated final_xml looks like [code] <disk type="network" device="disk"> <driver name="qemu" type="raw"/> <source protocol="iscsi" name="iqn.1992-09.com.seagate:01.array.00c0fff6c846-lun-3"> <host name="10.1.4.3"/> <initiator> <iqn name="iqn.2024-11.localdomain.agbu.agbuvh1:agbu-ldap"/> </initiator> </source> <target dev="vda" bus="virtio"/> </disk> [/code] The full error is [code] [Wed, 19 Feb 2025 16:43:35 virt-install 2174805] DEBUG (cli:256) File "/usr/bin/virt-install", line 8, in <module> virtinstall.runcli() File "/usr/share/virt-manager/virtinst/virtinstall.py", line 1233, in runcli sys.exit(main()) File "/usr/share/virt-manager/virtinst/virtinstall.py", line 1226, in main start_install(guest, installer, options) File "/usr/share/virt-manager/virtinst/virtinstall.py", line 974, in start_install fail(e, do_exit=False) File "/usr/share/virt-manager/virtinst/cli.py", line 256, in fail log.debug("".join(traceback.format_stack())) [Wed, 19 Feb 2025 16:43:35 virt-install 2174805] ERROR (cli:257) internal error: process exited while connecting to monitor: 2025-02-19T05:43:35.075695Z qemu-system-x86_64: -blockdev {"driver":"iscsi","portal":"10.1.4.3:3260","target":"iqn.1992-09.com.seagate:01.array.00c0fff6c846-lun-3","lun":0,"transport":"tcp","initiator-name":"iqn.2024-11.localdomain.agbu.agbuvh1:agbu-ldap","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}: iSCSI: Failed to connect to LUN : Failed to log in to target. Status: Target not found(515) [Wed, 19 Feb 2025 16:43:35 virt-install 2174805] DEBUG (cli:259) Traceback (most recent call last): File "/usr/share/virt-manager/virtinst/virtinstall.py", line 954, in start_install domain = installer.start_install( ^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/share/virt-manager/virtinst/install/installer.py", line 695, in start_install domain = self._create_guest( ^^^^^^^^^^^^^^^^^^^ File "/usr/share/virt-manager/virtinst/install/installer.py", line 637, in _create_guest domain = self.conn.createXML(initial_xml or final_xml, 0) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/libvirt.py", line 4481, in createXML raise libvirtError('virDomainCreateXML() failed') libvirt.libvirtError: internal error: process exited while connecting to monitor: 2025-02-19T05:43:35.075695Z qemu-system-x86_64: -blockdev {"driver":"iscsi","portal":"10.1.4.3:3260","target":"iqn.1992-09.com.seagate:01.array.00c0fff6c846-lun-3","lun":0,"transport":"tcp","initiator-name":"iqn.2024-11.localdomain.agbu.agbuvh1:agbu-ldap","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}: iSCSI: Failed to connect to LUN : Failed to log in to target. Status: Target not found(515) [/code] Things that could affect the answer * What I'm calling a SAN is a seagate exos-x iscsi unit * virtual host is debian 12 * virsh version 9.0.0 * iscsiadm version 2.1.8

2 1