@nerling:
Whatever is creating the domain XML (ie with 'create' or 'define') needs
to add the "" bit, after which it is
stored in the XML. If OpenNebula creates virtual machines and adds them
to libvirt, it must be adjusted for this. If OpenNebula is creating
virtual machines, then it should know
I can see already a Problem with the opennebula package.
It will no longer work, since it does not generate this information on the
domain xmls - it would not have this information anyway - else if it would
probe for the data type of the image, this - we are being told - being a
security issue.
** Changed in: ubuntu-release-notes
Status: New => Fix Released
--
libvirt no longer probes chained backing stores
https://bugs.launchpad.net/bugs/656173
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Sure applications change with versions. However, they normally also
provide useful error messages when something that was previously valid
no longer is. This is *not* the case here. There is *no* error
message.
I'm not saying that users shouldn't provide valid XML when defining a
VM. However,
Jamin, that is why there will be a release note. There isn't much else
that can be done. Applications change with new versions and people need
to adapt the applications that use the changed applications
appropriately. The tools that most people use are either already
adjusted or are going to be as
Jamie, I understand that the vm.xml does not contain enough information
for the version of libvirt in maverick. I understand that with
maverick's version one now has to supply a disk format. However, this
was not the case with libvirt under lucid. Furthermore, not providing
the disk format does
Updated suggested release note text (my last one had a typo and I've
tried to address Jamin's concerns):
Previous libvirt versions would probe a qemu disk to determine its format and
did not require that the format be declared in the XML. This is considered a
security problem in most deployments
Jamin, your vm.xml does not contain enough information-- you must
specify the disk format when defining a new VM. Simply put, if you are
using a qcow2 disk you must specify ""
in the vm.xml you are using.
--
libvirt no longer probes chained backing stores
https://bugs.launchpad.net/bugs/656173
Yo
The automated run of libvirt-migrate-qemu-disks is great if your virtual
machines are permanently defined within libvirt. However, if you simply
inject and run a VM as needed, with something like the following:
virsh create vm.xml
Which is what I've been doing. The VM definitions will not han
Suggested release note text:
Previous libvirt versions would probe a qemu disk to determine its format and
did not require that the format be declared in the XML. This is considered a
security problem in most deployments and newer versions of libvirt will default
to the 'raw' format when the fo
** Summary changed:
- virt-aa-helper generates incomplete apparmor profiles with chained backing
files
+ libvirt no longer probes chained backing stores
--
libvirt no longer probes chained backing stores
https://bugs.launchpad.net/bugs/656173
You received this bug notification because you are
11 matches
Mail list logo
