Bug 587675
| Summary: | RFE: API to facilitate remote URL installs | ||
|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Cole Robinson <crobinso> |
| Component: | libvirt | Assignee: | Daniel Veillard <veillard> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | berrange, crobinso, dallan, jkastner, syeghiay, veillard, xen-maint |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-07 23:34:12 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 546440, 628871 | ||
This feature request did not get resolved in time for Feature Freeze for the current Red Hat Enterprise Linux release and has now been denied. You may re-open your request by requesting your support representative to propose it for the next release. I don't think libvirtd wants to be in the business of downloading files itself, but that's not a problem because with the virStreamPtr APIs we added for tunnelled migration, we can easily provide an API for reading & writing storage volumes, eg
int virStorageVolRead(virStorageVolPtr, virStreamPtr st, unsigned long long offset, unsigned int flags);
int virStorageVolWrite(virStorageVolPtr, virStreamPtr st, unsigned long long offset, unsigned int flags);
static int
cmdPutSource(virStreamPtr st ATTRIBUTE_UNUSED,
char *bytes, size_t nbytes, void *opaque)
{
int *fd = opaque;
return read(*fd, bytes, nbytes);
}
virStreamPtr st;
int fd;
if ((fd = open(file, O_RDONLY)) < 0) {
vshError(ctl, FALSE, "cannot read %s", name);
goto cleanup;
}
st = virStreamNew(conn, 0);
if (virStorageVolRead(vol, st, offset, 0) < 0)
goto cleanup;
if (virStreamSendAll(st, cmdPutSource, &fd) < 0)
goto cleanup;
if (close(fd) < 0) {
virStreamAbort(st);
goto cleanup;
}
fd = -1;
if (virStreamFinish(st) < 0)
goto cleanup;
That way virt-manager can transfer any file it has locally, to a remote storage volume. virt-manager remains in control of downloading from the remote web server, making it easy todo progress feedback there.
There is a proof of concept impl of an API that is almost identical to this here
http://gitorious.org/~berrange/libvirt/staging/commits/data-streams-demo
How do we handle the case in which virt-manager is connected to a datacenter via a slow link, but the vm host and the remote webserver are connected by fast links? We can't solve every possible scenario. virt-manager is targetted to local LAN usage where communications links are reasonably fast. Users are free to deploy Cobbler if they want to maintain a cache of distros local to the datacenter. *** Bug 640974 has been marked as a duplicate of this bug. *** This is upstream for a while, and virt-install supports remote installs with URLs |
Libvirt support is required to enable remote VM installation from URLs. We need someway to tell libvirt to download a kernel/initrd. I figured an API like virStorageVolImport(virStoragePoolPtr pool, const char *uri, int flags) would be sufficient. This would also be useful for importing local files into a storage pool, which is something we could use in virt-manager.