Re: [libvirt] libvirt 0.7.5 vs qemu 0.12.1 imcompatability?
On 06/01/10 18:56, Nikola Ciprich wrote: I've had similar trouble with old bios images. Once I replaced them with those built with qemu-kvm, things started working... I've using the packages from virt-preview so I've got whatever BIOS images are being packaged. I've experimented some more now and even a simple: qemu-kvm -enable-kvm just gives me nothing whereas the older version brings up the BIOS screen. Actually looking at it, the BIOS is a separate package which doesn't exist in the virt-preview repository so I'm still using the normal Fedora one. Maybe that's the problem? What's the best channel for reporting issues with the virt-preview packages? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt 0.7.5 vs qemu 0.12.1 imcompatability?
The update from qemu 0.11.0 to qemu 0.12.1 in the virt-preview repository seems to have broken things. Starting a VM now just gives me a blank screen and a log which says: Option 'ipv4': Use 'on' or 'off' Failed to parse yes for dummy.ipv4 I assume libvirt is sending a it a command on the monitor interface that it no longer understands... Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt 0.7.5 vs qemu 0.12.1 imcompatability?
On 06/01/10 15:53, Daniel P. Berrange wrote: On Wed, Jan 06, 2010 at 03:38:29PM +, Tom Hughes wrote: The update from qemu 0.11.0 to qemu 0.12.1 in the virt-preview repository seems to have broken things. Starting a VM now just gives me a blank screen and a log which says: Option 'ipv4': Use 'on' or 'off' Failed to parse yes for dummy.ipv4 I assume libvirt is sending a it a command on the monitor interface that it no longer understands... That warning message should be harmless - all my VMs show that and they work ok. It is not actually something libirt sets - its a internal QEMU default setting which is wrong Hmm... Well something is wrong because I just get a black screen. I don't even get the BIOS messages since I updated this morning. Downgrading back to the fedora-updates version of qemu makes it work again. BTW the trigger for that warning seems to be that I have listen='0.0.0.0' set on the vnc adaptor to allow connections from remote machines, which causes libvirt to build a qemu command line with -vnc 0.0.0.0:0. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt 0.7.5 vs qemu 0.12.1 imcompatability?
On 06/01/10 17:32, Thomas Treutner wrote: On Wednesday 06 January 2010 17:11:17 Tom Hughes wrote: Hmm... Well something is wrong because I just get a black screen. I don't even get the BIOS messages since I updated this morning. If you start your VM with -kernel $image, there's a bug in qemu-0.12.1(.1?), which is fixed in 0.12.1.2. It's a windows VM, so no. The qemu command libvirt is using is: /usr/bin/qemu-kvm -S -M pc-0.11 -enable-kvm -m 1024 -smp 2 -name windows_xp_64 -uuid bb4c089d-1a5e-b349-07fe-4098efdf5fe0 -monitor unix:/var/lib/libvirt/qemu/windows_xp_64.monitor,server,nowait -localtime -boot c -drive file=/var/lib/libvirt/images/windows_xp_64.img,if=virtio,index=0,boot=on -drive if=ide,media=cdrom,index=2 -net nic,macaddr=00:16:3e:12:4a:56,vlan=0,model=virtio,name=virtio.0 -net tap,fd=27,vlan=0,name=tap.0 -serial pty -parallel none -usb -usbdevice tablet -vnc 0.0.0.0:0 -k en-gb -vga std -soundhw es1370 That said, I've tried stripping most of that out and still get nothing so I think something more fundamental is wrong. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
gPXE (was Re: [libvirt] [RFC,PATCH] network: add 'netboot' option to dhcp config)
I very much like this idea - e.g. I'd really like to have this to give people simple instructions for testing gPXE in next week's Fedora Test Day. On the subject of gPXE has anybody else found that it doesn't seem to be working at all? I'm using the virt-preview packages on F11 and ever since qemu switched to use gPXE network booting has been completely broken. I get the gPXE banner message appear and then nothing happens. Monitoring the network shows no signs of any DHCP requests being sent at all. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: [fedora-virt] ANNOUNCE: New release virt-manager 0.8.0
On 29/07/09 11:21, Ján ONDREJ (SAL) wrote: And one thing, which can make me happy. When I am trying virtual machines, I often reinstall existing one. Then I need to boot from network and after installation again from disk. I can't test new gPXE until it will work with my F11 kernel, may be it's better with this, but with currently functional bootrom I can't boot from disk if network boot is enabled and vice versa. If my guest is set to boot from disk (after previous installation) and I need to reinstall it, I have to do these steps: - click details panel (i) - click Boot Options - click on Boot Device menu - select Network (PXE) and confirm (click) - click Apply - click back to guest console - click start (play button) That's not a virt-manager issue, it's a qemu issue I assume. It works for me though - if I have network boot selected that I can bring up the boot menu with F12 and select the hard disk instead? What I suspect you may be referring to is the fact that if you don't have network boot set as the default then the F12 boot menu doesn't include the network option - so you can't be set to boot from the hard disk by default and then choose to boot from network instead using the boot menu. I too find that rather annoying, but as I say it is (I believe) a qemu issue rather than a libvirt issue. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VMware support and libcurl on rhel-u1
On 27/07/09 06:17, Shahar Klein wrote: I'll try with 7.15 can I test with ESX4i? ESX4i doesn't seem to work yet - the API version has changed: error: internal error Expecting VI API version '2.5.0' or '2.5u2' but found '4.0' Patching libvirt to allow the 4.0 API version allows me to connect and list guests, but trying to dumpxml a guest definition fails: virsh # dumpxml alvis error: memory conf:1: expecting a name Then again dumpxml fails for me with ESX3i as well, though with a different error: virsh # dumpxml bsa error: internal error Missing essential config entry 'scsi0.virtualDev' Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VMware support and libcurl on rhel-u1
On 27/07/09 09:38, Shahar Klein wrote: How do you connect to the esxi? Over https. Should I open an ssh in my ESXi server? [r...@rain8 libvirt]# virsh -c esx+ssh://rain3/system error: cannot recv data: Connection reset by peer error: failed to connect to the hypervisor I just use virsh -c esx://r...@server and it connects over https by default. I did have to hack the code to stop curl trying to validate the self signed cert on the server. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VMware support and libcurl on rhel-u1
On 27/07/09 09:19, Matthias Bolte wrote: 2009/7/27 Tom Hughest...@compton.nu: Patching libvirt to allow the 4.0 API version allows me to connect and list guests, but trying to dumpxml a guest definition fails: virsh # dumpxml alvis error: memory conf:1: expecting a name What's the content of line number 1 of the alvis.vmx file? The first two lines are: .encoding = UTF-8 config.version = 8 Looking at an ESX3i one I see the .encoding line is not there so I guess that is the problem. Then again dumpxml fails for me with ESX3i as well, though with a different error: virsh # dumpxml bsa error: internal error Missing essential config entry 'scsi0.virtualDev' Oh, that's a bug in the VMX parsing code, I'll fix that. The VMX parsing hasn't get much testing with in-the-wild VMX files yet. It would be useful if you could send my some of your VMX files to build up a pool as input for automatic testing and to make the VMX parser more robust. You could apply this quick fix for testing: That works, yes. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VMware support and libcurl on rhel-u1
On 27/07/09 11:00, Matthias Bolte wrote: I assume you set CURLOPT_SSL_VERIFYPEER to 0. Good idea I'll add that in they way the no_verify query parameter work for libvirtd based transports. That's the one, yes. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VMware ESX: Allow leading dots in VMX config entry names
On 27/07/09 12:25, Matthias Bolte wrote: '.encoding = UTF-8' is a valid VMX config entry, so the virConfParser must accept it in VMX mode. This patch lets the parser accept those names with leading dots. With that patch ESX4i gets a bit further but barfs on a version check: error: internal error Expecting VMX entry 'virtualHW.version' to be 4 but found 7 Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] VMware ESX: Allow leading dots in VMX config entry names
On 27/07/09 13:28, Matthias Bolte wrote: It seems that I should setup an ESXi 4 just in case there are more differences between version 3.5 and 4.0. See the other patch regarding VI API 4.0, that one should fix the virtualHW.version problem and make the version checking more robust. Latest git code is now able to connect to 4i, list domains, and dumpxml their definitions. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Video device config
On 08/07/09 12:21, Daniel Veillard wrote: On Tue, Jul 07, 2009 at 10:17:18PM +0100, Tom Hughes wrote: The updated patch is attached, and based on the list of outstanding tasks given before what remains to be done is: Upon rereading that patch it seems that Dan's version is a superset, am I missing something ? The new patch he posted last night is, yes. The one I was working from wasn't - that was this one: http://www.mail-archive.com/libvir-list@redhat.com/msg13520.html Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] PATCH: Video device config
I recently posted a patch on the RedHat bugzilla (bug #467038) to add a
model attribute to the graphics element so that the different graphics
cards supported by QEMU could be selected.
Apparently that approach has been rejected in the past however, and the
preferred approach is to add a separate video element.
I've taken the patch that Daniel Berrange posted here a few months ago
that added the necessary XML handling for the new element and extended
it by filling in the QEMU driver code to make it use the model details
as well as fixing the default video model for XEN domains as per the
list of outstanding issues given with the original patch.
The updated patch is attached, and based on the list of outstanding
tasks given before what remains to be done is:
- Add RNG XML schemas website docs
- Make Xen drivers use this info for setting stdvga=1|0 config arg
- Make VirtualBox use this info in whatever way it needs
Tom
--
Tom Hughes (t...@compton.nu)
http://www.compton.nu/
diff --git a/src/domain_conf.c b/src/domain_conf.c
index ffa2aef..0f1f249 100644
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -82,6 +82,7 @@ VIR_ENUM_IMPL(virDomainDevice, VIR_DOMAIN_DEVICE_LAST,
interface,
input,
sound,
+ video,
hostdev)
VIR_ENUM_IMPL(virDomainDisk, VIR_DOMAIN_DISK_TYPE_LAST,
@@ -142,6 +143,12 @@ VIR_ENUM_IMPL(virDomainSoundModel,
VIR_DOMAIN_SOUND_MODEL_LAST,
pcspk,
ac97)
+VIR_ENUM_IMPL(virDomainVideo, VIR_DOMAIN_VIDEO_TYPE_LAST,
+ vga,
+ cirrus,
+ vmvga,
+ xen)
+
VIR_ENUM_IMPL(virDomainInput, VIR_DOMAIN_INPUT_TYPE_LAST,
mouse,
tablet)
@@ -374,6 +381,14 @@ void virDomainSoundDefFree(virDomainSoundDefPtr def)
VIR_FREE(def);
}
+void virDomainVideoDefFree(virDomainVideoDefPtr def)
+{
+if (!def)
+return;
+
+VIR_FREE(def);
+}
+
void virDomainHostdevDefFree(virDomainHostdevDefPtr def)
{
if (!def)
@@ -401,6 +416,9 @@ void virDomainDeviceDefFree(virDomainDeviceDefPtr def)
case VIR_DOMAIN_DEVICE_SOUND:
virDomainSoundDefFree(def-data.sound);
break;
+case VIR_DOMAIN_DEVICE_VIDEO:
+virDomainVideoDefFree(def-data.video);
+break;
case VIR_DOMAIN_DEVICE_HOSTDEV:
virDomainHostdevDefFree(def-data.hostdev);
break;
@@ -458,6 +476,10 @@ void virDomainDefFree(virDomainDefPtr def)
virDomainSoundDefFree(def-sounds[i]);
VIR_FREE(def-sounds);
+for (i = 0 ; i def-nvideos ; i++)
+virDomainVideoDefFree(def-videos[i]);
+VIR_FREE(def-videos);
+
for (i = 0 ; i def-nhostdevs ; i++)
virDomainHostdevDefFree(def-hostdevs[i]);
VIR_FREE(def-hostdevs);
@@ -1653,6 +1675,84 @@ error:
goto cleanup;
}
+static virDomainVideoDefPtr
+virDomainVideoDefParseXML(virConnectPtr conn,
+ const xmlNodePtr node,
+ int flags ATTRIBUTE_UNUSED) {
+virDomainVideoDefPtr def;
+xmlNodePtr cur;
+char *type = NULL;
+char *heads = NULL;
+char *vram = NULL;
+
+if (VIR_ALLOC(def) 0) {
+virReportOOMError(conn);
+return NULL;
+}
+
+cur = node-children;
+while (cur != NULL) {
+if (cur-type == XML_ELEMENT_NODE) {
+if ((type == NULL) (vram == NULL) (heads == NULL)
+xmlStrEqual(cur-name, BAD_CAST model)) {
+type = virXMLPropString(cur, type);
+vram = virXMLPropString(cur, vram);
+heads = virXMLPropString(cur, heads);
+}
+}
+cur = cur-next;
+}
+
+if (type
+(def-type = virDomainVideoTypeFromString(type)) 0) {
+virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
+ _(unknown video model '%s'), type);
+goto error;
+}
+
+if (vram
+virStrToLong_ui(vram, NULL, 10, def-vram) 0) {
+virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
+ _(cannot parse video ram '%s'), vram);
+goto error;
+} else {
+switch (def-type) {
+/* Wierd, QEMU defaults to 9 MB ??! */
+case VIR_DOMAIN_VIDEO_TYPE_VGA:
+case VIR_DOMAIN_VIDEO_TYPE_CIRRUS:
+case VIR_DOMAIN_VIDEO_TYPE_VMVGA:
+def-vram = 9 * 1024;
+break;
+case VIR_DOMAIN_VIDEO_TYPE_XEN:
+/* Original PVFB hardcoded to 4 MB */
+def-vram = 4 * 1024;
+break;
+}
+}
+
+if (heads
+virStrToLong_ui(heads, NULL, 10, def-heads) 0) {
+virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR,
+ _(cannot parse video heads '%s'), heads);
+goto error;
+} else {
+def-heads = 1;
+}
+
+VIR_FREE(type);
+VIR_FREE(vram);
+VIR_FREE(heads);
+
+return def;
+
+error
