search for: qemus

...bug is for RHEL7, looks like the same behavior): https://bugzilla.redhat.com/show_bug.cgi?id=1082124 Where Michal Privoznik says, it should already be fixed with these commits in libvirt: 730af8f2cd7bc0e4c98b97200857909f42ea817f -- qemuMonitorJSONGetCPUx86Data: Don't fail on ancient qemus 84f69602143551433e3e0a5226dc572ecb33c059 -- qemu: Check for presence of device and properities when getting CPUID a6a6f84af92a506f83fdecf56f292bcb89905492 -- qemu: Change return type of qemuMonitorGetGuestCPU() > > The only thing I could do (even downgrading libvirt to 1.2.9 didn...

...it is set, we must always tell the host before we free pages back to the allocator. Without this we might free a page (and have another user touch it) while the hypervisor is unprepared for it. But, if the bit is _not_ set, we are under no obligation to reverse the order. Furthermore, all modern qemus set this bit. So, the "tell second" code is completely unused and untestable. Quoting Anthony: "untested code is broken code". This _also_ means that we don't have to preserve a pfn list after the pages are freed, which should let us get rid of some temporary storage (vb-&g...

...it is set, we must always tell the host before we free pages back to the allocator. Without this we might free a page (and have another user touch it) while the hypervisor is unprepared for it. But, if the bit is _not_ set, we are under no obligation to reverse the order. Furthermore, all modern qemus set this bit. So, the "tell second" code is completely unused and untestable. Quoting Anthony: "untested code is broken code". This _also_ means that we don't have to preserve a pfn list after the pages are freed, which should let us get rid of some temporary storage (vb-&g...

...ay, qemu implementation can put virtio devices on busses > with an iommu and bypass it, so at the very least for backward > compatibility, we should expose that appropriately from the "server" > side. And of course, since we are talking about backward compatibility with existing qemus here, the capability should be the opposite, ie "honor iommu", with the assumption that without it, the implementation bypasses it, which reflects what the current qemu implementation does on any architecture, whether you configure the bus to have an iommu emulated on it or not. Cheers,...

...ay, qemu implementation can put virtio devices on busses > with an iommu and bypass it, so at the very least for backward > compatibility, we should expose that appropriately from the "server" > side. And of course, since we are talking about backward compatibility with existing qemus here, the capability should be the opposite, ie "honor iommu", with the assumption that without it, the implementation bypasses it, which reflects what the current qemu implementation does on any architecture, whether you configure the bus to have an iommu emulated on it or not. Cheers,...

...gt; > > > > I would kindly like to ask you whether you found a solution for this > > problem or whether you could help me fixing it. > > This is likely a result of commit d94b78177 (v1.2.0). I'm not sure if > there are any attempts to make libvirt work with ancient qemus (pre 1.1 > - the qom_list command was added in b4b12c62). So the only option I can > think of right now is to update qemu. We should not be depending on qom-list existing unless the feature being used only exists in a QEMU which has qom-list. In general we expect to be able to work with any...

...x509_cert_dir and default_tls_x509_verify = 1 (and directories as required see 1), virsh initiated migrations with --tls flag succeed and captures show that it's using TLS. However, they equally succeed without the flag. Is there a way to ensure that only TLS communication is permitted between QEMUs? I tried nbd_tls, but that did not seem to have any effect. Thanks a lot for your help!

Traditionally if you did live migration (KVM to KVM), you had to ensure that cache=none was set on all disks of the guest up front. This was because of quirks in how NFS works (I think the close-to-open consistency and the fact that during live migration both qemus have the file open), and we had to assume the worst case that a guest might be backed by NFS. Because of this when virt-v2v converts a guest to run on KVM using libvirt it sets cache=none. This is not necessary with modern qemu. If qemu supports the drop-cache property of the file block driver,...

...> >> with an iommu and bypass it, so at the very least for backward > >> compatibility, we should expose that appropriately from the "server" > >> side. > > > > And of course, since we are talking about backward compatibility with > > existing qemus here, the capability should be the opposite, ie "honor > > iommu", with the assumption that without it, the implementation bypasses > > it, which reflects what the current qemu implementation does on any > > architecture, whether you configure the bus to have an iommu em...

...> >> with an iommu and bypass it, so at the very least for backward > >> compatibility, we should expose that appropriately from the "server" > >> side. > > > > And of course, since we are talking about backward compatibility with > > existing qemus here, the capability should be the opposite, ie "honor > > iommu", with the assumption that without it, the implementation bypasses > > it, which reflects what the current qemu implementation does on any > > architecture, whether you configure the bus to have an iommu em...

