[Bug 1948525] Re: Alters Performance options > Cache mode causing start failure

2022-01-14 Thread Launchpad Bug Tracker
[Expired for libvirt (Ubuntu) because there has been no activity for 60
days.]

** Changed in: libvirt (Ubuntu)
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1948525

Title:
  Alters Performance options > Cache mode causing start failure

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1948525/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1948525] Re: Alters Performance options > Cache mode causing start failure

2021-11-15 Thread Christian Ehrhardt 
Ok, so it seems rpc-statd [1] allows the locks to happen.

The other problem you describe seems unrelated to NFS and just a guest boot 
question right?
I have not heard about the "only seeing HD" problem and therefore have no 
immediate "this is it", but to poke on this a bit cdroms (virtuals as well) can 
be in ejected and active state, could it be that if not booting of it that it 
starts inactive waiting for the OS to ask spinning it up?

Things to try could be:
1. try specifying the cdrom as fallback boot, you can list multiple
   => https://libvirt.org/formatdomain.html#bios-bootloader
2. Force it to be perma-present like try=closed removable=false or so

virsh change-media came to mind, but I do not see where it could be
useful here

Was there a reply from #virt since your question there that would
indicate something deeper in seabios?

[1]: https://linux.die.net/man/8/rpc.statd

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1948525

Title:
  Alters Performance options > Cache mode causing start failure

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1948525/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1948525] Re: Alters Performance options > Cache mode causing start failure

2021-11-12 Thread TJ
Remaining problem could be with SeaBIOS. Copying here my question to
OFTC #virt

Doing some GRUB bios-mode boot testing with qemu/x86_64. Attached 2 IDE
devices, a small HDD (file with mbr and 2 partitions)  and a CDROM (iso
file). If SeaBIOS boots the CD GRUB can see both devices ("(cd) (hd0)")
but if SeaBIOS boots the HDD GRUB can only see the HD ("(hd0)").

Is this a SeaBios issue or something about how the guest is
(mis)configured

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1948525

Title:
  Alters Performance options > Cache mode causing start failure

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1948525/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1948525] Re: Alters Performance options > Cache mode causing start failure

2021-11-12 Thread TJ
After reserching the NFS lock issue it seems I found the solution on the
Debian 11 Bullseye server:

$ sudo systemctl enable rpc-statd
Created symlink /etc/systemd/system/nfs-server.service.wants/rpc-statd.service 
→ /lib/systemd/system/rpc-statd.service.
$ sudo systemctl start rpc-statd

Now, the guest VM on the client has started ... but GRUB isn't seeing
the virtual IDE CDROM device. I'd expect to see a second hd device.

This is testing GRUB BIOS mode for building various GRUB configs - no OS
image just a raw msdos label partitioned MBR with core image and a
/boot/ file-system with GRUB modules and a vmlinux.

Nothing out of line in the libvirt/qemu log file. I'll dig further

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1948525

Title:
  Alters Performance options > Cache mode causing start failure

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1948525/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1948525] Re: Alters Performance options > Cache mode causing start failure

2021-11-12 Thread TJ
One issue is that when the libvirt cache mode is set to "none" what is
passed to qemu is "write-cache=on". If I set libvirt cache mode to
"writethrough" qemu gets "write-cache=off" !

The remaining problem is solving the lock issue on NFS. Came back to
this issue again today and its again blocked everything.

The reason qemu cannot write the lock-file is the user/group it runs as
(libvirt-qemu/kvm) do not exist on the NFS server so there is no
possible NFS mapping for those. So, despite reading the other bugs and
the various links within them I'm still not clear how to simply tell
qemu not to bother with locking at all - I KNOW it is safe, so do what I
damned well tell you!

The qemu log ends with:

2021-11-12T20:35:51.527063Z qemu-system-x86_64: -device ide-
cd,bus=ide.0,unit=0,share-
rw=on,drive=libvirt-1-format,id=ide0-0-0,write-cache=off: Failed to lock
byte 100: No locks available

The relevant lines for the qemu-system-x86_64 command-line from the same
log file are:

-blockdev 
'{"node-name":"libvirt-2-format","read-only":true,"discard":"ignore","cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2
-storage"}' \
-device 
virtio-blk-pci,bus=pci.0,addr=0x7,drive=libvirt-2-format,id=virtio-disk0,bootindex=1,write-cache=on
 \
-blockdev 
'{"driver":"file","filename":"/srv/NAS/Sunny/Downloads/ISO/kubuntu-21.04-desktop-amd64.iso","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}'
 \

I tried adding various lines to:
/etc/apparmor.d/local/abstractions/libvirt-qemu

  /srv/NAS/Sunny/Downloads/** rk,

or

  /srv/NAS/Sunny/Downloads/**/* rk,

But of course these aren't going to help because they have no effect on
the underlying NFS permissions.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1948525

Title:
  Alters Performance options > Cache mode causing start failure

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1948525/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1948525] Re: Alters Performance options > Cache mode causing start failure

2021-10-25 Thread Christian Ehrhardt 
Hi TJ,

> Ubuntu 20.04 amd64. Originally thought this was virt-manager but tested via 
> virsh and found it 
> appears to be caused by libvirt.

Yes this issue isn't a virt-manager issue, but libvirt (or qemu) should
be right.

All the "Failed to lock byte" issues go back to 2017.
There qemu introduced the general behavior to lock images.
We had:
- bug 1716028 to set share-rw=on
- bug 1709818 to allow file locking through apparmor

Since then we only had a few users that needed help to adapt e.g. when
formerly sharing images now needing to mark them shared.

This is an interesting case as the question is if we just need to
changed the guest config in your case. Or if there is a real new issue
like certain combinations of attributes to end up wrong.

So let me check your XML and commandline ...
You seem to use that ISO in (potentially) multiple guests form the same NFS.
For that one should set "shareable" element as outlined in [1]
And then it also is recommended to disable caching which you already did.

In your options passed to qemu for this I'd expect "force-share" or "share-rw" 
(version dependent) as part of:
-blockdev {"driver":"file","filename":"/srv/NAS/Sunny/Downloads/
ISO/lubuntu-18.04-desktop-amd64.iso","...

Can you try setting "shareable" element in the guest XML if that then
works?

I must admit I do not yet see what the caching attribute would matter here.
Are you saying that it works by default, but with cache="none" it fails with 
this reported issue?
If so could you also send the qemu arguments it uses in your setup when 
cache="none" is not present?

[1]: https://libvirt.org/formatdomain.html#hard-drives-floppy-disks-
cdroms

** Changed in: libvirt (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1948525

Title:
  Alters Performance options > Cache mode causing start failure

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1948525/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1948525] Re: Alters Performance options > Cache mode causing start failure

2021-10-23 Thread TJ
** Attachment added: "Screenshot from virt-manager"
   
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1948525/+attachment/5535410/+files/Screenshot_2021-10-23_11-17-02.png

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1948525

Title:
  Alters Performance options > Cache mode causing start failure

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1948525/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs