Hi Dan, That's definitely be a useful feature. Some comments...
@@ -453,7 +454,7 @@ static int qemudOpenMonitor(virConnectPt char buf[1024]; int ret = -1;
- if (!(monfd = open(monitor, O_RDWR))) { + if (!(monfd = open(monitor, O_NOCTTY |O_RDWR))) {
Is this just to ensure portability or does it change the behavior?
@@ -1365,13 +1360,35 @@ static int qemudMonitorCommand(struct qe + retry1: + if (write(vm->logfile, buf, strlen(buf)) < 0) { + /* Log, but ignore failures to write logfile for VM */ + if (errno == EINTR) + goto retry1; + qemudLog(QEMUD_WARN, "Unable to log VM console data: %s", + strerror(errno)); + } + *reply = buf; return 0; + + error: + if (buf) { + retry2: + if (write(vm->logfile, buf, strlen(buf)) < 0) { + /* Log, but ignore failures to write logfile for VM */ + if (errno == EINTR) + goto retry2; + qemudLog(QEMUD_WARN, "Unable to log VM console data: %s", + strerror(errno)); + } + free(buf); + } + return -1;
I think both of these retry loops could be replaced with safewrite from util.c: if (safewrite(vm->logfile, buf, strlen(buf)) != strlen(buf)) qemudLog(...)
+static int qemudDomainChangeCDROM(virDomainPtr dom, + struct qemud_vm *vm, + struct qemud_vm_disk_def *olddisk, + struct qemud_vm_disk_def *newdisk) { + struct qemud_driver *driver = (struct qemud_driver *)dom->conn->privateData; + char *cmd; + char *reply; + /* XXX QEMU only supports a single CDROM for now */ + /*cmd = malloc(strlen("change ") + strlen(olddisk->dst) + 1 + strlen(newdisk->src) + 2);*/ + cmd = malloc(strlen("change ") + strlen("cdrom") + 1 + strlen(newdisk->src) + 2); + if (!cmd) { + qemudReportError(dom->conn, dom, NULL, VIR_ERR_NO_MEMORY, "monitor command"); + return -1; + } + strcpy(cmd, "change "); + /* XXX QEMU only supports a single CDROM for now */ + /*strcat(cmd, olddisk->dst);*/ + strcat(cmd, "cdrom"); + strcat(cmd, " "); + strcat(cmd, newdisk->src); + strcat(cmd, "\n");
Commands should be terminated with "\r", otherwise the terminal layer replaces "\n" -> "\r\n", and bugs in earlier qemu means it would execute the command twice. Recent qemu will still print the "(qemu) " prompt twice in this case, which might confuse qemudMonitorCommand into thinking that a subsequent command is finished before it's even started. Unless the O_NOCTTY somehow fixes that? -jim