Dear Sir, I am facing the same problem you were discussing here: https://www.redhat.com/archives/libvirt-users/2015-January/msg00070.html I am getting this error: Starting install... ERROR internal error: unable to execute QEMU command 'qom-list': The command qom-list has not been found Domain installation does not appear to have been successful. If it was, you can restart your domain

...4 that have qemu emulation and support some form of PCI) don't have an existing way to convey the information that a device bypasses the IOMMU (if any). ? - Even if we add such a mechanism (new property in the device-tree), we end up with a big turd: Because we need to be compatible with older qemus, we essentially need a quirk that will make all virtio devices assume that property is present. That will of course break whenever we try to use another implementation of virtio on powerpc which doesn't bypass the iommu. We don't have a way to differenciate a virtio device that does the by...

...4 that have qemu emulation and support some form of PCI) don't have an existing way to convey the information that a device bypasses the IOMMU (if any). ? - Even if we add such a mechanism (new property in the device-tree), we end up with a big turd: Because we need to be compatible with older qemus, we essentially need a quirk that will make all virtio devices assume that property is present. That will of course break whenever we try to use another implementation of virtio on powerpc which doesn't bypass the iommu. We don't have a way to differenciate a virtio device that does the by...

I think it has to be something trivial, but I cannot start 2 windows servers at the same time on the same dom0. If I start server 2008 first I can''t start 2012, if I start 2012, I can''t start 2008. The failure is: libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device Model not ready xl: fatal error: libxl_create.c:535, rc=-1: libxl__confirm_device_model_startup

...on and support some form of PCI) don't have an existing way to > convey the information that a device bypasses the IOMMU (if any). > > - Even if we add such a mechanism (new property in the device-tree), > we end up with a big turd: Because we need to be compatible with older > qemus, we essentially need a quirk that will make all virtio devices > assume that property is present. That will of course break whenever we > try to use another implementation of virtio on powerpc which doesn't > bypass the iommu. > > We don't have a way to differenciate a virtio...

Traditionally if you did live migration (KVM to KVM), you had to ensure that cache=none was set on all disks of the guest up front. This was because of quirks in how NFS works (I think the close-to-open consistency and the fact that during live migration both qemus have the file open), and we had to assume the worst case that a guest might be backed by NFS. Because of this when virt-v2v converts a guest to run on KVM using libvirt it sets cache=none. This is not necessary with modern qemu. If qemu supports the drop-cache property of the file block driver,...

...c $Gr $Cpu $Ram --name=$Name > > > I would kindly like to ask you whether you found a solution for this > problem or whether you could help me fixing it. This is likely a result of commit d94b78177 (v1.2.0). I'm not sure if there are any attempts to make libvirt work with ancient qemus (pre 1.1 - the qom_list command was added in b4b12c62). So the only option I can think of right now is to update qemu. Michal

...m all for doing this as some kind of bus property, if needed, although David Woodhouse may be right that the best solution is to *always* have the IOMMU there and to just ask it for an identity map if desired. > And of course, since we are talking about backward compatibility with > existing qemus here, the capability should be the opposite, ie "honor > iommu", with the assumption that without it, the implementation bypasses > it, which reflects what the current qemu implementation does on any > architecture, whether you configure the bus to have an iommu emulated on >...

...n put virtio devices on busses >> with an iommu and bypass it, so at the very least for backward >> compatibility, we should expose that appropriately from the "server" >> side. > > And of course, since we are talking about backward compatibility with > existing qemus here, the capability should be the opposite, ie "honor > iommu", with the assumption that without it, the implementation bypasses > it, which reflects what the current qemu implementation does on any > architecture, whether you configure the bus to have an iommu emulated on >...

...e same behavior): > > https://bugzilla.redhat.com/show_bug.cgi?id=1082124 > >Where Michal Privoznik says, it should already be fixed with these >commits in libvirt: > > 730af8f2cd7bc0e4c98b97200857909f42ea817f -- > qemuMonitorJSONGetCPUx86Data: Don't fail on ancient qemus > 84f69602143551433e3e0a5226dc572ecb33c059 -- qemu: Check for presence > of device and properities when getting CPUID > a6a6f84af92a506f83fdecf56f292bcb89905492 -- qemu: Change return type > of qemuMonitorGetGuestCPU() >> >> The only thing I could do (even downgrading...