Justin B Rye
2019-06-17 18:10:01 UTC
(Not sure how to re-open debian bugs, or if I should even try. Thought
I'd ping you guys as my email to the bug itself bounced (as it is
closed)...)
I would ask that release notes are modified to make it a lot easier for
KVM/qemu users to make changes.
Would we also need to add similar amounts of detail to the coverage ofI'd ping you guys as my email to the bug itself bounced (as it is
closed)...)
I would ask that release notes are modified to make it a lot easier for
KVM/qemu users to make changes.
other specific cases? At this stage we were rather hoping we'd got
the content of the release notes more or less settled, and could leave
the translators to get on with their side of the work.
How about the option of adding just a pointer to some wiki page, and
collecting the technical details there? Then we'd be able to make the
advice properly comprehensive, assuming there are people who know the
answers and care enough to contribute them.
I'm not sure if the qemu package has these notes, but I'm not upgrading
my stretch KVM host, I'm starting by upgrading/testing a few buster VMs.
(I assume you mean "upgrading a few VMs to buster"?)my stretch KVM host, I'm starting by upgrading/testing a few buster VMs.
And once buster is released, this process is likely to be repeated by
many people -- hypervisor host last.
My point is that I had no documentation on this, and even using google's
'verbatim' search, it literally took me > 1 hour to discover the full
command line for qemu to enable urandom pass through.
-object rng-random,id=rng0,filename=/dev/urandom -device
virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000
Note that max-bytes=1024,period=1000 is to prevent hypervisor host
starvation, and really isn't mandatory.
I was easily able to find the -device line in qemu's documentation, but
it was quite a search to find that the -object line actually
caused /dev/urandom in the VM to point to the host's VM.
Daniel Lange's article (linked from the release-notes) quotesmany people -- hypervisor host last.
My point is that I had no documentation on this, and even using google's
'verbatim' search, it literally took me > 1 hour to discover the full
command line for qemu to enable urandom pass through.
-object rng-random,id=rng0,filename=/dev/urandom -device
virtio-rng-pci,rng=rng0,max-bytes=1024,period=1000
Note that max-bytes=1024,period=1000 is to prevent hypervisor host
starvation, and really isn't mandatory.
I was easily able to find the -device line in qemu's documentation, but
it was quite a search to find that the -object line actually
caused /dev/urandom in the VM to point to the host's VM.
kvm ... -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x7
Would that also have worked for you?
--
If you are running QEMU/KVM, using virtio-rng-pci to pass through the
hypervisor's /dev/urandom will resolve randomness issues in virtualized
buster hosts.
-object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0
You may want to read up on the max-bytes=1024 and period options as
well.
--
I'm not sure what to say about libvirt, I'd imagine it is a bit easier to
set this up.
But I find it... unpleasant to think of enormous numbers of
Debian sysadmins, all having to Google the same thing....
Unfortunately it's rather hard to predict exactly what they'll typeIf you are running QEMU/KVM, using virtio-rng-pci to pass through the
hypervisor's /dev/urandom will resolve randomness issues in virtualized
buster hosts.
-object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0
You may want to read up on the max-bytes=1024 and period options as
well.
--
I'm not sure what to say about libvirt, I'd imagine it is a bit easier to
set this up.
But I find it... unpleasant to think of enormous numbers of
Debian sysadmins, all having to Google the same thing....
into Google. If we *did* have a good informative wiki page, what
would you suggest as a name for it? Maybe "Boot-time entropy
starvation"?
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package